+
+
+
+
+ TSF subsystem
+ TSF Module
+
+
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+
+
+
+
+
+ (informal
+ presentation)
+
+ architecture, high-level description of
+ SFR-Enf. behaviour, interactions
+ designation support
+ designation support means that
+ only documentation sufficient to support the
+ classification of the subsystem / module is
+ needed.
+
+ designation support
+
+
+
+
+
+
+ (informal
+ presentation)
+
+ architecture, detailed description of
+ SFR-Enf. behaviour, high-level description of other
+ behaviour interactions
+ architecture, high-level description of
+ behaviour, interactions
+ designation support, interactions
+
+
+
+
+
+
+
+ (informal
+ presentation)description,
+ interactionsdescription, interactions
+ description, interactions
+ common
+ data, interfaces
+ interfaces means that the module
+ description contains purpose, interfaces presented,
+ and interfaces used.,
+ algorithmicalgorithmic
+ means an algorithmic description of the entire
+ module is provided.
+
+ interaction, purpose
+ interaction, purpose
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+ common
+ data, interfaces, algorithmic
+ common
+ data, interfaces, algorithmic
+ interaction, purpose
+
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+ common
+ data, interfaces, algorithmic
+ common
+ data, interfaces, algorithmic
+ common
+ data, interfaces, algorithmic
+
+
+
+
+ (semiformal
+ presentation; additional formal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+ common
+ data, interfaces, algorithmic
+ common
+ data, interfaces, algorithmic
+ common
+ data, interfaces, algorithmic
+
+
+
+
+ Description Detail Levelling
+
+
+
+
+
+ Formal methods provide a mathematical representation of the
+ TSF and its behaviour and are required by the , , and
+ components. There are two aspects of formal methods: the
+ specification language that is used for
+ formal expression, and the theorem prover
+ that mathematically proves the completeness and correctness of
+ the formal specification.
+
+ A formal specification is expressed within a formal system
+ based upon well-established mathematical concepts. These
+ mathematical concepts are used to define well-defined
+ semantics, syntax and rules of inference. A formal system is
+ an abstract system of identities and relations that can be
+ described by specifying a formal alphabet, a formal language
+ over that alphabet which is based on a formal syntax, and a
+ set of formal rules of inference for constructing derivations
+ of sentences in the formal language.
+
+ The evaluator should examine the identified formal systems to
+ make sure that:
+
+ The semantics, syntax and inference rules of the
+ formal system are defined or a definition is
+ referenced.
+ Each formal system is accompanied by explanatory text
+ that provides defined semantics so that:
+
+ the explanatory text provides defined meanings of
+ terms, abbreviations and acronyms that are used in a
+ context other than that accepted by normal
+ usage,
+ the use of a formal system and semiformal notation
+ use is accompanied by supporting explanatory text in
+ informal style appropriate for unambiguous
+ meaning,
+ the formal system is able to express rules and
+ characteristics of applicable SFPs,
+ security functionality and interfaces (providing
+ details of effects, exceptions and error messages) of
+ TSF, their subsystems or modules to be specified for
+ the assurance family for which the notations are
+ used.
+ the notation provides rules to determine the
+ meaning of syntactical valid constructs.
+
+ Each formal system uses a formal syntax that provides
+ rules to unambiguously recognise constructs.
+ Each formal system provides proof rules which
+
+ support logical reasoning of well-established
+ mathematical concepts,
+ help to prevent derivation of
+ contradictions
+
+ If the developer uses a formal system which is already
+ accepted by the certification body the evaluator can rely on
+ the level of formality and strength of the system and focus on
+ the instantiation of the formal system to the TOE
+ specifications and correspondence proofs.
+
+ The formal style supports mathematical proofs of the security
+ properties based on the security features, the consistency of
+ refinements and the correspondence of the representations.
+ Formal tool support seems adequate whenever manual derivations
+ would otherwise become long winded and
+ incomprehensible. Formal tools are also apt to reduce the
+ error probability inherent in manual derivations.
+
+ Examples of formal systems:
+
+ The Z specification language is highly
+ expressive, and supports many different methods or styles
+ of formal specification. The use of Z has been
+ predominantly for model-oriented specification, using
+ schemes to formally specify
+ operations. See for more
+ information.
+ ACL2 is an open-source formal system
+ comprising a LISP-based specification language and a
+ theorem prover. See for
+ further information.
+ Isabelle is a popular generic theorem
+ proving environment that allows mathematical formulae to
+ be expressed in a formal language and provides tools for
+ proving those formulae within a logical calculus (see
+ e.g. for
+ additional information)
+ The B method is a formal system based
+ on the propositional calculus, the first order predicate
+ calculus with inference rules and set theory (see
+ e.g. for further
+ information).
+
+
+
+
+ The dependencies documented in the components of Clauses and - are the direct dependencies between the
+ assurance components.
+
+ The following dependency tables for assurance components show
+ their direct, indirect and optional dependencies. Each of the
+ components that is a dependency of some assurance component is
+ allocated a column. Each assurance component is allocated a
+ row. The value in the table cell indicate whether the column
+ label component is directly required (indicated by a cross
+ ``X'') or indirectly required (indicated by a dash ``-''), by
+ the row label component. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+ The purpose of this Clause is to document the philosophy that
+ underpins the CC approach to assurance. An understanding of this
+ Clause will permit the reader to understand the rationale behind
+ the CC Part 3 assurance requirements.
+
+
+ The CC philosophy is that the threats to security and
+ organisational security policy commitments should be clearly
+ articulated and the proposed security measures be demonstrably
+ sufficient for their intended purpose.
+
+ Furthermore, measures should be adopted that reduce the
+ likelihood of vulnerabilities, the ability to exercise
+ (i.e. intentionally exploit or unintentionally trigger) a
+ vulnerability, and the extent of the damage that could occur
+ from a vulnerability being exercised. Additionally, measures
+ should be adopted that facilitate the subsequent
+ identification of vulnerabilities and the elimination,
+ mitigation, and/or notification that a vulnerability has been
+ exploited or triggered.
+
+
+
+ The CC philosophy is to provide assurance based upon an
+ evaluation (active investigation) of the IT product that is to
+ be trusted. Evaluation has been the traditional means of
+ providing assurance and is the basis for prior evaluation
+ criteria documents. In aligning the existing approaches, the
+ CC adopts the same philosophy. The CC proposes measuring the
+ validity of the documentation and of the resulting IT product
+ by expert evaluators with increasing emphasis on scope, depth,
+ and rigour.
+
+ The CC does not exclude, nor does it comment upon, the
+ relative merits of other means of gaining assurance. Research
+ continues with respect to alternative ways of gaining
+ assurance. As mature alternative approaches emerge from these
+ research activities, they will be considered for inclusion in
+ the CC, which is so structured as to allow their future
+ introduction.
+
+
+ It is assumed that there are threat agents that will
+ actively seek to exploit opportunities to violate security
+ policies both for illicit gains and for well-intentioned,
+ but nonetheless insecure actions. Threat agents may also
+ accidentally trigger security vulnerabilities, causing harm
+ to the organisation. Due to the need to process sensitive
+ information and the lack of availability of sufficiently
+ trusted products, there is significant risk due to failures
+ of IT. It is, therefore, likely that IT security breaches
+ could lead to significant loss.
+
+ IT security breaches arise through the intentional
+ exploitation or the unintentional triggering of
+ vulnerabilities in the application of IT within business
+ concerns.
+
+ Steps should be taken to prevent vulnerabilities arising in
+ IT products. To the extent feasible, vulnerabilities should
+ be:
+
+
+ eliminated -- that is, active steps should be taken to
+ expose, and remove or neutralise, all exercisable
+ vulnerabilities;
+
+
+ minimised -- that is, active steps should be taken to
+ reduce, to an acceptable residual level, the potential
+ impact of any exercise of a vulnerability;
+
+
+ monitored -- that is, active steps should be taken to
+ ensure that any attempt to exercise a residual
+ vulnerability will be detected so that steps can be
+ taken to limit the damage.
+
+
+
+
+
+ Vulnerabilities can arise through failures in:
+
+
+ requirements -- that is, an IT product may possess all
+ the functions and features required of it and still
+ contain vulnerabilities that render it unsuitable or
+ ineffective with respect to security;
+
+
+ development -- that is, an IT product does not meet its
+ specifications and/or vulnerabilities have been
+ introduced as a result of poor development standards or
+ incorrect design choices;
+
+
+ operation -- that is, an IT product has been constructed
+ correctly to a correct specification but vulnerabilities
+ have been introduced as a result of inadequate controls
+ upon the operation.
+
+
+
+
+
+ Assurance is grounds for confidence that an IT product meets
+ its security objectives. Assurance can be derived from
+ reference to sources such as unsubstantiated assertions,
+ prior relevant experience, or specific experience. However,
+ the CC provides assurance through active
+ investigation. Active investigation is an evaluation of the
+ IT product in order to determine its security
+ properties.
+
+
+
+ Evaluation has been the traditional means of gaining
+ assurance, and is the basis of the CC approach. Evaluation
+ techniques can include, but are not limited to:
+
+
+ analysis and checking of process(es) and procedure(s);
+
+
+ checking that process(es) and procedure(s) are being
+ applied;
+
+
+ analysis of the correspondence between TOE design
+ representations;
+
+
+ analysis of the TOE design representation against the
+ requirements;
+
+
+ verification of proofs;
+
+
+ analysis of guidance documents;
+
+
+ analysis of functional tests developed and the results
+ provided;
+
+
+ independent functional testing;
+
+
+ analysis for vulnerabilities (including flaw
+ hypothesis);
+
+
+ penetration testing.
+
+
+
+
+
+
+ The CC philosophy asserts that greater assurance results from
+ the application of greater evaluation effort, and that the
+ goal is to apply the minimum effort required to provide the
+ necessary level of assurance. The increasing level of effort
+ is based upon:
+
+
+ scope -- that is, the effort is greater because a larger
+ portion of the IT product is included;
+
+
+ depth -- that is, the effort is greater because it is
+ deployed to a finer level of design and implementation
+ detail;
+
+
+ rigour -- that is, the effort is greater because it is
+ applied in a more structured, formal manner.
+
+
+
+
+
+
+ This annex provides an explanation of the criteria and examples of their application. This
+ annex does not define the criteria;
+ this definition can be found in CC Part 3 Section .
+
+ This annex consists of 2 major parts:
+
+
+ Guidance for completing an independent vulnerability
+ analysis. This is summarised in section , and described in more
+ detail in section
+ . These sections describe how an evaluator should approach
+ the construction of an independent Vulnerability Analysis.
+
+
+ How to characterise and use assumed Attack Potential of an
+ attacker. This is described in sections to . These sections provide an example of describe
+ how an attack potential can be characterised and should be
+ used, and provide examples.
+
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the existence and exploitability of flaws or
+ weaknesses in the TOE in the operational environment. This
+ determination is based upon analysis performed by the
+ evaluator, and is supported by evaluator testing.
+
+ At the lowest levels of the
+ evaluator simply performs a search of publicly available
+ information to identify any known weaknesses in the TOE, while
+ at the higher levels the evaluator performs a structured
+ analysis of the TOE evaluation evidence.
+
+ There are two main factors in performing a vulnerability
+ analysis, namely;
+
+
+ the identification of potential vulnerabilities;
+
+
+ penetration testing to determine whether the potential
+ vulnerabilities are exploitable in the operational
+ environment of the TOE.
+
+
+
+ The identification of vulnerabilities can be further
+ decomposed into the evidence to be searched and how hard to
+ search that evidence to identify potential vulnerabilities. In
+ a similar manner, the penetration testing can be further
+ decomposed into analysis of the potential vulnerability to
+ identify attack methods and the demonstration of the attack
+ methods.
+
+ These main factors are iterative in nature, i.e. penetration
+ testing of potential vulnerabilities may lead to the
+ identification of further potential vulnerabilities. Hence,
+ these are performed as a single vulnerability analysis
+ activity.
+
+
+
+ The evaluator vulnerability analysis is to determine that the
+ TOE is resistant to penetration attacks performed by an
+ attacker possessing a Basic (for and ),
+ Enhanced-Basic (for ),
+ Moderate (for ) or High (for
+ ) attack potential. The
+ evaluator first assesses the exploitability of all identified
+ potential vulnerabilities. This is accomplished by conducting
+ penetration testing. The evaluator should assume the role of
+ an attacker with a Basic (for
+ and ), Enhanced-Basic (for
+ ), Moderate (for ) or High (for ) attack potential when attempting to penetrate the
+ TOE.
+
+ The evaluator considers potential vulnerabilities encountered
+ by the evaluator during the conduct of other evaluation
+ activities. The evaluator penetration testing determining TOE
+ resistance to these potential vulnerabilities should be
+ performed assuming the role of an attacker with a Basic (for
+ and ), Enhanced-Basic (for ), Moderate (for )
+ or High (for ) attack
+ potential.
+
+ However, vulnerability analysis should not be performed as an
+ isolated activity. It is closely linked with and . The evaluator
+ performs these other evaluation activities with a focus on
+ identifying potential vulnerabilities or ``areas of
+ concern''. Therefore, evaluator familiarity with the generic
+ vulnerability guidance (provided in Section ) is required.
+
+
+ The following five categories provide discussion of generic
+ vulnerabilities.
+
+
+ Bypassing includes any means by which an attacker could
+ avoid security enforcement, by:
+
+
+ exploiting the capabilities of interfaces to the TOE,
+ or of utilities which can interact with the TOE;
+
+
+ inheriting privileges or other capabilities that
+ should otherwise be denied;
+
+
+ (where confidentiality is a concern) reading sensitive
+ data stored or copied to inadequately protected areas.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on exploiting the capabilities of
+ interfaces or utilities generally take advantage of
+ the absence of the required security enforcement on
+ those interfaces. For example, gaining access to
+ functionality that is implemented at a lower level
+ than that at which access control is
+ enforced. Relevant items include:
+
+
+ changing the predefined sequence of invocation of
+ TSFI;
+
+
+ invoking an additional TSFI;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using implementation detail introduced in less
+ abstract representations;
+
+
+ using the delay between time of access check and
+ time of use.
+
+
+
+
+ Changing the predefined sequence of invocation of
+ components should be considered where there is an
+ expected order in which interfaces to the TOE
+ (e.g. user commands) are called to invoke a TSFI
+ (e.g. opening a file for access and then reading data
+ from it). If a TSFI is invoked through one of the TOE
+ interfaces (e.g. an access control check), the
+ evaluator should consider whether it is possible to
+ bypass the control by performing the call at a later
+ point in the sequence or by missing it out altogether.
+
+
+ Executing an additional component (in the predefined
+ sequence) is a similar form of attack to the one
+ described above, but involves the calling of some
+ other TOE interface at some point in the sequence. It
+ can also involve attacks based on interception of
+ sensitive data passed over a network by use of network
+ traffic analysers (the additional component here being
+ the network traffic analyser).
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes using an unrelated TOE
+ interface to bypass the TSF by using it to achieve a
+ purpose that it was not designed or intended to
+ achieve. Covert channels are an example of this type
+ of attack (see for further discussion of covert
+ channels). The use of undocumented interfaces, which
+ may be insecure, also falls into this category. Such
+ interfaces may include undocumented support and help
+ facilities.
+
+
+ Using implementation detail introduced in lower
+ representations may allow an attacker to take
+ advantage of additional functions, resources or
+ attributes that are introduced to the TOE as a
+ consequence of the refinement process. Additional
+ functionality may include test harness code contained
+ in software modules and back-doors introduced during
+ the implementation process.
+
+
+ Using the delay between time of check and time of use
+ includes scenarios where an access control check is
+ made and access granted, and an attacker is
+ subsequently able to create conditions in which, had
+ they applied at the time the access check was made,
+ would have caused the check to fail. An example would
+ be a user creating a background process to read and
+ send highly sensitive data to the user's terminal, and
+ then logging out and logging back in again at a lower
+ sensitivity level. If the background process is not
+ terminated when the user logs off, the MAC checks
+ would have been effectively bypassed.
+
+
+ Attacks based on inheriting privileges are generally
+ based on illicitly acquiring the privileges or
+ capabilities of some privileged component, usually by
+ exiting from it in an uncontrolled or unexpected
+ manner. Relevant items include:
+
+
+ executing data not intended to be executable, or
+ making it executable;
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Executing data not intended to be executable, or
+ making it executable includes attacks involving
+ viruses (e.g. putting executable code or commands in a
+ file which are automatically executed when the file is
+ edited or accessed, thus inheriting any privileges the
+ owner of the file has).
+
+
+ Generating unexpected input for a component can have
+ unexpected effects which an attacker could take
+ advantage of. For example, if the TSF could be
+ bypassed if a user gains access to the underlying
+ operating system, it may be possible to gain such
+ access following the login sequence by exploring the
+ effect of hitting various control or escape sequences
+ whilst a password is being authenticated.
+
+
+ Invalidating assumptions and properties on which lower
+ level components rely includes attacks based on
+ breaking out of the constraints of an application to
+ gain access to an underlying operating system in order
+ to bypass the TSF of an application. In this case the
+ assumption being invalidated is that it is not
+ possible for a user of the application to gain such
+ access. A similar attack can be envisaged against an
+ application on an underlying database management
+ system: again the TSF could be bypassed if an attacker
+ can break out of the constraints of the application.
+
+
+ Attacks based on reading sensitive data stored in
+ inadequately protected areas (applicable where
+ confidentiality is a concern) include the following
+ issues which should be considered as possible means of
+ gaining access to sensitive data:
+
+
+ disk scavenging;
+
+
+ access to unprotected memory;
+
+
+ exploiting access to shared writable files or
+ other shared resources (e.g. swap files);
+
+
+ Activating error recovery to determine what access
+ users can obtain. For example, after a crash an
+ automatic file recovery system may employ a lost
+ and found directory for headerless files, which
+ are on disk without labels. If the TOE implements
+ mandatory access controls, it is important to
+ investigate at what security level this directory
+ is kept (e.g. at system high), and who has access
+ to this directory.
+
+
+
+
+
+ There are a number of different methods through which an
+ evaluator may identify a back-door, including two main
+ techniques. Firstly, by the evaluator inadvertently
+ identifying during testing an interface that can be
+ misused. Secondly, through testing each external
+ interface of the TSF in a debugging mode to identify any
+ modules that are not called as a part of testing the
+ documented interfaces and then inspecting the code that is
+ not called to consider whether it is a back-door.
+
+ For a software TOE where and or
+ higher components are included in the assurance package,
+ the evaluator may consider during their analysis of the
+ tools the libraries and packages that are linked by the
+ compiler at compilation stage to determine that back-doors
+ are not introduced at this stage.
+
+
+
+ Tampering includes any attack based on an attacker
+ attempting to influence the behaviour of the TSF
+ (i.e. corruption or de-activation), for example by:
+
+
+ accessing data on whose confidentiality or integrity
+ the TSF relies;
+
+
+ forcing the TOE to cope with unusual or unexpected
+ circumstances;
+
+
+ disabling or delaying security enforcement;
+
+
+ physical modification the TOE.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on accessing data, whose confidentiality
+ or integrity are protected, include:
+
+
+ reading, writing or modifying internal data
+ directly or indirectly;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using interfaces between components that are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Reading, writing or modifying internal data directly
+ or indirectly includes the following types of attack
+ which should be considered:
+
+
+ reading ``secrets'' stored internally, such as
+ user passwords;
+
+
+ spoofing internal data that security enforcing
+ mechanisms rely upon;
+
+
+ modifying environment variables (e.g. logical
+ names), or data in configuration files or
+ temporary files.
+
+
+
+ It may be possible to deceive a trusted process into
+ modifying a protected file that it wouldn't normally
+ access.
+
+
+ The evaluator should also consider the following
+ ``dangerous features'':
+
+
+ source code resident on the TOE along with a
+ compiler (for instance, it may be possible to
+ modify the login source code);
+
+
+ an interactive debugger and patch facility (for
+ instance, it may be possible to modify the
+ executable image);
+
+
+ the possibility of making changes at device
+ controller level, where file protection does not
+ exist;
+
+
+ diagnostic code which exists in the source code
+ and that may be optionally included;
+
+
+ developer's tools left in the TOE.
+
+
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes (for example), where the
+ TOE is an application built upon an operating system,
+ users exploiting knowledge of a word processor package
+ or other editor to modify their own command file
+ (e.g. to acquire greater privileges).
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction includes
+ attacks exploiting shared access to resources, where
+ modification of a resource by one component can
+ influence the behaviour of another (trusted)
+ component, e.g. at source code level, through the use
+ of global data or indirect mechanisms such as shared
+ memory or semaphores.
+
+
+ Attacks based on forcing the TOE to cope with unusual
+ or unexpected circumstances should always be
+ considered. Relevant items include:
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Generating unexpected input for a component includes
+ investigating the behaviour of the TOE when:
+
+
+ command input buffers overflow (possibly
+ ``crashing the stack'' or overwriting other
+ storage, which an attacker may be able to take
+ advantage of, or forcing a crash dump that may
+ contain sensitive information such as clear-text
+ passwords);
+
+
+ invalid commands or parameters are entered
+ (including supplying a read-only parameter to an
+ interface which expects to return data via that
+ parameter and supplying improperly formatted input
+ that should fail parsing such as SQL-injection,
+ format strings);
+
+
+ an end-of-file marker (e.g. CTRL-Z or CTRL-D) or
+ null character is inserted in an audit trail.
+
+
+
+
+ Invalidating assumptions and properties on which
+ lower-level components rely includes attacks taking
+ advantage of errors in the source code where the code
+ assumes (explicitly or implicitly) that security
+ relevant data is in a particular format or has a
+ particular range of values. In these cases the
+ evaluator should determine whether they can invalidate
+ such assumptions by causing the data to be in a
+ different format or to have different values, and if
+ so whether this could confer advantage to an attacker.
+
+
+ The correct behaviour of the TSF may be dependent on
+ assumptions that are invalidated under extreme
+ circumstances where resource limits are reached or
+ parameters reach their maximum value. The evaluator
+ should consider (where practical) the behaviour of the
+ TOE when these limits are reached, for example:
+
+
+ changing dates (e.g. examining how the TOE behaves
+ when a critical date threshold is passed);
+
+
+ filling disks;
+
+
+ exceeding the maximum number of users;
+
+
+ filling the audit log;
+
+
+ saturating security alarm queues at a console;
+
+
+ overloading various parts of a multi-user TOE
+ which relies heavily upon communications
+ components;
+
+
+ swamping a network, or individual hosts, with
+ traffic;
+
+
+ filling buffers or fields.
+
+
+
+
+ Attacks based on disabling or delaying security
+ enforcement include the following items:
+
+
+ using interrupts or scheduling functions to
+ disrupt sequencing;
+
+
+ disrupting concurrence;
+
+
+ using interfaces between components which are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Using interrupts or scheduling functions to disrupt
+ sequencing includes investigating the behaviour of the
+ TOE when:
+
+
+ a command is interrupted (with CTRL-C, CTRL-Y,
+ etc.);
+
+
+ a second interrupt is issued before the first is
+ acknowledged.
+
+
+
+
+ The effects of terminating security critical processes
+ (e.g. an audit daemon) should be explored. Similarly,
+ it may be possible to delay the logging of audit
+ records or the issuing or receipt of alarms such that
+ it is of no use to an administrator (since the attack
+ may already have succeeded).
+
+
+ Disrupting concurrence includes investigating the
+ behaviour of the TOE when two or more subjects attempt
+ simultaneous access. It may be that the TOE can cope
+ with the interlocking required when two subjects
+ attempt simultaneous access, but that the behaviour
+ becomes less well defined in the presence of further
+ subjects. For example, a critical security process
+ could be put into a resource-wait state if two other
+ processes are accessing a resource which it requires.
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction may provide a
+ means of delaying a time-critical trusted process.
+
+
+ Physical attacks can be categorised into physical
+ probing, physical manipulation, physical modification,
+ and substitution.
+
+
+ Physical probing by penetrating the TOE targeting
+ internals of the TOE, e.g. reading at internal
+ communication interfaces, lines or memories.
+
+
+ Physical manipulation can be with the TOE
+ internals aiming at internal modifications of the
+ TOE (e.g. by using optical fault induction as an
+ interaction process), at the external interfaces
+ of the TOE (e.g. by power or clock glitches) and
+ at the TOE environment (e.g. by modifying
+ temperature).
+
+
+ Physical modification of TOE internal security
+ enforcing attributes to inherit privileges or
+ other capabilities that should be denied in
+ regular operation. Such modifications can be
+ caused, e.g., by optical fault induction. Attacks
+ based on physical modification may also yield a
+ modification of the TSF itself, e.g. by causing
+ faults at TOE internal program data transfers
+ before execution. Note, that such kind of
+ bypassing by modifying the TSF itself can
+ jeopardise every TSF unless there are other
+ measures (possibly environmental measures) that
+ prevent an attacker from gaining physical access
+ to the TOE.
+
+
+ Physical substitution to replace the TOE with
+ another IT entity, during delivery or operation of
+ the TOE. Substitution during delivery of the TOE
+ from the development environment to the user
+ should be prevented through application of secure
+ delivery procedures (such as those considered
+ under ). Substitution of the TOE during
+ operation may be considered through a combination
+ of user guidance and the operational environment,
+ such that the user is able to be confident that
+ they are interacting with the TOE.
+
+
+
+
+
+
+
+ Direct attack includes the identification of any
+ penetration tests necessary to test the strength of
+ permutational or probabilistic mechanism and other
+ mechanisms to ensure they withstand direct attack.
+
+ For example, it may be a flawed assumption that a
+ particular implementation of a pseudo-random number
+ generator will possess the required entropy necessary to
+ seed the security mechanism.
+
+ Where a probabilistic or permutational mechanism relies on
+ selection of security attribute value (e.g. selection of
+ password length) or entry of data by a human user
+ (e.g. choice of password), the assumptions made should
+ reflect the worst case.
+
+ Probabilistic or permutational mechanisms should be
+ identified during examination of evaluation evidence
+ required as input to this sub-activity (security target,
+ functional specification, TOE design and implementation
+ representation subset) and any other TOE (e.g. guidance)
+ documentation may identify additional probabilistic or
+ permutational mechanisms.
+
+ Where the design evidence or guidance includes assertions
+ or assumptions (e.g. about how many authentication
+ attempts are possible per minute), the evaluator should
+ independently confirm that these are correct. This may be
+ achieved through testing or through independent
+ analysis.
+
+ Direct attacks reliant upon a weakness in a cryptographic
+ algorithm should not be considered under , as this is outside the scope
+ of the CC. Correctness of the implementation of the
+ cryptographic algorithm is considered during the and
+ activities.
+
+
+
+ Information is an abstract view on relation between the
+ properties of entities, i.e. a signal contains information
+ for a system, if the TOE is able to react to this
+ signal. The TOE resources processes and stores information
+ represented by user data. Therefore:
+
+
+ information may flow with the user data between
+ subjects by internal TOE transfer or export from the TOE;
+
+
+ information may be generated and passed to other user
+ data;
+
+
+ information may be gained through monitoring the
+ operations on data representing the information.
+
+
+
+ The information represented by user data may be
+ characterised by security attributes like ``classification
+ level'' having values, for example unclassified,
+ confidential, secret, top secret, to control operations to
+ the data. This information and therefore the security
+ attributes may be changed by operations e.g. may describe decrease of the
+ level by ``sanitarisation'' or increase of level by
+ combination of data. This is one aspects of an information
+ flow analysis focused on controlled operations of
+ controlled subjects on controlled objects.
+
+ The other aspect is the analysis of illicit
+ information flow. This aspect is more
+ general than the direct access to objects containing user
+ data addressed by the
+ family. An unenforced
+ signalling channel carrying information under control of
+ the information flow control policy can also be caused by
+ monitoring of the processing of any object containing or
+ related to this information (e.g. side channels). An
+ enforced signalling channels
+ may be identified in terms of the subjects manipulating
+ resources and the subject or user that observe such
+ manipulation. Classically, covert channels have been
+ identified as timing or storage channels, according to the
+ resource being modified or modulated. As for other
+ monitoring attacks, the use of the TOE is in accordance
+ with the SFRs.
+
+ Covert channels are normally applicable in the case when
+ the TOE has unobservability AND multi-level separation
+ policy requirements. Covert channels may be routinely
+ spotted during vulnerability analysis and design
+ activities, and should therefore be tested. However,
+ generally such monitoring attacks are only identified
+ through specialised analysis techniques commonly referred
+ to as ``covert channel analysis''. These techniques have
+ been the subject of much research and there are many
+ papers published on this subject. Guidance for the
+ conduct of covert channel analysis should be sought from
+ the evaluation authority.
+
+ Unenforced information flow monitoring
+ attacks include passive analysis techniques aiming at
+ disclosure of sensitive internal data of the TOE by
+ operating the TOE in the way that corresponds to the
+ guidance documents.
+
+ Side Channel Analysis includes crypt analytical techniques
+ based on physical leakage of the TOE. Physical leakage can
+ occur by timing information, power consumption or power
+ emanation during computation of a TSF. Timing information
+ can be collected also by a remote-attacker (having network
+ access to the TOE), power based information channels
+ requires that the attacker is in the near-by environment
+ of the TOE.
+
+ Eavesdropping techniques include interception of all forms
+ of energy, e.g., electromagnetic or optical emanation of
+ computer displays, not necessarily in the near-field of
+ the TOE.
+
+ Monitoring also includes exploits of protocol flaws, e.g.,
+ an attack on SSL implementation.
+
+
+
+ Misuse may arise from:
+
+
+ incomplete guidance documentation;
+
+
+ unreasonable guidance;
+
+
+ unintended misconfiguration of the TOE;
+
+
+ forced exception behaviour of the TOE.
+
+
+
+ If the guidance documentation is incomplete the user may
+ not know how to operate the TOE in accordance with the
+ SFRs. The evaluator should apply familiarity with the TOE
+ gained from performing other evaluation activities to
+ determine that the guidance is complete. In particular,
+ the evaluator should consider the functional
+ specification. The TSF described in this document should
+ be described in the guidance as required to permit secure
+ administration and use through the TSFI available to human
+ users. In addition, the different modes of operation
+ should be considered to ensure that guidance is provided
+ for all modes of operation.
+
+ The evaluator may, as an aid, prepare an informal mapping
+ between the guidance and these documents. Any omissions in
+ this mapping may indicate incompleteness.
+
+ The guidance is considered to be unreasonable if it makes
+ demands on the TOE's usage or operational environment that
+ are inconsistent with the ST or unduly onerous to maintain
+ security.
+
+ A TOE may use a variety of ways to assist the consumer in
+ effectively using that TOE in accordance with the SFRs and
+ prevent unintentional misconfiguration. A TOE may employ
+ functionality (features) to alert the consumer when the
+ TOE is in a state that is inconsistent with the SFRs,
+ whilst other TOEs may be delivered with enhanced guidance
+ containing suggestions, hints, procedures, etc. on using
+ the existing security features most effectively; for
+ instance, guidance on using the audit feature as an aid
+ for detecting when the SFRs are being compromised; namely
+ insecure.
+
+ The evaluator considers the TOE's functionality, its
+ purpose and security objectives for the operational
+ environment to arrive at a conclusion of whether or not
+ there is reasonable expectation that use of the guidance
+ would permit transition into an insecure state to be
+ detected in a timely manner.
+
+ The potential for the TOE to enter into insecure states
+ may be determined using the evaluation deliverables, such
+ as the ST, the functional specification and any other
+ design representations provided as evidence for components
+ included in the assurance package for the TOE (e.g. the
+ TOE/TSF design specification if a component from is included).
+
+ Instances of forced exception behaviour of the TSF could
+ include, but are not limited to, the following:
+
+
+ behaviour of the TOE when start-up, close-down or error
+ recovery is activated;
+
+
+ behaviour of the TOE under extreme circumstances
+ (sometimes termed overload or asymptotic behaviour),
+ particularly where this could lead to the
+ de-activation or disabling of parts of the TSF;
+
+
+ any potential for unintentional misconfiguration or
+ insecure use arising from attacks noted in the section
+ on tampering above.
+
+
+
+
+
+
+ Potential vulnerabilities may be identified by the evaluator
+ during different activities. They may become apparent during
+ an evaluation activity or they may be identified as a result
+ of analysis of evidence to search for
+ vulnerabilities.
+
+
+ The encountered identification of vulnerabilities is where
+ potential vulnerabilities are identified by the evaluator
+ during the conduct of evaluation activities, i.e. the
+ evidence are not being analysed with the express aim of
+ identifying potential vulnerabilities.
+
+ The encountered method of identification is dependent on
+ the evaluator's experience and knowledge; which is
+ monitored and controlled by the Certification
+ Authority. It is not reproducible in approach, but will be
+ documented to ensure repeatability of the conclusions from
+ the reported potential vulnerabilities.
+
+ There are no formal analysis criteria required for this
+ method. Potential vulnerabilities are identified from the
+ evidence provided as a result of knowledge and
+ experience. However, this method of identification is not
+ constrained to any particular subset of evidence.
+
+ Evaluator is assumed to have knowledge of the TOE-type
+ technology and known security flaws as documented in the
+ public domain. The level of knowledge assumed is that
+ which can be gained from a security e-mail list relevant
+ to the TOE type, the regular bulletins (bug, vulnerability
+ and security flaw lists) published by those organisations
+ researching security issues in products and technologies
+ in widespread use. This knowledge is not expected to
+ extend to specific conference proceedings or detailed
+ theses produced by university research for or . However, to ensure the knowledge applied is
+ up to date, the evaluator may need to perform a search of
+ public domain material.
+
+ For to the search of publicly
+ available information is expected to include conference
+ proceeding and theses produced during research activities
+ by universities and other relevant organisations.
+
+ Examples of how these may arise (how the evaluator may
+ encounter potential vulnerabilities):
+
+
+ while the evaluator is examining some evidence, it
+ sparks a memory of a potential vulnerability
+ identified in a similar product type, that the
+ evaluator believes to also be present in the TOE under
+ evaluation;
+
+
+ while examining some evidence, the evaluator spots a
+ flaw in the specification of an interface, that
+ reflects a potential vulnerability.
+
+
+ This may include becoming aware of a potential
+ vulnerability in a TOE through reading about generic
+ vulnerabilities in a particular product type in an IT
+ security publication or on a security e-mail list to which
+ the evaluator is subscribed.
+
+ Attack methods can be developed directly from these
+ potential vulnerabilities. Therefore, the encountered
+ potential vulnerabilities are collated at the time of
+ producing penetration tests based on the evaluator's
+ vulnerability analysis. There is no explicit action for
+ the evaluator to encounter potential
+ vulnerabilities. Therefore, the evaluator is directed
+ through an implicit action specified in and .*.4E.
+
+ Current information regarding public domain
+ vulnerabilities and attacks may be provided to the
+ evaluator by, for example, an evaluation authority. This
+ information is to be taken into account by the evaluator
+ when collating encountered vulnerabilities and attack
+ methods when developing penetration tests.
+
+
+
+ The following types of analysis are presented in terms of
+ the evaluator actions.
+
+
+ The unstructured analysis to be performed by the
+ evaluator (for )
+ permits the evaluator to consider the generic
+ vulnerabilities (as discussed in ). The evaluator will also apply their
+ experience and knowledge of flaws in similar technology
+ types.
+
+
+
+ During the conduct of evaluation activities the
+ evaluator may also identify areas of concern. These are
+ specific portions of the TOE evidence that the evaluator
+ has some reservation about, although the evidence meets
+ the requirements for the activity with which the
+ evidence is associated. For example, a particular
+ interface specification looks particularly complex, and
+ therefore may be prone to error either in the
+ development of the TOE or in the operation of the
+ TOE. There is no potential vulnerability apparent at
+ this stage, further investigation is required. This is
+ beyond the bounds of encountered, as further
+ investigation is required.
+
+ Difference between potential vulnerability and area of
+ concern:
+
+
+ Potential vulnerability - The evaluator knows a
+ method of attack that can be used to exploit the
+ weakness or the evaluator knows of vulnerability
+ information that is relevant to the TOE.
+
+
+ Area of concern - The evaluator may be able to
+ discount concern as a potential vulnerability based
+ on information provided elsewhere. While reading
+ interface specification, the evaluator identifies
+ that due to the extreme (unnecessary) complexity of
+ an interface a potential vulnerability may lay
+ within that area, although it is not apparent
+ through this initial examination.
+
+
+ The focused approach to the identification of
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. This
+ approach to the identification of potential
+ vulnerabilities can be used during the independent
+ vulnerability analysis required by .
+
+ This analysis can be achieved through different
+ approaches, that will lead to commensurate levels of
+ confidence. None of the approaches have a rigid format
+ for the examination of evidence to be performed.
+
+ The approach taken is directed by the results of the
+ evaluator's assessment of the evidence to determine it
+ meets the requirements of the /
+ sub-activities. Therefore, the investigation of the
+ evidence for the existence of potential vulnerabilities
+ may be directed by any of the following:
+
+
+ areas of concern identified during examination of
+ the evidence during the conduct of evaluation
+ activities;
+
+
+ reliance on particular functionality to provide
+ separation, identified during the analysis of the
+ architectural design (as in ), requiring further analysis to
+ determine it cannot be bypassed;
+
+
+ representative examination of the evidence to
+ hypothesise potential vulnerabilities in the
+ TOE.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, the evaluator may not be able to
+ describe the steps in identifying potential
+ vulnerabilities before the outset of the
+ examination. The approach will evolve as a result of the
+ outcome of evaluation activities.
+
+ The areas of concern may arise from examination of any
+ of the evidence provided to satisfy the SARs specified
+ for the TOE evaluation. The information publicly
+ accessible is also considered.
+
+ The activities performed by the evaluator can be
+ repeated and the same conclusions, in terms of the level
+ of assurance in the TOE, can be reached although the
+ steps taken to achieve those conclusions may vary. As
+ the evaluator is documenting the form the analysis took,
+ the actual steps taken to achieve those conclusions are
+ also reproducible.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the
+ focused identification method). The method is specified
+ in terms of the information that will be considered and
+ how/why it will be considered. This approach to the
+ identification of potential vulnerabilities can be used
+ during the independent vulnerability analysis required
+ by and .
+
+ This analysis of the evidence is deliberate and
+ pre-planned in approach, considering all evidence
+ identified as an input into the analysis.
+
+ All evidence provided to satisfy the () assurance requirements specified in the
+ assurance package are used as input to the potential
+ vulnerability identification activity.
+
+ The ``methodical'' descriptor for this analysis has been
+ used in an attempt to capture the characterisation that
+ this identification of potential vulnerabilities is to
+ take an ordered and planned approach. A ``method'' or
+ ``system'' is to be applied in the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered; and the
+ hypothesis that is to be generated.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a security mechanism, such as domain
+ separation, hypothesising internal buffer overflows
+ leading to degradation of separation;
+
+
+ analysis to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine the SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the analysis that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be analysed to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ This identification method will provide a plan of attack
+ of the TOE, that would be performed by an evaluator
+ completing penetration testing of potential
+ vulnerabilities in the TOE. The rationale for the method
+ of identification would provide the evidence for the
+ coverage and depth of exploitation determination that
+ would be performed on the TOE.
+
+
+
+
+
+
+
+ Attack potential is used by a PP/ST author during the
+ development of the PP/ST, in consideration of the threat
+ environment and the selection of assurance components. This
+ may simply be a determination that the attack potential
+ possessed by the assumed attackers of the TOE is generically
+ characterised as Basic, Enhanced-Basic, Moderate or
+ High. Alternatively, the PP/ST may wish to specify
+ particular levels of individual factors assumed to be
+ possessed by attackers. (e.g. the attackers are assumed to
+ be experts in the TOE technology type, with access to
+ specialised equipment.)
+
+ The PP/ST author considers the threat profile developed
+ during a risk assessment (outside the scope of the CC, but
+ used as an input into the development of the PP/ST in terms
+ of the Security Problem Definition or in the case of low
+ assurance STs, the objectives statement). Consideration of
+ this threat profile in terms of one of the approaches
+ discussed in the following sections will permit the
+ specification of the attack potential the TOE is to
+ resist.
+
+
+
+ Attack potential is especially considered by the evaluator
+ in two distinct ways during the ST evaluation and the
+ vulnerability assessment activities.
+
+ Attack potential is used by an evaluator during the conduct
+ of the vulnerability analysis sub-activity to determine
+ whether or not the TOE is resistant to attacks assuming a
+ specific attack potential of an attacker. If the evaluator
+ determines that a potential vulnerability is exploitable in
+ the TOE, they have to confirm that it is exploitable
+ considering all aspects of the intended environment,
+ including the attack potential assumed by an
+ attacker.
+
+ Therefore, using the information provided in the threat
+ statement of the Security Target, the evaluator determines
+ the minimum attack potential required by an attacker to
+ effect an attack, and arrives at some conclusion about the
+ TOE's resistance to attacks. Table demonstrates the relationship between this
+ analysis and attack potential.
+
+
+
+
+ Vulnerability Component
+ TOE resistant to attacker with
+ attack potential of:
+ Residual vulnerabilities only
+ exploitable by attacker with attack potential
+ of:
+
+
+
+
+ VAN.5
+ High
+ Beyond High
+
+
+ VAN.4
+ Moderate
+ High
+
+
+ VAN.3
+ Enhanced-Basic
+ Moderate
+
+
+ VAN.2
+ Basic
+ Enhanced-Basic
+
+
+ VAN.1
+ Basic
+ Enhanced-Basic
+
+
+
+ Vulnerability testing and attack potential
+
+
+ The ``beyond high'' entry in the residual vulnerabilities
+ column of the above table represents those potential
+ vulnerabilities that would require an attacker to have an
+ attack potential greater than that of ``high'' in order to
+ exploit the potential vulnerability. A vulnerability
+ classified as residual in this instance reflects the fact
+ that a known weakness exists in the TOE, but in the current
+ operational environment, with the assumed attack potential,
+ the weakness cannot be exploited.
+
+ At any level of attack potential a potential vulnerability
+ may be deemed ``infeasible'' due to a countermeasure in the
+ operational environment that prevents the vulnerability from
+ being exploited.
+
+ A vulnerability analysis applies to all TSFI, including ones
+ that access probabilistic or permutational mechanisms. No
+ assumptions are made regarding the correctness of the design
+ and implementation of the TSFI; nor are constraints placed
+ on the attack method or the attacker's interaction with the
+ TOE - if an attack is possible, then it is to be considered
+ during the vulnerability analysis. As shown in Table , successful evaluation
+ against a vulnerability assurance component reflects that
+ the TSF is designed and implemented to protect against the
+ required level of threat.
+
+ It is not necessary for an evaluator to perform an attack
+ potential calculation for each potential vulnerability. In
+ some cases it is apparent when developing the attack method
+ whether or not the attack potential required to develop and
+ run the attack method is commensurate with that assumed of
+ the attacker in the operational environment. For any
+ vulnerabilities for which an exploitation is determined, the
+ evaluator performs an attack potential calculation to
+ determine that the exploitation is appropriate to the level
+ of attack potential assumed for the attacker.
+
+ The approach described below is to
+ be applied whenever it is necessary to calculate attack
+ potential, unless the evaluation authority provides
+ mandatory guidance that an alternative approach is to be
+ applied. The values given in Tables and below are
+ not mathematically proven. Therefore, the values given in
+ these example tables may need to be adjusted according to
+ the technology type and specific environments. Guidance
+ from the evaluation authority should be sought.
+
+
+
+
+
+ Attack potential is a function of expertise, resources and
+ motivation. There are multiple methods of representing and
+ quantifying these factors. Also, there may be other factors
+ that are applicable for particular TOE types.
+
+
+ Motivation is an attack potential factor that can be used
+ to describe several aspects related to the attacker and
+ the assets the attacker desires. Firstly, motivation can
+ imply the likelihood of an attack - one can infer from a
+ threat described as highly motivated that an attack is
+ imminent, or that no attack is anticipated from an
+ un-motivated threat. However, except for the two extreme
+ levels of motivation, it is difficult to derive a
+ probability of an attack occurring from motivation.
+
+ Secondly, motivation can imply the value of the asset,
+ monetarily or otherwise, to either the attacker or the
+ asset holder. An asset of very high value is more likely
+ to motivate an attack compared to an asset of little
+ value. However, other than in a very general way, it is
+ difficult to relate asset value to motivation because the
+ value of an asset is subjective - it depends largely upon
+ the value an asset holder places on it.
+
+ Thirdly, motivation can imply the expertise and resources
+ with which an attacker is willing to effect an attack. One
+ can infer that a highly motivated attacker is likely to
+ acquire sufficient expertise and resources to defeat the
+ measures protecting an asset. Conversely, one can infer
+ that an attacker with significant expertise and resources
+ is not willing to effect an attack using them if the
+ attacker's motivation is low.
+
+ During the course of preparing for and conducting an
+ evaluation, all three aspects of motivation are at some
+ point considered. The first aspect, likelihood of attack,
+ is what may inspire a developer to pursue an
+ evaluation. If the developer believes that the attackers
+ are sufficiently motivated to mount an attack, then an
+ evaluation can provide assurance of the ability of the TOE
+ to thwart the attacker's efforts. Where the operational
+ environment is well defined, for example in a system
+ evaluation, the level of motivation for an attack may be
+ known, and will influence the selection of
+ countermeasures.
+
+ Considering the second aspect, an asset holder may believe
+ that the value of the assets (however measured) is
+ sufficient to motivate attack against them. Once an
+ evaluation is deemed necessary, the attacker's motivation
+ is considered to determine the methods of attack that may
+ be attempted, as well as the expertise and resources used
+ in those attacks. Once examined, the developer is able to
+ choose the appropriate assurance level, in particular the
+ requirement components,
+ commensurate with the attack potential for the
+ threats. During the course of the evaluation, and in
+ particular as a result of completing the vulnerability
+ assessment activity, the evaluator determines whether or
+ not the TOE, operating in its operational environment, is
+ sufficient to thwart attackers with the identified
+ expertise and resources.
+
+ It may be possible for a PP author to quantify the
+ motivation of an attacker, as the PP author has greater
+ knowledge of the operational environment in which the TOE
+ (conforming to the requirements of the PP) is to be
+ placed. Therefore, the motivation could form an explicit
+ part of the expression of the attack potential in the PP,
+ along with the necessary methods and measures to quantify
+ the motivation.
+
+
+
+
+ This section examines the factors that determine attack
+ potential, and provides some guidelines to help remove some
+ of the subjectivity from this aspect of the evaluation
+ process.
+
+
+ The determination of the attack potential for an attack
+ corresponds to the identification of the effort required
+ to create the attack, and to demonstrate that it can be
+ successfully applied to the TOE (including setting up or
+ building any necessary test equipment), thereby exploiting
+ the vulnerability in the TOE. The demonstration that the
+ attack can be successfully applied needs to consider any
+ difficulties in expanding a result shown in the laboratory
+ to create a useful attack. For example, where an
+ experiment reveals some bits or bytes of a confidential
+ data item (such as a key), it is necessary to consider how
+ the remainder of the data item would be obtained (in this
+ example some bits might be measured directly by further
+ experiments, while others might be found by a different
+ technique such as exhaustive search). It may not be
+ necessary to carry out all of the experiments to identify
+ the full attack, provided it is clear that the attack
+ actually proves that access has been gained to a TOE
+ asset, and that the complete attack could realistically be
+ carried out in exploitation according to the component targeted. In some cases
+ the only way to prove that an attack can realistically be
+ carried out in exploitation according to the component targeted is to perform
+ completely the attack and this shall be rated. One of the
+ outputs from the identification of a potential
+ vulnerability is assumed to be a script that gives a
+ step-by-step description of how to carry out the attack
+ that can be used in the exploitation of the vulnerability
+ on another instance of the TOE.
+
+ In many cases, the evaluators will estimate the parameters
+ for exploitation, rather than carry out the full
+ exploitation. The estimates and their rationale will be
+ documented in the ETR.
+
+
+
+ The following factors should be considered during analysis
+ of the attack potential required to exploit a
+ vulnerability:
+
+
+ Time taken to identify and exploit (
+ Elapsed Time);
+
+
+ Specialist technical expertise required (
+ Specialist Expertise);
+
+
+ Knowledge of the TOE design and operation (
+ Knowledge of the TOE);
+
+
+
+ Window of opportunity;
+
+
+
+ IT hardware/software or other
+ equipment required for
+ exploitation.
+
+
+
+ In many cases these factors are not independent, but may
+ be substituted for each other in varying degrees. For
+ example, expertise or hardware/software may be a
+ substitute for time. A discussion of these factors
+ follows. (The levels of each factor are discussed in
+ increasing order of magnitude.) When it is the case, the
+ less ``expensive'' combination shall be considered in
+ exploitation phase.
+
+ Elapsed time is the total
+ amount of time taken by an attacker to identify that a
+ particular potential vulnerability may exist in the TOE,
+ to develop an attack method and to sustain effort required
+ to mount the attack against the TOE. When considering this
+ factor, the worst case scenario should be used to estimate
+ the amount of time required. The identified amount of time
+ is as follows:
+
+ less than one day;
+ between one day and one week;
+ between one week and two weeks;
+ between two weeks and one month;
+ each additional month up to 6 months leads to an
+ increased value;
+ more than 6 months.
+
+ Specialist expertise refers
+ to the level of generic knowledge of the underlying
+ principles, product type or attack methods (e.g. Internet
+ protocols, Unix operating systems, buffer overflows). The
+ identified levels are as follows:
+
+
+ Laymen are unknowledgeable compared to experts or
+ proficient persons, with no particular expertise;
+
+
+ Proficient persons are knowledgeable in that they are
+ familiar with the security behaviour of the product or
+ system type;
+
+
+ Experts are familiar with the underlying algorithms,
+ protocols, hardware, structures, security behaviour,
+ principles and concepts of security employed,
+ techniques and tools for the definition of new
+ attacks, cryptography, classical attacks for the
+ product type, attack methods, etc. implemented in the
+ product or system type.
+
+
+ The level ``Multiple Expert'' is introduced to allow for
+ a situation, where different fields of expertise are
+ required at an Expert level for distinct steps of an
+ attack.
+
+ It may occur that several types of expertise are
+ required. By default, the higher of the different
+ expertises factors is chosen. In very specific cases, the
+ ``multiple expert'' level could be used but it should be
+ noted that the expertise must concern fields that are
+ strictly different like for example HW manipulation and
+ cryptography.
+
+
+ Knowledge of the TOE refers to
+ specific expertise in relation to the TOE. This is
+ distinct from generic expertise, but not unrelated to
+ it. Identified levels are as follows:
+
+
+ Public information concerning the TOE (e.g. as gained
+ from the Internet);
+
+
+ Restricted information concerning the TOE
+ (e.g. knowledge that is controlled within the
+ developer organisation and shared with other
+ organisations under a non-disclosure agreement)
+
+
+ Sensitive information about the TOE (e.g. knowledge
+ that is shared between discreet teams within the
+ developer organisation, access to which is constrained
+ only to members of the specified teams);
+
+
+ Critical information about the TOE (e.g. knowledge
+ that is known by only a few individuals, access to
+ which is very tightly controlled on a strict need to
+ know basis and individual undertaking).
+
+
+
+ The knowledge of the TOE may graduate according to design
+ abstraction, although this can only be done on a TOE by
+ TOE basis. Some TOE designs may be public source (or
+ heavily based on public source) and therefore even the
+ design representation would be classified as public or at
+ most restricted, while the implementation representation
+ for other TOEs is very closely controlled as it would give
+ an attacker information that would aid an attack and is
+ therefore considered to be sensitive or even
+ critical.
+
+ It may occur that several types of knowledge are
+ required. In such cases, the higher of the different
+ knowledge factors is chosen.
+
+
+ Window of opportunity
+
+ (Opportunity) is also an important consideration, and has
+ a relationship to the Elapsed Time
+ factor. Identification or exploitation of a
+ vulnerability may require considerable amounts of access
+ to a TOE that may increase the likelihood of
+ detection. Some attack methods may require considerable
+ effort off-line, and only brief access to the TOE to
+ exploit. Access may also need to be continuous, or over a
+ number of sessions.
+
+ For some TOEs the Window of
+ opportunity may equate to the number of
+ samples of the TOE that the attacker can obtain. This is
+ particularly relevant where attempts to penetrate the
+ TOE and undermine the SFRs may result in the destruction
+ of the TOE preventing use of that TOE sample for further
+ testing, e.g. hardware devices. Often in these cases
+ distribution of the TOE is controlled and so the
+ attacker must apply effort to obtain further samples of
+ the TOE.
+
+ For the purposes of this discussion:
+
+
+ unnecessary/unlimited access means that the attack
+ doesn't need any kind of opportunity to be realised
+ because there is no risk of being detected during
+ access to the TOE and it is no problem to access the
+ number of TOE samples for the attack;
+
+ easy means that access is required for less than a day
+ and that the number of TOE samples required to perform
+ the attack is less than ten;
+
+ moderate means that access is required for less than a
+ month and that the number of TOE samples required to
+ perform the attack is less than one hundred;
+
+ difficult means that access is required for at least a
+ month or that the number of TOE samples required to
+ perform the attack is at least one hundred;
+
+ none means that the opportunity window is not
+ sufficient to perform the attack (the length for which
+ the asset to be exploited is available or is sensitive
+ is less than the opportunity length needed to perform
+ the attack - for example, if the asset key is changed
+ each week and the attack needs two weeks); another
+ case is, that a sufficient number of TOE samples
+ needed to perform the attack is not accessible to the
+ attacker - for example if the TOE is a hardware and
+ the probability to destroy the TOE during the attack
+ instead of being successful is very high and the
+ attacker has only access to one sample of the
+ TOE.
+
+ Consideration of this factor may result in determining
+ that it is not possible to complete the exploit, due to
+ requirements for time availability that are greater than
+ the opportunity time.
+
+
+ IT hardware/software or other equipment
+ refers to the equipment required to identify
+ or exploit a vulnerability.
+
+
+ Standard equipment is readily available to the
+ attacker, either for the identification of a
+ vulnerability or for an attack. This equipment may be
+ a part of the TOE itself (e.g. a debugger in an
+ operating system), or can be readily obtained
+ (e.g. Internet downloads, protocol analyser or simple
+ attack scripts).
+
+
+ Specialised equipment is not readily available to the
+ attacker, but could be acquired without undue
+ effort. This could include purchase of moderate
+ amounts of equipment (e.g. power analysis tools, use
+ of hundreds of PCs linked across the Internet would
+ fall into this category), or development of more
+ extensive attack scripts or programs. If clearly
+ different test benches consisting of specialised
+ equipment are required for distinct steps of an attack
+ this shall be rated as bespoke.
+
+
+ Bespoke equipment is not readily available to the
+ public as it may need to be specially produced
+ (e.g. very sophisticated software), or because the
+ equipment is so specialised that its distribution is
+ controlled, possibly even restricted. Alternatively,
+ the equipment may be very expensive.
+
+ The level ``Multiple Bespoke'' is introduced to allow
+ for a situation, where different types of bespoke
+ equipment are required for distinct steps of an
+ attack.
+
+ Specialist expertise and Knowledge of the
+ TOE are concerned with the information
+ required for persons to be able to attack a TOE. There
+ is an implicit relationship between an attacker's
+ expertise (where the attacker may be one or more persons
+ with complementary areas of knowledge) and the ability
+ to effectively make use of equipment in an attack. The
+ weaker the attacker's expertise, the lower the potential
+ to use equipment (IT hardware/software or other
+ equipment). Likewise, the greater the expertise, the
+ greater the potential for equipment to be used in the
+ attack. Although implicit, this relationship between
+ expertise and the use of equipment does not always
+ apply, for instance, when environmental measures prevent
+ an expert attacker's use of equipment, or when, through
+ the efforts of others, attack tools requiring little
+ expertise to be effectively used are created and freely
+ distributed (e.g. via the Internet).
+
+
+
+ Table identifies the
+ factors discussed in the previous section and associates
+ numeric values with the total value of each factor.
+
+ Where a factor falls close to the boundary of a range the
+ evaluator should consider use of an intermediate value to
+ those in the table. For example, if twenty samples are
+ required to perform the attack then a value between one
+ and four may be selected for that factor, or if the design
+ is based on a publicly available design but the developer
+ has made some alterations then a value between zero and
+ four should be selected according to the evaluator's view
+ of the impact of those design changes. The table is
+ intended as a guide.
+
+ The ``**'' specification in the table in considering
+ Window of Opportunity is not
+ to be seen as a natural progression from the timescales
+ specified in the preceding ranges associated with this
+ factor. This specification identifies that for a
+ particular reason the potential vulnerability cannot be
+ exploited in the TOE in its intended operational
+ environment. For example, access to the TOE may be
+ detected after a certain amount of time in a TOE with a
+ known environment (i.e. in the case of a system) where
+ regular patrols are completed, and the attacker could not
+ gain access to the TOE for the required two weeks
+ undetected. However, this would not be applicable to a TOE
+ connected to the network where remote access is possible,
+ or where the physical environment of the TOE is
+ unknown.
+
+
+
+
+
+ Factor
+
+
+ Value
+
+
+
+
+
+
+ Elapsed Time
+
+
+
+
+
+ <= one day
+
+ 0
+
+
+
+ <= one week
+
+ 1
+
+
+
+ <= two weeks
+
+ 2
+
+
+
+ <= one month
+
+ 4
+
+
+
+ <= two months
+
+ 7
+
+
+
+ <= three months
+
+ 10
+
+
+
+ <= four months
+
+ 13
+
+
+
+ <= five months
+
+ 15
+
+
+
+ <= six months
+
+ 17
+
+
+
+ > six months
+
+ 19
+
+
+
+ Expertise
+
+
+
+
+
+ Layman
+
+ 0
+
+
+
+ Proficient
+
+
+ 3*When several proficient persons are
+ required to complete the attack path, the
+ resulting level of expertise still remains
+ ``proficient'' (which leads to a 3
+ rating).
+
+
+
+ Expert
+
+ 6
+
+
+
+ Multiple experts
+
+ 8
+
+
+
+ Knowledge of TOE
+
+
+
+
+
+ Public
+
+ 0
+
+
+
+ Restricted
+
+ 3
+
+
+
+ Sensitive
+
+ 7
+
+
+
+ Critical
+
+ 11
+
+
+
+ Window of Opportunity
+
+
+
+
+
+ Unnecessary / unlimited access
+
+ 0
+
+
+
+ Easy
+
+ 1
+
+
+
+ Moderate
+
+ 4
+
+
+
+ Difficult
+
+ 10
+
+
+
+ None
+
+
+ **Indicates that the attack path is not
+ exploitable due to other measures in the
+ intended operational environment of the
+ TOE.
+
+
+
+
+ Equipment
+
+
+
+
+
+ Standard
+
+ 0
+
+
+
+ Specialised
+
+ 4If clearly different test benches
+ consisting of specialised equipment are required
+ for distinct steps of an attack, this should be
+ rated as bespoke.
+
+
+
+ Bespoke
+
+ 7
+
+
+
+ Multiple bespoke
+
+ 9
+
+
+
+
+ Calculation of attack potential
+
+
+ To determine the resistance of the TOE to the potential
+ vulnerabilities identified the following steps should be
+ applied:
+
+
+ Define the possible attack scenarios {AS1, AS2, ...,
+ ASn} for the TOE in the operational
+ environment.
+
+ For each attack scenario, perform a theoretical
+ analysis and calculate the relevant attack potential
+ using Table .
+
+ For each attack scenario, if necessary, perform
+ penetration tests in order to confirm or to disprove
+ the theoretical analysis.
+
+ Divide all attack scenarios {AS1, AS2, ..., ASn} into
+ two groups:
+
+
+ the attack scenarios having been successful
+ (i.e. those that have been used to successfully
+ undermine the SFRs), and
+
+ the attack scenarios that have been demonstrated
+ to be unsuccessful.
+
+
+
+ For each successful attack scenario, apply Table and determine, whether
+ there is a contradiction between the resistance of the
+ TOE and the chosen
+ assurance component, see the last column of Table .
+
+ Should one contradiction be found, the vulnerability
+ assessment will fail, e.g. the author of the ST chose
+ the component and an
+ attack scenario with an attack potential of 21 points
+ (high) has broken the security of the TOE. In this
+ case the TOE is resistant to attacker with attack
+ potential 'Moderate', this contradicts to , hence, the vulnerability
+ assessment fails.
+
+ The ``Values'' column of Table indicates the range of attack potential
+ values (calculated using Table ) of an attack scenario that results in the
+ SFRs being undermined.
+
+
+ An approach such as this cannot take account of every
+ circumstance or factor, but should give a better
+ indication of the level of resistance to attack required
+ to achieve the standard ratings. Other factors, such as
+ the reliance on unlikely chance occurrences are not
+ included in the basic model, but can be used by an
+ evaluator as justification for a rating other than those
+ that the basic model might indicate.
+
+ It should be noted that whereas a number of
+ vulnerabilities rated individually may indicate high
+ resistance to attack, collectively the combination of
+ vulnerabilities may indicate that overall a lower rating
+ is applicable. The presence of one vulnerability may make
+ another easier to exploit.
+
+ If a PP/ST author wants to use the attack potential table
+ for the determination of the level of attack the TOE
+ should withstand (selection of Vulnerability analysis
+ () component), he should
+ proceed as follows: For different types of attacker and/or
+ different types of attack the author has in mind, several
+ passes through Table
+ should be made to determine the different values of attack
+ potential understood for each type of attacker. The PP/ST
+ author then considers the highest value obtained in order
+ to determine the claimed level of resistance from Table
+ .
+
+
+
+
+
+
+
+ Mechanisms subject to direct attack are often vital for system
+ security and developers often strengthen these mechanisms. As
+ an example, a TOE might use a simple pass number
+ authentication mechanism that can be overcome by an attacker
+ who has the opportunity to repeatedly guess another user's
+ pass number. The system can strengthen this mechanism by
+ restricting pass numbers and their use in various ways. During
+ the course of the evaluation an analysis of this direct attack
+ could proceed as follows:
+
+ Information gleaned from the ST and design evidence reveals
+ that identification and authentication provides the basis upon
+ which to control access to network resources from widely
+ distributed terminals. Physical access to the terminals is not
+ controlled by any effective means. The duration of access to a
+ terminal is not controlled by any effective means. Authorised
+ users of the system choose their own pass numbers when
+ initially authorised to use the system, and thereafter upon
+ user request. The system places the following restrictions on
+ the pass numbers selected by the user:
+
+
+ the pass number must be at least four and no greater than
+ six digits long;
+
+
+ consecutive numerical sequences are disallowed (such as
+ 7,6,5,4,3);
+
+
+ repeating digits is disallowed (each digit must be
+ unique).
+
+
+
+ Guidance provided to the users at the time of pass number
+ selection is that pass numbers should be as random as possible
+ and should not be affiliated with the user in some way - a
+ date of birth, for instance.
+
+ The pass number space is calculated as follows:
+
+
+ Patterns of human usage are important considerations that
+ can influence the approach to searching a password
+ space. Assuming the worst case scenario and the user
+ chooses a number comprising only four digits, the number
+ of pass number permutations assuming that each digit must
+ be unique is:
+
+
+ The number of possible increasing sequences is seven, as
+ is the number of decreasing sequences. The pass number
+ space after disallowing sequences is:
+
+
+
+ Based on further information gleaned from the design evidence,
+ the pass number mechanism is designed with a terminal locking
+ feature. Upon the sixth failed authentication attempt the
+ terminal is locked for one hour. The failed authentication
+ count is reset after five minutes so that an attacker can at
+ best attempt five pass number entries every five minutes, or
+ 60 pass number entries every hour.
+
+ On average, an attacker would have to enter 2513 pass numbers,
+ over 2513 minutes, before entering the correct pass
+ number. The average successful attack would, as a result,
+ occur in slightly less than:
+
+ Using either of the approaches to calculate attack potential
+ described above, it is possible that a layman can defeat the
+ mechanism within days (given easy access to the TOE), with the
+ use of standard equipment, and with no knowledge of the TOE,
+ giving a value of 1. Given the resulting sum, 1, the attack
+ potential required to effect a successful attack is not rated,
+ as it falls below that considered to be Basic.
+
+
+
+
+ Table describes the
+ relationship between the composition assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Composed Assurance Packages (CAPs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance for
+ composed TOEs.
+
+ It is important to note that there are only a small number of
+ families and components from CC Part 3 included in the
+ CAPs. This is due to their nature of building upon evaluation
+ results of previously evaluated entities (base components and
+ dependent components), and is not to say that these do not
+ provide meaningful and desirable assurances.
+
+
+ CAPs are to be applied to composed TOEs, which are comprised
+ of components that have been (are going through) component TOE
+ evaluation (see ). The
+ individual components will have been certified to an EAL or
+ another assurance package specified in the ST. It is expected
+ that a basic level of assurance in a composed TOE will be
+ gained through application of EAL1, which can be achieved with
+ information about the components that is generally available
+ in the public domain. (EAL1 can be applied as specified
+ within to both component and composed TOEs.) CAPs provide an
+ alternative approach to obtaining higher levels of assurance
+ for a composed TOE than application of the EALs above
+ EAL1.
+
+ While a dependent component can be evaluated using a
+ previously evaluated and certified base component to satisfy
+ the IT platform requirements in the environment, this does not
+ provide any formal assurance of the interactions between the
+ components or the possible introduction of vulnerabilities
+ resulting from the composition. Composed assurance packages
+ consider these interactions and, at higher levels of
+ assurance, ensure that the interface between the components
+ has itself been the subject of testing. A vulnerability
+ analysis of the composed TOE is also performed to consider the
+ possible introduction of vulnerabilities as a result of
+ composing the components.
+
+ Table represents a summary
+ of the CAPs. The columns represent a hierarchically ordered
+ set of CAPs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, three hierarchically
+ ordered composed assurance packages are defined in the CC for
+ the rating of a composed TOE's assurance. They are
+ hierarchically ordered inasmuch as each CAP represents more
+ assurance than all lower CAPs. The increase in assurance from
+ CAP to CAP is accomplished by substitution of a hierarchically
+ higher assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements). These increases result in
+ greater analysis of the composition to identify the impact on
+ the evaluation results gained for the individual component
+ TOEs.
+
+ These CAPs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each CAP includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ The CAPs only consider resistance against an attacker with an
+ attack potential up to extended-basic. This is due to the
+ level of design information that can be provided through the
+ , limiting some of the factors
+ associated with attack potential (knowledge of the composed
+ TOE) and subsequently affecting the rigour of vulnerability
+ analysis that can be performed by the evaluator. Therefore,
+ the level of assurance in the composed TOE is limited,
+ although the assurance in the individual components within the
+ composed TOE may be much higher.
+
+
+
+
+ The following Subclauses provide definitions of the CAPs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ Unlike the CC, where each element maintains the last digit of
+ its identifying symbol for all components within the family,
+ the CEM may introduce new work units when a CC evaluator
+ action element changes from sub-activity to sub-activity; as a
+ result, the last digit of the work unit's identifying symbol
+ may change although the work unit remains unchanged.
+
+ Any methodology-specific evaluation work required that is not
+ derived directly from CC requirements is termed
+ task or sub-task.
+
+
+
+ All work unit and sub-task verbs are preceded by the auxiliary
+ verb shall and by presenting both the verb
+ and the shall in
+
+ bold italic type face. The
+ auxiliary verb shall is used only when the
+ provided text is mandatory and therefore only within the work
+ units and sub-tasks. The work units and sub-tasks contain
+ mandatory activities that the evaluator must perform in order
+ to assign verdicts.
+
+ Guidance text accompanying work units and sub-tasks gives
+ further explanation on how to apply the CC words in an
+ evaluation. The verb usage is in accordance with ISO
+ definitions for these verbs. The auxiliary verb
+ should is used when the described method is
+ strongly preferred. All other auxiliary verbs, including
+ may, are used where the described method(s)
+ is allowed but is neither recommended nor strongly preferred;
+ it is merely explanation.
+
+ The verbs check, examine,
+ report and record are used
+ with a precise meaning within this part of the CEM and the
+ Clause should be
+ referenced for their definitions.
+
+
+
+ Material that has applicability to more than one sub-activity
+ is collected in one place. Guidance whose applicability is
+ widespread (across activities and EALs) has been collected
+ into . Guidance that
+ pertains to multiple sub-activities within a single activity
+ has been provided in the introduction to that activity. If
+ guidance pertains to only a single sub-activity, it is
+ presented within that sub-activity.
+
+
+
+ There are direct relationships between the CC structure
+ (i.e. class, family, component and element) and the structure
+ of the CEM. Figure illustrates the correspondence
+ between the CC constructs of class, family and evaluator
+ action elements and CEM activities, sub-activities and
+ actions. However, several CEM work units may result from the
+ requirements noted in CC developer action and content and
+ presentation elements.
+
+
+
+
+ For the purposes of this document, the following terms and
+ definitions apply.
+
+ Terms which are presented in bold-faced type are themselves
+ defined in this Subclause.
+
+
+ action
+
+
+ evaluator action element of the CC Part 3. These actions are
+ either explicitly stated as evaluator actions or implicitly
+ derived from developer actions (implied evaluator actions)
+ within the CC Part 3 assurance components.
+
+
+
+
+ activity
+
+
+ the application of an assurance class of the CC Part 3.
+
+
+
+
+ check
+
+ to generate a verdict by a simple
+ comparison. Evaluator expertise is not required. The statement
+ that uses this verb describes what is mapped.
+
+
+
+ evaluation deliverable
+
+ any resource required from the sponsor or developer by
+ the evaluator or overseer to perform one or more evaluation or
+ evaluation oversight activities.
+
+
+
+ evaluation evidence
+
+ a tangible evaluation
+ deliverable.
+
+
+
+ evaluation technical report
+
+ a report that documents the overall
+ verdict and its justification, produced by the
+ evaluator and submitted to an overseer.
+
+
+
+ examine
+
+ to generate a verdict by analysis using
+ evaluator expertise. The statement that uses this verb
+ identifies what is analysed and the properties for which it is
+ analysed.
+
+
+
+ interpretation
+
+ a clarification or amplification of a CC, CEM or
+ scheme requirement.
+
+
+
+ methodology
+
+ the system of principles, procedures and processes
+ applied to IT security evaluations.
+
+
+
+ observation report
+
+ a report written by the evaluator requesting a
+ clarification or identifying a problem during the
+ evaluation.
+
+
+
+ overall verdict
+
+ a pass or fail statement issued by an
+ evaluator with respect to the result of an
+ evaluation.
+
+
+
+ oversight verdict
+
+ a statement issued by an overseer confirming or
+ rejecting an overall verdict based on the
+ results of evaluation oversight activities.
+
+
+
+ record
+
+ to retain a written description of procedures, events,
+ observations, insights and results in sufficient detail to
+ enable the work performed during the evaluation to be
+ reconstructed at a later time.
+
+
+
+ report
+
+ to include evaluation results and supporting material
+ in the Evaluation Technical Report or an
+ Observation Report.
+
+
+
+ scheme
+
+ set of rules, established by an evaluation authority,
+ defining the evaluation environment, including criteria and
+ methodology required to conduct IT security
+ evaluations.
+
+
+
+ sub-activity
+
+
+ the application of an assurance component of the CC Part
+ 3. Assurance families are not explicitly addressed in the CEM
+ because evaluations are conducted on a single assurance
+ component from an assurance family.
+
+
+
+
+ tracing
+
+ a simple directional relation between two sets of
+ entities, which shows which entities in the first set
+ correspond to which entities in the second.
+
+
+
+ verdict
+
+ a pass, fail or inconclusive
+ statement issued by an evaluator with respect to a CC
+ evaluator action element, assurance component, or class. Also
+ see overall verdict.
+
+
+
+ work unit
+
+
+ the most granular level of evaluation work. Each CEM action
+ comprises one or more work units, which are grouped within the
+ CEM action by CC content and presentation of evidence or
+ developer action element. The work units are presented in the
+ CEM in the same order as the CC elements from which they are
+ derived. Work units are identified in the left margin by a
+ symbol such as . In
+ this symbol, the string indicates the CC component (i.e. the CEM
+ sub-activity), and the final digit (2)
+ indicates that this is the second work unit in the sub-activity.
+
+
+
+
+
+ The target audience for the Common Methodology for Information
+ Technology Security Evaluation (CEM) is primarily evaluators
+ applying the CC and certifiers confirming evaluator actions;
+ evaluation sponsors, developers, PP/ST authors and other parties
+ interested in IT security may be a secondary audience.
+
+ The CEM recognises that not all questions concerning IT security
+ evaluation will be answered herein and that further
+ interpretations will be needed. Individual schemes will
+ determine how to handle such interpretations, although these may
+ be subject to mutual recognition agreements. A list of
+ methodology-related activities that may be handled by individual
+ schemes can be found in .
+
+
+
+
+ Clause defines the
+ conventions used in the CEM.
+
+ Clause
+ describes general evaluation tasks with no verdicts associated
+ with them as they do not map to CC evaluator action
+ elements.
+
+ Clause addresses the work
+ necessary for reaching an evaluation result on a PP.
+
+ Clauses to define the evaluation activities, organised by
+ Assurance Classes.
+
+ covers the basic
+ evaluation techniques used to provide technical evidence of
+ evaluation results.
+
+ provides an explanation
+ of the Vulnerability Analysis criteria and examples of their
+ application
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CC
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+
+
+
+
+ The Common Methodology for Information Technology Security
+ Evaluation (CEM) is a companion document to the Common Criteria
+ for Information Technology Security Evaluation (CC). The CEM
+ describes the minimum actions to be performed by an evaluator in
+ order to conduct a CC evaluation, using the criteria and
+ evaluation evidence defined in the CC.
+
+
+
+ CEM
+
+ Common Methodology for Information Technology Security
+ Evaluation
+
+
+
+ ETR
+
+ Evaluation Technical Report
+
+
+
+ OR
+
+ Observation Report
+
+
+
+
+
+ For the purpose of this document, the following terms and
+ definitions apply.
+
+ This Clause contains only
+ those terms which are used in a specialised way throughout the
+ CC. Some combinations of common terms used in the CC, while not
+ meriting inclusion in this Clause , are explained for clarity in the context where they
+ are used.
+
+
+ assets
+
+
+ entities that the owner of the TOE presumably places value
+ upon.
+
+
+
+
+ assignment
+
+
+ the specification of an identified parameter in a component
+ (of the CC) or requirement.
+
+
+
+
+ assurance
+
+
+ grounds for confidence that a TOE meets the SFRs.
+
+
+
+
+ attack potential
+
+
+ a measure of the effort to be expended in attacking a TOE,
+ expressed in terms of an attacker's expertise, resources and
+ motivation.
+
+
+
+
+ augmentation
+
+
+ the addition of one or more requirement(s) to a package.
+
+
+
+ authentication data
+
+ information used to verify the claimed identity of a user.
+
+
+
+ authorised user
+
+ a user who may, in accordance with the SFRs, perform an
+ operation.
+
+
+
+
+ can
+
+
+ within normative text, ``can'' indicates ``statements of
+ possibility and capability, whether material, physical or
+ causal'' ().
+
+
+
+
+ class
+
+
+ a grouping of CC families that share a common focus.
+
+
+
+
+ coherent
+
+
+ an entity is logically ordered and has a discernible
+ meaning. For documentation, this addresses both the actual
+ text and the structure of the document, in terms of whether it
+ is understandable by its target audience.
+
+
+
+
+ complete
+
+
+ all necessary parts of an entity have been provided. In terms
+ of documentation, this means that all relevant information is
+ covered in the documentation, at such a level of detail that
+ no further explanation is required at that level of
+ abstraction.
+
+
+
+
+ component
+
+
+ the smallest selectable set of elements on which requirements
+ may be based.
+
+
+
+
+ component TOE
+
+
+ an evaluated TOE that is part of another TOE.
+
+
+
+
+ composed assurance package (CAP)
+
+
+ an assurance package, consisting of requirements drawn from CC
+ Part 3 (predominately from the
+ class), representing a point on the CC predefined composition
+ assurance scale.
+
+
+
+
+ confirm
+
+
+ this term is used to indicate that something needs to be
+ reviewed in detail, and that an independent determination of
+ sufficiency needs to be made. The level of rigour required
+ depends on the nature of the subject matter. This term is only
+ applied to evaluator actions.
+
+
+
+ connectivity
+
+ the property of the TOE which allows interaction with IT
+ entities external to the TOE. This includes exchange of data by
+ wire or by wireless means, over any distance in any environment
+ or configuration.
+
+
+
+
+ consistent
+
+
+ this term describes a relationship between two or more
+ entities, indicating that there are no apparent contradictions
+ between these entities.
+
+
+
+
+ counter (verb)
+
+
+ this term is typically used when the impact of a particular
+ threat is mitigated but not necessarily eradicated.
+
+
+
+
+ demonstrate
+
+
+ this term refers to an analysis leading to a conclusion, which
+ is less rigorous than a ``proof''.
+
+
+
+
+ dependency
+
+
+ a relationship between components such that if a requirement
+ based on the depending component is included in a PP, ST or
+ package, a requirement based on the component that is depended
+ upon must normally also be included in the PP, ST or package.
+
+
+
+
+ describe
+
+
+ this term requires that specific details of an entity be
+ provided.
+
+
+
+
+ determine
+
+
+ this term requires an independent analysis to be made, with
+ the objective of reaching a particular conclusion. The usage
+ of this term differs from ``confirm'' or ``verify'', since
+ these other terms imply that an analysis has already been
+ performed which needs to be reviewed, whereas the usage of
+ ``determine'' implies a truly independent analysis, usually in
+ the absence of any previous analysis having been performed.
+
+
+
+
+ development environment
+
+
+ the environment in which the TOE is developed.
+
+
+
+
+ element
+
+
+ an indivisible statement of security need.
+
+
+
+
+ ensure
+
+
+ this term, used by itself, implies a strong causal
+ relationship between an action and its consequences. When this
+ term is preceded by the word ``helps'' it indicates that the
+ consequence is not fully certain, on the basis of that action
+ alone.
+
+
+
+
+ evaluation
+
+
+ assessment of a PP, an ST or a TOE, against defined criteria.
+
+
+
+
+ evaluation assurance level (EAL)
+
+
+ an assurance package, consisting of assurance requirements
+ drawn from CC Part 3, representing a point on the CC
+ predefined assurance scale.
+
+
+
+
+ evaluation authority
+
+
+ a body that implements the CC for a specific community by
+ means of an evaluation scheme and thereby sets the standards
+ and monitors the quality of evaluations conducted by bodies
+ within that community.
+
+
+
+
+ evaluation scheme
+
+
+ the administrative and regulatory framework under which the CC
+ is applied by an evaluation authority within a specific
+ community.
+
+
+
+
+ exhaustive
+
+
+ this term is used in the CC with respect to conducting an
+ analysis or other activity. It is related to ``systematic''
+ but is considerably stronger, in that it indicates not only
+ that a methodical approach has been taken to perform the
+ analysis or activity according to an unambiguous plan, but
+ that the plan that was followed is sufficient to ensure that
+ all possible avenues have been exercised.
+
+
+
+
+ explain
+
+
+ this term differs from both ``describe'' and
+ ``demonstrate''. It is intended to answer the question
+ ``Why?'' without actually attempting to argue that the course
+ of action that was taken was necessarily optimal.
+
+
+
+ extension
+
+ the addition to an ST or PP of functional requirements not
+ contained in Part 2 and/or assurance requirements not
+ contained in Part 3 of the CC.
+
+
+
+
+ external entity
+
+
+ any entity (human or IT) outside the TOE that interacts
+ (or may interact) with the TOE.
+
+
+
+
+ family
+
+
+ a grouping of components that share a similar goal but may
+ differ in emphasis or rigour.
+
+
+
+
+ formal
+
+
+ expressed in a restricted syntax language with defined
+ semantics based on well-established mathematical concepts.
+
+
+
+
+ guidance documentation
+
+
+ documentation that describes the delivery, preparation,
+ operation, management and/or use of the TOE.
+
+
+
+ identity
+
+ a representation (e.g. a string) uniquely identifying an
+ authorised user, which can either be the full or abbreviated
+ name of that user or a pseudonym.
+
+
+
+
+ informal
+
+
+ expressed in natural language.
+
+
+
+
+ informative
+
+
+ informative text ``provides additional information intended to
+ assist the understanding or use of the document.'' ().
+
+
+
+ inter-TSF transfers
+
+ communicating data between the TOE and the security
+ functionality of other trusted IT products.
+
+
+
+ internal communication channel
+
+ a communication channel between separated parts of the TOE.
+
+
+
+ internal TOE transfer
+
+ communicating data between separated parts of the TOE.
+
+
+
+
+ internally consistent
+
+
+ this term means that there are no apparent contradictions
+ between any aspects of an entity. In terms of documentation,
+ this means that there can be no statements within the
+ documentation that can be taken to contradict each other.
+
+
+
+
+ iteration
+
+
+ the use of the same component to express two or more distinct
+ requirements.
+
+
+
+
+ justification
+
+
+ this term refers to an analysis leading to a conclusion, but
+ is more rigorous than a demonstration. This term requires
+ significant rigour in terms of very carefully and thoroughly
+ explaining every step of a logical argument.
+
+
+
+
+ may
+
+
+ within normative text, ``may'' indicates ``a course of action
+ permissible within the limits of the document'' ().
+
+
+
+
+ normative
+
+
+ normative text ``describes the scope of the document, and sets
+ out provisions.'' (). Within normative text, the verbs ``shall'',
+ ``should'', ``may'', and ``can'' have the ISO standard meanings
+ described in this glossary and the verb ``must'' is not
+ used. Unless explicitly labelled ``informative'', all CC text is
+ normative.
+
+
+
+
+ object
+
+
+ a passive entity in the TOE, that contains or receives
+ information, and upon which subjects perform operations.
+
+
+
+
+ operation (on a component of the CC)
+
+
+ modifying or repeating that component. Allowed operations on
+ components are assignment, iteration, refinement and
+ selection.
+
+
+
+
+ operation (on an object)
+
+
+ a specific type of action performed by a subject on an object.
+
+
+
+
+ operational environment
+
+
+ the environment in which the TOE is operated.
+
+
+
+
+ organisational security policy (OSP)
+
+
+ a set of security rules, procedures, or guidelines imposed (or
+ presumed to be imposed) now and/or in the future by an actual
+ or hypothetical organisation in the operational environment.
+
+
+
+
+ package
+
+
+ a named set of either functional or assurance requirements
+ (e.g. EAL 3).
+
+
+
+
+ PP evaluation
+
+
+ assessment of a PP against defined criteria.
+
+
+
+
+ Protection Profile (PP)
+
+
+ an implementation-independent statement of security needs for
+ a TOE type.
+
+
+
+
+ prove
+
+
+ this term refers to a formal analysis in its mathematical
+ sense. It is completely rigorous in all ways. Typically,
+ ``prove'' is used when there is a desire to show
+ correspondence between two TSF representations at a high level
+ of rigour.
+
+
+
+
+ refinement
+
+
+ the addition of details to a component.
+
+
+
+ role
+
+ a predefined set of rules establishing the allowed
+ interactions between a user and the TOE.
+
+
+
+ secret
+
+ information that must be known only to authorised users
+ and/or the TSF in order to enforce a specific SFP.
+
+
+
+ secure state
+
+ a state in which the TSF data are consistent and the TSF
+ continues correct enforcement of the SFRs.
+
+
+
+
+ security attribute
+
+
+ a property of subjects, users (including external IT products),
+ objects, information, sessions and/or resources that is used in
+ defining the SFRs and whose values are used in enforcing the
+ SFRs.
+
+
+
+ security function policy (SFP)
+
+ a set of rules describing specific security behaviour enforced
+ by the TSF and expressible as a set of SFRs.
+
+
+
+
+ security objective
+
+
+ a statement of intent to counter identified threats and/or
+ satisfy identified organisation security policies and/or
+ assumptions.
+
+
+
+
+ Security Target (ST)
+
+
+ an implementation-dependent statement of security needs for a
+ specific identified TOE.
+
+
+
+
+ selection
+
+
+ the specification of one or more items from a list in a
+ component.
+
+
+
+
+ semiformal
+
+
+ expressed in a restricted syntax language with defined
+ semantics.
+
+
+
+
+ shall
+
+
+ within normative text, ``shall'' indicates ``requirements
+ strictly to be followed in order to conform to the document
+ and from which no deviation is permitted.'' ().
+
+
+
+
+ should
+
+
+ within normative text, ``should'' indicates ``that among
+ several possibilities one is recommended as particularly
+ suitable, without mentioning or excluding others, or that a
+ certain course of action is preferred but not necessarily
+ required.'' () The CC
+ interprets 'not necessarily required' to mean that the choice
+ of another possibility requires a justification of why the
+ preferred option was not chosen.
+
+
+
+
+ specify
+
+
+ this term is used in the same context as ``describe'', but is
+ intended to be more rigorous and precise. It is very similar
+ to ``define''.
+
+
+
+
+ ST evaluation
+
+
+ assessment of an ST against defined criteria.
+
+
+
+
+ subject
+
+
+ an active entity in the TOE that performs operations on
+ objects.
+
+
+
+
+ target of evaluation (TOE)
+
+
+ a set of software, firmware and/or hardware possibly
+ accompanied by guidance.
+
+
+
+
+ TOE evaluation
+
+
+ assessment of a TOE against defined criteria.
+
+
+
+ TOE resource
+
+ anything useable or consumable in the TOE.
+
+
+
+
+ TOE Security Functionality (TSF)
+
+
+ a set consisting of all hardware, software, and firmware of
+ the TOE that must be relied upon for the correct enforcement
+ of the SFRs.
+
+
+
+
+ trace (verb)
+
+
+ this term is used to indicate that an informal correspondence
+ is required between two entities with only a minimal level of
+ rigour.
+
+
+
+ transfers outside of the TOE
+
+ TSF mediated communication of data to entities not under control
+ of the TSF.
+
+
+
+ trusted channel
+
+ a means by which a TSF and a remote trusted IT product can
+ communicate with necessary confidence.
+
+
+
+ trusted IT product
+
+ an IT product other than the TOE which has its security
+ functional requirements administratively coordinated with
+ the TOE and which is assumed to enforce its security functional
+ requirements correctly (e. g. by being separately evaluated).
+
+
+
+ trusted path
+
+ a means by which a user and a TSF can communicate with
+ necessary confidence.
+
+
+
+ TSF data
+
+ data created by and for the TOE, that might affect the
+ operation of the TOE.
+
+
+
+
+ TSF interface (TSFI)
+
+
+ a means by which external entities (or subjects in the TOE but
+ outside of the TSF) supply data to the TSF, receive data from
+ the TSF and invoke services from the TSF.
+
+
+
+ user
+
+ see .
+
+
+
+ user data
+
+ data created by and for the user, that does not affect the
+ operation of the TSF.
+
+
+
+
+ verify
+
+
+ this term is similar in context to ``confirm'', but has more
+ rigorous connotations. This term when used in the context of
+ evaluator actions indicates that an independent effort is
+ required of the evaluator.
+
+
+
+
+ The following terms are used in the requirements for software
+ internal structuring. Some of these are derived from the
+ Institute of Electrical and Electronics Engineers
+ Glossary of software engineering terminology, IEEE Std
+ 610.12-1990.
+
+
+ administrator
+
+
+ an entity that has complete trust with respect to all
+ policies implemented by the TSF.
+
+
+
+ call tree
+
+ a diagram that identifies the modules in a system and shows
+ which modules call one another. All the modules named in a
+ call tree that originates with (i.e., is rooted by) a
+ specific module are the modules that directly or indirectly
+ implement the functions of the originating module.
+
+
+
+ cohesion (also called module strength)
+
+ the manner and degree to which the tasks performed by a
+ single software module are related to one another; types of
+ cohesion include coincidental, communicational, functional,
+ logical, sequential, and temporal. These types of cohesion
+ are characterised below, listed in the order of decreasing
+ desirability.
+
+
+
+ coincidental cohesion
+
+ a module with this characteristic performs unrelated, or
+ loosely related, activities.
+
+
+
+ communicational cohesion
+
+ a module with this characteristic contains functions that
+ produce output for, or use output from, other functions
+ within the module. An example of a communicationally
+ cohesive module is an access check module
+ that includes mandatory, discretionary, and capability
+ checks.
+
+
+
+ complexity
+
+ this is a measure of how difficult software is to
+ understand, and thus to analyse, test, and
+ maintain. Reducing complexity is the ultimate goal for using
+ modular decomposition, layering and
+ minimisation. Controlling coupling and cohesion contributes
+ significantly to this goal.
+
+ A good deal of effort in the software engineering field
+ has been expended in attempting to develop metrics to
+ measure the complexity of source code. Most of these
+ metrics use easily computed properties of the source code,
+ such as the number of operators and operands, the
+ complexity of the control flow graph (cyclomatic
+ complexity), the number of lines of source code, the ratio
+ of comments to executable code, and similar
+ measures. Coding standards have been found to be a useful
+ tool in generating code that is more readily
+ understood.
+
+ This family calls for a
+ complexity analysis in all components. It
+ is expected that the developer will provide support for
+ the claims that there has been a sufficient reduction in
+ complexity. This support could include the developer's
+ programming standards, and an indication that all modules
+ meet the standard (or that there are some exceptions that
+ are justified by software engineering arguments). It could
+ include the results of tools used to measure some of the
+ properties of the source code. Or it could include other
+ support that the developer finds appropriate.
+
+
+
+ coupling
+
+ the manner and degree of interdependence between software
+ modules; types of coupling include call, common and content
+ coupling. These types of coupling are characterised below,
+ listed in the order of decreasing desirability
+
+
+ call: two modules are call coupled if
+ they communicate strictly through the use of their
+ documented function calls; examples of call coupling are
+ data, stamp, and control, which are defined below.
+
+
+ data: two modules are data coupled
+ if they communicate strictly through the use of call
+ parameters that represent single data items.
+
+ stamp: two modules are stamp
+ coupled if they communicate through the use of call
+ parameters that comprise multiple fields or that
+ have meaningful internal structures.
+
+ control: two modules are control
+ coupled if one passes information that is intended
+ to influence the internal logic of the other.
+
+
+
+ common: two modules are common coupled
+ if they share a common data area or a common system
+ resource. Global variables indicate that modules using
+ those global variables are common coupled. Common
+ coupling through global variables is generally allowed,
+ but only to a limited degree. For example, variables
+ that are placed into a global area, but are used by only
+ a single module, are inappropriately placed, and should
+ be removed. Other factors that need to be considered in
+ assessing the suitability of global variables are:
+
+
+ The number of modules that modify a global variable:
+ In general, only a single module should be allocated
+ the responsibility for controlling the contents of a
+ global variable, but there may be situations in
+ which a second module may share that responsibility;
+ in such a case, sufficient justification must be
+ provided. It is unacceptable for this responsibility
+ to be shared by more than two modules. (In making
+ this assessment, care should be given to determining
+ the module actually responsible for the contents of
+ the variable; for example, if a single routine is
+ used to modify the variable, but that routine simply
+ performs the modification requested by its caller,
+ it is the calling module that is responsible, and
+ there may be more than one such module). Further, as
+ part of the complexity determination, if two modules
+ are responsible for the contents of a global
+ variable, there should be clear indications of how
+ the modifications are coordinated between
+ them.
+
+ The number of modules that reference a global
+ variable: Although there is generally no limit on
+ the number of modules that reference a global
+ variable, cases in which many modules make such a
+ reference should be examined for validity and
+ necessity.
+
+
+
+ content: two modules are content
+ coupled if one can make direct reference to the
+ internals of the other (e.g. modifying code of, or
+ referencing labels internal to, the other module). The
+ result is that some or all of the content of one module
+ are effectively included in the other. Content coupling
+ can be thought of as using unadvertised module
+ interfaces; this is in contrast to call coupling, which
+ uses only advertised module interfaces.
+
+
+
+
+ domain separation
+
+ the security architecture property whereby the TSF defines
+ separate security domains for each user and for the TSF and
+ ensures that no user process can affect the contents of a
+ security domain of another user or of the TSF.
+
+
+
+ functional cohesion
+
+ a module with this characteristic performs activities
+ related to a single purpose. A functionally cohesive module
+ transforms a single type of input into a single type of
+ output, such as a stack manager or a queue manager.
+
+
+
+ interaction
+
+ a general communication-based relationship between entities.
+
+
+
+ interface
+
+ a means of interaction with a component or module.
+
+
+
+ layering
+
+ the design of software such that separate groups of modules
+ (the layers) are hierarchically organised
+ to have separate responsibilities such that one layer
+ depends only on layers below it in the hierarchy for
+ services, and provides its services only to the layers above
+ it. Strict layering adds the constraint that each layer
+ receives services only from the layer immediately beneath
+ it, and provides services only to the layer immediately
+ above it.
+
+
+
+ logical (or procedural) cohesion
+
+ a module with this characteristic performs similar
+ activities on different data structures. A module exhibits
+ logical cohesion if its functions perform related, but
+ different, operations on different inputs.
+
+
+
+ modular decomposition
+
+ the process of breaking a system into components to
+ facilitate design and development.
+
+
+
+ non-bypassability (of the TSF)
+
+ the security architecture property whereby all SFR-related
+ actions are mediated by the TSF.
+
+
+
+ security domain
+
+ the collection of resources to which an active entity has
+ access.
+
+
+
+ sequential cohesion
+
+ a module with this characteristic contains functions each of
+ whose output is input for the following function in the
+ module. An example of a sequentially cohesive module is one
+ that contains the functions to write audit records and to
+ maintain a running count of the accumulated number of audit
+ violations of a specified type.
+
+
+
+ software engineering
+
+ the application of a systematic, disciplined, quantifiable
+ approach to the development, operation, and maintenance of
+ software; that is, the application of engineering to
+ software. As with engineering practises in general, some
+ amount of judgement must be used in applying engineering
+ principles. Many factors affect choices, not just the
+ application of measures of modular decomposition, layering,
+ and minimisation. For example, a developer may design a
+ system with future applications in mind that will not be
+ implemented initially. The developer may choose to include
+ some logic to handle these future applications without fully
+ implementing them; further, the developer may include some
+ calls to as-yet unimplemented modules, leaving call
+ stubs. The developer's justification for such deviations
+ from well-structured programs will have to be assessed using
+ judgement, as well as the application of good software
+ engineering discipline.
+
+
+
+ temporal cohesion
+
+ a module with this characteristic contains functions that
+ need to be executed at about the same time. Examples of
+ temporally cohesive modules include
+ initialisation, recovery,
+ and shutdown modules.
+
+
+
+ TSF self-protection
+
+ the security architecture property whereby the TSF cannot be
+ corrupted by non-TSF code or entities.
+
+
+
+
+
+
+
+
+ installation
+
+
+ the procedures that the user has to perform normally only once
+ after receipt and acceptance of the TOE to progress it to the
+ secure configuration as described in the ST including the
+ embedding of the TOE in its operational environment. If
+ similar processes have to be performed by the developer they
+ are denoted as ``generation'' throughout . If the TOE requires an initial start-up that does
+ not need to be repeated regularly, this process would be
+ classified as installation here.
+
+
+
+
+ operation
+
+
+ the usage phase of the TOE. This includes ``normal usage'',
+ administration and maintenance of the TOE.
+
+
+
+
+ operation (of the TOE)
+
+
+ usage of the TOE after delivery and preparation.
+
+
+
+
+ preparation
+
+
+ the product life-cycle phase comprising the customer's
+ acceptance of the delivered TOE and its installation which
+ may include such things as booting, initialisation,
+ start-up, progressing the TOE to a state ready for
+ operation.
+
+
+
+
+
+
+ acceptance criteria
+
+
+ the criteria to be applied when performing the acceptance
+ procedures (e.g. successful document review, or successful
+ testing in the case of software, firmware or hardware).
+
+
+
+
+ acceptance procedures
+
+
+ the procedures followed in order to accept newly created or
+ modified configuration items as part of the TOE, or to move
+ them to the next step of the life-cycle. These procedures
+ identify the roles or individuals responsible for the
+ acceptance and the criteria to be applied to decide on the
+ acceptance.
+
+ There are several types of acceptance situations some of
+ which may overlap:
+
+
+ acceptance of an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers into
+ the TOE (``integration'');
+
+
+ progression of configuration items to the next
+ life-cycle phase at each stage of the construction of
+ the TOE (e.g. module, subsystem, quality control of
+ the finished TOE);
+
+
+ subsequent to transports of configuration items (for
+ example parts of the TOE or preliminary products)
+ between different development sites;
+
+
+ subsequent to the delivery of the TOE to the consumer.
+
+
+
+
+
+
+ CM documentation (documentation of the CM system)
+
+
+ overall term for the following:
+
+
+ CM output
+
+
+ CM list (configuration list)
+
+
+ CM system records
+
+
+
+
+ CM plan
+
+
+ CM usage documentation
+
+
+
+
+
+
+ CM evidence
+
+
+ everything that may be used to establish confidence in the
+ correct operation of the CM system, e.g., CM output,
+ rationales provided by the developer, observations,
+ experiments or interviews made by the evaluator during a
+ site visit.
+
+
+
+
+ CM item (configuration item)
+
+
+ object managed by the CM system during the TOE
+ development. These may be either parts of the TOE or objects
+ related to the development of the TOE like evaluation
+ documents or development tools. CM items may be stored in
+ the CM system directly (for example files) or by reference
+ (for example hardware parts) together with their version.
+
+
+
+
+ CM list (configuration list)
+
+
+ a CM output document listing all configuration items for a
+ specific product together with the exact version of each CM
+ item relevant for a specific version of the complete
+ product. This list allows distinguishing the items belonging
+ to the evaluated version of the product from other versions
+ of these items belonging to other versions of the
+ product. The final CM list is a specific document for a
+ specific version of a specific product. (Of course the list
+ can be an electronic document inside of a CM tool. In that
+ case it can be seen as a specific view into the system or a
+ part of the system rather than an output of the
+ system. However, for the practical use in an evaluation the
+ configuration list will probably be delivered as a part of
+ the evaluation documentation.) The configuration list
+ defines the items that are under the CM requirements of
+ .
+
+
+
+
+ CM output
+
+
+ CM related results produced or enforced by the CM
+ system. These CM related results could occur as documents
+ (for example filled paper forms, CM system records, logging
+ data, hard-copies and electronic output data) as well as
+ actions (for example manual measures to fulfil CM
+ instructions). Examples of such CM outputs are configuration
+ lists, CM plans and/or behaviours during the product
+ life-cycle.
+
+
+
+
+ CM plan
+
+
+ part of the CM documentation describing how the CM system is
+ used for the TOE. The objective of issuing a CM plan is that
+ staff members can see clearly what they have to do. From the
+ point of view of the overall CM system this can be seen as
+ an output document (because it may be produced as part of
+ the application of the CM system). From the point of view of
+ the concrete project it is a usage document because members
+ of the project team use it in order to understand the steps
+ that they have to perform during the project. The CM plan
+ defines the usage of the system for the specific product;
+ the same system may be used to a different extent for other
+ products. That means the CM plan defines and describes the
+ output of the CM system of a company which is used during
+ the TOE development.
+
+
+
+
+ CM system
+
+
+ overall term for the set of procedures and tools (including
+ their documentation) used by a developer to develop and
+ maintain configurations of his products during their
+ life-cycles. CM systems may have varying degrees of rigour
+ and function. At higher levels, CM systems may be automated,
+ with flaw remediation, change controls, and other tracking
+ mechanisms.
+
+
+
+
+ CM system records
+
+
+ those CM output documents which are produced during the
+ operation of the CM system documenting important
+ activities. Examples of CM system records are CM item change
+ control forms or CM item access approval forms.
+
+
+
+
+ CM tools
+
+
+ tools realising or supporting a CM system, for example tools
+ for the version management of the parts of the TOE. They may
+ require manual operation or may be automated.
+
+
+
+
+ CM usage documentation
+
+
+ that part of the CM system, which describes, how the CM
+ system is defined and applied by using for example
+ handbooks, regulations and/or documentation of tools and
+ procedures.
+
+
+
+
+ delivery
+
+
+ the product life-cycle phase which is concerned with the
+ transmission of the finished TOE from the production
+ environment into the hands of the customer. This may include
+ packaging and storage at the development site, but does not
+ include transportations of the unfinished TOE or parts of
+ the TOE between different developers or different
+ development sites.
+
+
+
+
+ developer
+
+
+ the organisation responsible for the development of the TOE.
+
+
+
+
+ development
+
+
+ the product life-cycle phase which is concerned with
+ generating the implementation representation of the
+ TOE. Throughout the requirements,
+ development and related terms (developer, develop) are meant
+ in the more general sense to comprise development
+ and production.
+
+
+
+
+ development tools
+
+
+ tools (including test software, if applicable) supporting
+ the development and production of the TOE. E.g., for a
+ software TOE, development tools are usually programming
+ languages, compilers, linkers and generating tools.
+
+
+
+
+ implementation representation
+
+
+ the least abstract representation of the TSF, specifically
+ the one that is used to create the TSF itself without
+ further design refinement. Source code that is then compiled
+ or a hardware drawing that is used to build the actual
+ hardware are examples of parts of an implementation
+ representation.
+
+
+
+
+ life-cycle
+
+
+ the sequence of stages of existence of an object (for
+ example a product or a system) in time.
+
+
+
+
+ life-cycle definition
+
+
+ the definition of the life-cycle model.
+
+
+
+
+ life-cycle model
+
+
+ description of the stages and their relations to each other
+ that are used in the management of the life-cycle of a
+ certain object, how the sequence of stages looks like and
+ which high level characteristics the stages have.
+
+
+
+
+ measurable life-cycle model
+
+
+ a life-cycle model using some quantitative valuation
+ (arithmetic parameters and/or metrics) of the managed
+ product in order to measure development properties of the
+ product. Typical metrics are source code complexity metrics,
+ defect density (errors per size of code) or mean time to
+ failure.
+
+
+
+
+ production
+
+
+ the production life-cycle phase follows the development
+ phase and consists of transforming the implementation
+ representation into the implementation of the TOE, i.e. into
+ a state acceptable for delivery to the customer. This phase
+ may comprise manufacturing, integration, generation,
+ internal transports, storage, and labelling of the TOE.
+
+
+
+
+
+
+
+
+ covert channel
+
+
+ an enforced, illicit signalling channel that allows a user to
+ surreptitiously contravene the multi-level separation policy
+ and unobservability requirements of the TOE (this is a special
+ case of monitoring attacks).
+
+
+
+
+ encountered potential vulnerabilities
+
+
+ potential weakness in the TOE identified by the evaluator
+ while performing evaluation activities that could be used to
+ violate the SFRs.
+
+
+
+
+ exploitable vulnerability
+
+
+ a weakness in the TOE that can be used to violate the SFRs
+ in the operational environment for the TOE.
+
+
+
+
+ monitoring attacks
+
+
+ a generic category of attack methods that includes passive
+ analysis techniques aiming at disclosure of sensitive internal
+ data of the TOE by operating the TOE in the way that
+ corresponds to the guidance documents.
+
+
+
+
+ potential vulnerability
+
+
+ a weakness the existence of which is suspected (by virtue of
+ a postulated attack path), but not confirmed, to violate the
+ SFRs.
+
+
+
+
+ residual vulnerability
+
+
+ a weakness that cannot be exploited in the operational
+ environment for the TOE, but that could be used to violate
+ the SFRs by an attacker with greater attack potential than
+ is anticipated in the operational environment for the TOE.
+
+
+
+
+ vulnerability
+
+
+ a weakness in the TOE that can be used to violate the SFRs
+ in some environment.
+
+
+
+
+
+
+
+ base component
+
+
+ the entity in a composed TOE, which has itself been the
+ subject of an evaluation, providing services and resources
+ to a dependent component.
+
+
+
+
+ compatible (components)
+
+
+ one component providing the services required by the other
+ component, through the corresponding interfaces of each
+ component, in consistent operational environments.
+
+
+
+
+ composed TOE
+
+
+ comprised solely of two or more components that have been
+ successfully evaluated.
+
+
+
+
+ dependent component
+
+
+ an entity in a composed TOE, which is itself the subject of
+ an evaluation, relying on the provision on services by a
+ base component.
+
+
+
+
+ functional interface
+
+
+ the (external) interfaces that provide a user with access to
+ functionality of the TOE that is not directly involved in
+ enforcing security functional requirements. In a composed
+ TOE these are the interfaces provided by the base component
+ that are required by the dependent component to support the
+ operation of the composed TOE.
+
+
+
+
+
+
+ Table describes the
+ relationship between the evaluation assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Evaluation Assurance Levels (EALs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance. The
+ CC approach identifies the separate concepts of assurance in a
+ TOE at the end of the evaluation, and of maintenance of that
+ assurance during the operational use of the TOE.
+
+ It is important to note that not all families and components
+ from CC Part 3 are included in the EALs. This is not to say that
+ these do not provide meaningful and desirable
+ assurances. Instead, it is expected that these families and
+ components will be considered for augmentation of an EAL in
+ those PPs and STs for which they provide utility.
+
+
+ Table represents a summary
+ of the EALs. The columns represent a hierarchically ordered
+ set of EALs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, seven hierarchically
+ ordered evaluation assurance levels are defined in the CC for
+ the rating of a TOE's assurance. They are hierarchically
+ ordered inasmuch as each EAL represents more assurance than
+ all lower EALs. The increase in assurance from EAL to EAL is
+ accomplished by substitution of a hierarchically higher
+ assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements).
+
+ These EALs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each EAL includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ While the EALs are defined in the CC, it is possible to
+ represent other combinations of assurance. Specifically, the
+ notion of ``augmentation'' allows the addition of assurance
+ components (from assurance families not already included in
+ the EAL) or the substitution of assurance components (with
+ another hierarchically higher assurance component in the same
+ assurance family) to an EAL. Of the assurance constructs
+ defined in the CC, only EALs may be augmented. The notion of
+ an ``EAL minus a constituent assurance component'' is not
+ recognised by the standard as a valid claim. Augmentation
+ carries with it the obligation on the part of the claimant to
+ justify the utility and added value of the added assurance
+ component to the EAL. An EAL may also be augmented with
+ extended assurance requirements.
+
+
+
+
+ The following Subclauses provide definitions of the EALs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ The objective of this clause is to cover general guidance
+ used to provide technical evidence of evaluation results. The
+ use of such general guidance helps in achieving objectivity,
+ repeatability and reproducibility of the work performed by the
+ evaluator.
+
+
+
+ This Subclause provides general guidance on sampling. Specific
+ and detailed information is given in those work units under
+ the specific evaluator action elements where sampling has to
+ be performed.
+
+ Sampling is a defined procedure of an evaluator whereby some
+ subset of a required set of evaluation evidence is examined
+ and assumed to be representative for the entire set. It allows
+ the evaluator to gain enough confidence in the correctness of
+ particular evaluation evidence without analysing the whole
+ evidence. The reason for sampling is to conserve resources
+ while maintaining an adequate level of assurance. Sampling of
+ the evidence can provide two possible outcomes:
+
+
+ The subset reveals no errors, allowing the evaluator to
+ have some confidence that the entire set is correct.
+
+
+ The subset reveals errors and therefore the validity of
+ the entire set is called into question. Even the
+ resolution of all errors that were found may be
+ insufficient to provide the evaluator the necessary
+ confidence and as a result the evaluator may have to
+ increase the size of the subset, or stop using sampling
+ for this particular evidence.
+
+
+
+ Sampling is a technique which can be used to reach a reliable
+ conclusion if a set of evidence is relatively homogeneous in
+ nature, e.g. if the evidence has been produced during a well
+ defined process.
+
+ Sampling in the cases identified in the CC, and in cases
+ specifically covered in CEM work items, is recognised as a
+ cost-effective approach to performing evaluator
+ actions. Sampling in other areas is permitted only in
+ exceptional cases, where performance of a particular activity
+ in its entirety would require effort disproportionate to the
+ other evaluation activities, and where this would not add
+ correspondingly to assurance. In such cases a rationale for
+ the use of sampling in that area will need to be made. Neither
+ the fact that the TOE is large and complex, nor that it has
+ many security functional requirements, is sufficient
+ justification, since evaluations of large, complex TOEs can be
+ expected to require more effort. Rather it is intended that
+ this exception be limited to cases such as that where the TOE
+ development approach yields large quantities of material for a
+ particular CC requirement that would normally all need to be
+ checked or examined, and where such an action would not be
+ expected to raise assurance correspondingly.
+
+ Sampling needs to be justified taking into account the
+ possible impact on the security objectives and threats of the
+ TOE. The impact depends on what might be missed as a result of
+ sampling. Consideration also needs to be given to the nature
+ of the evidence to be sampled, and the requirement not to
+ diminish or ignore any security functions.
+
+ It should be recognised that sampling of evidence directly
+ related to the implementation of the TOE (e.g. developer test
+ results) requires a different approach to sampling, then
+ sampling related to the determination of whether a process is
+ being followed. In many cases the evaluator is required to
+ determine that a process is being followed, and a sampling
+ strategy is recommended. The approach for sampling a
+ developer's test results will differ. This is because the
+ former case is concerned with ensuring that a process is in
+ place, and the latter deals with determining correct
+ implementation of the TOE. Typically, larger sample sizes
+ should be analysed in cases related to the correct
+ implementation of the TOE than would be necessary to ensure
+ that a process is in place.
+
+ In certain cases it may be appropriate for the evaluator to
+ give greater emphasis to the repetition of developer
+ testing. For example if the independent tests left for the
+ evaluator to perform would be only superficially different
+ from those included in an extensive developer test set
+ (possibly because the developer has performed more testing
+ than necessary to satisfy the
+ and criteria) then it would
+ be appropriate for the evaluator to give greater focus to the
+ repetition of developer tests. Note that this does not
+ necessarily imply a requirement for a high percentage sample
+ for repetition of developer tests; indeed, given an extensive
+ developer test set, the evaluator may be able to justify a low
+ percentage sample.
+
+ Where the developer has used an automated test suite to
+ perform functional testing, it will usually be easier for the
+ evaluator to re-run the entire test suite rather than repeat
+ only a sample of developer tests. However the evaluator does
+ have an obligation to check that the automatic testing does
+ not give misrepresentative results. The implication is thus
+ that this check must be performed for a sample of the
+ automatic test suite, with the principles for selecting some
+ tests in preference to others and ensuring a sufficient sample
+ size applying equally in this case.
+
+ The following principles should be followed whenever sampling
+ is performed:
+
+
+ Sampling should not be random, rather it should be chosen
+ such that it is representative of all of the evidence. The
+ sample size and composition must always be justified.
+
+
+ When sampling relates to the correct implementation of the
+ TOE, the sample should be representative of all aspects
+ relevant to the areas that are sampled. In particular, the
+ selection should cover a variety of components,
+ interfaces, developer and operational sites (if more than
+ one is involved) and hardware platform types (if more than
+ one is involved). The sample size should be commensurate
+ with the cost effectiveness of the evaluation and will
+ depend on a number of TOE dependent factors (e.g. the size
+ and complexity of the TOE, the amount of documentation).
+
+
+ Also, when sampling relates to specifically gaining
+ evidence that the developer testing is repeatable and
+ reproducible the sample used must be sufficient to
+ represent all distinct aspects of developer testing, such
+ as different test regimes. The sample used must be
+ sufficient to detect any systematic problem in the
+ developer's functional testing process. The evaluator
+ contribution resulting from the combination of repeating
+ developer tests and performing independent tests must be
+ sufficient to address the major points of concern for the
+ TOE.
+
+
+ Where sampling relates to gaining evidence that a process
+ (e.g. visitor control or design review) the evaluator
+ should sample sufficient information to gain reasonable
+ confidence that the procedure is being followed.
+
+
+ The sponsor and developer should not be informed in
+ advance of the exact composition of the sample, subject to
+ ensuring timely delivery of the sample and supporting
+ deliverable, e.g. test harnesses and equipment to the
+ evaluator in accordance with the evaluation schedule.
+
+
+ The choice of the sample should be free from bias to the
+ degree possible (one should not always choose the first or
+ last item). Ideally the sample selection should be done by
+ someone other than the evaluator.
+
+
+
+ Errors found in the sample can be categorised as being either
+ systematic or sporadic. If the error is systematic, the
+ problem should be corrected and a complete new sample
+ taken. If properly explained, sporadic errors might be solved
+ without the need for a new sample, although the explanation
+ should be confirmed. The evaluator should use judgement in
+ determining whether to increase the sample size or use a
+ different sample.
+
+
+
+ In general it is possible to perform the required evaluation
+ activities, sub-activities, and actions in any order or in
+ parallel. However, there are different kinds of dependencies
+ which have to be considered by the evaluator. This Subclause
+ provides general guidance on dependencies between different
+ activities, sub-activities, and actions.
+
+
+ For some cases the different assurance classes may recommend
+ or even require a sequence for the related activities. A
+ specific instance is the ST activity. The ST evaluation
+ activity is started prior to any TOE evaluation activities
+ since the ST provides the basis and context to perform
+ them. However, a final verdict on the ST evaluation may not
+ be possible until the TOE evaluation is complete, since
+ changes to the ST may result from activity findings during
+ the TOE evaluation.
+
+
+
+ Dependencies identified between components in CC Part 3 have
+ to be considered by the evaluator. Most dependencies are
+ one way, e.g. claims a
+ dependency on and . There are also instances of
+ mutual dependencies, where both components depend on each
+ other. An example of this is and .
+
+ A sub-activity can be assigned a pass verdict normally only
+ if all those sub-activities are successfully completed on
+ which it has a one-way dependency. For example, a pass
+ verdict on can normally
+ only be assigned if the sub-activities related to and are assigned a pass verdict too. In the case
+ of mutual dependency the ordering of these components is
+ down to the evaluator deciding which sub-activity to perform
+ first. Note this indicates that pass verdicts can normally
+ only be assigned once both sub-activities have been
+ successful.
+
+ So when determining whether a sub-activity will impact
+ another sub-activity, the evaluator should consider whether
+ this activity depends on potential evaluation results from
+ any dependent sub-activities. Indeed, it may be the case
+ that a dependent sub-activity will impact this sub-activity,
+ requiring previously completed evaluator actions to be
+ performed again.
+
+ A significant dependency effect occurs in the case of
+ evaluator-detected flaws. If a flaw is identified as a
+ result of conducting one sub-activity, the assignment of a
+ pass verdict to a dependent sub-activity may not be possible
+ until all flaws related to the sub-activity upon which it
+ depends are resolved.
+
+
+
+ It may be the case, that results which are generated by the
+ evaluator during one action are used for performing another
+ action. For example, actions for completeness and
+ consistency cannot be completed until the checks for content
+ and presentation have been completed. This means for example
+ that the evaluator is recommended to evaluate the PP/ST
+ rationale after evaluating the constituent parts of the
+ PP/ST.
+
+
+
+
+
+ The assurance class includes
+ requirements for
+
+
+ the application of configuration management, ensuring
+ that the integrity of the TOE is preserved;
+
+
+ measures, procedures, and standards concerned with
+ secure delivery of the TOE, ensuring that the security
+ protection offered by the TOE is not compromised during
+ the transfer to the user,
+
+
+ security measures, used to protect the development
+ environment.
+
+
+
+ A development site visit is a useful means whereby the
+ evaluator determines whether procedures are being followed
+ in a manner consistent with that described in the
+ documentation.
+
+ Reasons for visiting sites include:
+
+
+ to observe the use of the CM system as described in the
+ CM plan;
+
+
+ to observe the practical application of delivery
+ procedures as described in the delivery documentation;
+
+
+ to observe the application of security measures during
+ development and maintenance of the TOE as described in
+ the development security documentation.
+
+
+
+ Specific and detailed information is given in work units for
+ those activities where site visits are performed:
+
+
+ .n with n>=3
+ (especially work unit = = );
+
+
+ (especially work unit
+ );
+
+
+ (especially work unit
+ = ).
+
+
+
+
+
+ During an evaluation it is often necessary that the
+ evaluator will meet the developer more than once and it is a
+ question of good planning to combine the site visit with
+ another meeting to reduce costs. For example one might
+ combine the site visits for configuration management, for
+ the developer's security and for delivery. It may also be
+ necessary to perform more than one site visit to the same
+ site to allow the checking of all development phases. It
+ should be considered that development could occur at
+ multiple facilities within a single building, multiple
+ buildings at the same site, or at multiple sites.
+
+ The first site visit should be scheduled early during the
+ evaluation. In the case of an evaluation which starts during
+ the development phase of the TOE, this will allow corrective
+ actions to be taken, if necessary. In the case of an
+ evaluation which starts after the development of the TOE, an
+ early site visit could allow corrective measures to be put
+ in place if serious deficiencies in the applied procedures
+ emerge. This avoids unnecessary evaluation effort.
+
+ Interviews are also a useful means of determining whether
+ the written procedures reflect what is done. In conducting
+ such interviews, the evaluator should aim to gain a deeper
+ understanding of the analysed procedures at the development
+ site, how they are used in practise and whether they are
+ being applied as described in the provided evaluation
+ evidence. Such interviews complement but do not replace the
+ examination of evaluation evidence.
+
+ As a first step preparing the site visits the evaluators
+ should perform the evaluator work units concerning the
+ assurance class excluding the
+ aspects describing the results of the site visit. Based on
+ the information provided by the relevant developer
+ documentation and the remaining open questions which were
+ not answered by the documentation the evaluators compile a
+ check list of the questions which are to be resolved by the
+ site visits.
+
+ The first version of the evaluation report concerning the
+ class and the check list serves
+ as input for the consultation with the evaluation authority
+ concerning the site visits.
+
+ The check list serve as a guide line for the site visits,
+ which questions are to be answered by inspection of the
+ relevant measures, their application and results, and by
+ interviews. Where appropriate, sampling is used for gaining
+ the required level of confidence (see Subclause ).
+
+ The results of the site visits are recorded and serve as
+ input for the final version of the evaluation report
+ concerning the assurance class .
+
+ Other approaches to gain confidence should be considered
+ that provide an equivalent level of assurance (e.g. to
+ analyse evaluation evidence). Any decision not to make a
+ visit should be determined in consultation with the
+ evaluation authority. Appropriate security criteria and a
+ methodology should be based on other standards of the
+ Information Security Management Systems area.
+
+
+
+ In the following some keywords are provided, which topics
+ should be checked during an audit.
+
+ Basic
+
+
+ Items of the configuration list, including TOE, source
+ code, run time libraries, design documentation,
+ development tools ().
+
+
+ Tracking of design documentation, source code, user
+ guidance to different versions of the TOE.
+
+
+ Integration of the configuration system in the design
+ and development process, test planning, test analysis
+ and quality management procedures.
+
+
+
+ Test analysis
+
+
+ Tracking of test plans and results to specific
+ configurations and versions of the TOE.
+
+
+
+ Access control to development systems
+
+
+ Policies for access control and logging.
+
+
+ Policies for project specific assignment and changing
+ of access rights.
+
+
+
+ Clearance
+
+
+ Policies for clearance of the TOE and user guidance to
+ the customer.
+
+
+ Policies for testing and approving of components and
+ the TOE before deployment.
+
+
+
+
+
+ Infrastructure
+
+
+ Security measures for physical access control to the
+ development site and rationale for the effectiveness
+ of these measures.
+
+
+
+ Organisational measures
+
+
+ Organisational structure of the company in respect of
+ the security of the development environment.
+
+
+ Organisational separation between development,
+ production, testing and quality assurance.
+
+
+
+ Personal measures
+
+
+ Measures for education of the personnel in respect of
+ development security.
+
+
+ Measures and legal agreements of non disclosure of
+ internal information.
+
+
+
+ Access control
+
+
+ Assignment of secured objects (for instance TOE,
+ source code, run time libraries, design documentation,
+ development tools, user guidance) and security
+ policies.
+
+
+ Policies and responsibilities concerning the access
+ control and the handling of authentication
+ information.
+
+
+ Policies for logging of any kind access to the
+ development site and protection of the logging data.
+
+
+
+ Input, processing and output of data
+
+
+ Security measures for protection of output and output
+ devices (printer, plotter and displays).
+
+
+ Securing of local networks and communication
+ connections.
+
+
+
+ Storage, transfer and destruction of documents and data
+ media.
+
+
+ Policies for handling of documents and data media.
+
+
+ Policies and responsibilities for destruction of
+ sorted out documents and logging of these events.
+
+
+
+ Data protection
+
+
+ Policies and responsibilities for data and information
+ protection (e.g. for performing backups).
+
+
+
+ Contingency plan
+
+
+ Practises in case of emergency and responsibilities.
+
+
+ Documentation of the contingency measures concerning
+ access control.
+
+
+ Information of the personnel about applicable
+ practises in extreme cases. protection (e.g. for
+ performing backups).
+
+
+
+
+
+
+ The examples of checklists for site visits consist in tables
+ for the preparation of an audit and for the presentation of
+ the results of an audit.
+
+ The checklist structure given in the following is
+ preliminary. Dependent on the concrete contents of the new
+ guideline, changes might become necessary.
+ The checklist is divided into three subclauses according
+ to the subjects indicated in the introduction (Subclause ).
+
+
+ Configuration management system.
+
+
+ Delivery procedures.
+
+
+ Security measures during development.
+
+
+ These subclauses correspond to the actual CC class , especially the families .n with n>=3, and .
+ The subclauses are subdivided further into rows
+ corresponding to the relevant work units of the CEM.
+
+ The columns of the checklist contain in turn
+
+
+ a consecutive number,
+
+
+ the referenced work unit,
+
+
+ the references to the corresponding developer
+ documentation,
+
+
+ the explicit reproduction of the developer measures,
+
+
+ special remarks and questions to be clarified on the
+ visit (beyond the standard evaluator task to verify the
+ application of the indicated measures),
+
+
+ the result of the examinations during the visit.
+
+
+ If it is decided to have separate checklists for
+ preparation and reporting of the audit, the result column is
+ omitted in the preparation list and the remarks and
+ questions column is omitted in the reporting list. The
+ remaining columns should be identical in both lists.
+
+
+ Example of a checklist at EAL 4 (extract)
+
+
+
+
+
+ A. Examination of the CM system ( and )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ A.1
+
+
+ ,
+
+
+
+ ``Configuration Management System'', ch. ...
+
+
+ The system automatically managing the source code
+ files is capable of administering user profiles and
+ graded access rights, and of checking identification
+ and authentication of users.
+
+
+ Does reading or updating of a source code file
+ require a user authentication?
+
+
+ If a user has not the right to access a confidential
+ document, it is not even displayed to him in the
+ file list.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ B. Examination of the Delivery Procedures ()
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ B.1
+
+
+ ,
+
+
+
+ ``Delivery of the TOE'', ch. ...
+
+
+ The software is transmitted PGP-signed and encrypted
+ to the customer.
+
+
+ ---
+
+
+ The evaluators have checked the process and found it
+ as described, additionally a checksum is
+ transmitted.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ C. Examination of the organisational and
+ infrastructural developer security
+ (,
+ ,
+ )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ C.1
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Premises)
+
+
+ The premises are protected by security fencing.
+
+
+ Is the fencing sufficiently strong and high to
+ prevent an easy intrusion into the premises?
+
+
+ The evaluators considered the fencing to be
+ sufficiently strong and high.
+
+
+
+
+ C.2
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Building)
+
+
+ The building has the following access possibilities:
+ The main entrance which is surveyed by the reception
+ and is closed if the reception is not manned. And an
+ access in the goods reception which is secured by
+ two roller shutters.
+
+
+ Is the listing of the access possibilities complete?
+
+
+ Beyond the indicated access possibilities, there is
+ an emergency exit that cannot be opened from the
+ outside. The roller shutters mentioned before can be
+ operated only from inside.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+
+ This CEM describes the minimum technical work that evaluations
+ conducted under oversight (scheme) bodies must
+ perform. However, it also recognises (both explicitly and
+ implicitly) that there are activities or methods upon which
+ mutual recognition of evaluation results do not rely. For the
+ purposes of thoroughness and clarity, and to better delineate
+ where the CEM ends and an individual scheme's methodology
+ begins, the following matters are left up to the discretion of
+ the schemes. Schemes may choose to provide the following,
+ although they may choose to leave some unspecified. (Every
+ effort has been made to ensure this list is complete;
+ evaluators encountering a subject neither listed here nor
+ addressed in the CEM should consult with their evaluation
+ schemes to determine under whose auspices the subject
+ falls.)
+
+ The matters that schemes may choose to specify include:
+
+
+ what is required in ensuring that an evaluation was done
+ sufficiently - every scheme has a means of verifying the
+ technical competence, understanding of work and the work
+ of its evaluators, whether by requiring the evaluators to
+ present their findings to the oversight body, by requiring
+ the oversight body to redo the evaluator's work, or by
+ some other means that assures the scheme that all
+ evaluation bodies are adequate and comparable;
+
+
+ process for disposing of evaluation evidence upon
+ completion of an evaluation;
+
+
+ any requirements for confidentiality (on the part of the
+ evaluator and the non-disclosure of information obtained
+ during evaluation);
+
+
+ the course of action to be taken if a problem is
+ encountered during the evaluation (whether the evaluation
+ continues once the problem is remedied, or the evaluation
+ ends immediately and the remedied product must be
+ re-submitted for evaluation);
+
+
+ any specific (natural) language in which documentation
+ must be provided;
+
+
+ any recorded evidence that must be submitted in the ETR -
+ this CEM specifies the minimum to be reported in an ETR;
+ however, individual schemes may require additional
+ information to be included;
+
+
+ any additional reports (other than the ETR) required from
+ the evaluators -for example, testing reports;
+
+
+ any specific ORs that may be required by the scheme,
+ including the structure, recipients, etc. of any such ORs;
+
+
+ any specific content structure of any written report as a
+ result from an ST evaluation - a scheme may have a
+ specific format for all of its reports detailing results
+ of an evaluation, be it the evaluation of a TOE or of an
+ ST;
+
+
+ any additional PP/ST identification information required;
+
+
+ any activities to determine the suitability of
+ explicitly-stated requirements in an ST;
+
+
+ any requirements for provision of evaluator evidence to
+ support re-evaluation and re-use of evidence;
+
+
+ any specific handling of scheme identifiers, logos,
+ trademarks, etc.;
+
+
+ any specific guidance in dealing with cryptography;
+
+
+ handling and application of scheme, national and
+ international interpretations;
+
+
+ a list or characterisations of suitable alternative
+ approaches to testing where testing is infeasible;
+
+
+ the mechanism by which an overseer can determine what
+ steps an evaluator took while testing;
+
+
+ preferred test approach (if any): at internal interface or
+ at external interface;
+
+
+ a list or characterisation of acceptable means of
+ conducting the evaluator's vulnerability analysis
+ (e.g. flaw hypothesis methodology);
+
+
+ information regarding any vulnerabilities and weaknesses
+ to be considered.
+
+
+
+
+
+
+
+ This Clause presents the expected results from PP and ST/TOE
+ evaluations.
+
+ PP evaluations lead to catalogues of evaluated PPs.
+
+ An ST evaluation leads to intermediate results that
+ are used in the frame of a TOE evaluation.
+
+
+ ST/TOE evaluations lead to catalogues of evaluated
+ TOEs. In many cases these catalogues will refer to the IT
+ products that the TOEs are derived from rather than the
+ specific TOE. Therefore, the existence of an IT product in
+ a catalogue should not be construed as meaning that the
+ whole IT product has been evaluated; instead the actual
+ extent of the ST/TOE evaluation is defined by the ST.
+
+
+
+ STs may be based on packages, evaluated PPs or
+ non-evaluated PPs - however this is not mandatory, as STs do
+ not have to be based on anything at all.
+
+ Evaluation should lead to objective and repeatable results
+ that can be cited as evidence, even if there is no absolute
+ objective scale for representing the results of a security
+ evaluation. The existence of a set of evaluation criteria is a
+ necessary pre-condition for evaluation to lead to a meaningful
+ result and provides a technical basis for mutual recognition
+ of evaluation results between evaluation authorities.
+
+ An evaluation result represents the findings of a specific
+ type of investigation of the security properties of a
+ TOE. Such a result does not automatically guarantee fitness
+ for use in any particular application environment. The
+ decision to accept a TOE for use in a specific application
+ environment is based on consideration of many security issues
+ including the evaluation findings.
+
+
+
+ The CC contains the evaluation criteria that permit an
+ evaluator to state whether a PP is complete, consistent, and
+ technically sound and hence suitable for use in developing an
+ ST.
+
+ Evaluation of the PP shall result in a pass/fail statement. If
+ the PP evaluation has resulted in a pass statement, the PP
+ shall be eligible for inclusion within a registry. The results
+ of the evaluation shall also include a ``Conformance Claim''
+ (see Subclause ).
+
+
+
+ The CC contains the evaluation criteria that enable an
+ evaluator to determine whether sufficient assurance exists
+ that the TOE satisfies the SFRs in the ST. Evaluation of the
+ TOE shall therefore result in a pass/fail statement for the
+ ST. If both the ST and the TOE evaluation have resulted in a
+ pass statement, the underlying product is eligible for
+ inclusion in a registry. The results of evaluation shall also
+ include a ``Conformance Claim'' as defined in the next
+ Subclause.
+ It may be the case that the evaluation results are
+ subsequently used in a certification process, but this
+ certification process is outside the scope of the CC.
+
+
+
+ The conformance claim indicates the source of the collection
+ of requirements that is met by a PP or ST that passes its
+ evaluation. This conformance claim contains a CC conformance
+ claim that:
+
+
+ describes the version of the CC to which the PP or ST
+ claims conformance.
+
+
+ describes the conformance to CC Part 2 (security
+ functional requirements) as either:
+
+
+ CC Part 2 conformant - A PP or ST is CC
+ Part 2 conformant if all SFRs in that PP or ST are
+ based only upon functional components in CC Part 2, or
+
+
+ CC Part 2 extended - A PP or ST is CC
+ Part 2 extended if at least one SFR in that PP or ST
+ is not based upon functional components in CC Part 2.
+
+
+
+
+ describes the conformance to CC Part 3 (security assurance
+ requirements) as either:
+
+
+ CC Part 3 conformant - A PP or ST is CC
+ Part 3 conformant if all SARs in that PP or ST are
+ based only upon assurance components in CC Part 3, or
+
+
+ CC Part 3 extended - A PP or ST is CC
+ Part 3 extended if at least one SAR in that PP or ST
+ is not based upon assurance components in CC Part 3.
+
+
+
+
+
+ Additionally, the conformance claim may include a statement
+ made with respect to packages, in which case it consists of
+ one of the following:
+
+
+ Package name Conformant - A PP or ST is
+ conformant to a pre-defined package (e.g. EAL) if:
+
+ the SFRs of that PP or ST are identical to the
+ SFRs in the package, or
+ the SARs of that PP or ST are identical to the
+ SARs in the package.
+
+
+
+ Package name Augmented - A PP or ST is an
+ augmentation of a predefined package if:
+
+ the SFRs of that PP or ST contain all SFRs in the
+ package, but have at least one additional SFR or one
+ SFR that is hierarchically higher than an SFR in the
+ package.
+ the SARs of that PP or ST contain all SARs in the
+ package, but have at least one additional SAR or one
+ SAR that is hierarchically higher than an SAR in the
+ package.
+
+
+
+ Note that when a TOE is successfully evaluated to a given
+ ST, any conformance claims of the ST also hold for the TOE. A
+ TOE can therefore also be e.g. CC Part 2 conformant.
+
+ Finally, the conformance claim may also include two statements
+ with respect to Protection Profiles:
+
+
+ PP Conformant - A PP or TOE meets
+ specific PP(s), which are listed as part of the
+ conformance result.
+
+
+ Conformance Statement (Only for PPs) -
+ This statement describes the manner in which PPs or STs
+ must conform to this PP: strict or demonstrable. For more
+ information on this Conformance Statement, see .
+
+
+
+
+
+ Once an ST and a TOE have been evaluated, asset owners can
+ have the assurance (as defined in the ST) that the TOE,
+ together with the operational environment, counters the
+ threats. The evaluation results may be used by the asset owner
+ in deciding whether to accept the risk of exposing the assets
+ to the threats.
+
+ However, the asset owner should carefully check whether:
+
+ the Security Problem Definition in the ST matches the
+ security problem of the asset owner;
+
+ the Operational Environment of the asset owner conforms
+ (or can be made to conform) to the security objectives for
+ the Operational Environment described in the ST.
+
+
+ If either of these is not the case, the TOE may not be
+ suitable for the purposes of the asset owner.
+
+ Additionally, once an evaluated TOE is in operation, it is
+ possible that previously unknown errors or vulnerabilities in
+ the TOE may surface. In that case, the developer may correct
+ the TOE (to repair the vulnerabilities) or the ST. However,
+ the evaluation results of the old ST and TOE do not apply to
+ the new ST and TOE.
+ If it is deemed necessary that confidence is regained,
+ re-evaluation is needed. The CC may be used for this
+ re-evaluation, but detailed procedures for re-evaluation are
+ outside the scope of this document.
+
+
+
+
+ The following annexes through provide the application notes for the functional
+ classes defined in the main body of this part of the CC.
+
+
+ For the purposes of this document, the terms, definitions,
+ symbols and abbreviated terms given in CC Part 1 apply.
+
+
+ Security functional components, as defined in this CC Part 2, are
+ the basis for the security functional requirements expressed in a
+ Protection Profile (PP) or a Security Target (ST). These
+ requirements describe the desired security behaviour expected of a
+ Target of Evaluation (TOE) and are intended to meet the security
+ objectives as stated in a PP or an ST. These requirements describe
+ security properties that users can detect by direct interaction
+ (i.e. inputs, outputs) with the IT or by the IT response to
+ stimulus.
+
+ Security functional components express security requirements
+ intended to counter threats in the assumed operating environment
+ of the TOE and/or cover any identified organisational security
+ policies and assumptions.
+
+ The audience for this CC Part 2 includes consumers, developers,
+ and evaluators of secure IT products. CC Part 1
+ Chapter provides additional
+ information on the target audience of the CC, and on the use of
+ the CC by the groups that comprise the target audience. These
+ groups may use this part of the CC as follows:
+
+
+ Consumers, who use this CC Part 2 when selecting components to
+ express functional requirements to satisfy the security
+ objectives expressed in a PP or ST. CC Part 1 Section provides more detailed
+ information on the relationship between security objectives
+ and security requirements.
+
+
+ Developers, who respond to actual or perceived consumer
+ security requirements in constructing a TOE, may find a
+ standardised method to understand those requirements in this
+ part of the CC. They can also use the contents of this part of
+ the CC as a basis for further defining the TOE security
+ functionality and mechanisms that comply with those
+ requirements.
+
+
+ Evaluators, who use the functional requirements defined in
+ this part of the CC in verifying that the TOE functional
+ requirements expressed in the PP or ST satisfy the IT security
+ objectives and that all dependencies are accounted for and
+ shown to be satisfied. Evaluators also should use this part of
+ the CC to assist in determining whether a given TOE satisfies
+ stated requirements.
+
+
+
+
+
+ The CC and the associated security functional requirements
+ described herein are not meant to be a definitive answer to all
+ the problems of IT security. Rather, the CC offers a set of well
+ understood security functional requirements that can be used to
+ create trusted products reflecting the needs of the market. These
+ security functional requirements are presented as the current
+ state of the art in requirements specification and
+ evaluation.
+
+ This part of the CC does not presume to include all possible
+ security functional requirements but rather contains those that
+ are known and agreed to be of value by the CC Part 2 authors at
+ the time of release.
+
+ Since the understanding and needs of consumers may change, the
+ functional requirements in this part of the CC will need to be
+ maintained. It is envisioned that some PP/ST authors may have
+ security needs not (yet) covered by the functional requirement
+ components in CC Part 2. In those cases the PP/ST author may
+ choose to consider using functional requirements not taken from
+ the CC (referred to as extensibility), as explained in annexes
+ and
+ of
+ CC Part 1.
+
+
+
+ Clause
+ describes the paradigm used in the security functional
+ requirements of CC Part 2.
+
+ Clause
+ introduces the catalogue of CC Part 2 functional components
+ while clauses through describe the functional classes.
+
+ provides explanatory information for potential
+ users of the functional components including a complete cross
+ reference table of the functional component dependencies.
+
+ through provide the explanatory information for the
+ functional classes. This material must be seen as normative
+ instructions on how to apply relevant operations and select
+ appropriate audit or documentation information; the use of the
+ auxiliary verb should means that the instruction is strongly
+ preferred, but others may be justifiable. Where different
+ options are given, the choice is left to the PP/ST
+ author.
+
+ Those who author PPs or STs should refer to clause 2 of CC Part
+ 1 for relevant structures, rules, and guidance:
+
+
+ CC Part 1, clause
+ defines the terms used in the CC.
+
+
+ CC Part 1, annex defines the
+ structure for STs.
+
+
+ CC Part 1, annex defines the
+ structure for PPs.
+
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest edition
+ of the referenced document (including any amendments) applies.CC
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 1: Introduction and general model.
+
+
+ This part of the CC defines the required structure and content
+ of security functional components for the purpose of security
+ evaluation. It includes a catalogue of functional components
+ that will meet the common security functionality requirements
+ of many IT products.
+
+
+ This chapter describes the paradigm used in the security
+ functional requirements of this part of the CC. Key concepts
+ discussed are highlighted in bold/italics. This section is not
+ intended to replace or supersede any of the terms found in CC Part
+ 1, chapter .
+
+ This part of the CC is a catalogue of security functional
+ requirements that can be specified for a Target of
+ Evaluation (TOE). A TOE is a set of software, firmware
+ and/or hardware possibly accompanied by user and administrator
+ guidance documentation. A TOE may contain resources such as
+ electronic storage media (e.g. main memory, disk space),
+ peripheral devices (e.g. printers), and computing capacity
+ (e.g. CPU time) that can be used for processing and storing
+ information and is the subject of an evaluation.
+
+ TOE evaluation is concerned primarily with ensuring that a defined
+ set of security functional requirements (SFRs) is
+ enforced over the TOE resources. The SFRs define the rules by
+ which the TOE governs access to and use of its resources, and thus
+ information and services controlled by the TOE.
+
+ The SFRs may, in turn, include multiple Security Function
+ Policies (SFPs). Each SFP has a scope of control, that
+ defines the subjects, objects, resources or information, and
+ operations controlled under the SFP. All SFPs are implemented by
+ the TSF (see below), whose mechanisms enforce the rules defined in
+ the SFRs and provide necessary capabilities.
+
+ Those portions of a TOE that must be relied on for the correct
+ enforcement of the SFRs are collectively referred to as the
+ TOE Security Functionality (TSF). The TSF consists of
+ all hardware, software, and firmware of a TOE that is either
+ directly or indirectly relied upon for security enforcement.
+
+ The TOE may be a monolithic product containing hardware, firmware,
+ and software.
+
+ Alternatively a TOE may be a distributed product that consists
+ internally of multiple separated parts. Each of these parts of the
+ TOE provides a particular service for the TOE, and is connected to
+ the other parts of the TOE through an internal communication
+ channel. This channel can be as small as a processor bus,
+ or may encompass a network internal to the TOE.
+
+ When the TOE consists of multiple parts, each part of the TOE may
+ have its own part of the TSF which exchanges user and TSF data
+ over internal communication channels with other parts of the
+ TSF. This interaction is called internal TOE
+ transfer. In this case the separate parts of the TSF
+ abstractly form the composite TSF, which enforces the SFRs.
+
+ TOE interfaces may be localised to the particular TOE, or they may
+ allow interaction with other IT products over external
+ communication channels. These external interactions with
+ other IT products may take two forms:
+
+
+ The SFRs of the other ``trusted IT product'' and the SFRs of
+ the TOE have been administratively coordinated and the other
+ trusted IT product is assumed to enforce its SFRs correctly
+ (e. g. by being separately evaluated). Exchanges of
+ information in this situation are called inter-TSF
+ transfers, as they are between the TSFs of distinct
+ trusted products.
+
+
+ The other IT product may not be trusted, it may be called an
+ ``untrusted IT product''. Therefore its SFRs are either
+ unknown or their implementation is not viewed as
+ trustworthy. TSF mediated exchanges of information in this
+ situation are called transfers outside of the
+ TOE, as there is no TSF (or its policy characteristics
+ are unknown) on the other IT product.
+
+
+ The set of interfaces, whether interactive (man-machine
+ interface) or programmatic (application programming interface),
+ through which resources are accessed that are mediated by the TSF,
+ or information is obtained from the TSF, is referred to as the
+ TSF Interface (TSFI). The TSFI defines the boundaries
+ of the TOE functionality that provide for the enforcement of the
+ SFRs.
+
+ Users are outside of the TOE. However, in order to request that
+ services be performed by the TOE that are subject to rules defined
+ in the SFRs, users interact with the TOE through the TSFI. There
+ are two types of users of interest to the CC Part 2 security
+ functional requirements: human users and
+ external IT entities. Human users may further be
+ differentiated as local human users, meaning they
+ interact directly with the TOE via TOE devices
+ (e.g. workstations), or remote human users, meaning
+ they interact indirectly with the TOE through another IT product.
+
+ A period of interaction between users and the TSF is referred to
+ as a user session. Establishment of user sessions can
+ be controlled based on a variety of considerations, for example:
+ user authentication, time of day, method of accessing the TOE, and
+ number of allowed concurrent sessions (per user or in total).
+
+ This part of the CC uses the term authorised to
+ signify a user who possesses the rights and/or privileges
+ necessary to perform an operation. The term authorised
+ user, therefore, indicates that it is allowable for a user
+ to perform a specific operation or a set of operations as defined
+ by the SFRs.
+
+ To express requirements that call for the separation of
+ administrator duties, the relevant CC Part 2 security functional
+ components (from family ) explicitly
+ state that administrative roles are required. A role
+ is a pre-defined set of rules establishing the allowed
+ interactions between a user operating in that role and the TOE. A
+ TOE may support the definition of any number of roles. For
+ example, roles related to the secure operation of a TOE may
+ include ``Audit Administrator'' and ``User Accounts
+ Administrator''.
+
+ TOEs contain resources that may be used for the
+ processing and storing of information. The primary goal of the TSF
+ is the complete and correct enforcement of the SFRs over the
+ resources and information that the TOE controls.
+
+ TOE resources can be structured and utilised in many different
+ ways. However, CC Part 2 makes a specific distinction that allows
+ for the specification of desired security properties. All entities
+ that can be created from resources can be characterised in one of
+ two ways. The entities may be active, meaning that they are the
+ cause of actions that occur internal to the TOE and cause
+ operations to be performed on information. Alternatively, the
+ entities may be passive, meaning that they are either the
+ container from which information originates or to which
+ information is stored.
+
+ Active entities in the TOE that perform operations on objects are
+ referred to as subjects. Several types of subjects
+ may exist within a TOE:
+
+
+ those acting on behalf of an authorised user (e.g. UNIX
+ processes);
+
+
+ those acting as a specific functional process that may in turn
+ act on behalf of multiple users (e.g. functions as might be
+ found in client/server architectures); or
+
+
+ those acting as part of the TOE itself (e.g. processes not
+ acting on behalf of a user).
+
+
+
+ CC Part 2 addresses the enforcement of the SFRs over types of
+ subjects as those listed above.
+
+ Passive entities in the TOE that contain or receive information
+ and upon which subjects perform operations are called
+ objects. In the case where a subject (an active
+ entity) is the target of an operation (e.g. interprocess
+ communication), a subject may also be acted on as an object.
+
+ Objects can contain information. This concept is
+ required to specify information flow control policies as addressed
+ in the FDP class.
+
+ Users, subjects, information, objects, sessions and resources
+ controlled by rules in the SFRs may possess certain
+ attributes that contain information that is used by
+ the TOE for its correct operation. Some attributes, such as file
+ names, may be intended to be informational or may be used to
+ identify individual resources while others, such as access control
+ information, may exist specifically for the enforcement of the
+ SFRs. These latter attributes are generally referred to as
+ ``security attributes''. The word attribute will be
+ used as a shorthand in some places of this part of the CC for the
+ word ``security attribute''. However, no matter what the intended
+ purpose of the attribute information, it may be necessary to have
+ controls on attributes as dictated by the SFRs.
+
+ Data in a TOE is categorised as either user data or TSF
+ data. Figure depicts this
+ relationship. User Data is information stored in TOE
+ resources that can be operated upon by users in accordance with
+ the SFRs and upon which the TSF places no special meaning. For
+ example, the content of an electronic mail message is user
+ data. TSF Data is information used by the TSF in making decisions
+ as required by the SFRs. TSF Data may be influenced
+ by users if allowed by the SFRs. Security attributes,
+ authentication data, TSF internal status variables used by the
+ rules defined in the SFRs or used for the protection of the TSF
+ and access control list entries are examples of TSF data.
+
+ There are several SFPs that apply to data protection such as
+ access control SFPs and information flow
+ control SFPs. The mechanisms that implement access control
+ SFPs base their policy decisions on attributes of the users,
+ resources, subjects, objects, sessions, TSF status data and
+ operations within the scope of control. These attributes are used
+ in the set of rules that govern operations that subjects may
+ perform on objects.
+
+ The mechanisms that implement information flow control SFPs base
+ their policy decisions on the attributes of the subjects and
+ information within the scope of control and the set of rules that
+ govern the operations by subjects on information. The attributes
+ of the information, which may be associated with the attributes of
+ the container or may be derived from the data in the container,
+ stay with the information as it is processed by the TSF.
+
+
+ Two specific types of TSF data addressed by CC Part 2 can be, but
+ are not necessarily, the same. These are authentication
+ data and secrets.
+
+ Authentication data is used to verify the claimed identity of a
+ user requesting services from a TOE. The most common form of
+ authentication data is the password, which depends on being kept
+ secret in order to be an effective security mechanism. However,
+ not all forms of authentication data need to be kept
+ secret. Biometric authentication devices (e.g. fingerprint
+ readers, retinal scanners) do not rely on the fact that the data
+ is kept secret, but rather that the data is something that only
+ one user possesses and that cannot be forged.
+
+ The term secrets, as used in CC Part 2 functional requirements,
+ while applicable to authentication data, is intended to also be
+ applicable to other types of data that must be kept secret in
+ order to enforce a specific SFP. For example, a trusted channel
+ mechanism that relies on cryptography to preserve the
+ confidentiality of information being transmitted via the channel
+ can only be as strong as the method used to keep the cryptographic
+ keys secret from unauthorised disclosure.
+
+ Therefore, some, but not all, authentication data needs to be kept
+ secret and some, but not all, secrets are used as authentication
+ data. Figure shows this relationship
+ between secrets and authentication data. In the Figure the types
+ of data typically encountered in the authentication data and the
+ secrets sections are indicated.
+
+
+
+
+
+ This clause provides an overview of the evaluation process
+ and defines the tasks an evaluator is intended to perform when
+ conducting an evaluation.
+
+ Each evaluation, whether of a PP or TOE (including ST),
+ follows the same process, and has four evaluator tasks in
+ common: the input task, the output task, the evaluation
+ sub-activities, and the demonstration of the technical
+ competence to the evaluation authority task.
+
+ The input task and the output tasks, which are related to
+ management of evaluation evidence and to report generation,
+ are entirely described in this clause. Each task has
+ associated sub-tasks that apply to, and are normative for all
+ CC evaluations (evaluation of a PP or a TOE).
+
+ The evaluation sub-activities are only introduced in this
+ clause, and fully described in the following clauses.
+
+ In contrast to the evaluation sub-activities, input and output
+ tasks have no verdicts associated with them as they do not map
+ to CC evaluator action elements; they are performed in order
+ to ensure conformance with the universal principles and to
+ comply with the CEM.
+
+ The demonstration of the technical competence to the
+ evaluation authority task may be fulfilled by the evaluation
+ authority analysis of the output tasks results, or may include
+ the demonstration by the evaluators of their understanding of
+ the inputs for the evaluation sub-activities. This task has no
+ associated evaluator verdict, but has an evaluator authority
+ verdict. The detailed criteria to pass this task are left to
+ the discretion of the evaluation authority, as noted in Annex
+ .
+
+
+
+
+ This subclause presents the general model of the methodology
+ and identifies:
+
+
+ roles and responsibilities of the parties involved in
+ the evaluation process;
+
+
+ the general evaluation model.
+
+
+
+
+
+ The general model defines the following roles: sponsor,
+ developer, evaluator and evaluation authority.
+
+ The sponsor is responsible for requesting and supporting an
+ evaluation. This means that the sponsor establishes the
+ different agreements for the evaluation (e.g. commissioning
+ the evaluation). Moreover, the sponsor is responsible for
+ ensuring that the evaluator is provided with the evaluation
+ evidence.
+
+ The developer produces the TOE and is responsible for
+ providing the evidence required for the evaluation
+ (e.g. training, design information), on behalf of the
+ sponsor.
+
+ The evaluator performs the evaluation tasks required in the
+ context of an evaluation: the evaluator receives the
+ evaluation evidence from the developer on behalf of the
+ sponsor or directly from the sponsor, performs the
+ evaluation sub-activities and provides the results of the
+ evaluation assessment to the evaluation authority.
+
+ The evaluation authority establishes and maintains the
+ scheme, monitors the evaluation conducted by the evaluator,
+ and issues certification/validation reports as well as
+ certificates based on the evaluation results provided by the
+ evaluator.
+
+
+
+ To prevent undue influence from improperly affecting an
+ evaluation, some separation of roles is required. This
+ implies that the roles described above are fulfilled by
+ different entities, except that the roles of developer and
+ sponsor may be satisfied by a single entity.
+
+ Moreover, some evaluations (e.g. EAL1 evaluation) may not
+ require the developer to be involved in the project. In this
+ case, it is the sponsor who provides the TOE to the
+ evaluator and who generates the evaluation evidence.
+
+
+
+ The evaluation process consists of the evaluator performing
+ the evaluation input task, the evaluation output task and
+ the evaluation sub-activities. Figure provides an overview of
+ the relationship between these tasks and
+ sub-activities.
+
+
+ The evaluation process may be preceded by a preparation
+ phase where initial contact is made between the sponsor and
+ the evaluator. The work that is performed and the
+ involvement of the different roles during this phase may
+ vary. It is typically during this step that the evaluator
+ performs a feasibility analysis to assess the likelihood of
+ a successful evaluation.
+
+
+
+ The evaluator assigns verdicts to the requirements of the CC
+ and not to those of the CEM. The most granular CC structure
+ to which a verdict is assigned is the evaluator action
+ element (explicit or implied). A verdict is assigned to an
+ applicable CC evaluator action element as a result of
+ performing the corresponding CEM action and its constituent
+ work units. Finally, an evaluation result is assigned, as
+ described in CC Part 1, Clause .
+
+
+ The CEM recognises three mutually exclusive verdict states:
+
+
+ Conditions for a pass verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST or TOE under evaluation are met. The
+ conditions for passing the element are defined as:
+
+
+ the constituent work units of the related CEM
+ action, and;
+
+
+ all evaluation evidence required for performing
+ these work units is coherent, that is it can be
+ fully and completely understood by the evaluator,
+ and
+
+
+ all evaluation evidence required for performing
+ these work units does not have any obvious internal
+ inconsistencies or inconsistencies with other
+ evaluation evidence. Note that obvious means here
+ that the evaluator discovers this inconsistency
+ while performing the work units: the evaluator
+ should not undertake a full consistency analysis
+ across the entire evaluation evidence every time a
+ work unit is performed.
+
+
+
+
+ Conditions for a fail verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST, or TOE under evaluation are not met, or
+ that the evidence is incoherent, or an obvious
+ inconsistency in the evaluation evidence has been found;
+
+
+ All verdicts are initially inconclusive
+ and remain so until either a pass or
+ fail verdict is assigned.
+
+
+
+ The overall verdict is pass if and only if
+ all the constituent verdicts are also
+ pass. In the example illustrated in Figure
+ , if the verdict for one
+ evaluator action element is fail then the
+ verdicts for the corresponding assurance component,
+ assurance class, and overall verdict are also
+ fail.
+
+
+
+
+
+ The objective of this task is to ensure that the evaluator
+ has available the correct version of the evaluation evidence
+ necessary for the evaluation and that it is adequately
+ protected. Otherwise, the technical accuracy of the
+ evaluation cannot be assured, nor can it be assured that the
+ evaluation is being conducted in a way to provide repeatable
+ and reproducible results.
+
+
+
+ The responsibility to provide all the required evaluation
+ evidence lies with the sponsor. However, most of the
+ evaluation evidence is likely to be produced and supplied by
+ the developer, on behalf of the sponsor.
+
+ Since the assurance requirements apply to the entire TOE,
+ all evaluation evidence pertaining to all parts of the TOE
+ is to be made available to the evaluator. The scope and
+ required content of such evaluation evidence is independent
+ of the level of control that the developer has over each of
+ the parts of the TOE. For example, if design is required,
+ then the requirements will
+ apply to all subsystems that are part of the TSF. In
+ addition, assurance requirements that call for procedures to
+ be in place (for example,
+ and ) will also apply to the
+ entire TOE (including any part produced by another
+ developer).
+
+ It is recommended that the evaluator, in conjunction with
+ the sponsor, produce an index to required evaluation
+ evidence. This index may be a set of references to the
+ documentation. This index should contain enough information
+ (e.g. a brief summary of each document, or at least an
+ explicit title, indication of the subclauses of interest) to
+ help the evaluator to find easily the required
+ evidence.
+
+ It is the information contained in the evaluation evidence
+ that is required, not any particular document
+ structure. Evaluation evidence for a sub-activity may be
+ provided by separate documents, or a single document may
+ satisfy several of the input requirements of a
+ sub-activity.
+
+ The evaluator requires stable and formally-issued versions
+ of evaluation evidence. However, draft evaluation evidence
+ may be provided during an evaluation, for example, to help
+ an evaluator make an early, informal assessment, but is not
+ used as the basis for verdicts. It may be helpful for the
+ evaluator to see draft versions of particular appropriate
+ evaluation evidence, such as:
+
+
+ test documentation, to allow the evaluator to make an
+ early assessment of tests and test procedures;
+
+
+ design documents, to provide the evaluator with
+ background for understanding the TOE design;
+
+
+ source code or hardware drawings, to allow the evaluator
+ to assess the application of the developer's standards.
+
+
+
+ Draft evaluation evidence is more likely to be encountered
+ where the evaluation of a TOE is performed concurrently with
+ its development. However, it may also be encountered during
+ the evaluation of an already-developed TOE where the
+ developer has had to perform additional work to address a
+ problem identified by the evaluator (e.g. to correct an
+ error in design or implementation) or to provide evaluation
+ evidence of security that is not provided in the existing
+ documentation (e.g. in the case of a TOE not originally
+ developed to meet the requirements of the CC).
+
+
+
+
+ The evaluator shall perform configuration control of the
+ evaluation evidence.
+
+ The CC implies that the evaluator is able to identify and
+ locate each item of evaluation evidence after it has been
+ received and is able to determine whether a specific
+ version of a document is in the evaluator's
+ possession.
+
+ The evaluator shall protect the evaluation evidence from
+ alteration or loss while it is in the evaluator's
+ possession.
+
+
+
+ Schemes may wish to control the disposal of evaluation
+ evidence at the conclusion of an evaluation. The disposal
+ of the evaluation evidence should be achieved by one or
+ more of:
+
+
+ returning the evaluation evidence;
+
+
+ archiving the evaluation evidence;
+
+
+ destroying the evaluation evidence.
+
+
+
+
+
+ An evaluator may have access to sponsor and developer
+ commercially-sensitive information (e.g. TOE design
+ information, specialist tools), and may have access to
+ nationally-sensitive information during the course of an
+ evaluation. Schemes may wish to impose requirements for
+ the evaluator to maintain the confidentiality of the
+ evaluation evidence. The sponsor and evaluator may
+ mutually agree to additional requirements as long as these
+ are consistent with the scheme.
+
+ Confidentiality requirements affect many aspects of
+ evaluation work, including the receipt, handling, storage
+ and disposal of evaluation evidence.
+
+
+
+
+
+ The evaluation sub-activities vary depending whether it is a
+ PP or a TOE evaluation. Moreover, in the case of a TOE
+ evaluation, the sub-activities depend upon the selected
+ assurance requirements.
+
+
+
+
+ The objective of this Subclause is to describe the Observation
+ Report (OR) and the Evaluation Technical Report
+ (ETR). Schemes may require additional evaluator reports such
+ as reports on individual units of work, or may require
+ additional information to be contained in the OR and the
+ ETR. The CEM does not preclude the addition of information
+ into these reports as the CEM specifies only the minimum
+ information content.
+
+ Consistent reporting of evaluation results facilitates the
+ achievement of the universal principle of repeatability and
+ reproducibility of results. The consistency covers the type
+ and the amount of information reported in the ETR and
+ OR. ETR and OR consistency among different evaluations is
+ the responsibility of the overseer.
+
+ The evaluator performs the two following sub-tasks in order
+ to achieve the CEM requirements for the information content
+ of reports:
+
+
+ write OR sub-task (if needed in the context of the
+ evaluation);
+
+
+ write ETR sub-task.
+
+
+
+
+
+ The evaluator delivers the ETR to the evaluation authority,
+ as well as any ORs as they become available. Requirements
+ for controls on handling the ETR and ORs are established by
+ the scheme which may include delivery to the sponsor or
+ developer. The ETR and ORs may include sensitive or
+ proprietary information and may need to be sanitised before
+ they are given to the sponsor.
+
+
+
+ In this version of the CEM, the requirements for the
+ provision of evaluator evidence to support re-evaluation and
+ re-use have not been explicitly stated. Where information
+ for re-evaluation or re-use is required by the sponsor, the
+ scheme under which the evaluation is being performed should
+ be consulted.
+
+
+
+ ORs provide the evaluator with a mechanism to request a
+ clarification (e.g. from the overseer on the application of
+ a requirement) or to identify a problem with an aspect of
+ the evaluation.
+
+ In the case of a fail verdict, the evaluator shall provide
+ an OR to reflect the evaluation result. Otherwise, the
+ evaluator may use ORs as one way of expressing clarification
+ needs.
+
+ For each OR, the evaluator shall report the following:
+
+
+ the identifier of the PP or TOE evaluated;
+
+
+ the evaluation task/sub-activity during which the
+ observation was generated;
+
+
+ the observation;
+
+
+ the assessment of its severity (e.g. implies a fail
+ verdict, holds up progress on the evaluation, requires a
+ resolution prior to evaluation being completed);
+
+
+ the identification of the organisation responsible for
+ resolving the issue;
+
+
+ the recommended timetable for resolution;
+
+
+ the assessment of the impact on the evaluation of
+ failure to resolve the observation.
+
+
+
+ The intended audience of an OR and procedures for handling
+ the report depend on the nature of the report's content and
+ on the scheme. Schemes may distinguish different types of
+ ORs or define additional types, with associated differences
+ in required information and distribution (e.g. evaluation
+ ORs to overseers and sponsors).
+
+
+
+
+ The evaluator shall provide an ETR to present technical
+ justification of the verdicts.
+
+ The CEM defines the ETR's minimum content requirement;
+ however, schemes may specify additional content and
+ specific presentational and structural requirements. For
+ instance, schemes may require that certain introductory
+ material (e.g. disclaimers and copyright Clauses) be
+ reported in the ETR.
+
+ The reader of the ETR is assumed to be familiar with
+ general concepts of information security, the CC, the CEM,
+ evaluation approaches and IT.
+
+ The ETR supports the evaluation authority to confirm that
+ the evaluation was done to the required standard, but it
+ is anticipated that the documented results may not provide
+ all of the necessary information, so additional
+ information specifically requested by the scheme may be
+ necessary. This aspect is outside the scope of the
+ CEM.
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a PP evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report PP configuration control
+ identifiers.
+
+ PP configuration control identifiers (e.g. name, date
+ and version number) are required to identify what is
+ being evaluated in order for the overseer to verify that
+ the verdicts have been assigned correctly by the
+ evaluator.
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the PP developer is required to identify
+ the party responsible for producing the PP.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator references the evaluation criteria,
+ methodology and interpretations used to evaluate the
+ PP.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the handling of evaluation
+ results and assumptions made during the evaluation that
+ have an impact on the evaluation results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ The evaluator shall report a verdict and a supporting
+ rationale for each assurance component that constitutes
+ an activity, as a result of
+ performing the corresponding CEM action and its
+ constituent work units.
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, in particular the overall verdict as defined
+ in CC Part 1 Clause , and determined by application
+ of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be
+ useful for the overseer. These recommendations may
+ include shortcomings of the PP discovered during the
+ evaluation or mention of features which are particularly
+ useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a TOE evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report ST and TOE configuration
+ control identifiers.
+
+ ST and TOE configuration control identifiers identify
+ what is being evaluated in order for the overseer to
+ verify that the verdicts have been assigned correctly by
+ the evaluator.
+
+ If the ST claims that the TOE conforms to the
+ requirements of one or more PPs, the ETR shall report
+ the reference of the corresponding PPs.
+
+ The PPs reference contains information that uniquely
+ identifies the PPs (e.g. title, date, and version
+ number).
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the TOE developer is required to
+ identify the party responsible for producing the
+ TOE.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report a high level description of
+ the TOE and its major components based on the evaluation
+ evidence described in the CC assurance family entitled
+ , where
+ applicable.
+
+ The intent of this Subclause is to characterise the degree
+ of architectural separation of the major components. If
+ there is no requirement
+ in the ST, this is not applicable and is considered to
+ be satisfied.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator may reference the evaluation criteria,
+ methodology and interpretations used to evaluate the TOE
+ or the devices used to perform the tests.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the distribution of
+ evaluation results and assumptions made during the
+ evaluation that have an impact on the evaluation
+ results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ For each activity on which the TOE is evaluated, the
+ evaluator shall report:
+
+
+ the title of the activity considered;
+
+
+ a verdict and a supporting rationale for each
+ assurance component that constitutes this activity,
+ as a result of performing the corresponding CEM
+ action and its constituent work units.
+
+
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+ The evaluator shall report all information specifically
+ required by a work unit.
+
+ For the and activities, work units that identify
+ information to be reported in the ETR have been
+ defined.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, which will relate to whether the TOE has
+ satisfied its associated ST, in particular the overall
+ verdict as defined in CC Part 1 Clause , and determined by
+ application of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be
+ useful for the overseer. These recommendations may
+ include shortcomings of the IT product discovered during
+ the evaluation or mention of features which are
+ particularly useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+
+
+
+ The CC permits comparability between the results of independent
+ security evaluations. The CC does so by providing a common set
+ of requirements for the security functionality of IT products
+ and for assurance measures applied to these IT products during a
+ security evaluation. These IT products may be implemented in
+ hardware, firmware or software.
+
+ The evaluation process establishes a level of confidence that
+ the security functionality of these IT products and the
+ assurance measures applied to these IT products meet these
+ requirements. The evaluation results may help consumers to
+ determine whether these IT products fulfil their security
+ needs.
+
+ The CC is useful as a guide for the development, evaluation
+ and/or procurement of IT products with security
+ functionality.
+
+ The CC addresses protection of assets from unauthorised
+ disclosure, modification, or loss of use. The categories of
+ protection relating to these three types of failure of security
+ are commonly called confidentiality, integrity, and
+ availability, respectively. The CC may also be applicable to
+ aspects of IT security outside of these three. The CC is
+ applicable to risks arising from human activities (malicious or
+ otherwise) and to risks arising from non-human activities. Apart
+ from IT security, the CC may be applied in other areas of IT,
+ but makes no claim of applicability in these areas.
+
+
+
+ Table describes the
+ relationship between PPs and the families and components of the
+ class.
+
+
+
+ This Clause introduces the main concepts of the CC. It
+ identifies the concept ``TOE'', the target audience of the CC,
+ and the approach taken to present the material in the remainder
+ of the CC.
+
+
+ The previous Subclauses used the term ``IT product''. The CC is
+ flexible in what to evaluate and is therefore not tied to the
+ boundaries of IT products. Instead of the term IT product, the
+ CC uses the term ``TOE'' (Target of Evaluation).
+ A TOE is defined as a set of software, firmware and/or
+ hardware possibly accompanied by guidance.
+ While there are cases where a TOE consists of an IT
+ product, this need not be the case. The TOE may be an IT
+ product, a part of an IT product, a set of IT products, a
+ unique technology that may never be made into a product, or a
+ combination of these.
+
+ As far as the CC is concerned, the precise relation between
+ the TOE and any IT products is only important in one aspect:
+ the evaluation of a TOE containing only part of an IT product
+ should not be misrepresented as the evaluation of the entire
+ IT product.
+ Examples of TOEs include:
+
+
+ A software application;
+
+
+ An operating system;
+
+
+ A software application in combination with an operating
+ system;
+
+
+ A software application in combination with an operating
+ system and a workstation;
+
+
+ An operating system in combination with a workstation;
+
+
+ A smart card integrated circuit;
+
+
+ The cryptographic co-processor of a smart card integrated
+ circuit;
+
+
+ A Local Area Network including all terminals, servers,
+ network equipment and software;
+
+
+ A database application excluding the remote client
+ software normally associated with that database
+ application;
+
+
+
+
+ In the CC, a TOE can occur in several representations, such
+ as (for a software TOE):
+
+ a list of files in a configuration management
+ system;
+ a single master copy, that has just been
+ compiled;
+ a box containing a CD-ROM and a manual, ready to be
+ shipped to a customer;
+ an installed and operational version.
+
+ All of these are considered to be a TOE: and wherever the
+ term ``TOE'' is used in the remainder of the CC, the context
+ determines the representation that is meant.
+
+
+ In general, IT products can be configured in many ways:
+ installed in different ways, with different options enabled
+ or disabled. As, during a CC evaluation, it will be
+ determined whether a TOE meets certain requirements, this
+ flexibility in configuration may lead to problems, as all
+ possible configurations of the TOE must meet the
+ requirements. For these reasons, it is often the case that
+ the guidance part of the TOE strongly constrains the
+ possible configurations of the TOE. That is: the guidance of
+ the TOE may be different from the general guidance of the IT
+ product.
+ An example is an operating system IT product. This
+ product can be configured in many ways (e.g. types of users,
+ number of users, types of external connections
+ allowed/disallowed, options enabled/disabled etc.).
+ If the same IT product is to be a TOE, and is evaluated
+ against a reasonable set of requirements, the configuration
+ should be much more tightly controlled, as many options
+ (e.g. allow all types of external connections or the system
+ administrator does not need to be authenticated) will lead
+ to a TOE not meeting the requirements.
+ For this reason, there would normally be a difference
+ between the guidance of the IT product (allowing many
+ configurations) and the guidance of the TOE (allowing only
+ one or only configurations that do not differ in
+ security-relevant ways).
+ Note that if the guidance of the TOE still allows more
+ than one configuration, these configurations are
+ collectively called ``the TOE'' and each such configuration
+ must meet the requirements levied on the TOE.
+
+
+
+
+ There are three groups with a general interest in evaluation
+ of the security properties of TOEs: consumers, developers and
+ evaluators. The criteria presented in this document have been
+ structured to support the needs of all three groups. They are
+ all considered to be the principal users of the CC. The three
+ groups can benefit from the criteria as explained in the
+ following paragraphs.
+
+
+ The CC is written to ensure that evaluation fulfils the
+ needs of the consumers as this is the fundamental purpose
+ and justification for the evaluation process.
+
+ Consumers can use the results of evaluations to help decide
+ whether a TOE fulfils their security needs. These security
+ needs are typically identified as a result of both risk
+ analysis and policy direction. Consumers can also use the
+ evaluation results to compare different TOEs.
+
+ The CC gives consumers, especially in consumer groups and
+ communities of interest, an implementation-independent
+ structure, termed the Protection Profile (PP), in which to
+ express their security requirements in an unambiguous
+ manner.
+
+
+
+ The CC is intended to support developers in preparing for
+ and assisting in the evaluation of their TOEs and in
+ identifying security requirements to be satisfied by those
+ TOEs. These requirements are contained in an
+ implementation-dependent construct termed the Security
+ Target (ST). This ST may be based on one or more PPs to show
+ that the ST conforms to the security requirements from
+ consumers as laid down in those PPs.
+
+ The CC can then be used to determine the responsibilities
+ and actions to provide evidence that is necessary to support
+ the evaluation of the TOE against these requirements. It
+ also defines the content and presentation of that
+ evidence.
+
+
+
+ The CC contains criteria to be used by evaluators when
+ forming judgements about the conformance of TOEs to their
+ security requirements. The CC describes the set of general
+ actions the evaluator is to carry out. Note that the CC does
+ not specify procedures to be followed in carrying out those
+ actions. More information on these procedures may be found
+ in Subclause .
+
+
+
+ While the CC is oriented towards specification and
+ evaluation of the IT security properties of TOEs, it may
+ also be useful as reference material to all parties with an
+ interest in or responsibility for IT security. Some of the
+ additional interest groups that can benefit from information
+ contained in the CC are:
+
+
+ system custodians and system security officers
+ responsible for determining and meeting organisational
+ IT security policies and requirements;
+
+
+ auditors, both internal and external, responsible for
+ assessing the adequacy of the security of an IT solution
+ (which may consist of or contain a TOE);
+
+
+ security architects and designers responsible for the
+ specification of security properties of IT products;
+
+
+ accreditors responsible for accepting an IT solution for
+ use within a particular environment;
+
+
+ sponsors of evaluation responsible for requesting and
+ supporting an evaluation; and
+
+
+ evaluation authorities responsible for the management
+ and oversight of IT security evaluation programmes.
+
+
+
+
+
+ The CC is presented as a set of distinct but related parts
+ as identified below. Terms used in the description of the
+ parts are explained in Clause .
+
+
+
+ Part 1, Introduction and general model
+
+ is the introduction to the CC. It defines the general
+ concepts and principles of IT security evaluation and
+ presents a general model of evaluation.
+
+
+
+ Part 2, Security functional components
+
+ establishes a set of functional components that serve as
+ standard templates upon which to base functional
+ requirements for TOEs. CC Part 2 catalogues the set of
+ functional components and organises them in families and
+ classes.
+
+
+
+ Part 3, Security assurance components
+
+ establishes a set of assurance components that serve as
+ standard templates upon which to base assurance
+ requirements for TOEs. CC Part 3 catalogues the set of
+ assurance components and organises them into families
+ and classes. CC Part 3 also defines evaluation criteria
+ for PPs and STs and presents seven pre-defined assurance
+ packages which are called the Evaluation Assurance
+ Levels (EALs).
+
+
+
+ In support of the three parts of the CC listed above, other
+ documents have been published, most notably the CEM []. It is anticipated that other
+ documents will be published, including technical rationale
+ material and guidance documents.
+
+ The following table presents, for the three key target
+ audience groupings, how the parts of the CC will be of
+ interest.
+
+
+
+
+
+
+ Consumers
+
+
+ Developers
+
+
+ Evaluators
+
+
+
+
+
+
+ Part 1
+
+
+ Use for background information and reference
+ purposes. Guidance structure for PPs.
+
+
+ Use for background information and reference
+ purposes. Development of security specifications
+ for TOEs.
+
+
+ Use for background information and reference
+ purposes. Guidance structure for PPs and STs.
+
+
+
+
+ Part 2
+
+
+ Use for guidance and reference when formulating
+ statements of requirements for a TOE.
+
+
+ Use for reference when interpreting statements of
+ functional requirements and formulating functional
+ specifications for TOEs.
+
+
+ Use for reference when interpreting statements of
+ functional requirements.
+
+
+
+
+ Part 3
+
+
+ Use for guidance when determining required levels of
+ assurance.
+
+
+ Use for reference when interpreting statements of
+ assurance requirements and determining assurance
+ approaches of TOEs.
+
+
+ Use for reference when interpreting statements of
+ assurance requirements.
+
+
+
+
+
+ Road map to the Common Criteria
+
+
+
+
+
+ In order to achieve greater comparability between evaluation
+ results, evaluations should be performed within the framework
+ of an authoritative evaluation scheme that sets the standards,
+ monitors the quality of the evaluations and administers the
+ regulations to which the evaluation facilities and evaluators
+ must conform.
+
+ The CC does not state requirements for the regulatory
+ framework. However, consistency between the regulatory
+ frameworks of different evaluation authorities will be
+ necessary to achieve the goal of mutual recognition of the
+ results of such evaluations.
+
+ An example of a regulatory framework is the CCRA (Arrangement
+ on the Recognition of the CC Certificates in the field of IT
+ Security). This arrangement has been executed among a number
+ of evaluation authorities in different countries and provides
+ the conditions for mutual recognition of CC certificates
+ between these evaluation authorities.
+ A second way of achieving greater comparability between
+ evaluation results is using a common methodology to achieve
+ these results. For the CC, this methodology has been described
+ in the Common Methodology for IT Security Evaluation [].
+
+ Use of a common evaluation methodology contributes to the
+ repeatability and objectivity of the results but is not by
+ itself sufficient. Many of the evaluation criteria require the
+ application of expert judgement and background knowledge for
+ which consistency is more difficult to achieve. In order to
+ enhance the consistency of the evaluation findings, the final
+ evaluation results may be submitted to a certification
+ process.
+
+ The certification process is the independent inspection of the
+ results of the evaluation leading to the production of the
+ final certificate or approval, which is normally publicly
+ available. The certification process is a means of gaining
+ greater consistency in the application of IT security
+ criteria.
+
+ The evaluation schemes and certification processes are the
+ responsibility of the evaluation authorities that run such
+ schemes and processes and are outside the scope of the
+ CC.
+
+
+
+
+ A PP is intended to be used as a ``template" for an ST.
+ That is: the PP describes a set of user needs, while an ST
+ that conforms to that PP describes a TOE that satisfies those
+ needs.
+ Note that it is also possible for a PP to be used as a
+ template for another PP. This case is completely similar to
+ that of an ST vs. a PP. For clarity this Annex describes only
+ the ST/PP case, but it holds also for the PP case.
+ This Annex describes what it means for an ST to conform to
+ a PP. The CC recognises two types of conformance:
+
+ strict conformance: there exists a
+ very strict relation between the PP and the ST. This
+ relation can be roughly defined as ``the ST shall contain
+ all statements that are in the PP, but may contain
+ more''. Strict conformance is expected to be used for
+ stringent requirements that are to be adhered to in a
+ single manner;demonstrable
+ conformance: there is no subset-superset type
+ relation between the PP and the ST. The PP and the ST may
+ contain entirely different statements that discuss
+ different entities, use different concepts etc. However,
+ the ST shall contain a rationale on why the ST is
+ considered to be ``equivalent or more restrictive'' than
+ the PP (see Subclause ). Demonstrable conformance
+ allows a PP author to describe a common security problem
+ to be solved and provide generic guidelines to the
+ requirements necessary for its resolution, in the
+ knowledge that there is likely to be more than one way of
+ specifying a resolution. Demonstrable conformance is also
+ suitable for a TOE type where several similar PPs already
+ exist (or likely to exist in the future), thus allowing
+ the ST author to claim conformance to all these PPs
+ simultaneously, thereby saving work.
+ The allowed type of conformance is determined by the
+ PP. That is, the PP states (in the PP conformance
+ statement, see Subclause )
+ what the allowed types of conformance for the ST are:
+
+ if the PP states that strict conformance is required,
+ the ST shall conform to the PP in a strict manner;
+ if the PP states that demonstrable conformance is
+ required, the ST shall conform to the PP in a strict or
+ demonstrable manner.
+ Restating this in other words, an ST is only allowed to
+ conform in a PP in a demonstrable manner, if the PP explicitly
+ allows this.
+ If an ST claims conformance to multiple PPs, it shall
+ conform (as described above) to each PP in the manner ordained
+ by that PP. This may mean that the ST conforms strictly to
+ some PPs and demonstrably to other PPs.
+ Note that either the ST conforms to the PP in question or
+ it does not. The CC does not recognise ``partial" conformance.
+ It is therefore the responsibility of the PP author to ensure
+ the PP is not overly onerous, prohibiting PP/ST authors in
+ claiming conformance to the PP.
+
+
+
+ Strict conformance is oriented to the PP-author who requires
+ evidence that the requirements in the PP are met, that the ST
+ is an instantiation of the PP, though the ST could be broader
+ than the PP. In essence, the ST specifies that the TOE does at
+ least the same as in the PP, while the operational environment
+ does at most the same as in the PP. In more detail:
+
+
+ Security problem definition: The ST shall
+ contain the security problem definition of the PP, may
+ specify additional threats and OSPs, but may not specify
+ additional assumptions.
+
+ Security objectives: The ST:
+
+ shall contain all security objectives for the TOE
+ of the PP but may specify additional security
+ objectives for the TOE;
+ shall contain all security objectives for the
+ operational environment (with one exception in the
+ next bullet) but may not specify additional security
+ objectives for the operational environment;
+ may specify that certain objectives for the
+ operational environment in the PP are security
+ objectives for the TOE in the ST. This is called
+ re-assigning a security
+ objective.
+ Security requirements: The ST shall
+ contain all SFRs and SARs in the PP, but may claim
+ additional or hierarchically stronger SFRs and SARs. The
+ completion of operations in the ST must be consistent with
+ that in the PP; either the same completion will be used in
+ the ST as that in the PP or one that makes the requirement
+ more restrictive (the rules of refinement apply).
+
+ Note that in some cases a PP author may not wish that some
+ or all objectives for the operational environment are
+ re-assigned as objectives of the TOE. If this is the case,
+ this should be stated in the PP.
+ Also note that it is allowed to restate threats, OSPs,
+ assumptions and security objectives using a terminology that
+ may be more familiar to ST consumers for that particular ST
+ (e.g. an ST for a medical system may use terms like ``doctors'',
+ ``medical assistants'', ``hospital administrator'') even though it
+ claims conformance to a more general PP, that uses terminology
+ like ``senior staff'', ``junior staff'' and ``administrative
+ staff''). In this case, the conformance rationale in the PP
+ shall demonstrate the equivalence of the different
+ terminologies.
+
+
+
+ Demonstrable conformance is orientated to the PP-author who
+ requires evidence that the ST is a suitable solution to the
+ generic security problem described in the PP. Where there is a
+ clear subset-superset type relation between PP and ST in the
+ case of strict conformance, the relation is less clear-cut in
+ the case of demonstrable conformance. The general statement is
+ that the ST must be equivalent or more restrictive than the
+ PP. An ST is equivalent or more restrictive than a PP if:
+
+ all TOEs that meet the PP also meet ST, and
+ all operational environments that meet the ST also
+ meet the PP.
+
+ or, informally, the ST shall levy the same or more,
+ restrictions on the TOE and the same or less restrictions on
+ the operational environment of the TOE.
+
+ This general statement can be made more specific for various
+ subclauses of the ST:
+
+
+ Security problem definition: The conformance
+ rationale in the ST shall demonstrate that the security
+ problem definition in the ST is equivalent (or more
+ restrictive) than the security problem definition in the
+ PP. This means that:
+
+ all TOEs that would meet the security problem
+ definition in the ST also meet the security problem
+ definition in the PP;
+ all operational environments that would meet the
+ security problem definition in the PP would also meet
+ the security problem definition in the ST.
+
+
+
+ Security objectives: The conformance
+ rationale in the ST shall demonstrate that the security
+ objectives in the ST is equivalent (or more restrictive)
+ than the security objectives in the PP. This means that:
+
+ all TOEs that would meet the security objectives
+ for the TOE in the ST also meet the security
+ objectives for the TOE in the PP;
+ all operational environments that would meet the
+ security objectives for the operational environment in
+ the PP would also meet the security objectives for the
+ operational environment in the ST.
+
+
+ SFRs: The conformance rationale in the ST
+ shall demonstrate that the SFRs in the ST are equivalent
+ (or more restrictive) than the SFRs in the PP. This means
+ that all TOEs that would meet the SFRs in the ST would
+ also meet the SFRs in the PP;
+ SARs: The ST shall contain all SARs in
+ the PP, but may claim additional or hierarchically
+ stronger SARs. The completion of operations in the ST must
+ be consistent with that in the PP; either the same
+ completion will be used in the ST as that in the PP or a
+ completion that makes the SAR more restrictive (the rules
+ of refinement apply).
+
+
+
+
+
+ To allow consumer groups and communities of interest to
+ express their security needs, and to facilitate writing STs,
+ the CC provides two special constructs: packages and
+ Protection Profiles (PPs). In the following two Subclauses
+ these constructs are described in more detail, followed by a
+ Subclause on how these constructs can be used.
+
+
+
+ A package is a named set of security requirements. A package
+ is either
+
+ a functional package, containing only SFRs, or
+ an assurance package, containing only SARs.
+ Mixed packages containing both SFRs and SARs are not
+ allowed.
+ A package can be defined by any party and is intended to
+ be re-usable. To this goal it should contain requirements that
+ are useful and effective in combination. Packages can be used
+ in the construction of larger packages, PPs and STs. At
+ present there are no criteria for the evaluation of packages,
+ therefore any set of SFRs or SARs can be a package.
+ Examples of assurance packages are the evaluation
+ assurance levels (EALs) that are defined in CC Part 3. At the
+ time of writing there are no functional packages for this
+ version of the CC.
+
+
+
+ Whereas an ST always describes a specific TOE (e.g. the
+ MinuteGap v18.5 Firewall), a PP is intended to describe a TOE
+ type (e.g. firewalls). The same PP may therefore be used as a
+ template for many different STs to be used in different
+ evaluations. A detailed description of PPs is given in .
+
+ In general an ST describes requirements for a TOE and is
+ written by the developer of that TOE, while a PP describes the
+ general requirements for a TOE type, and is therefore
+ typically written by:
+
+ A user community seeking to come to a consensus on
+ the requirements for a given TOE type;
+ A developer of a TOE, or a group of developers of
+ similar TOEs wishing to establish a minimum baseline for
+ that type of TOE;
+ A government or large corporation specifying its
+ requirements as part of its acquisition process.
+
+
+ PPs can be evaluated (by applying the criteria to them as listed in CC Part 3). The goal
+ of such an evaluation is to demonstrate that the PP is
+ complete, consistent, and technically sound and suitable for
+ use as a template on which to build another PP or an
+ ST.
+ Basing a PP/ST on an evaluated PP has two advantages:
+
+ There is much less risk that there are errors,
+ ambiguities or gaps in the PP. If any problems with a PP
+ (that would have been caught by evaluating that PP) are
+ found during the writing or evaluation of the new ST,
+ significant time may elapse before the PP is
+ corrected.
+ Evaluation of the new PP/ST may often re-use
+ evaluation results of the evaluated PP, resulting in less
+ effort for evaluating the new PP/ST.
+
+
+
+ If an ST claims to be conformant to one or more packages
+ and/or Protection Profiles, the evaluation of that ST will
+ (among other properties of that ST) demonstrate that the ST
+ actually conforms to these packages and/or PPs that they claim
+ conformance to. Details of this determination of conformance
+ can be found in .
+
+ This allows the following process:
+
+ An organisation seeking to acquire a particular type
+ of IT security product develops their security needs into
+ a PP, then has this evaluated and publishes it;
+
+
+ A developer takes this PP, writes an ST that claims
+ conformance to the PP and has this ST evaluated;
+
+
+ The developer then builds a TOE (or uses an existing one)
+ and has this evaluated against the ST.
+
+
+
+ The result is that the developer can prove that his TOE is
+ conformant to the security needs of the organisation: the
+ organisation can therefore acquire that TOE. A similar line of
+ reasoning applies to packages.
+
+
+
+ The CC also allows PPs to conform to other PPs, allowing
+ chains of PPs to be constructed, each based on the previous
+ one(s).
+
+ For instance, one could take a PP for an Integrated Circuit
+ and a PP for a Smart Card OS, and use these to construct a
+ Smart Card PP (IC and OS) that claims conformance to the other
+ two. One could then write a PP on Smart Cards for Public
+ Transport based on the Smart Card PP and a PP on Applet
+ Loading. Finally, a developer could then construct an ST based
+ on this Smart Cards for Public Transport PP.
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CEM
+
+ Common Methodology for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+
+
+ ISO/IEC
+
+ ISO/IEC Directives - Part 2: Rules for the structure and
+ drafting of International Standards.
+
+
+
+
+
+ This multi-part standard, the Common Criteria (CC), is meant to
+ be used as the basis for evaluation of security properties of IT
+ products. By establishing such a common criteria base, the
+ results of an IT security evaluation may be meaningful to a
+ wider audience.
+
+ Certain topics, because they involve specialised techniques or
+ because they are somewhat peripheral to IT security, are
+ considered to be outside the scope of the CC. Some of these are
+ identified below.
+
+
+ The CC does not contain security evaluation criteria
+ pertaining to administrative security measures not related
+ directly to the IT security functionality. However, it is
+ recognised that significant security can often be achieved
+ through or supported by administrative measures such as
+ organisational, personnel, physical, and procedural
+ controls.
+
+
+ The evaluation of some technical physical aspects of IT
+ security such as electromagnetic emanation control is not
+ specifically covered, although many of the concepts
+ addressed will be applicable to that area.
+
+
+ The CC does not address the evaluation methodology under
+ which the criteria should be applied. This methodology is
+ described in the Common Methodology for IT Security
+ Evaluation [].
+
+
+ The CC does not address the administrative and legal
+ framework under which the criteria may be applied by
+ evaluation authorities. However, it is expected that the CC
+ will be used for evaluation purposes in the context of such
+ a framework.
+
+
+ The procedures for use of evaluation results in
+ accreditation are outside the scope of the CC. Accreditation
+ is the administrative process whereby authority is granted
+ for the operation of an IT product (or collection thereof)
+ in its full operational environment including all of its
+ non-IT parts. The results of the evaluation process are an
+ input to the accreditation process. However, as other
+ techniques are more appropriate for the assessments of
+ non-IT related properties and their relationship to the IT
+ security parts, accreditors should make separate provisions
+ for those aspects.
+
+ The subject of criteria for the assessment of the
+ inherent qualities of cryptographic algorithms is not
+ covered in the CC. Should independent assessment of
+ mathematical properties of cryptography be required, the
+ evaluation scheme under which the CC is applied must make
+ provision for such assessments.
+
+
+ The CC is intentionally flexible, enabling a range of
+ evaluation methods to be applied to a range of security
+ properties of a range of IT products. Therefore care should be
+ exercised to ensure that this flexibility is not misused. For
+ example, the CC should not be used to apply unsuitable
+ evaluation methods, to irrelevant security properties, of
+ inappropriate IT products, resulting in meaningless evaluation
+ results.
+ Consequently, the fact that an IT product has been evaluated
+ has meaning only in the context of the security properties that
+ were evaluated and the evaluation methods that were used.
+ Evaluation authorities should carefully check the products,
+ properties and methods to determine that an evaluation will
+ provide meaningful results. Additionally, purchasers of
+ evaluated products should carefully consider this context to
+ determine whether the evaluated product is useful and applicable
+ to their specific situation and needs.
+
+
+
+
+ The following Subclauses describe the constructs used in
+ representing the assurance classes, families, and
+ components.
+
+ Figure
+ illustrates the SARs defined in this CC Part 3. Note that the
+ most abstract collection of SARs is referred to as a
+ class. Each class contains assurance families, which then
+ contain assurance components, which in turn contain assurance
+ elements. Classes and families are used to provide a taxonomy
+ for classifying SARs, while components are used to specify
+ SARs in a PP/ST.
+
+
+ Figure
+ illustrates the assurance class structure.
+
+
+ Each assurance class is assigned a unique name. The name
+ indicates the topics covered by the assurance
+ class.
+
+ A unique short form of the assurance class name is also
+ provided. This is the primary means for referencing the
+ assurance class. The convention adopted is an ``A''
+ followed by two letters related to the class name.
+
+
+
+ Each assurance class has an introductory Subclause that
+ describes the composition of the class and contains
+ supportive text covering the intent of the class.
+
+
+
+ Each assurance class contains at least one assurance
+ family. The structure of the assurance families is
+ described in the following Subclause.
+
+
+
+
+
+ Figure
+ illustrates the assurance family structure.
+
+
+ Every assurance family is assigned a unique name. The name
+ provides descriptive information about the topics covered
+ by the assurance family. Each assurance family is placed
+ within the assurance class that contains other families
+ with the same intent.
+
+ A unique short form of the assurance family name is also
+ provided. This is the primary means used to reference the
+ assurance family. The convention adopted is that the short
+ form of the class name is used, followed by an underscore,
+ and then three letters related to the family name.
+
+
+
+ The objectives Subclause of the assurance family presents
+ the intent of the assurance family.
+
+ This Subclause describes the objectives, particularly
+ those related to the CC assurance paradigm, that the
+ family is intended to address. The description for the
+ assurance family is kept at a general level. Any specific
+ details required for objectives are incorporated in the
+ particular assurance component.
+
+
+
+ Each assurance family contains one or more assurance
+ components. This Subclause of the assurance family
+ describes the components available and explains the
+ distinctions between them. Its main purpose is to
+ differentiate between the assurance components once it has
+ been determined that the assurance family is a necessary
+ or useful part of the SARs for a PP/ST.
+
+ Assurance families containing more than one component are
+ levelled and rationale is provided as to how the
+ components are levelled. This rationale is in terms of
+ scope, depth, and/or rigour.
+
+
+
+ The application notes Subclause of the assurance family,
+ if present, contains additional information for the
+ assurance family. This information should be of particular
+ interest to users of the assurance family (e.g. PP and ST
+ authors, designers of TOEs, evaluators). The presentation
+ is informal and covers, for example, warnings about
+ limitations of use and areas where specific attention may
+ be required.
+
+
+
+ Each assurance family has at least one assurance
+ component. The structure of the assurance components is
+ provided in the following Subclause.
+
+
+
+
+ Figure illustrates the
+ assurance component structure.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding convention. Those parts of the
+ requirements that are new, enhanced or modified beyond the
+ requirements of the previous component within a hierarchy
+ are bolded.
+
+
+ The component identification Subclause provides
+ descriptive information necessary to identify, categorise,
+ register, and reference a component.
+
+ Every assurance component is assigned a unique name. The
+ name provides descriptive information about the topics
+ covered by the assurance component. Each assurance
+ component is placed within the assurance family that
+ shares its security objective.
+
+ A unique short form of the assurance component name is
+ also provided. This is the primary means used to reference
+ the assurance component. The convention used is that the
+ short form of the family name is used, followed by a
+ period, and then a numeric character. The numeric
+ characters for the components within each family are
+ assigned sequentially, starting from 1.
+
+
+
+ The objectives Subclause of the assurance component, if
+ present, contains specific objectives for the particular
+ assurance component. For those assurance components that
+ have this Subclause, it presents the specific intent of
+ the component and a more detailed explanation of the
+ objectives.
+
+
+
+ The application notes Subclause of an assurance component,
+ if present, contains additional information to facilitate
+ the use of the component.
+
+
+
+ Dependencies among assurance components arise when a
+ component is not self-sufficient, and relies upon the
+ presence of another component.
+
+ Each assurance component provides a complete list of
+ dependencies to other assurance components. Some
+ components may list ``No dependencies'', to indicate that
+ no dependencies have been identified. The components
+ depended upon may have dependencies on other
+ components.
+
+ The dependency list identifies the minimum set of
+ assurance components which are relied upon. Components
+ which are hierarchical to a component in the dependency
+ list may also be used to satisfy the dependency.
+
+ In specific situations the indicated dependencies might
+ not be applicable. The PP/ST author, by providing
+ rationale for why a given dependency is not applicable,
+ may elect not to satisfy that dependency.
+
+
+
+ A set of assurance elements is provided for each assurance
+ component. An assurance element is a security requirement
+ which, if further divided, would not yield a meaningful
+ evaluation result. It is the smallest security requirement
+ recognised in the CC.
+
+ Each assurance element is identified as belonging to one
+ of the three sets of assurance elements:
+
+
+ Developer action elements: the activities that shall
+ be performed by the developer. This set of actions is
+ further qualified by evidential material referenced in
+ the following set of elements. Requirements for
+ developer actions are identified by appending the
+ letter ``D'' to the element number.
+
+
+ Content and presentation of evidence elements: the
+ evidence required, what the evidence shall
+ demonstrate, and what information the evidence shall
+ convey. Requirements for content and presentation of
+ evidence are identified by appending the letter ``C''
+ to the element number.
+
+
+ Evaluator action elements: the activities that shall
+ be performed by the evaluator. This set of actions
+ explicitly includes confirmation that the requirements
+ prescribed in the content and presentation of evidence
+ elements have been met. It also includes explicit
+ actions and analysis that shall be performed in
+ addition to that already performed by the
+ developer. Implicit evaluator actions are also to be
+ performed as a result of developer action elements
+ which are not covered by content and presentation of
+ evidence requirements. Requirements for evaluator
+ actions are identified by appending the letter ``E''
+ to the element number.
+
+
+
+ The developer actions and content and presentation of
+ evidence define the assurance requirements that are used
+ to represent a developer's responsibilities in
+ demonstrating assurance in the TOE meeting the SFRs of a
+ PP or ST.
+
+ The evaluator actions define the evaluator's
+ responsibilities in the two aspects of evaluation. The
+ first aspect is validation of the PP/ST, in accordance
+ with the classes and in Clauses and . The second
+ aspect is verification of the TOE's conformance with its
+ SFRs and SARs. By demonstrating that the PP/ST is valid
+ and that the requirements are met by the TOE, the
+ evaluator can provide a basis for confidence that the TOE
+ in its operational environment solves the defined security
+ problem.
+
+ The developer action elements, content and presentation of
+ evidence elements, and explicit evaluator action elements,
+ identify the evaluator effort that shall be expended in
+ verifying the security claims made in the ST of the
+ TOE.
+
+
+
+
+ Each element represents a requirement to be met. These
+ statements of requirements are intended to be clear,
+ concise, and unambiguous. Therefore, there are no compound
+ sentences: each separable requirement is stated as an
+ individual element.
+
+
+
+ This CC Part 3 contains classes of families and components
+ that are grouped on the basis of related assurance. At the
+ start of each class is a diagram that indicates the families
+ in the class and the components in each family.
+
+
+ In Figure ,
+ above, the class as shown contains a single family. The
+ family contains three components that are linearly
+ hierarchical (i.e. component 2 requires more than component
+ 1, in terms of specific actions, specific evidence, or
+ rigour of the actions or evidence). The assurance families
+ in this CC Part 3 are all linearly hierarchical, although
+ linearity is not a mandatory criterion for assurance
+ families that may be added in the future.
+
+
+
+
+ Figure illustrates
+ the EALs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in an EAL by reference to the actual
+ components defined in the CC.
+
+
+
+ Each EAL is assigned a unique name. The name provides
+ descriptive information about the intent of the EAL.
+
+ A unique short form of the EAL name is also provided. This
+ is the primary means used to reference the EAL.
+
+
+
+ The objectives Subclause of the EAL presents the intent of
+ the EAL.
+
+
+
+ The application notes Subclause of the EAL, if present,
+ contains information of particular interest to users of the
+ EAL (e.g. PP and ST authors, designers of TOEs targeting
+ this EAL, evaluators). The presentation is informal and
+ covers, for example, warnings about limitations of use and
+ areas where specific attention may be required.
+
+
+ A set of assurance components have been chosen for each
+ EAL.
+
+ A higher level of assurance than that provided by a given
+ EAL can be achieved by:
+
+
+ including additional assurance components from other
+ assurance families; or
+
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+
+
+
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ assurance levels defined in the CC. While assurance
+ components further decompose into assurance elements,
+ assurance elements cannot be individually referenced by
+ assurance levels. Note that the arrow in the figure
+ represents a reference from an EAL to an assurance component
+ within the class where it is defined.
+
+
+
+
+
+ The structure of the CAPs is similar to that of the EALs. The
+ main difference between these two types of package is the type
+ of TOE they apply to; the EALs applying to component TOEs and
+ the CAPs applying to composed TOEs.
+
+ Figure illustrates
+ the CAPs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in a CAP by reference to the actual
+ components defined in the CC.
+
+
+
+ Each CAP is assigned a unique name. The name provides
+ descriptive information about the intent of the CAP.
+
+ A unique short form of the CAP name is also provided. This
+ is the primary means used to reference the CAP.
+
+
+
+ The objectives Subclause of the CAP presents the intent of
+ the CAP.
+
+
+
+ The application notes Subclause of the CAP, if present,
+ contains information of particular interest to users of the
+ CAP (e.g. PP and ST authors, integrators of composed TOEs
+ targeting this CAP, evaluators). The presentation is
+ informal and covers, for example, warnings about limitations
+ of use and areas where specific attention may be
+ required.
+
+
+ A set of assurance components have been chosen for each
+ CAP.
+
+ Some dependencies identify the activities performed during
+ the evaluation of the dependent component on which the
+ composed TOE activity relies. Where it is not explicitly
+ identified that the dependency is on a dependent component
+ activity, the dependency is to another evaluation activity
+ of the composed TOE.
+
+ A higher level of assurance than that provided by a given
+ CAP can be achieved by:
+
+
+ including additional assurance components from other
+ assurance families; or
+
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+
+
+ The components included in the CAP
+ assurance packages should not be used as augmentations for
+ component TOE evaluations, as this would provide no
+ meaningful assurance for the component.
+
+
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ composed assurance packages defined in the CC. While
+ assurance components further decompose into assurance
+ elements, assurance elements cannot be individually
+ referenced by assurance packages. Note that the arrow in the
+ figure represents a reference from a CAP to an assurance
+ component within the class where it is defined.
+
+
+
+
+
+
+
+
+ This clause defines the content and presentation of the
+ functional requirements of the CC, and provides guidance on
+ the organisation of the requirements for new components to be
+ included in an ST. The functional requirements are expressed
+ in classes, families, and components.
+
+
+
+ Figure illustrates the
+ functional class structure in diagrammatic form. Each
+ functional class includes a class name, class introduction,
+ and one or more functional families.
+
+
+
+
+
+ The class name subclause provides information necessary to
+ identify and categorise a functional class. Every
+ functional class has a unique name. The categorical
+ information consists of a short name of three
+ characters. The short name of the class is used in the
+ specification of the short names of the families of that
+ class.
+
+
+
+ The class introduction expresses the common intent or
+ approach of those families to satisfy security
+ objectives. The definition of functional classes does not
+ reflect any formal taxonomy in the specification of the
+ requirements.
+
+ The class introduction provides a figure describing the
+ families in this class and the hierarchy of the components
+ in each family, as explained in subclause .
+
+
+
+
+
+ Figure
+ illustrates the functional family structure in diagrammatic
+ form.
+
+
+
+
+
+ The family name subclause provides categorical and
+ descriptive information necessary to identify and
+ categorise a functional family. Every functional family
+ has a unique name. The categorical information consists of
+ a short name of seven characters, with the first three
+ identical to the short name of the class followed by an
+ underscore and the short name of the family as follows
+ XXX_YYY. The unique short form of the family name provides
+ the principal reference name for the components.
+
+
+
+ The family behaviour is the narrative description of the
+ functional family stating its security objective and a
+ general description of the functional requirements. These
+ are described in greater detail below:
+
+
+ The security objectives of the family
+ address a security problem that may be solved with the
+ help of a TOE that incorporates a component of this
+ family;
+
+
+ The description of the functional
+ requirements summarises all the requirements
+ that are included in the component(s). The description
+ is aimed at authors of PPs, STs and functional
+ packages who wish to assess whether the family is
+ relevant to their specific requirements.
+
+
+
+
+
+ Functional families contain one or more components, any
+ one of which can be selected for inclusion in PPs, STs and
+ functional packages. The goal of this section is to
+ provide information to users in selecting an appropriate
+ functional component once the family has been identified
+ as being a necessary or useful part of their security
+ requirements.
+
+ This section of the functional family description
+ describes the components available, and their
+ rationale. The exact details of the components are
+ contained within each component.
+
+ The relationships between components within a functional
+ family may or may not be hierarchical. A component is
+ hierarchical to another if it offers more security.
+
+ As explained in the descriptions of the
+ families provide a graphical overview of the hierarchy of
+ the components in a family.
+
+
+
+
+ The management requirements contain
+ information for the PP/ST authors to consider as
+ management activities for a given component. The
+ management requirements are detailed in components of the
+ management class (FMT).
+
+ A PP/ST author may select the indicated management
+ requirements or may include other management requirements
+ not listed. As such the information should be considered
+ informative.
+
+
+
+
+ The audit requirements contain auditable
+ events for the PP/ST authors to select, if requirements
+ from the class , are included in the
+ PP/ST. These requirements include security relevant events
+ in terms of the various levels of detail supported by the
+ components of the family. For example,
+ an audit note might include actions that are in terms of:
+ Minimal - successful use of the security mechanism; Basic
+ - any use of the security mechanism as well as relevant
+ information regarding the security attributes involved;
+ Detailed - any configuration changes made to the
+ mechanism, including the actual configuration values
+ before and after the change.
+
+ It should be observed that the categorisation of auditable
+ events is hierarchical. For example, when Basic Audit
+ Generation is desired, all auditable events identified as
+ being both Minimal and Basic should be included in the
+ PP/ST through the use of the appropriate assignment
+ operation, except when the higher level event simply
+ provides more detail than the lower level event. When
+ Detailed Audit Generation is desired, all identified
+ auditable events (Minimal, Basic and Detailed) should be
+ included in the PP/ST.
+
+ In the class the rules governing the audit
+ are explained in more detail.
+
+
+
+
+
+ Figure illustrates the
+ functional component structure.
+
+
+
+
+
+ The component identification subclause provides
+ descriptive information necessary to identify, categorise,
+ register and cross-reference a component. The following is
+ provided as part of every functional component:
+
+ A unique name. The name reflects the
+ purpose of the component.
+
+ A short name. A unique short form of the
+ functional component name. This short name serves as the
+ principal reference name for the categorisation,
+ registration and cross-referencing of the component. This
+ short name reflects the class and family to which the
+ component belongs and the component number within the
+ family.
+
+ A hierarchical-to list. A list of other
+ components that this component is hierarchical to and for
+ which this component can be used to satisfy dependencies
+ to the listed components.
+
+
+
+
+ A set of elements is provided for each component. Each
+ element is individually defined and is self-contained.
+
+ A functional element is a security functional requirement
+ that if further divided would not yield a meaningful
+ evaluation result. It is the smallest security functional
+ requirement identified and recognised in the CC.
+
+ When building packages, PPs and/or STs, it is not
+ permitted to select only one or more elements from a
+ component. The complete set of elements of a component
+ must be selected for inclusion in a PP, ST or package.
+
+ A unique short form of the functional element name is
+ provided. For example the requirement name FDP_IFF.4.2
+ reads as follows: F - functional requirement, DP - class
+ ``User data protection'', _IFF -
+ family ``Information flow control
+ functions'', .4 - 4th component named
+ ``Partial elimination of illicit information
+ flows'', .2 - 2nd element of the component.
+
+
+
+
+ Dependencies among functional components arise when a
+ component is not self sufficient and relies upon the
+ functionality of, or interaction with, another component
+ for its own proper functioning.
+
+ Each functional component provides a complete list of
+ dependencies to other functional and assurance
+ components. Some components may list ``No
+ dependencies''. The components depended upon may in
+ turn have dependencies on other components. The list
+ provided in the components will be the direct
+ dependencies. That is only references to the functional
+ requirements that are required for this requirement to
+ perform its job properly. The indirect dependencies, that
+ is the dependencies that result from the depended upon
+ components can be found in
+ of this part of the CC. It is noted that in some cases the
+ dependency is optional in that a number of functional
+ requirements are provided, where each one of them would be
+ sufficient to satisfy the dependency (see for example
+ ).
+
+ The dependency list identifies the minimum functional or
+ assurance components needed to satisfy the security
+ requirements associated with an identified
+ component. Components that are hierarchical to the
+ identified component may also be used to satisfy the
+ dependency.
+
+ The dependencies indicated in CC Part 2 are
+ normative. They must be satisfied within a PP/ST. In
+ specific situations the indicated dependencies might not
+ be applicable. The PP/ST author, by providing the
+ rationale why it is not applicable, may leave the depended
+ upon component out of the package, PP or ST.
+
+
+
+
+
+
+
+
+ The grouping of the components in this part of the CC does not
+ reflect any formal taxonomy.
+
+ This part of the CC contains classes of families and
+ components, which are rough groupings on the basis of related
+ function or purpose, presented in alphabetic order. At the
+ start of each class is an informative diagram that indicates
+ the taxonomy of each class, indicating the families in each
+ class and the components in each family. The diagram is a
+ useful indicator of the hierarchical relationship that may
+ exist between components.
+
+ In the description of the functional components, a section
+ identifies the dependencies between the component and any
+ other components.
+
+ In each class a figure describing the family hierarchy similar
+ to Figure , is provided. In Figure
+ the first family, Family 1,
+ contains three hierarchical components, where component 2 and
+ component 3 can both be used to satisfy dependencies on
+ component 1. Component 3 is hierarchical to component 2 and
+ can also be used to satisfy dependencies on component 2.
+
+
+
+
+ In Family 2 there are three components not all of which are
+ hierarchical. Components 1 and 2 are hierarchical to no other
+ components. Component 3 is hierarchical to component 2, and
+ can be used to satisfy dependencies on component 2, but not to
+ satisfy dependencies on component 1.
+
+ In Family 3, components 2, 3, and 4 are hierarchical to
+ component 1. Components 2 and 3 are both hierarchical to
+ component 1, but non-comparable. Component 4 is hierarchical
+ to both component 2 and component 3.
+
+ These diagrams are meant to complement the text of the
+ families and make identification of the relationships
+ easier. They do not replace the ``Hierarchical
+ to:'' note in each component that is the mandatory
+ claim of hierarchy for each component.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding
+ convention. This bolding convention calls for the bolding of
+ all new requirements. For hierarchical components,
+ requirements are bolded when they are
+ enhanced or modified beyond the requirements of the previous
+ component. In addition, any new or enhanced permitted
+ operations beyond the previous component are also
+ highlighted using bold type.
+
+
+
+
+
+ This annex contains additional guidance for the families and
+ components defined in the elements of this CC Part 2, which
+ may be required by users, developers or evaluators to use the
+ components. To facilitate finding the appropriate information,
+ the presentation of the classes, families and components in
+ this annex is similar to the presentation within the elements.
+
+
+
+ This clause defines the content and presentation of the notes
+ related to functional requirements of the CC.
+
+
+
+ Figure below
+ illustrates the functional class structure in this annex.
+
+
+
+
+
+ This is the unique name of the class defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The class introduction in this annex provides information
+ about the use of the families and components of the
+ class. This information is completed with the informative
+ diagram that describes the organisation of each class with
+ the families in each class and the hierarchical
+ relationship between components in each family.
+
+
+
+
+
+ Figure illustrates
+ the functional family structure for application notes in
+ diagrammatic form.
+
+
+
+
+
+ This is the unique name of the family defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The user notes contain additional information that is of
+ interest to potential users of the family, that is PP, ST
+ and functional package authors, and developers of TOEs
+ incorporating the functional components. The presentation
+ is informative, and might cover warnings about limitations
+ of use and areas where specific attention might be
+ required when using the components.
+
+
+
+
+ The evaluator notes contain any information that is of
+ interest to developers and evaluators of TOEs that claim
+ compliance with a component of the family. The
+ presentation is informative and can cover a variety of
+ areas where specific attention might be needed when
+ evaluating the TOE. This can include clarifications of
+ meaning and specification of the way to interpret
+ requirements, as well as caveats and warnings of specific
+ interest to evaluators.
+
+ These User Notes and Evaluator Notes sections are not
+ mandatory and appear only if appropriate.
+
+
+
+
+
+ Figure illustrates
+ the functional component structure for the application
+ notes.
+
+
+
+
+
+ This is the unique name of the component defined within
+ the normative elements of this part of the CC.
+
+
+
+
+ Any specific information related to the component can be
+ found in this section.
+
+
+ The rationale contains the specifics
+ of the rationale that refine the general statements on
+ rationale for the specific level, and should only be
+ used if level specific amplification is required.
+
+
+ The application notes contain
+ additional refinement in terms of narrative
+ qualification as it pertains to a specific
+ component. This refinement can pertain to user notes,
+ and/or evaluator notes as described in Subclause . This refinement can be
+ used to explain the nature of the dependencies
+ (e.g. shared information, or shared operation).
+
+
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+ This portion of each component contains advice relating to
+ the permitted operations of the component.
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+
+ The following dependency tables for functional components
+ show their direct, indirect and optional dependencies. Each
+ of the components that is a dependency of some functional
+ component is allocated a column. Each functional component is
+ allocated a row. The value in the table cell indicate whether
+ the column label component is directly required (indicated by
+ a cross ``X''), indirectly required (indicated by a
+ dash ``-''), or optionally required (indicated by a
+ ``o'') by the row label component. An example of a
+ component with optional dependencies is , which requires either
+ or to be present. So if is present, is not
+ necessary and vice versa. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+ The following abbreviations are used in one or more parts of the
+ CC:
+
+ API
+
+ Application Programming Interface
+
+
+
+ CAP
+
+ Composed Assurance Package
+
+
+
+ CC
+
+ Common Criteria
+
+
+
+ CCRAArrangement on the
+ Recognition of Common Criteria Certificates in the field of IT
+ Security
+
+
+
+ DAC
+
+ Discretionary Access Control
+
+
+
+ EAL
+
+ Evaluation Assurance Level
+
+
+
+ GHz
+
+ Gigahertz
+
+
+
+ GUI
+
+ Graphical User Interface
+
+
+
+ IC
+
+ Integrated Circuit
+
+
+
+ IOCTL
+
+ Input Output Control
+
+
+
+ IP
+
+ Internet Protocol
+
+
+
+ IT
+
+ Information Technology
+
+
+
+ MB
+
+ Mega Byte
+
+
+
+ OS
+
+ Operating System
+
+
+
+ OSP
+
+ Organisational Security Policy
+
+
+
+ PC
+
+ Personal Computer
+
+
+
+ PCI
+
+ Peripheral Component Interconnect
+
+
+
+ PKI
+
+ Public Key Infrastructure
+
+
+
+ PP
+
+ Protection Profile
+
+
+
+ RAM
+
+ Random Access Memory
+
+
+
+ RPC
+
+ Remote Procedure Call
+
+
+
+ SAR
+
+ Security Assurance Requirement
+
+
+
+ SFR
+
+ Security Functional Requirement
+
+
+
+ SFP
+
+ Security Function Policy
+
+
+
+ ST
+
+ Security Target
+
+
+
+ TCP
+
+ Transmission Control Protocol
+
+
+
+ TOE
+
+ Target of Evaluation
+
+
+
+ TSF
+
+ TOE Security Functionality
+
+
+
+ TSFI
+
+ TSF Interface
+
+
+
+ VPN
+
+ Virtual Private Network
+
+
+
+
+
+
+ Security auditing involves recognising, recording, storing,
+ and analysing information related to security relevant
+ activities (i.e. activities controlled by the TSF). The
+ resulting audit records can be examined to determine which
+ security relevant activities took place and whom (which user)
+ is responsible for them.
+
+
+
+ CC audit families allow PP/ST authors the ability to define
+ requirements for monitoring user activities and, in some
+ cases, detecting real, possible, or imminent violations of
+ the enforcement of the SFRs. The TOE's security audit functions are
+ defined to help monitor security-relevant events, and act as a
+ deterrent against security violations. The requirements of the
+ audit families refer to functions that include audit data
+ protection, record format, and event selection, as well as
+ analysis tools, violation alarms, and real-time analysis. The
+ audit trail should be presented in human-readable format
+ either directly (e.g. storing the audit trail in
+ human-readable format) or indirectly (e.g. using audit
+ reduction tools), or both.
+
+ While developing the security audit requirements, the PP/ST
+ author should take note of the inter-relationships among the
+ audit families and components. The potential exists to specify
+ a set of audit requirements that comply with the
+ family/component dependencies lists, while at the same time
+ resulting in a deficient audit function (e.g. an audit
+ function that requires all security relevant events to be
+ audited but without the selectivity to control them on any
+ reasonable basis such as individual user or object).
+
+
+ The implementation of audit requirements for networks and
+ other large systems may differ significantly from those
+ needed for stand-alone systems. Larger, more complex and
+ active systems require more thought concerning which audit
+ data to collect and how this should be managed, due to
+ lowered feasibility of interpreting (or even storing) what
+ gets collected. The traditional notion of a time-ordered list
+ or ``trail'' of audited events may not
+ be applicable in a global asynchronous network with
+ arbitrarily many events occurring at once.
+
+ Also, different hosts and servers on a distributed TOE may
+ have differing naming policies and values. Symbolic names
+ presentation for audit review may require a net-wide
+ convention to avoid redundancies and ``name
+ clashes.''
+
+ A multi-object audit repository, portions of which are
+ accessible by a potentially wide variety of authorised
+ users, may be required if audit repositories are to serve a
+ useful function in distributed systems.
+
+ Finally, misuse of authority by authorised users should be
+ addressed by systematically avoiding local storage of audit
+ data pertaining to administrator actions.
+
+
+
+
+
+
+ This family defines the response to be taken in case of
+ detected events indicative of a potential security
+ violation.
+
+
+
+ The Security audit automatic response family describes
+ requirements for the handling of audit events. The
+ requirement could include requirements for alarms or TSF
+ action (automatic response). For example, the TSF could
+ include the generation of real time alarms, termination of
+ the offending process, disabling of a service, or
+ disconnection or invalidation of a user account.
+
+ An audit event is defined to be an ``potential
+ security violation'' if so indicated by the
+ components.
+
+
+
+
+
+
+
+
+ An action should be taken for follow up action in the
+ event of an alarm. This action can be to inform the
+ authorised user, to present the authorised user with a set
+ of possible containment actions, or to take corrective
+ actions. The timing of the actions should be carefully
+ considered by the PP/ST author.
+
+
+
+ At , the TSF shall take actions in
+ case a potential security violation is detected.
+
+
+ the management (addition, removal, or modification) of
+ actions.
+
+
+ Actions taken due to potential security violations.
+
+
+ The TSF shall take
+
+
+ list of actions
+
+
+
+ the PP/ST author should specify the actions to be taken
+ in case of a potential security violation. An example of
+ such a list is: ``inform the authorised user, disable
+ the subject that created the potential security
+ violation.'' It can also specify that the action to be
+ taken can be specified by an authorised user.
+
+
+ upon detection of a potential security violation.
+
+
+
+
+
+
+
+ This family defines requirements for recording the
+ occurrence of security relevant events that take place under
+ TSF control. This family identifies the level of auditing,
+ enumerates the types of events that shall be auditable by
+ the TSF, and identifies the minimum set of audit-related
+ information that should be provided within various audit
+ record types.
+
+
+
+ The Security audit data generation family includes
+ requirements to specify the audit events that should be
+ generated by the TSF for security-relevant events.
+
+ This family is presented in a manner that avoids a dependency
+ on all components requiring audit support. Each component has
+ an audit section developed in which the events to be audited
+ for that functional area are listed. When the PP/ST author
+ assembles the PP/ST, the items in the audit area are used to
+ complete the variable in this component. Thus, the
+ specification of what could be audited for a functional area
+ is localised in that functional area.
+
+ The list of auditable events is entirely dependent on the
+ other functional families within the PP/ST. Each family
+ definition should therefore include a list of its
+ family-specific auditable events. Each auditable event in the
+ list of auditable events specified in the functional family
+ should correspond to one of the levels of audit event
+ generation specified in this family (i.e. minimal, basic,
+ detailed). This provides the PP/ST author with information
+ necessary to ensure that all appropriate auditable events are
+ specified in the PP/ST. The following example shows how
+ auditable events are to be specified in appropriate functional
+ families:
+
+ ``The following actions should be auditable if is included in the PP/ST:
+
+
+ Minimal: Successful use of the user security attribute
+ administration functions;
+
+
+ Basic: All attempted uses of the user security attribute
+ administration functions;
+
+
+ Basic: Identification of which user security attributes
+ have been modified;
+
+
+ Detailed: With the exception of specific sensitive
+ attribute data items (e.g. passwords, cryptographic
+ keys), the new values of the attributes should be
+ captured.''
+
+
+
+ For each functional component that is chosen, the auditable
+ events that are indicated in that component, at and below the
+ level indicated in should be
+ auditable. If, for example, in the previous example ``Basic''
+ would be selected in , the
+ auditable events mentioned in a), b) and c) should be
+ auditable.
+
+ Observe that the categorisation of auditable events is
+ hierarchical. For example, when Basic Audit Generation is
+ desired, all auditable events identified as being either
+ Minimal or Basic, should also be included in the PP/ST
+ through the use of the appropriate assignment operation,
+ except when the higher level event simply provides more
+ detail than the lower level event. When Detailed Audit
+ Generation is desired, all identified auditable events
+ (Minimal, Basic, and Detailed) should be included in the
+ PP/ST.
+
+ A PP/ST author may decide to include other auditable events
+ beyond those required for a given audit level. For example,
+ the PP/ST may claim only minimal audit capabilities while
+ including most of the basic capabilities because the few
+ excluded capabilities conflict with other PP/ST constraints
+ (e.g. because they require the collection of unavailable
+ data).
+
+ The functionality that creates the auditable event should be
+ specified in the PP or ST as a functional requirement.
+
+ The following are examples of the types of the events that
+ should be defined as auditable within each PP/ST functional
+ component:
+
+
+ Introduction of objects within the control of the TSF into a
+ subject's address space;
+
+
+ Deletion of objects;
+
+
+ Distribution or revocation of access rights or
+ capabilities;
+
+
+ Changes to subject or object security attributes;
+
+
+ Policy checks performed by the TSF as a result of a
+ request by a subject;
+
+
+ The use of access rights to bypass a policy check;
+
+
+ Use of Identification and Authentication functions;
+
+
+ Actions taken by an operator, and/or authorised user
+ (e.g. suppression of a TSF protection mechanism as
+ human-readable labels);
+
+
+ Import/export of data from/to removable media
+ (e.g. printed output, tapes, diskettes).
+
+
+
+
+
+
+
+
+
+
+ This component defines requirements to identify the
+ auditable events for which audit records should be
+ generated, and the information to be provided in the audit
+ records.
+
+ by itself might be used
+ when the SFRs do not require that individual user identities
+ be associated with audit events. This could be appropriate
+ when the PP/ST also contains privacy requirements. If the
+ user identity must be incorporated could be used in addition.
+
+ If the subject is a user, the user identity may be recorded
+ as the subject identity. The identity of the user may not
+ yet been verified if has
+ not been applied. Therefore in the instance of an invalid
+ login the claimed user identity will be recorded as the
+ subject identity.
+
+
+
+ There is a dependency on . If correctness of time is not an issue for
+ this TOE, elimination of this dependency could be
+ justified.
+
+
+
+ defines the level of auditable
+ events, and specifies the list of data that shall be
+ recorded in each record.
+
+
+ The TSF shall be able to generate an audit record of the
+ following auditable events:
+
+
+ Start-up and shutdown of the audit functions;
+
+
+ All auditable events for the
+
+ minimum
+ basic
+ detailed
+ not specified
+
+
+ the PP/ST author should select the level of
+ auditable events called out in the audit section of
+ other functional components included in the
+ PP/ST. This level is one of the following:
+ ``minimum'', ``basic'', ``detailed'' or ``not
+ specified''.
+
+
+ level of audit; and
+
+
+
+
+ other specifically defined auditable events
+
+
+
+ the PP/ST author should assign a list of other
+ specifically defined auditable events to be included
+ in the list of auditable events. The assignment may
+ comprise none, or events that could be auditable
+ events of a functional requirement that are of a
+ higher audit level than requested in , as well as the
+ events generated through the use of a specified
+ Application Programming Interface (API).
+
+ .
+
+
+
+
+ The TSF shall record within each audit record at least the
+ following information:
+
+
+ Date and time of the event, type of event, subject
+ identity, and the outcome (success or failure) of the
+ event; and
+
+
+ For each audit event type, based on the auditable event
+ definitions of the functional components included in the
+ PP/ST,
+
+
+ other audit relevant information
+
+
+
+ the PP/ST author should assign, for each auditable
+ events included in the PP/ST, either a list of other
+ audit relevant information to be included in audit
+ events records or none.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ This component addresses the requirement of accountability
+ of auditable events at the level of individual user
+ identity. This component should be used in addition to
+ .
+
+ There is a potential conflict between the audit and privacy
+ requirements. For audit purposes it may be desirable to know
+ who performed an action. The user may want to keep his/her
+ actions to himself/herself and not be identified by other
+ persons (e.g. a site with job offers). Or it might be
+ required in the Organisational Security Policy that the
+ identity of the users must be protected. In those cases the
+ objectives for audit and privacy might contradict each
+ other. Therefore if this requirement is selected and privacy
+ is important, inclusion of the component user pseudonimity
+ might be considered. Requirements on determining the real
+ user name based on its pseudonym are specified in the
+ privacy class.
+
+ If the identity of the user has not yet been verified
+ through authentication, in the instance of an invalid
+ login the claimed user identity will be recorded as the
+ user identity.
+
+
+
+ At , the TSF shall associate
+ auditable events to individual user identities.
+
+
+ The TSF shall be able to associate each auditable event with
+ the identity of the user that caused the event.
+
+
+
+
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible or
+ real security violations. This analysis may work in support of
+ intrusion detection, or automatic response to a potential
+ security violation.
+
+ The actions to be taken based on the detection can be
+ specified using the family as
+ desired.
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible
+ or real security violations. This analysis may work in
+ support of intrusion detection, or automatic response to a
+ potential security violation.
+
+ The action to be performed by the TSF on detection of a
+ potential violation is defined in components.
+
+ For real-time analysis, audit data could be transformed into a
+ useful format for automated treatment, but into a different
+ useful format for delivery to authorised users for
+ review.
+
+
+
+
+
+
+
+
+ This component is used to specify the set of auditable
+ events whose occurrence or accumulated occurrence held to
+ indicate a potential violation of the enforcement of the
+ SFRs, and any rules to be used to perform the violation
+ analysis.
+
+
+
+ In , basic threshold
+ detection on the basis of a fixed rule set is
+ required.
+
+
+ maintenance of the rules by (adding, modifying, deletion)
+ of rules from the set of rules.
+
+
+ Enabling and disabling of any of the analysis mechanisms;
+
+
+ Automated responses performed by the tool.
+
+
+ The TSF shall be able to apply a set of rules in monitoring
+ the audited events and based upon these rules indicate a
+ potential violation of the enforcement of the SFRs.
+
+
+ The TSF shall enforce the following rules for monitoring
+ audited events:
+
+
+ Accumulation or combination of
+
+
+ subset of defined auditable events
+
+
+
+ the PP/ST author should identify the subset of
+ defined auditable events whose occurrence or
+ accumulated occurrence need to be detected as an
+ indication of a potential violation of the
+ enforcement of the SFRs.
+
+
+ known to indicate a potential security violation;
+
+
+
+
+ any other rules
+
+
+
+ the PP/ST author should specify any other rules that
+ the TSF should use in its analysis of the audit
+ trail. Those rules could include specific
+ requirements to express the needs for the events to
+ occur in a certain period of time (e.g. period of
+ the day, duration). If there are no additional
+ rules that the TSF should use in the analysis of the
+ audit trail, this assignment can be completed with
+ ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ A profile is a structure that
+ characterises the behaviour of users and/or subjects; it
+ represents how the users/subjects interact with the TSF in
+ a variety of ways. Patterns of usage are established with
+ respect to the various types of activity the
+ users/subjects engage in (e.g. patterns in exceptions
+ raised, patterns in resource utilisation (when, which,
+ how), patterns in actions performed). The ways in which
+ the various types of activity are recorded in the profile
+ (e.g. resource measures, event counters, timers) are
+ referred to as profile metrics.
+
+ Each profile represents the expected patterns of usage
+ performed by members of the profile target
+ group. This pattern may be based on past use
+ (historical patterns) or on normal use for users of
+ similar target groups (expected behaviour). A profile
+ target group refers to one or more users who interact with
+ the TSF. The activity of each member of the profile group
+ is used by the analysis tool in establishing the usage
+ patterns represented in the profile. The following are
+ some examples of profile target groups:
+
+
+ Single user account: one profile per
+ user;
+
+
+ Group ID or Group Account: one profile
+ for all users who possess the same group ID or operate
+ using the same group account;
+
+
+ Operating Role: one profile for all users
+ sharing a given operating role;
+
+
+ System: one profile for all users of a
+ system.
+
+
+
+ Each member of a profile target group is assigned an
+ individual suspicion rating that
+ represents how closely that member's new
+ activity corresponds to the established patterns of usage
+ represented in the group profile.
+
+ The sophistication of the anomaly detection tool will
+ largely be determined by the number of target profile
+ groups required by the PP/ST and the complexity of the
+ required profile metrics.
+
+ This component is used to specify the set of auditable
+ events whose occurrence or accumulated occurrence indicates
+ a potential violation of the enforcement of the SFRs, and
+ any rules to be used to perform the violation analysis. This
+ set of events or rules could be modified by the authorised
+ user, through addition, modification or deletion of events
+ or rules.
+
+ The PP/ST author should enumerate specifically what activity
+ should be monitored and/or analysed by the TSF. The PP/ST
+ author should also identify specifically what information
+ pertaining to the activity is necessary to construct the
+ usage profiles.
+
+ requires that the TSF
+ maintain profiles of system usage. The word maintain implies
+ that the anomaly detector is actively updating the usage
+ profile based on new activity performed by the profile
+ target members. It is important here that the metrics for
+ representing user activity are defined by the PP/ST
+ author. For example, there may be a thousand different
+ actions an individual may be capable of performing, but the
+ anomaly detector may choose to monitor a subset of that
+ activity. Anomalous activity gets integrated into the
+ profile just like non-anomalous activity (assuming the tool
+ is monitoring those actions). Things that may have appeared
+ anomalous four months ago, might over time become the norm
+ (and vice-versa) as the user's work duties change. The TSF
+ wouldn't be able to capture this notion if it filtered out
+ anomalous activity from the profile updating
+ algorithms.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ suspicion rating.
+
+ The PP/ST author should define how to interpret suspicion
+ ratings and the conditions under which anomalous activity is
+ indicated to the
+ mechanism.
+
+
+
+ In , the TSF maintains
+ individual profiles of system usage, where a profile
+ represents the historical patterns of usage performed by
+ members of the profile target group. A profile target group
+ refers to a group of one or more individuals (e.g. a single
+ user, users who share a group ID or group account, users who
+ operate under an assigned role, users of an entire system or
+ network node) who interact with the TSF. Each member of a
+ profile target group is assigned an individual suspicion
+ rating that represents how well that member's current
+ activity corresponds to the established patterns of usage
+ represented in the profile. This analysis can be performed
+ at runtime or during a post-collection batch-mode
+ analysis.
+
+
+ maintenance (deletion, modification, addition) of the
+ group of users in the profile target group.
+
+
+
+ The TSF shall be able to maintain profiles of system usage,
+ where an individual profile represents the historical
+ patterns of usage performed by the member(s) of
+
+
+ the profile target group
+
+
+
+ the PP/ST author should specify the profile target
+ group. A single PP/ST may include multiple profile
+ target groups.
+
+ .
+
+
+ The TSF shall be able to maintain a suspicion rating
+ associated with each user whose activity is recorded in a
+ profile, where the suspicion rating represents the degree to
+ which the user's current activity is found
+ inconsistent with the established patterns of usage
+ represented in the profile.
+
+
+ The TSF shall be able to indicate a possible violation of
+ the enforcement of the SFRs when a user's suspicion rating exceeds
+ the following threshold conditions
+
+
+ conditions under which anomalous activity is reported by
+ the TSF
+
+
+
+ the PP/ST author should specify conditions under which
+ anomalous activity is reported by the TSF. Conditions
+ may include the suspicion rating reaching a certain
+ value, or be based on the type of anomalous activity
+ observed.
+
+ .
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant that they are always worthy of
+ independent review. Example of such events include the
+ deletion of a key TSF security data file (e.g. the
+ password file) or activity such as a remote user
+ attempting to gain administrative privilege. These events
+ are referred to as signature events in that their
+ occurrence in isolation from the rest of the system
+ activity are indicative of intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data).
+
+ The elements of do not
+ require that the TSF implementing the immediate attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able
+ to detect the occurrence of signature events that represent
+ a significant threat to enforcement of the SFRs. This search
+ for signature events may occur in real-time or during a
+ post-collection batch-mode analysis.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of system
+ events whose occurrence, in isolation from all other
+ system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by
+ themselves indicate a clear violation to the enforcement
+ of the SFRs, or whose occurrence is so significant that
+ they warrant actions.
+
+
+ that may indicate a violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events
+ against the record of system activity discernible from an
+ examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when a system event is found to match
+ a signature event that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant they are always worthy of independent
+ review. Example of such events include the deletion of a key
+ TSF security data file (e.g. the password file) or activity
+ such as a remote user attempting to gain administrative
+ privilege. These events are referred to as signature events
+ in that their occurrence in isolation from the rest of the
+ system activity are indicative of intrusive activity. Event
+ sequences are an ordered set of signature events that might
+ indicate intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events and event sequences.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data). Levelling, therefore, requires the
+ PP/ST author to specify the type of input data used to
+ monitor system activity.
+
+ The elements of do not
+ require that the TSF implementing the complex attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able to
+ represent and detect multi-step intrusion scenarios. The
+ TSF is able to compare system events (possibly performed
+ by multiple individuals) against event sequences known to
+ represent entire intrusion scenarios. The TSF shall be
+ able to indicate when a signature event or event sequence
+ is found that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events;
+
+
+ maintenance (deletion, modification, addition) of the set of
+ sequence of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following event sequences of known intrusion
+ scenarios
+
+
+ list of sequences of system events whose occurrence are
+ representative of known penetration scenarios
+
+
+
+ the PP/ST author should identify a base set of list of
+ sequences of system events whose occurrence are
+ representative of known penetration scenarios. These
+ event sequences represent known penetration
+ scenarios. Each event represented in the sequence should
+ map to a monitored system event, such that as the system
+ events are performed, they are bound (mapped) to the
+ known penetration event sequences.
+
+
+ and the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of
+ system events whose occurrence, in isolation from all
+ other system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by themselves indicate
+ a clear violation to the SFRs, or whose occurrence is
+ so significant they warrant action.
+
+
+ that may indicate a potential
+ violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events and
+ event sequences against the record of system activity
+ discernible from an examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when system activity is found to match
+ a signature event or event sequence that indicates a potential
+ violation of the enforcement of the SFRs.
+
+
+
+
+
+
+
+ This family defines the requirements for audit tools that
+ should be available to authorised users to assist in the
+ review of audit data.
+
+
+
+ The Security audit review family defines requirements
+ related to review of the audit information.
+
+ These functions should allow pre-storage or post-storage
+ audit selection that includes, for example, the ability to
+ selectively review:
+
+
+ the actions of one or more users (e.g. identification,
+ authentication, TOE entry, and access control actions);
+
+
+ the actions performed on a specific object or TOE
+ resource;
+
+
+ all of a specified set of audited exceptions;
+ or
+
+
+ actions associated with a specific SFR attribute.
+
+
+
+ The distinction between audit reviews is based on
+ functionality. Audit review (only) encompasses the ability
+ to view audit data. Selectable review is more sophisticated,
+ and requires the ability to perform searches based on a
+ single criterion or multiple criteria with logical
+ (i.e. and/or) relations, sort audit data, filter audit data,
+ before audit data are reviewed.
+
+
+
+
+
+
+
+
+ This component will provide authorised users the
+ capability to obtain and interpret the information. In
+ case of human users this information needs to be in a
+ human understandable presentation. In case of external IT
+ entities the information needs to be unambiguously
+ represented in an electronic fashion.
+
+
+
+ This component is used to specify that users and/or
+ authorised users can read the audit records. These audit
+ records will be provided in a manner appropriate to the
+ user. There are different types of users (human users,
+ machine users) that might have different needs.
+
+ The content of the audit records that can be viewed can be
+ specified.
+
+
+
+ , provides the capability to read
+ information from the audit records.
+
+
+ maintenance (deletion, modification, addition) of the group
+ of users with read access right to the audit records.
+
+
+ Reading of information from the audit records.
+
+
+ The TSF shall provide
+
+
+ authorised users
+
+
+
+ the PP/ST author should specify the authorised users
+ that can use this capability. If appropriate the PP/ST
+ author may include security roles (see ).
+
+
+ with the capability to read
+
+
+ list of audit information
+
+
+
+ the PP/ST author should specify the type of information
+ the specified user is permitted to obtain from the audit
+ records. Examples are ``all'', ``subject identity'',
+ ``all information belonging to audit records referencing
+ this user''. When employing the SFR, FAU_SAR.1, it is not
+ necessary to repeat, in full detail, the list of audit
+ information first specified in FAU_GEN.1. Use of terms
+ such as ``all'' or ``all audit information'' assist in
+ eliminating ambiguity and the further need for
+ comparative analysis between the two security
+ requirements.
+
+
+ from the audit records.
+
+
+ The TSF shall provide the audit records in a manner suitable
+ for the user to interpret the information.
+
+
+
+
+
+
+
+
+
+ This component specifies that any users not identified in
+ will not be able to read
+ the audit records.
+
+
+
+ , requires that there are
+ no other users except those that have been identified in
+ that can read the
+ information.
+
+
+ Unsuccessful attempts to read information from the audit
+ records.
+
+
+ The TSF shall prohibit all users read access to the audit
+ records, except those users that have been granted explicit
+ read-access.
+
+
+
+
+
+
+
+
+
+ This component is used to specify that it should be
+ possible to perform selection of the audit data to be
+ reviewed. If based on multiple criteria, those criteria
+ should be related together with logical
+ (i.e. ``and'' or
+ ``or'') relations, and the tools
+ should provide the ability to manipulate audit data
+ (e.g. sort, filter).
+
+
+
+ , requires audit review
+ tools to select the audit data to be reviewed based on
+ criteria.
+
+
+ the parameters used for the viewing.
+
+
+ The TSF shall provide the ability to perform
+
+ searches
+ sorting
+ ordering
+
+
+ the PP/ST author should select whether searches,
+ sorting and/or ordering can be performed by the TSF.
+
+
+ of audit data based on
+
+
+ criteria with logical relations
+
+
+
+ the PP/ST author should assign the criteria, possibly
+ with logical relations, to be used to select the audit
+ data for review. The logical relations are intended to
+ specify whether the operation can be on an individual
+ attribute or a collection of attributes. An example of
+ this assignment could be: ``application, user account
+ and/or location''. In this case the operation could be
+ specified using any combination of the three attributes:
+ application, user account and location.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements to select the events to be
+ audited during TOE operation. It defines requirements to
+ include or exclude events from the set of auditable events.
+
+
+
+ The Security audit event selection family provides
+ requirements related to the capabilities of identifying which
+ of the possible auditable events are to be audited. The
+ auditable events are defined in the family, but those events should be defined as
+ being selectable in this component to be audited.
+
+ This family ensures that it is possible to keep the audit
+ trail from becoming so large that it becomes useless, by
+ defining the appropriate granularity of the selected
+ security audit events.
+
+
+
+
+
+
+
+
+
+ This component defines the criteria used for the selection
+ of events to be audited. Those criteria could permit
+ inclusion or exclusion of events from the set of auditable
+ events, based on user attributes, subject attributes,
+ objects attributes, or event types.
+
+ The existence of individual user identities is not assumed
+ for this component. This allows for TOEs such as routers
+ that may not support the notion of users.
+
+ For a distributed environment, the host identity could be
+ used as a selection criteria for events to be audited.
+
+ The management function
+ will handle the rights of authorised users to query or
+ modify the selections.
+
+
+
+ , requires the ability to
+ include or exclude events from the set of audited events,
+ identified in , based upon
+ attributes to be specified by the PP/ST author.
+
+
+ maintenance of the rights to view/modify the audit events.
+
+
+ All modifications to the audit configuration that occur
+ while the audit collection functions are operating.
+
+
+ The TSF shall be able to include or exclude auditable events
+ from the set of audited events based on the following
+ attributes:
+
+
+
+ object identity
+ user identity
+ subject identity
+ host identity
+ event type
+
+
+ the PP/ST author should select whether the
+ security attributes upon which audit selectivity
+ is based, is related to object identity, user
+ identity, subject identity, host identity, or
+ event type.
+
+
+
+
+
+
+ list of additional attributes that audit selectivity
+ is based upon
+
+
+
+ the PP/ST author should specify any additional
+ attributes upon which audit selectivity is based. If
+ there are no additional rules upon which audit
+ selectivity is based, this assignment can be
+ completed with ``none''.
+
+
+
+
+
+
+
+
+
+
+
+ This family defines the requirements for the TSF to be able
+ to create and maintain a secure audit trail. Stored audit
+ records refers to those records within the audit trail, and
+ not the audit records that have been retrieved (to temporary
+ storage) through selection.
+
+
+
+ The Security audit event storage family describes
+ requirements for storing audit data for later use, including
+ requirements controlling the loss of audit information due
+ to TOE failure, attack and/or exhaustion of storage
+ space.
+
+
+
+
+
+
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+ The TSF will protect the audit trail from unauthorised
+ deletion and modification. It is noted that in some TOEs the
+ auditor (role) might not be authorised to delete the audit
+ records for a certain period of time.
+
+
+
+ At , requirements are
+ placed on the audit trail. It will be protected from
+ unauthorised deletion and/or modification.
+
+
+ The TSF shall protect the stored audit records in the audit
+ trail from unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+
+
+
+
+
+
+
+
+ This component allows the PP/ST author to specify to which
+ metrics the audit trail should conform.
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+
+
+ , specifies the guarantees
+ that the TSF maintains over the audit data given the
+ occurrence of an undesired condition.
+
+
+ maintenance of the parameters that control the audit storage
+ capability.
+
+
+ The TSF shall protect the stored audit records from
+ unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+ The TSF shall ensure that
+
+
+ metric for saving audit records
+
+
+
+ the PP/ST author should specify the metric that the TSF
+ must ensure with respect to the stored audit
+ records. This metric limits the data loss by enumerating
+ the number of records that must be kept, or the time
+ that records are guaranteed to be maintained. An example
+ of the metric could be ``100,000'' indicating that
+ 100,000 audit records can be stored.
+
+
+ stored audit records will be maintained when the
+ following conditions occur:
+
+ audit storage exhaustion
+ failure
+ attack
+
+
+ the PP/ST author should specify the condition under which the
+ TSF shall still be able to maintain a defined amount of audit
+ data. This condition can be any of the following: audit
+ storage exhaustion, failure, attack.
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that actions will be taken when
+ the audit trail exceeds certain pre-defined limits.
+
+
+
+ , specifies actions to be taken if a
+ threshold on the audit trail is exceeded.
+
+
+ maintenance of the threshold;
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of imminent audit storage failure.
+
+
+ Actions taken due to exceeding of a threshold.
+
+
+ The TSF shall
+
+
+ actions to be taken in case
+ of possible audit storage failure
+
+
+
+ the PP/ST author should indicate the pre-defined
+ limit. If the management functions indicate that this
+ number might be changed by the authorised user, this
+ value is the default value. The PP/ST author might
+ choose to let the authorised user define this
+ limit. In that case the assignment can be for example
+ ``an authorised user set limit''.
+
+
+ if the audit trail exceeds
+
+
+ pre-defined limit
+
+
+
+ the PP/ST author should specify actions that should be
+ taken in case of imminent audit storage failure
+ indicated by exceeding the threshold. Actions might
+ include informing an authorised user.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies the behaviour of the TOE if the
+ audit trail is full: either audit records are ignored, or
+ the TOE is frozen such that no auditable events can take
+ place. The requirement also states that no matter how the
+ requirement is instantiated, the authorised user with
+ specific rights to this effect, can continue to generate
+ auditable events (actions). The reason is that otherwise
+ the authorised user could not even reset the
+ TOE. Consideration should be given to the choice of the
+ action to be taken by the TSF in the case of audit storage
+ exhaustion, as ignoring events, which provides better
+ availability of the TOE, will also permit actions to be
+ performed without being recorded and without the user
+ being accountable.
+
+
+
+ , specifies actions in case the
+ audit trail is full.
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of audit storage failure.
+
+
+ Actions taken due to the audit storage failure.
+
+
+ The TSF shall
+
+ ``ignore auditable
+ events''
+ ``prevent auditable events,
+ except those taken by the authorised user with special
+ rights''
+
+ ``overwrite the oldest stored audit
+ records''
+
+
+
+ the PP/ST author should select whether the TSF shall ignore
+ auditable actions, or whether it should prevent auditable
+ actions from happening, or whether the oldest audit records
+ should be overwritten when the TSF can no longer store audit
+ records. Only one of these options may be chosen.
+
+
+ and
+
+
+ other actions to be taken in case of audit storage
+ failure
+
+
+
+ the PP/ST author should specify other actions that should be
+ taken in case of audit storage failure, such as informing the
+ authorised user. If there is no other action to be taken in
+ case of audit storage failure, this assignment can be
+ completed with ``none''.
+
+
+ if the audit trail is full.
+
+
+
+
+
+
+
+ This class provides two families specifically concerned with
+ assuring the identity of a party participating in a data
+ exchange. These families are related to assuring the identity
+ of the originator of transmitted information (proof of origin)
+ and assuring the identity of the recipient of transmitted
+ information (proof of receipt). These families ensure that an
+ originator cannot deny having sent the message, nor can the
+ recipient deny having received it.
+
+
+
+ This class describes requirements specifically of interest for
+ TOEs that are used for the transport of information. Families
+ within this class deal with non-repudiation.
+
+ In this class the concept of ``information'' is
+ used. This information should be interpreted as the object
+ being communicated, and could contain an electronic mail
+ message, a file, or a set of predefined attribute types.
+
+ In the literature, the terms ``proof of receipt''
+ and ``proof of origin'' are commonly used
+ terms. However it is recognised that the term
+ ``proof'' might be interpreted in a legal sense to
+ imply a form of mathematical rationale. The components in this
+ class interpret the de-facto use of the word
+ ``proof'' in the context of ``evidence''
+ that the TSF demonstrates the non-repudiated transport of
+ types of information.
+
+
+
+
+
+ Non-repudiation of origin ensures that the originator of
+ information cannot successfully deny having sent the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that receives information
+ during a data exchange is provided with evidence of the
+ origin of the information. This evidence can then be
+ verified by either this subject or other subjects.
+
+
+
+ Non-repudiation of origin defines requirements to provide
+ evidence to users/subjects about the identity of the
+ originator of some information. The originator cannot
+ successfully deny having sent the information because
+ evidence of origin (e.g. digital signature) provides
+ evidence of the binding between the originator and the
+ information sent. The recipient or a third party can verify
+ the evidence of origin. This evidence should not be
+ forgeable.
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of origin might
+ fail. Therefore a PP/ST author should consider including
+ integrity requirements such as in the
+ PP/ST.
+
+ In non-repudiation there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of origin (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of origin, for
+ example, a recipient or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was transmitted. For example, requests for
+ proposals must be transmitted before a certain date in order
+ to be considered. In such instances, these requirements can
+ be customised to provide a timestamp indication (time of
+ origin).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with the capability to request evidence of the
+ origin of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and recipients of evidence.
+
+
+ The identity of the user who requested that evidence of
+ origin would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall be able to generate evidence of origin for
+ transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection, should specify the third
+ parties that can request evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of origin.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+ list of information fields
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of origin for transmitted information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of origin
+ for transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at all times.
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ Non-repudiation of receipt ensures that the recipient of
+ information cannot successfully deny receiving the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that transmits information
+ during a data exchange is provided with evidence of receipt
+ of the information. This evidence can then be verified by
+ either this subject or other subjects.
+
+
+
+ Non-repudiation of receipt defines requirements to provide
+ evidence to other users/subjects that the information was
+ received by the recipient. The recipient cannot successfully
+ deny having received the information because evidence of
+ receipt (e.g. digital signature) provides evidence of the
+ binding between the recipient attributes and the
+ information. The originator or a third party can verify the
+ evidence of receipt. This evidence should not be forgeable.
+
+ It should be noted that the provision of evidence that the
+ information was received does not necessarily imply that the
+ information was read or comprehended, but only delivered
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of receipt with
+ respect to the original information might fail. Therefore a
+ PP/ST author should consider including integrity
+ requirements such as in the PP/ST.
+
+ In non-repudiation, there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of receipt (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided, (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of receipt, for
+ example, an originator or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case, the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was received. For example, when an offer expires
+ at a certain date, orders must be received before a certain
+ date in order to be considered. In such instances, these
+ requirements can be customised to provide a timestamp
+ indication (time of receipt).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with a capability to request evidence of the
+ receipt of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and third parties recipients of
+ evidence.
+
+
+ The identity of the user who requested that evidence of
+ receipt would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+ The TSF shall be able to generate
+ evidence of receipt for received
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can request
+ evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of receipt.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of receipt for received information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of receipt
+ for received
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example electronic mail messages.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+ For each cryptographic key generation method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key distribution method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key access method implemented by the
+ TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key destruction method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic operation (such as digital signature,
+ data encryption, key agreement, secure hash, etc.) performed
+ by the TOE, if any, the PP/ST author should select the component.
+
+ Cryptographic functionality may be used to meet objectives
+ specified in class , and in families , , ,
+ , , , to meet a variety of objectives. In the cases
+ where cryptographic functionality is used to meet objectives
+ for other classes, the individual functional components
+ specify the objectives that cryptographic functionality must
+ satisfy. The objectives in class should be
+ used when cryptographic functionality of the TOE is sought by
+ consumers.
+
+
+
+
+
+ Cryptographic keys must be managed throughout their life
+ cycle. This family is intended to support that lifecycle and
+ consequently defines requirements for the following
+ activities: cryptographic key generation, cryptographic key
+ distribution, cryptographic key access and cryptographic key
+ destruction. This family should be included whenever there
+ are functional requirements for the management of
+ cryptographic keys.
+
+
+
+ Cryptographic keys must be managed throughout their
+ lifetime. The typical events in the lifecycle of a
+ cryptographic key include (but are not limited to):
+ generation, distribution, entry, storage, access
+ (e.g. backup, escrow, archive, recovery) and destruction.
+
+ The inclusion of other stages is dependent on the key management
+ strategy being implemented, as the TOE need not be involved in
+ all of the key life-cycle (e.g. the TOE may only generate and
+ distribute cryptographic keys).
+
+ This family is intended to support the cryptographic key
+ lifecycle and consequently defines requirements for the
+ following activities: cryptographic key generation,
+ cryptographic key distribution, cryptographic key access and
+ cryptographic key destruction. This family should be
+ included whenever there are functional requirements for the
+ management of cryptographic keys.
+
+ If Security Audit Data Generation is
+ included in the PP/ST then, in the context of the events
+ being audited:
+
+
+ The object attributes may include the assigned user
+ for the cryptographic key, the user role, the
+ cryptographic operation that the cryptographic key is
+ to be used for, the cryptographic key identifier and
+ the cryptographic key validity period.
+
+
+ The object value may include the values of cryptographic
+ key(s) and parameters excluding any sensitive
+ information (such as secret or private cryptographic
+ keys).
+
+
+
+ Typically, random numbers are used to generate cryptographic
+ keys. If this is the case, then
+ Cryptographic key generation should be used instead of the
+ component TSF Generation of
+ secrets. In cases where random number generation is required
+ for purposes other than for the generation of cryptographic
+ keys, the component TSF Generation of
+ secrets should be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic key sizes and
+ method used to generate cryptographic keys to be
+ specified, this can be in accordance with an assigned
+ standard. It should be used to specify the cryptographic
+ key sizes and the method (e.g. algorithm) used to generate
+ the cryptographic keys. Only one instance of the component
+ is needed for the same method and multiple key sizes. The
+ key size could be common or different for the various
+ entities, and could be either the input to or the output
+ from the method.
+
+
+
+ , requires cryptographic keys to be
+ generated in accordance with a specified algorithm and key
+ sizes which can be based on an assigned standard.
+
+
+ the management of changes to cryptographic key
+ attributes. Examples of key attributes include user, key
+ type (e.g. public, private, secret), validity period, and
+ use (e.g. digital signature, key encryption, key agreement,
+ data encryption).
+
+
+ Success and failure of the activity.
+
+
+ The object attribute(s), and object value(s) excluding any
+ sensitive information (e.g. secret or private keys).
+
+
+ The TSF shall generate cryptographic keys in accordance with
+ a specified cryptographic key generation algorithm
+
+
+ cryptographic key generation algorithm
+
+
+
+ the PP/ST author should specify the cryptographic key
+ generation algorithm to be used.
+
+
+ and specified cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to generate
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to distribute
+ cryptographic keys to be specified, this can be in
+ accordance with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ distributed in accordance with a specified distribution
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall distribute cryptographic keys in accordance
+ with a specified cryptographic key distribution method
+
+
+ cryptographic key distribution method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ distribution method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to distribute
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to access
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires access to cryptographic
+ keys to be performed in accordance with a specified access
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall perform
+
+
+ type of cryptographic key access
+
+
+
+ the PP/ST author should specify the type of
+ cryptographic key access being used. Examples of types
+ of cryptographic key access include (but are not
+ limited to) cryptographic key backup, cryptographic
+ key archival, cryptographic key escrow and
+ cryptographic key recovery.
+
+
+ in accordance with a specified cryptographic key access
+ method
+
+
+ cryptographic key access method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ access method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to access cryptographic
+ keys. The assigned standard may comprise none, one or
+ more actual standards publications, for example, from
+ international, national, industry or organisational
+ standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to destroy
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ destroyed in accordance with a specified destruction
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall destroy cryptographic keys in accordance with
+ a specified cryptographic key destruction method
+
+
+ cryptographic key destruction method
+
+
+
+ the PP/ST author should specify the key destruction
+ method to be used to destroy cryptographic keys.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to destroy
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+ In order for a cryptographic operation to function
+ correctly, the operation must be performed in accordance
+ with a specified algorithm and with a cryptographic key of a
+ specified size. This family should be included whenever
+ there are requirements for cryptographic operations to be
+ performed.
+
+ Typical cryptographic operations include data encryption
+ and/or decryption, digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or verification of checksum, secure hash
+ (message digest), cryptographic key encryption and/or
+ decryption, and cryptographic key agreement.
+
+
+
+ A cryptographic operation may have cryptographic mode(s) of
+ operation associated with it. If this is the case, then the
+ cryptographic mode(s) must be specified. Examples of
+ cryptographic modes of operation are cipher block chaining,
+ output feedback mode, electronic code book mode, and cipher
+ feedback mode.
+
+ Cryptographic operations may be used to support one or more
+ TOE security services. The component
+ may need to be iterated more than once depending on:
+
+
+ the user application for which the security service is
+ being used.
+
+
+ the use of different cryptographic algorithms and/or
+ cryptographic key sizes.
+
+
+ the type or sensitivity of the data being operated on.
+
+
+
+ If Security audit data generation is
+ included in the PP/ST then, in the context of the
+ cryptographic operation events being audited:
+
+
+ The types of cryptographic operation may include digital
+ signature generation and/or verification, cryptographic
+ checksum generation for integrity and/or for
+ verification of checksum, secure hash (message digest)
+ computation, data encryption and/or decryption,
+ cryptographic key encryption and/or decryption,
+ cryptographic key agreement and random number
+ generation.
+
+
+ The subject attributes may include subject role(s) and
+ user(s) associated with the subject.
+
+
+ The object attributes may include the assigned user for
+ the cryptographic key, user role, cryptographic
+ operation the cryptographic key is to be used for,
+ cryptographic key identifier, and the cryptographic key
+ validity period.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic algorithm and
+ key size used to perform specified cryptographic
+ operation(s) which can be based on an assigned standard.
+
+
+
+ , requires a cryptographic operation
+ to be performed in accordance with a specified algorithm
+ and with a cryptographic key of specified sizes. The
+ specified algorithm and cryptographic key sizes can be
+ based on an assigned standard.
+
+
+ Success and failure, and the type of cryptographic
+ operation.
+
+
+ Any applicable cryptographic mode(s) of operation, subject
+ attributes and object attributes.
+
+
+ The TSF shall perform
+
+
+ list of cryptographic operations
+
+
+
+ the PP/ST author should specify the cryptographic
+ operations being performed. Typical cryptographic
+ operations include digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or for verification of checksum, secure
+ hash (message digest) computation, data encryption
+ and/or decryption, cryptographic key encryption and/or
+ decryption, cryptographic key agreement and random
+ number generation. The cryptographic operation may be
+ performed on user data or TSF data.
+
+
+ in accordance with a specified cryptographic algorithm
+
+
+ cryptographic algorithm
+
+
+
+ the PP/ST author should specify the cryptographic
+ algorithm to be used. Typical cryptographic algorithms
+ include, but are not limited to, DES, RSA and IDEA.
+
+
+ and cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents how the identified cryptographic
+ operation(s) are performed. The assigned standard may
+ comprise none, one or more actual standards
+ publications, for example, from international,
+ national, industry or organisational standards.
+
+ .
+
+
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. is split
+ into four groups of families (listed below) that address user
+ data within a TOE, during import, export, and storage as well
+ as security attributes directly related to user data.
+
+ The families in this class are organised into four groups:
+
+
+ User data protection security function policies:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families permit the PP/ST author to
+ name the user data protection security function policies
+ and define the scope of control of the policy, necessary
+ to address the security objectives. The names of these
+ policies are meant to be used throughout the remainder
+ of the functional components that have an operation that
+ calls for an assignment or selection of an "access
+ control SFP" or an "information flow control
+ SFP". The rules that define the functionality of
+ the named access control and information flow control
+ SFPs will be defined in the and
+ families (respectively).
+
+
+ Forms of user data protection:
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ; and
+
+
+ .
+
+
+
+
+ Off-line storage, import and export:
+
+
+ ;
+
+
+ ;
+
+
+ .
+
+
+
+ Components in these families address the trustworthy
+ transfer into or out of the TOE.
+
+
+ Inter-TSF communication:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families address communication
+ between the TSF of the TOE and another trusted IT
+ product.
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. This class differs from FIA and FPT
+ in that specifies components to
+ protect user data, FIA specifies components to protect
+ attributes associated with the user, and FPT specifies
+ components to protect TSF information.
+
+ The class does not contain explicit requirements for
+ traditional Mandatory Access Controls (MAC) or traditional
+ Discretionary Access Controls (DAC); however, such
+ requirements may be constructed using components from this
+ class.
+
+ does not explicitly deal with
+ confidentiality, integrity, or availability, as all three are
+ most often intertwined in the policy and mechanisms. However,
+ the TOE security policy must adequately cover these three
+ objectives in the PP/ST.
+
+ A final aspect of this class is that it specifies access
+ control in terms of ``operations''. An operation
+ is defined as a specific type of access on a specific
+ object. It depends on the level of abstraction of the PP/ST
+ author whether these operations are described as
+ ``read'' and/or ``write''
+ operations, or as more complex operations such as
+ ``update the database''.
+
+ The access control policies are policies that control access
+ to the information container. The attributes represent
+ attributes of the container. Once the information is out of
+ the container, the accessor is free to modify that
+ information, including writing the information into a
+ different container with different attributes. By contrast, an
+ information flow policies controls access to the information,
+ independent of the container. The attributes of the
+ information, which may be associated with the attributes of
+ the container (or may not, as in the case of a multi-level
+ database) stay with the information as it moves. The accessor
+ does not have the ability, in the absence of an explicit
+ authorisation, to change the attributes of the information.
+
+ This class is not meant to be a complete taxonomy of IT access
+ policies, as others can be imagined. Those policies included
+ here are simply those for which current experience with actual
+ systems provides a basis for specifying requirements. There
+ may be other forms of intent that are not captured in the
+ definitions here.
+
+ For example, one could imagine a goal of having user-imposed
+ (and user-defined) controls on information flow (e.g. an
+ automated implementation of the NO FOREIGN handling
+ caveat). Such concepts could be handled as refinements of, or
+ extensions to the components.
+
+ Finally, it is important when looking at the components in
+ to remember that these components are
+ requirements for functions that may be implemented by a
+ mechanism that also serves or could serve another purpose. For
+ example, it is possible to build an access control policy
+ () that uses labels () as the basis of the access control
+ mechanism.
+
+ A set of SFRs may encompass many security function
+ policies (SFPs), each to be identified by the two policy
+ oriented components , and . These policies will typically take
+ confidentiality, integrity, and availability aspects into
+ consideration as required, to satisfy the TOE
+ requirements. Care should be taken to ensure that all objects
+ are covered by at least one SFP and that there are no
+ conflicts arising from implementing the multiple SFPs.
+
+ When building a PP/ST using components from the class, the following information provides guidance
+ on where to look and what to select from the class.
+
+ The requirements in the class are defined in
+ terms of a set of SFRs that will
+ implement a SFP. Since a TOE may implement multiple SFPs
+ simultaneously, the PP/ST author must specify the name for
+ each SFP, so it can be referenced in other families. This name
+ will then be used in each component selected to indicate that
+ it is being used as part of the definition of requirements for
+ that SFP. This allows the author to easily indicate the
+ scope for operations such as objects covered, operations
+ covered, authorised users, etc.
+
+ Each instantiation of a component can apply to only one
+ SFP. Therefore if an SFP is specified in a component then
+ this SFP will apply to all the elements in this
+ component. The components may be instantiated multiple times
+ within a PP/ST to account for different policies if so
+ desired.
+
+ The key to selecting components from this family is to have a
+ well defined set of TOE security objectives to enable proper
+ selection of the components from the two policy components;
+ and . In and respectively, all access control
+ policies and all information flow control policies are
+ named. Furthermore the scope of control of these components in
+ terms of the subjects, objects and operations covered by this
+ security functionality. The names of these policies are meant
+ to be used throughout the remainder of the functional
+ components that have an operation that calls for an assignment
+ or selection of an ``access control SFP'' or an ``information
+ flow control SFP''. The rules that define the functionality
+ of the named access control and information flow control SFPs
+ will be defined in the and
+ families
+ (respectively).
+
+ The following steps are guidance on how this class is applied
+ in the construction of a PP/ST:
+
+
+ Identify the policies to be enforced from the , and families. These
+ families define scope of control for the policy,
+ granularity of control and may identify some rules to go
+ with the policy.
+
+
+ Identify the components and perform any applicable operations
+ in the policy components. The assignment operations may be
+ performed generally (such as with a statement ``All
+ files'') or specifically (``The files
+ ``A'', ``B'', etc.) depending upon
+ the level of detail known.
+
+
+ Identify any applicable function components from the and families to address
+ the named policy families from and
+ . Perform the operations to make the
+ components define the rules to be enforced by the named
+ policies. This should make the components fit the
+ requirements of the selected function envisioned or to be
+ built.
+
+
+ Identify who will have the ability to control and change
+ security attributes under the function, such as only a
+ security administrator, only the owner of the object,
+ etc. Select the appropriate components from
+ and perform the operations. Refinements may be useful here
+ to identify missing features, such as that some or all
+ changes must be done via trusted path.
+
+
+ Identify any appropriate components from the for initial values for new objects and subjects.
+
+
+ Identify any applicable rollback components from the family.
+
+
+ Identify any applicable residual information protection
+ requirements from the family.
+
+
+ Identify any applicable import or export components, and how
+ security attributes should be handled during import and
+ export, from the and families.
+
+
+ Identify any applicable internal TOE communication
+ components from the family.
+
+
+ Identify any requirements for integrity protection of stored
+ information from the .
+
+
+ Identify any applicable inter-TSF communication components
+ from the or
+ families.
+
+
+
+
+
+
+
+ This family identifies the access control SFPs (by name) and
+ defines the scope of control of the policies that form the
+ identified access control portion of the SFRs related to the SFP. This scope of
+ control is characterised by three sets: the subjects under
+ control of the policy, the objects under control of the
+ policy, and the operations among controlled subjects and
+ controlled objects that are covered by the policy. The
+ criteria allows multiple policies to exist, each having a
+ unique name. This is accomplished by iterating components
+ from this family once for each named access control policy.
+ The rules that define the functionality of an access control
+ SFP will be defined by other families such as and . The names of the
+ access control SFPs identified here in
+ are meant to be used throughout the remainder of the
+ functional components that have an operation that calls for
+ an assignment or selection of an ``access control
+ SFP.''
+
+
+
+ This family is based upon the concept of arbitrary controls
+ on the interaction of subjects and objects. The scope and
+ purpose of the controls is based upon the attributes of the
+ accessor (subject), the attributes of the container being
+ accessed (object), the actions (operations) and any
+ associated access control rules.
+
+ The components in this family are capable of identifying the
+ access control SFPs (by name) to be enforced by the
+ traditional Discretionary Access Control (DAC)
+ mechanisms. It further defines the subjects, objects and
+ operations that are covered by identified access control
+ SFPs. The rules that define the functionality of an access
+ control SFP will be defined by other families, such as and . The names of the
+ access control SFPs defined in are
+ meant to be used throughout the remainder of the functional
+ components that have an operation that calls for an
+ assignment or selection of an ``access control
+ SFP.''
+
+ The access control SFP covers a set of triplets: subject,
+ object, and operations. Therefore a subject can be covered
+ by multiple access control SFPs but only with respect to a
+ different operation or a different object. Of course the
+ same applies to objects and operations.
+
+ A critical aspect of an access control function that
+ enforces an access control SFP is the ability for users to
+ modify the attributes involved in access control
+ decisions. The family does not address
+ these aspects. Some of these requirements are left
+ undefined, but can be added as refinements, while others are
+ covered elsewhere in other families and classes such as
+ .
+
+ There are no audit requirements in as
+ this family specifies access control SFP requirements. Audit
+ requirements will be found in families specifying functions
+ to satisfy the access control SFPs identified in this
+ family.
+
+ This family provides a PP/ST author the capability to
+ specify several policies, for example, a fixed access
+ control SFP to be applied to one scope of control, and a
+ flexible access control SFP to be defined for a different
+ scope of control. To specify more than one access control
+ policy, the components from this family can be iterated
+ multiple times in a PP/ST to different subsets of operations
+ and objects. This will accommodate TOEs that contain
+ multiple policies, each addressing a particular set of
+ operations and objects. In other words, the PP/ST author
+ should specify the required information in the ACC component
+ for each of the access control SFPs that the TSF will
+ enforce. For example, a TOE incorporating three access
+ control SFPs, each covering only a subset of the objects,
+ subjects, and operations within the TOE, will contain one
+ component for each of the three
+ access control SFPs, necessitating a total of three components.
+
+
+
+
+
+
+
+
+ The terms object and subject refer to generic elements in
+ the TOE. For a policy to be implementable, the entities
+ must be clearly identified. For a PP, the objects and
+ operations might be expressed as types such as: named
+ objects, data repositories, observe accesses, etc. For a
+ specific TOE these generic terms (subject, object) must be
+ refined, e.g. files, registers, ports, daemons, open
+ calls, etc.
+
+ This component specifies that the policy cover some
+ well-defined set of operations on some subset of the
+ objects. It places no constraints on any operations
+ outside the set - including operations on objects for
+ which other operations are controlled.
+
+
+
+ , requires that each identified
+ access control SFP be in place for a subset of the
+ possible operations on a subset of the objects in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects, objects, and operations among subjects
+ and objects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ objects, and operations among subjects and objects
+ covered by the SFP.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations on
+ objects, that are included in the SFP, are covered by an
+ access control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ objects and subjects is covered by an access control SFP.
+
+
+
+ , requires that each identified
+ access control SFP cover all operations on subjects and
+ objects covered by that SFP. It further requires that all
+ objects and operations protected by the TSF are covered by at
+ least one identified access control SFP.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects and objects
+
+
+
+ the PP/ST author should specify the list of subjects
+ and objects covered by the SFP. All operations among
+ those subjects and objects will be covered by the SFP.
+
+
+ and all operations among subjects and objects covered by the
+ SFP.
+
+
+ The TSF shall ensure that all operations between any subject
+ controlled by the TSF and any object controlled by the TSF are covered by an
+ access control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in . specifies the scope of control of the
+ policy.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in which also specifies the scope of
+ control of the policy.
+
+ This family provides a PP/ST author the capability to
+ describe the rules for access control. This results in a
+ TOE where the access to objects will not change. An
+ example of such an object is ``Message of the Day'', which
+ is readable by all, and changeable only by the authorised
+ administrator. This family also provides the PP/ST author
+ with the ability to describe rules that provide for
+ exceptions to the general access control rules. Such
+ exceptions would either explicitly allow or deny
+ authorisation to access an object.
+
+ There are no explicit components to specify other possible
+ functions such as two-person control, sequence rules for
+ operations, or exclusion controls. However, these
+ mechanisms, as well as traditional DAC mechanisms, can be
+ represented with the existing components, by careful
+ drafting of the access control rules.
+
+ A variety of acceptable access control functionality may be
+ specified in this family such as:
+
+
+ Access control lists (ACLs)
+
+
+ Time-based access control specifications
+
+
+ Origin-based access control specifications
+
+
+ Owner-controlled access control attributes
+
+
+
+
+
+
+
+
+
+
+ This component provides requirements for a mechanism that
+ mediates access control based on security attributes
+ associated with subjects and objects. Each object and
+ subject has a set of associated attributes, such as
+ location, time of creation, access rights (e.g., Access
+ Control Lists (ACLs)). This component allows the PP/ST
+ author to specify the attributes that will be used for the
+ access control mediation. This component allows access
+ control rules, using these attributes, to be
+ specified.
+
+ Examples of the attributes that a PP/ST author might
+ assign are presented in the following paragraphs.
+
+ An identity attribute may be associated with users,
+ subjects, or objects to be used for mediation. Examples of
+ such attributes might be the name of the program image
+ used in the creation of the subject, or a security
+ attribute assigned to the program image.
+
+ A time attribute can be used to specify that access will
+ be authorised during certain times of the day, during
+ certain days of the week, or during a certain calendar
+ year.
+
+ A location attribute could specify whether the location is
+ the location of the request for the operation, the
+ location where the operation will be carried out, or
+ both. It could be based upon internal tables to translate
+ the logical interfaces of the TSF into locations such as
+ through terminal locations, CPU locations, etc.
+
+ A grouping attribute allows a single group of users to be
+ associated with an operation for the purposes of access
+ control. If required, the refinement operation should be
+ used to specify the maximum number of definable groups,
+ the maximum membership of a group, and the maximum number
+ of groups to which a user can concurrently be
+ associated.
+
+ This component also provides requirements for the access
+ control security functions to be able to explicitly
+ authorise or deny access to an object based upon security
+ attributes. This could be used to provide privilege,
+ access rights, or access authorisations within the
+ TOE. Such privileges, rights, or authorisations could
+ apply to users, subjects (representing users or
+ applications), and objects.
+
+
+
+ This family addresses security attribute usage and
+ characteristics of policies. The component within this
+ family is meant to be used to describe the rules for the
+ function that implements the SFP as identified in . The PP/ST author may also
+ iterate this component to address multiple policies in the
+ TOE.
+
+ Security attribute
+ based access control allows the TSF to enforce access
+ based upon security attributes and named groups of
+ attributes. Furthermore, the TSF may have the ability to
+ explicitly authorise or deny access to an object based
+ upon security attributes.
+
+
+ Managing the attributes used to make explicit access or
+ denial based decisions.
+
+
+ Successful requests to perform an operation on an object
+ covered by the SFP.
+
+
+ All requests to perform an operation on an object covered by
+ the SFP.
+
+
+ The specific security attributes used in making an access
+ check.
+
+
+ The TSF shall enforce the
+
+ access control SFP
+
+ the PP/ST author should specify an access control SFP
+ name that the TSF is to enforce. The name of the access
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+ to objects based on the following:
+
+ list of subjects and objects controlled under the
+ indicated SFP, and for each, the SFP-relevant security
+ attributes, or named groups of SFP-relevant security
+ attributes
+
+ the PP/ST author should specify, for each controlled
+ subject and object, the security attributes and/or named
+ groups of security attributes that the function will use
+ in the specification of the rules. For example, such
+ attributes may be things such as the user identity,
+ subject identity, role, time of day, location, ACLs, or
+ any other attribute specified by the PP/ST author. Named
+ groups of security attributes can be specified to
+ provide a convenient means to refer to multiple security
+ attributes. Named groups could provide a useful way to
+ associate ``roles'' defined in , and
+ all of their relevant attributes, with subjects. In
+ other words, each role could relate to a named group of
+ attributes..
+
+
+ The TSF shall enforce the following rules to determine if an
+ operation among controlled subjects and controlled objects
+ is allowed:
+
+
+ rules governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects
+
+
+
+ the PP/ST author should specify the SFP rules
+ governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects. These rules specify when access
+ is granted or denied. It can specify general access
+ control functions (e.g. typical permission bits) or
+ granular access control functions (e.g. ACLs).
+
+ .
+
+
+ The TSF shall explicitly authorise access of subjects to
+ objects based on the following additional rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise access of subjects to objects
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise access
+ of subjects to objects that will be used to explicitly
+ authorise access. These rules are in addition to those
+ specified in . They are
+ included in as they are
+ intended to contain exceptions to the rules in . An example of rules to explicitly
+ authorise access is based on a privilege vector
+ associated with a subject that always grants access to
+ objects covered by the access control SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny access of subjects to objects
+ based on the
+
+
+ rules, based on security attributes, that explicitly
+ deny access of subjects to objects
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly deny access of
+ subjects to objects. These rules are in addition to
+ those specified in . They are
+ included in as they are
+ intended to contain exceptions to the rules in . An example of rules to explicitly
+ deny access is based on a privilege vector associated
+ with a subject that always denies access to objects
+ covered by the access control SFP that has been
+ specified. If such a capability is not desired, then
+ the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+
+
+
+
+
+ Data authentication permits an entity to accept
+ responsibility for the authenticity of information (e.g., by
+ digitally signing it). This family provides a method of
+ providing a guarantee of the validity of a specific unit of
+ data that can be subsequently used to verify that the
+ information content has not been forged or fraudulently
+ modified. In contrast to , this family is
+ intended to be applied to "static" data rather
+ than data that is being transferred.
+
+
+
+ This family describes specific functions that can be used to
+ authenticate ``static'' data.
+
+ Components in this family are to be used when there is a
+ requirement for ``static'' data
+ authentication, i.e. where data is to be signed but not
+ transmitted. (Note that the family
+ provides for non-repudiation of origin of information
+ received during a data exchange.)
+
+
+
+
+
+ This component may be satisfied by one-way hash functions
+ (cryptographic checksum, fingerprint, message digest), to
+ generate a hash value for a definitive document that may
+ be used as verification of the validity or authenticity of
+ its information content.
+
+
+
+ , requires that the TSF is capable
+ of generating a guarantee of authenticity of the
+ information content of objects (e.g. documents).
+
+
+ The assignment or modification of the objects for which data
+ authentication may apply could be configurable.
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element. The list of subjects could be
+ very specific, if the subjects are known, or it could
+ be more generic and refer to a
+ ``type'' of subject such
+ as an identified role.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information.
+
+
+
+
+
+
+
+
+
+
+ This component additionally requires the ability to verify
+ the identity of the user that provided the guarantee of
+ authenticity (e.g. a trusted third party).
+
+
+
+ additionally requires that the TSF
+ is capable of establishing the identity of the subject who
+ provided the guarantee of authenticity.
+
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The identity of the subject that generated the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element as well as the identity of the
+ user that created the data authentication evidence.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information and the identity of the user that
+ generated the evidence.
+
+
+
+
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes and protection
+ either can be explicitly preserved or can be ignored once it
+ has been exported. It is concerned with limitations on
+ export and with the association of security attributes with
+ the exported user data.
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes either can be
+ explicitly preserved or can be ignored once it has been
+ exported. Consistency of these security attributes are
+ addressed by .
+
+ is concerned with limitations on export
+ and association of security attributes with the exported
+ user data.
+
+ This family, and the corresponding Import family , address how the TOE deals with user data
+ transferred into and outside its control. In principle this
+ family is concerned with the TSF-mediated exporting of user data and its
+ related security attributes.
+
+ A variety of activities might be involved here:
+
+
+ exporting of user data without any security attributes;
+
+
+ exporting user data including security attributes where
+ the two are associated with one another and the security
+ attributes unambiguously represent the exported user
+ data.
+
+
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the TSF-mediated exporting of user data
+ without the export of its security attributes.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs when exporting user data outside the
+ TSF. User data that is exported by this function is
+ exported without its associated security attributes.
+
+
+ Successful export of information.
+
+
+ All attempts to export information.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data without the user
+ data's associated security attributes
+
+
+
+
+
+
+
+
+
+
+
+
+ The user data is exported together with its security
+ attributes. The security attributes are unambiguously
+ associated with the user data. There are several ways of
+ achieving this association. One way that this can be
+ achieved is by physically collocating the user data and
+ the security attributes (e.g. the same floppy), or by
+ using cryptographic techniques such as secure signatures
+ to associate the attributes and the user data. could be used to assure that the attributes
+ are correctly received at the other trusted IT product
+ while can be used to make sure that
+ those attributes are properly interpreted. Furthermore,
+ could be used to make sure that the
+ export is being initiated by the proper user.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs using a function that accurately and
+ unambiguously associates security attributes with the user
+ data that is exported.
+
+
+ The additional exportation control rules could be
+ configurable by a user in a defined role.
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data with the user
+ data's associated security attributes.
+
+
+ The TSF shall ensure that the security attributes, when
+ exported outside the TOE, are unambiguously associated with
+ the exported user data.
+
+
+ The TSF shall enforce the following rules when user data is
+ exported from the TOE:
+
+
+ additional exportation control rules
+
+
+
+ the PP/ST author should specify any additional
+ exportation control rules or
+ ``none'' if there are no
+ additional exportation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family identifies the information flow control SFPs (by
+ name) and defines the scope of control for each named information flow control SFP.
+ This scope of control is characterised by three sets:
+ the subjects under control of the policy, the information
+ under control of the policy, and operations which cause
+ controlled information to flow to and from controlled
+ subjects covered by the policy. The criteria allows multiple
+ policies to exist, each having a unique name. This is
+ accomplished by iterating components from this family once
+ for each named information flow control policy. The rules
+ that define the functionality of an information flow control
+ SFP will be defined by other families such as and . The names of the information flow control
+ SFPs identified here in are
+ meant to be used throughout the remainder of the functional
+ components that have an operation that calls for an
+ assignment or selection of an ``information flow control
+ SFP.''
+
+ The TSF mechanism controls the flow of information in
+ accordance with the information flow control SFP. Operations
+ that would change the security attributes of information are
+ not generally permitted as this would be in violation of an
+ information flow control SFP. However, such operations may
+ be permitted as exceptions to the information flow control
+ SFP if explicitly specified.
+
+
+
+ This family covers the identification of information flow
+ control SFPs; and, for each, specifies the scope of control
+ of the SFP.
+
+ The components in this family are capable of identifying the
+ information flow control SFPs to be enforced by the
+ traditional Mandatory Access Control mechanisms that would be
+ found in a TOE. However, they go beyond just the traditional
+ MAC mechanisms and can be used to identify and describe
+ non-interference policies and state-transitions. It further
+ defines the subjects under control of the policy, the
+ information under control of the policy, and operations which
+ cause controlled information to flow to and from controlled
+ subjects for each information flow control SFP in the TOE. The
+ functionality that defines the rules of an information flow
+ control SFP will be defined by other families such as and . The information flow control SFPs named here
+ in are meant to be used
+ throughout the remainder of the functional components that
+ have an operation that calls for an assignment or selection of
+ an ``information flow control SFP.''
+
+ These components are quite flexible. They allow the domain
+ of flow control to be specified and there is no requirement
+ that the mechanism be based upon labels. The different
+ elements of the information flow control components also
+ permit different degrees of exception to the policy.
+
+ Each SFP covers a set of triplets: subject, information, and
+ operations that cause information to flow to and from
+ subjects. Some information flow control policies may be at a
+ very low level of detail and explicitly describe subjects in
+ terms of processes within an operating system. Other
+ information flow control policies may be at a high level and
+ describe subjects in the generic sense of users or
+ input/output channels. If the information flow control
+ policy is at too high a level of detail, it may not clearly
+ define the desired IT security functions. In such cases, it
+ is more appropriate to include such descriptions of
+ information flow control policies as objectives. Then the
+ desired IT security functions can be specified as supportive
+ of those objectives.
+
+ In the second component (), each
+ information flow control SFP will cover all possible
+ operations that cause information covered by that SFP to
+ flow to and from subjects covered by that SFP. Furthermore,
+ all information flows will need to be covered by a
+ SFP. Therefore for each action that causes information to
+ flow, there will be a set of rules that define whether the
+ action is allowed. If there are multiple SFPs that are
+ applicable for a given information flow, all involved SFPs
+ must allow this flow before it is permitted to take place.
+
+ An information flow control SFP covers a well-defined set of
+ operations. The SFPs coverage may be
+ ``complete'' with respect to some
+ information flows, or it may address only some of the
+ operations that affect the information flow.
+
+ An access control SFP controls access to the objects that
+ contain information. An information flow control SFP
+ controls access to the information, independent of its
+ container. The attributes of the information, which may be
+ associated with the attributes of the container (or may not,
+ as in the case of a multi-level database) stay with the
+ information as it flows. The accessor does not have the
+ ability, in the absence of an explicit authorisation, to
+ change the attributes of the information.
+
+ Information flows and operations can be expressed at
+ multiple levels. In the case of a ST, the information flows
+ and operations might be specified at a system-specific
+ level: TCP/IP packets flowing through a firewall based upon
+ known IP addresses. For a PP, the information flows and
+ operations might be expressed as types: email, data
+ repositories, observe accesses, etc.
+
+ The components in this family can be applied multiple times
+ in a PP/ST to different subsets of operations and
+ objects. This will accommodate TOEs that contain multiple
+ policies, each addressing a particular set of objects,
+ subjects, and operations.
+
+
+
+
+
+
+
+
+ This component requires that an information flow control
+ policy apply to a subset of the possible operations in the
+ TOE.
+
+
+
+ , requires that each identified
+ information flow control SFPs be in place for a subset of
+ the possible operations on a subset of information flows
+ in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects, information, and operations that cause
+ controlled information to flow to and from controlled
+ subjects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ information, and operations which cause controlled
+ information to flow to and from controlled subjects
+ covered by the SFP. As mentioned above, the list of
+ subjects could be at various levels of detail
+ depending on the needs of the PP/ST author. It could
+ specify users, machines, or processes for
+ example. Information could refer to data such as email
+ or network protocols, or more specific objects similar
+ to those specified under an access control policy. If
+ the information that is specified is contained within
+ an object that is subject to an access control policy,
+ then both the access control policy and information
+ flow control policy must be enforced before the
+ specified information could flow to or from the
+ object.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations that
+ cause information to flow to and from subjects included in
+ the SFP, are covered by an information flow control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ information flows and subjects is covered by an
+ information flow control SFP.
+
+
+
+ , requires that each identified
+ information flow control SFP cover all operations on
+ subjects and information covered by that SFP. It further
+ requires that all information flows and operations controlled
+ by the TSF are covered by at least one identified information
+ flow control SFP.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects and information
+
+
+
+ the PP/ST author should specify the list of subjects
+ and information that will be covered by the SFP. All
+ operations that cause that information to flow to and
+ from subjects will be covered by the SFP. As mentioned
+ above, the list of subjects could be at various levels
+ of detail depending on the needs of the PP/ST
+ author. It could specify users, machines, or processes
+ for example. Information could refer to data such as
+ email or network protocols, or more specific objects
+ similar to those specified under an access control
+ policy. If the information that is specified is
+ contained within an object that is subject to an
+ access control policy, then both the access control
+ policy and information flow control policy must be
+ enforced before the specified information could flow
+ to or from the object.
+
+
+ and all operations that cause that information to flow to
+ and from subjects covered by the SFP.
+
+
+ The TSF shall ensure that all operations that cause any
+ information in the TOE to flow to and from any subject in
+ the TOE are covered by an information flow control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policy. It consists of two kinds of
+ requirements: one addressing the common information flow
+ function issues, and a second addressing illicit information
+ flows (i.e. covert channels). This division arises because
+ the issues concerning illicit information flows are, in some
+ sense, orthogonal to the rest of an information flow control
+ SFP. By their nature they circumvent the information flow
+ control SFP resulting in a violation of the policy. As such,
+ they require special functions to either limit or prevent
+ their occurrence.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policies. It consists of two
+ ``trees:'' one addressing the common
+ information flow control function issues, and a second
+ addressing illicit information flows (i.e. covert channels)
+ with respect to one or more information flow control
+ SFPs. This division arises because the issues concerning
+ illicit information flows are, in some sense, orthogonal to
+ the rest of an SFP. Illicit information flows are flows in
+ violation of policy; thus they are not a policy issue.
+
+ In order to implement strong protection against disclosure
+ or modification in the face of untrusted software, controls
+ on information flow are required. Access controls alone are
+ not sufficient because they only control access to
+ containers, allowing the information they contain to flow,
+ without controls, throughout a system.
+
+ In this family, the phrase ``types of illicit
+ information flows'' is used. This phrase may be
+ used to refer to the categorisation of flows as
+ ``Storage Channels'' or
+ ``Timing Channels'', or it can refer to
+ improved categorisations reflective of the needs of a PP/ST
+ author.
+
+ The flexibility of these components allows the definition of
+ a privilege policy within and to allow the controlled bypass of all or
+ part of a particular SFP. If there is a need for a
+ predefined approach to SFP bypass, the PP/ST author should
+ consider incorporating a privilege policy.
+
+
+
+
+
+
+
+
+
+ This component requires security attributes on
+ information, and on subjects that cause that information
+ to flow and subjects that act as recipients of that
+ information. The attributes of the containers of the
+ information should also be considered if it is desired
+ that they should play a part in information flow control
+ decisions or if they are covered by an access control
+ policy. This component specifies the key rules that are
+ enforced, and describes how security attributes are
+ derived.
+
+ This component does not specify the details of how a
+ security attribute is assigned (i.e. user versus
+ process). Flexibility in policy is provided by having
+ assignments that allow specification of additional policy
+ and function requirements, as necessary.
+
+ This component also provides requirements for the
+ information flow control functions to be able to
+ explicitly authorise and deny an information flow based
+ upon security attributes. This could be used to implement
+ a privilege policy that covers exceptions to the basic
+ policy defined in this component.
+
+
+
+ , requires security attributes on
+ information, and on subjects that cause that information
+ to flow and on subjects that act as recipients of that
+ information. It specifies the rules that must be enforced
+ by the function, and describes how security attributes are
+ derived by the function.
+
+
+ Managing the attributes used to make explicit access based
+ decisions.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+
+ the PP/ST author should specify any additional
+ information flow control SFP rules that the TSF is to
+ enforce. If there are no additional rules then the
+ PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall provide the following
+
+
+ list of additional SFP capabilities
+
+
+
+ the PP/ST author should specify any additional SFP
+ capabilities that the TSF is to provide. If there are
+ no additional capabilities then the PP/ST author
+ should specify ``none''.
+
+ .
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly deny information
+ flows. These rules are in addition to those specified
+ in the preceding elements. They are included in as they are intended to contain
+ exceptions to the rules in the preceding elements. An
+ example of rules to explicitly authorise information
+ flows is based on a privilege vector associated with a
+ subject that always denies the subject the ability to
+ cause an information flow for information that is
+ covered by the SFP that has been specified. If such a
+ capability is not desired, then the PP/ST author
+ should specify ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that the named information flow control
+ SFP uses hierarchical security attributes that
+ form a lattice.
+
+ It is important to note that the hierarchical relationship
+ requirements identified in need
+ only apply to the information flow control security
+ attributes for the information flow control SFPs that have
+ been identified in . This
+ component is not meant to apply to other SFPs such as
+ access control SFPs.
+
+ Like the preceding component, this component could also be
+ used to implement a privilege policy that covers rules
+ that allow for the explicit authorisation or denial of
+ information flows.
+
+ If it is the case that multiple information flow control
+ SFPs are to be specified, and that each of these SFPs will
+ have their own security attributes that are not related to
+ one another, then the PP/ST author should iterate this
+ component once for each of those SFPs. Otherwise a
+ conflict might arise with the sub-items of since the required relationships will
+ not exist.
+
+
+
+ expands on the requirements of
+ by requiring that all information
+ flow control SFPs in the set of SFRs use hierarchical security
+ attributes that form a lattice.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules, based on the
+ ordering relationships between security attributes hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce. These
+ relationships should be based upon the ordering
+ relationships between the security attributes.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+
+ the PP/ST author should specify any additional
+ information flow control SFP rules that the TSF is to
+ enforce. If there are no additional rules then the
+ PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall provide the following
+
+
+ list of additional SFP capabilities
+
+
+
+ the PP/ST author should specify any additional SFP
+ capabilities that the TSF is to enforce. If there are
+ no additional rules then the PP/ST author should
+ specify ``none''.
+
+ .
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly deny information
+ flows. These rules are in addition to those specified
+ in the preceding elements. They are included in as they are intended to contain
+ exceptions to the rules in the preceding elements. An
+ example of rules to explicitly authorise information
+ flows is based on a privilege vector associated with a
+ subject that always denies the subject the ability to
+ cause an information flow for information that is
+ covered by the SFP that has been specified. If such a
+ capability is not desired, then the PP/ST author
+ should specify ``none''.
+
+ .
+
+
+ The TSF shall enforce the following relationships for any
+ two valid information flow control security attributes:
+
+
+ There exists an ordering function that, given two valid
+ security attributes, determines if the security
+ attributes are equal, if one security attribute is
+ greater than the other, or if the security attributes
+ are incomparable; and
+
+
+ There exists a ``least upper bound''
+ in the set of security attributes, such that, given any
+ two valid security attributes, there is a valid security
+ attribute that is greater than or equal to the two valid
+ security attributes; and
+
+
+ There exists a ``greatest lower
+ bound'' in the set of security attributes,
+ such that, given any two valid security attributes,
+ there is a valid security attribute that is not greater
+ than the two valid security attributes.
+
+
+
+
+
+
+
+
+
+
+
+ This component should be used when at least one of the
+ SFPs that requires control of illicit information flows
+ does not require elimination of flows.
+
+ For the specified illicit information flows, certain
+ maximum capacities should be provided. In addition a PP/ST
+ author has the ability to specify whether the illicit
+ information flows must be audited.
+
+
+
+ , requires the SFP to cover illicit
+ information flows, but not necessarily eliminate them.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The use of identified illicit information flow channels.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The use of identified illicit information flow channels with
+ estimated maximum capacity exceeding a specified value.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when all the SFPs that
+ requires control of illicit information flows require
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+ , requires the SFP to cover the
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows which are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+ The TSF shall prevent
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows to be eliminated. This list may not
+ be empty as this component requires that some illicit
+ information flows are to be eliminated.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when the SFPs that require
+ control of illicit information flows require elimination
+ of all illicit information flows. However, the PP/ST
+ author should carefully consider the potential impact that
+ eliminating all illicit information flows might have on
+ the normal functional operation of the TOE. Many practical
+ applications have shown that there is an indirect
+ relationship between illicit information flows and normal
+ functionality within a TOE and eliminating all illicit
+ information flows may result in less than desired
+ functionality.
+
+
+
+ , requires SFP to cover the
+ elimination of all illicit information flows.
+
+
+
+
+
+ The TSF shall ensure that no illicit information flows exist
+ to circumvent
+
+
+ name of information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFP for which illicit information flows are to
+ be eliminated. The name of the information flow
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+
+ .
+
+
+
+
+
+
+
+
+
+ This component should be used when it is desired that the
+ TSF provide the ability to monitor the use of illicit
+ information flows that exceed a specified capacity. If it
+ is desired that such flows be audited, then this component
+ could serve as the source of audit events to be used by
+ components from the family.
+
+
+
+ , requires the SFP to monitor
+ illicit information flows for specified and maximum
+ capacities.
+
+
+ The enabling or disabling of the monitoring function.
+
+
+ Modification of the maximum capacity at which the monitoring
+ occurs.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to monitor
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that will be monitored for exceeding
+ a maximum capacity.
+
+
+ when it exceeds the
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ above which illicit information flows will be
+ monitored by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family defines the mechanisms for TSF-mediated importing of user
+ data into the TOE such that it has appropriate security
+ attributes and is appropriately protected. It is concerned
+ with limitations on importation, determination of desired
+ security attributes, and interpretation of security
+ attributes associated with the user data.
+
+
+
+ This family defines mechanisms for TSF-mediated importing of user data from
+ outside the TOE into the TOE such that the user data
+ security attributes can be preserved. Consistency of these
+ security attributes are addressed by .
+
+ is concerned with limitations on
+ import, user specification of security attributes, and
+ association of security attributes with the user data.
+
+ This family, and the corresponding export family , address how the TOE deals with user data
+ outside its control. This family is concerned with assigning
+ and abstraction of the user data security attributes.
+
+ A variety of activities might be involved here:
+
+
+ importing user data from an unformatted medium
+ (e.g. floppy disk, tape, scanner, video or audit
+ signal), without including any security attributes, and
+ physically marking the medium to indicate its contents;
+
+
+ importing user data, including security attributes, from
+ a medium and verifying that the object security
+ attributes are appropriate;
+
+
+ importing user data, including security attributes, from
+ a medium using a cryptographic sealing technique to
+ protect the association of user data and security
+ attributes.
+
+
+
+ This family is not concerned with the determination of
+ whether the user data may be imported. It is concerned with
+ the values of the security attributes to associate with the
+ imported user data.
+
+ There are two possibilities for the import of user data:
+ either the user data is unambiguously associated with
+ reliable object security attributes (values and meaning of
+ the security attributes is not modified), or no reliable
+ security attributes (or no security attributes at all) are
+ available from the import source. This family addresses both
+ cases.
+
+ If there are reliable security attributes available, they
+ may have been associated with the user data by physical
+ means (the security attributes are on the same media), or by
+ logical means (the security attributes are distributed
+ differently, but include unique object identification,
+ e.g. cryptographic checksum).
+
+ This family is concerned with TSF-mediated importing of user data and
+ maintaining the association of security attributes as
+ required by the SFP. Other families are concerned with other
+ import aspects such as consistency, trusted channels, and
+ integrity that are beyond the scope of this
+ family. Furthermore, is only concerned
+ with the interface to the import medium. is responsible for the other end point of the
+ medium (the source).
+
+ Some of the well known import requirements are:
+
+
+ importing of user data without any security attributes;
+
+
+ importing of user data including security attributes
+ where the two are associated with one another and the
+ security attributes unambiguously represent the
+ information being imported.
+
+
+
+ These import requirements may be handled by the TSF with or
+ without human intervention, depending on the IT limitations
+ and the organisational security policy. For example, if user
+ data is received on a ``confidential''
+ channel, the security attributes of the objects will be set
+ to ``confidential''.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that does not have reliable (or any) security attributes
+ associated with it. This function requires that the
+ security attributes for the imported user data be
+ initialised within the TSF. It could also be the case that
+ the PP/ST author specifies the rules for import. It may be
+ appropriate, in some environments, to require that these
+ attributes be supplied via a trusted path or a trusted
+ channel mechanism.
+
+
+
+ , requires that the security
+ attributes correctly represent the user data and are
+ supplied separately from the object.
+
+
+ The modification of the additional control rules used for
+ import.
+
+
+ Successful import of user data, including any security
+ attributes.
+
+
+ All attempts to import user data, including any security
+ attributes.
+
+
+ The specification of security attributes for imported user
+ data supplied by an authorised user.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s) and/or information flow control SFP(s)
+
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be
+ enforced when importing user data from outside of the
+ TOE. The user data that this function imports is
+ scoped by the assignment of these SFPs.
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall ignore any security attributes associated with
+ the user data when imported from outside the TOE.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that has reliable security attributes associated with
+ it. This function relies upon the security attributes that
+ are accurately and unambiguously associated with the
+ objects on the import medium. Once imported, those objects
+ will have those same attributes. This requires to ensure the consistency of the data. It
+ could also be the case that the PP/ST author specifies the
+ rules for import.
+
+
+
+ , requires that security attributes
+ correctly represent the user data and are accurately and
+ unambiguously associated with the user data imported from
+ outside the TOE.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when importing user data from outside
+ of the TOE. The user data that this function imports
+ is scoped by the assignment of these SFPs.
+
+
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall use the security attributes associated with
+ the imported user data.
+
+
+ The TSF shall ensure that the protocol used provides for the
+ unambiguous association between the security attributes and
+ the user data received.
+
+
+ The TSF shall ensure that interpretation of the security
+ attributes of the imported user data is as intended by the
+ source of the user data.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between separated parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and families,
+ which provide protection for user data when it is
+ transferred between distinct TSFs across an external
+ channel, and and ,
+ which address TSF-mediated transfer of data to or from outside the
+ TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and family, which
+ provide protection for user data when it is transferred
+ between distinct TSFs across an external channel, and and , which address
+ TSF-mediated transfer of data to or from outside the TOE.
+
+ The requirements in this family allow a PP/ST author to
+ specify the desired security for user data while in transit
+ within the TOE. This security could be protection against
+ disclosure, modification, or loss of availability.
+
+ The determination of the degree of physical separation above
+ which this family should apply depends on the intended
+ environment of use. In a hostile environment, there may be
+ risks arising from transfers between parts of the TOE
+ separated by only a system bus. In more benign environments,
+ the transfers may be across more traditional network media.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ , requires that user data be
+ protected when transmitted between parts of the TOE.
+
+
+ If the TSF provides multiple methods to protect user data
+ during transmission between physically separated parts of
+ the TOE, the TSF could provide a pre-defined role with the
+ ability to select the method that will be used.
+
+
+ Successful transfers of user data, including identification
+ of the protection method used.
+
+
+ All attempts to transfer user data, including the protection
+ method used and any errors that occurred.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component could, for example, be used to provide
+ different forms of protection to information with
+ different clearance levels.
+
+ One of the ways to achieve separation of data when it is
+ transmitted is through the use of separate logical or
+ physical channels.
+
+
+
+ , requires separation of data based
+ on the value of SFP-relevant attributes in addition to the
+ first component.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+ The TSF shall separate data controlled by the SFP(s) when
+ transmitted between physically-separated parts of the TOE,
+ based on the values of the following:
+
+
+ security attributes that require separation
+
+
+
+ the PP/ST author should specify the security
+ attributes, the values of which the TSF will use to
+ determine when to separate data that is being
+ transmitted between physically-separated parts of the
+ TOE. An example is that user data associated with the
+ identity of one owner is transmitted separately from
+ the user data associated with the identify of a
+ different owner. In this case, the value of the
+ identity of the owner of the data is what is used to
+ determine when to separate the data for transmission.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with either or . It ensures
+ that the TSF checks received user data (and their
+ attributes) for integrity. or will provide the data in a manner such
+ that it is protected from modification (so that can detect any modifications).
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ , requires that the TSF monitor user
+ data transmitted between parts of the TOE for identified
+ integrity errors.
+
+
+ The specification of the actions to be taken upon detection
+ of an integrity error could be configurable.
+
+
+ Successful transfers of user data, including identification
+ of the integrity protection method used.
+
+
+ All attempts to transfer user data, including the integrity
+ protection method used and any errors that occurred.
+
+
+ Unauthorised attempts to change the integrity protection
+ method.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with . It ensures that the TSF checks received
+ user data, that has been transmitted by separate channels
+ (based on values of specified security attributes), for
+ integrity. It allows the PP/ST author to specify actions
+ to be taken upon detection of an integrity error.
+
+ For example, this component could be used to provide
+ different integrity error detection and action for
+ information at different integrity levels.
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author should specify the attributes (and
+ associated transmission channels) that necessitate
+ integrity error monitoring
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ expands on the third component by
+ allowing the form of integrity monitoring to differ by
+ SFP-relevant attribute.
+
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow
+ control SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ , based on the following attributes:
+
+
+ security attributes that require separate transmission
+ channels
+
+
+
+ the PP/ST author should specify a list of security
+ attributes that require separate transmission
+ channels. This list is used to determine which user
+ data to monitor for integrity errors., based on its
+ security attributes and its transmission channel. This
+ element is directly related to .
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity
+ error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the need to ensure that deleted
+ information is no longer accessible, and that newly created
+ objects do not contain information that should not be
+ accessible. This family requires protection for information
+ that has been logically deleted or released, but may still
+ be present within the TOE.
+
+
+
+ This family addresses the need to ensure that deleted
+ information is no longer accessible, and that newly-created
+ objects do not contain information from previously used
+ objects within the TOE. This family does not address objects
+ stored off-line.
+
+ This family requires protection for information that has
+ been logically deleted or released. In particular, this
+ includes information that is contained in an object, as part
+ of the TSF reusable resources, where destruction of the
+ object does not necessarily equate to destruction of the
+ resource or any contents of the resource.
+
+ It also applies to resources that are serially reused by
+ different subjects within the system. For example, most
+ operating systems typically rely upon hardware registers
+ (resources) to support processes within the system. As
+ processes are swapped from a ``run'' state to a ``sleep''
+ state (and vice versa), these registers are serially reused
+ by different subjects. While this ``swapping'' action may
+ not be considered an allocation or deallocation of a
+ resource, could apply to
+ such events and resources.
+
+ typically controls access
+ to information that is not part of any currently defined or
+ accessible object; however, in certain cases this may not be
+ true. For example, object ``A'' is a file and object ``B''
+ is the disk upon which that file resides. If object ``A'' is
+ deleted, the information from object ``A'' is under the
+ control of even though it
+ is still part of object ``B''.
+
+ It is important to note that applies only to on-line objects and not
+ off-line objects such as those backed-up on tapes. For
+ example, if a file is deleted in the TOE, can be instantiated to require that no
+ residual information exists upon deallocation; however, the
+ TSF cannot extend this enforcement to that same file that
+ exists on the off-line back-up. Therefore that same file is
+ still available. If this is a concern, then the PP/ST author
+ should make sure that the proper environmental objectives
+ are in place to support operational user guidance to address
+ off-line objects.
+
+ and can conflict when is instantiated to require that residual
+ information be cleared at the time the application releases
+ the object to the TSF (i.e. upon deallocation). Therefore,
+ the selection of
+ ``deallocation'' should not be used with since there would be no information to roll
+ back. The other selection, ``unavailability upon
+ allocation'', may be used with , but there is the risk that the resource
+ which held the information has been allocated to a new
+ object before the roll back took place. If that were to
+ occur, then the roll back would not be possible.
+
+ There are no audit requirements in because this is not a user-invokable
+ function. Auditing of allocated or deallocated resources
+ would be auditable as part of the access control SFP or the
+ information flow control SFP operations.
+
+ This family should apply to the objects specified in the
+ access control SFP(s) or the information flow control SFP(s)
+ as specified by the PP/ST author.
+
+
+
+
+
+ This component requires that, for a subset of the objects
+ in the TOE, the TSF will ensure that there is no available
+ residual information contained in a resource allocated to
+ those objects or deallocated from those objects.
+
+
+
+ , requires that the TSF
+ ensure that any residual information content of any
+ resources is unavailable to a defined subset of the
+ objects controlled by the TSF upon the resource's
+ allocation or deallocation.
+
+
+ The choice of when to perform residual information
+ protection (i.e. upon allocation or deallocation) could be
+ made configurable within the TOE.
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ the following objects:
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ subject to residual information protection.
+
+ .
+
+
+
+
+
+
+
+ This component requires that for all objects in the TOE,
+ the TSF will ensure that there is no available residual
+ information contained in a resource allocated to those
+ objects or deallocated from those objects.
+
+
+
+ , requires that the TSF ensure that
+ any residual information content of any resources is
+ unavailable to all objects upon the resource's
+ allocation or deallocation.
+
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ all objects.
+
+
+
+
+
+
+
+ The rollback operation involves undoing the last operation
+ or a series of operations, bounded by some limit, such as a
+ period of time, and return to a previous known
+ state. Rollback provides the ability to undo the effects of
+ an operation or series of operations to preserve the
+ integrity of the user data.
+
+
+
+ This family addresses the need to return to a well defined
+ valid state, such as the need of a user to undo
+ modifications to a file or to undo transactions in case of
+ an incomplete series of transaction as in the case of
+ databases.
+
+ This family is intended to assist a user in returning to a
+ well defined valid state after the user undoes the last set
+ of actions, or, in distributed databases, the return of all
+ of the distributed copies of the databases to the state
+ before an operation failed.
+
+ and conflict when
+ enforces that the contents will be made
+ unavailable at the time that a resource is deallocated from
+ an object. Therefore, this use of
+ cannot be combined with as there would
+ be no information to roll back. can be
+ used only with when it enforces that
+ the contents will be unavailable at the time that a resource
+ is allocated to an object. This is because the mechanism will have an opportunity to access
+ the previous information that may still be present in the
+ TOE in order to successfully roll back the operation.
+
+ The rollback requirement is bounded by certain limits. For
+ example a text editor typically only allows you roll back up
+ to a certain number of commands. Another example would be
+ backups. If backup tapes are rotated, after a tape is
+ reused, the information can no longer be retrieved. This
+ also poses a bound on the rollback requirement.
+
+
+
+
+
+
+
+
+
+
+
+ This component allows a user or subject to undo a set of
+ operations on a predefined set of objects. The undo is
+ only possible within certain limits, for example up to a
+ number of characters or up to a time limit.
+
+
+
+ addresses a need to roll back or
+ undo a limited number of operations within the defined
+ bounds.
+
+
+ The boundary limit to which rollback may be performed could
+ be a configurable item within the TOE.
+
+
+ Permission to perform a rollback operation could be
+ restricted to a well defined role.
+
+
+ All successful rollback operations.
+
+
+ All attempts to perform rollback operations.
+
+
+ All attempts to perform rollback operations, including
+ identification of the types of operations rolled back.
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of the
+
+
+ list of operations
+
+
+
+ the PP/ST author should specify the list of operations
+ that can be rolled back.
+
+
+ on the
+
+ information and/or list of objects
+
+ the PP/ST author should specify the information and/or
+ list of objects that are subjected to the rollback policy..
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component enforces that the TSF provide the
+ capability to rollback all operations; however, the user
+ can choose to rollback only a part of them.
+
+
+
+ addresses the need to roll back or
+ undo all operations within the defined bounds.
+
+
+
+
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of all the operations on the
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ that are subjected to the rollback policy.
+
+ .
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF. Integrity
+ errors may affect user data stored in memory, or in a
+ storage device. This family differs from which protects the user data from integrity
+ errors while being transferred within the TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF.
+
+ Hardware glitches or errors may affect data stored in
+ memory. This family provides requirements to detect these
+ unintentional errors. The integrity of user data while
+ stored on storage devices controlled by the TSF are also addressed
+ by this family.
+
+ To prevent a subject from modifying the data, the or families are required
+ (rather than this family).
+
+ This family differs from that protects
+ the user data from integrity errors while being transferred
+ within the TOE.
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify different kinds of
+ user data attributes that will be used as the basis for
+ monitoring.
+
+
+
+ , requires that the TSF monitor user
+ data stored within containers controlled by the TSF for identified integrity
+ errors.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify which action should
+ be taken in case an integrity error is detected.
+
+
+
+ adds the additional capability to
+ the first component by allowing for actions to be taken as
+ a result of an error detection.
+
+
+ The actions to be taken upon the detection of an integrity
+ error could be configurable.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ action to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken in case an integrity error is detected.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT product.
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT
+ product. Confidentiality is enforced by preventing
+ unauthorised disclosure of user data in transit between the
+ two end points. The end points may be a TSF or a user.
+
+ This family provides a requirement for the protection of user
+ data during transit. In contrast, handles TSF data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The TSF has the ability to protect from disclosure some
+ user data which is exchanged.
+
+
+
+ In , the goal is to provide
+ protection from disclosure of user data while in transit.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any unauthorised user or subject attempting
+ to use the data exchange mechanisms.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the information.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exchanging user data. The
+ specified policies will be enforced to make decisions
+ about who can exchange data and which data can be
+ exchanged.
+
+
+ to be able to
+
+
+ transmit
+
+
+ receive
+
+
+
+ the PP/ST author should specify whether this element
+ applies to a mechanism that transmits or receives user
+ data.
+
+
+ objects in a manner protected from unauthorised disclosure.
+
+
+
+
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TOE and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TSF and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+ This family defines the requirements for providing integrity
+ for user data in transit; while handles
+ TSF data.
+
+ and are duals of
+ each other, as addresses user data
+ confidentiality. Therefore, the same mechanism that
+ implements could possibly be used to
+ implement other families such as and
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The TSF has a basic ability to send or receive user data
+ in a manner such that modification of the user data can be
+ detected. There is no requirement for a TSF mechanism to
+ attempt to recover from the modification.
+
+
+
+ addresses detection of
+ modifications, deletions, insertions, and replay errors of
+ the user data transmitted.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced on the transmitted data or on the
+ received data. The specified policies will be enforced
+ to make decisions about who can transmit or who can
+ receive data, and which data can be transmitted or
+ received.
+
+
+ to be able to
+
+
+ transmit
+
+
+ receive
+
+
+
+ the PP/ST author should specify whether this element
+ applies to a TSF that is transmitting or receiving
+ objects.
+
+
+ user data in a manner protected from
+
+
+ modification
+
+
+ deletion
+
+
+ insertion
+
+
+ replay
+
+
+
+ the PP/ST author should specify whether the data
+ should be protected from modification, deletion,
+ insertion or replay.
+
+
+ errors.
+
+
+ The TSF shall be able to determine on receipt of user data,
+ whether
+
+
+ modification
+
+
+ deletion
+
+
+ insertion
+
+
+ replay
+
+
+
+ the PP/ST author should specify whether the errors of
+ the type: modification, deletion, insertion or replay
+ are detected.
+
+
+ has occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors, if required, with the
+ help of the other trusted IT product. As the other trusted
+ IT product is outside the TOE, the TSF cannot control its
+ behaviour. However, it can provide functions that have the
+ ability to cooperate with the other trusted IT product for
+ the purposes of recovery. For example, the TSF could
+ include functions that depend upon the source trusted IT
+ product to re-send the data in the event that an error is
+ detected. This component deals with the ability of the TSF
+ to handle such an error recovery.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF with help from the source
+ trusted IT product.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ Successful recovery from errors including they type of error
+ that was detected.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the TSF, with the help of the source
+ trusted IT product, is be able to recover the original
+ user data.
+
+
+ with the help of the source trusted IT product.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors. It accomplishes this
+ task without help from the source trusted IT product. For
+ example, if certain errors are detected, the transmission
+ protocol must be robust enough to allow the TSF to recover
+ from the error based on checksums and other information
+ available within that protocol.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF on its own without any help
+ from the source trusted IT product.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the receiving TSF, alone, is able to
+ recover the original user data.
+
+
+ without any help from the source trusted IT product.
+
+
+
+
+
+
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user identity.
+
+ Identification and Authentication is required to ensure that
+ users are associated with the proper security attributes
+ (e.g. identity, groups, roles, security or integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the intended
+ security policies. The families in this class deal with
+ determining and verifying the identity of users, determining
+ their authority to interact with the TOE, and with the correct
+ association of security attributes for each authorised
+ user. Other classes of requirements (e.g. User Data
+ Protection, Security Audit) are dependent upon correct
+ identification and authentication of users in order to be
+ effective.
+
+
+
+ A common security requirement is to unambiguously identify the
+ person and/or entity performing functions in a TOE. This
+ involves not only establishing the claimed identity of each
+ user, but also verifying that each user is indeed who he/she
+ claims to be. This is achieved by requiring users to provide
+ the TSF with some information that is known by the TSF to be
+ associated with the user in question.
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user
+ identity. Identification and Authentication is required to
+ ensure that users are associated with the proper security
+ attributes (e.g. identity, groups, roles, security or
+ integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the security
+ policies.
+
+ The family addresses determining the
+ identity of a user.
+
+ The family addresses verifying the
+ identity of a user.
+
+ The family addresses defining limits on
+ repeated unsuccessful authentication attempts.
+
+ The family address the definition of user
+ attributes that are used in the enforcement of the SFRs.
+
+ The family addresses the correct
+ association of security attributes for each authorised user.
+
+ The family addresses the generation and
+ verification of secrets that satisfy a defined metric.
+
+
+
+
+
+ This family contains requirements for defining values for
+ some number of unsuccessful authentication attempts and TSF
+ actions in cases of authentication attempt
+ failures. Parameters include, but are not limited to, the
+ number of failed authentication attempts and time
+ thresholds.
+
+
+
+ This family addresses requirements for defining values for
+ authentication attempts and TSF actions in cases of
+ authentication attempt failure. Parameters include, but are
+ not limited to, the number of attempts and time thresholds.
+
+ The session establishment process is the interaction with
+ the user to perform the session establishment independent of
+ the actual implementation. If the number of unsuccessful
+ authentication attempts exceeds the indicated threshold,
+ either the user account or the terminal (or both) will be
+ locked. If the user account is disabled, the user cannot
+ log-on to the system. If the terminal is disabled, the
+ terminal (or the address that the terminal has) cannot be
+ used for any log-on. Both of these situations continue until
+ the condition for re-establishment is satisfied.
+
+
+
+
+
+
+
+
+ The PP/ST author may define the number of unsuccessful
+ authentication attempts or may choose to let the TOE
+ developer or the authorised user to define this
+ number. The unsuccessful authentication attempts need not
+ be consecutive, but rather related to an authentication
+ event. Such an authentication event could be the count
+ from the last successful session establishment at a given
+ terminal.
+
+ The PP/ST author could specify a list of actions that the
+ TSF shall take in the case of authentication failure. An
+ authorised administrator could also be allowed to manage
+ the events, if deemed opportune by the PP/ST author. These
+ actions could be, among other things, terminal
+ deactivation, user account deactivation, or administrator
+ alarm. The conditions under which the situation will be
+ restored to normal must be specified on the action.
+
+ In order to prevent denial of service, TOEs usually ensure
+ that there is at least one user account that cannot be
+ disabled.
+
+ Further actions for the TSF can be stated by the PP/ST
+ author, including rules for re-enabling the user session
+ establishment process, or sending an alarm to the
+ administrator. Examples of these actions are: until a
+ specified time has lapsed, until the authorised
+ administrator re-enables the terminal/account, a time
+ related to failed previous attempts (every time the
+ attempt fails, the disabling time is doubled).
+
+
+
+ , requires that the TSF be able to
+ terminate the session establishment process after a
+ specified number of unsuccessful user authentication
+ attempts. It also requires that, after termination of the
+ session establishment process, the TSF be able to disable
+ the user account or the point of entry (e.g. workstation)
+ from which the attempts were made until an
+ administrator-defined condition occurs.
+
+
+ management of the threshold for unsuccessful authentication
+ attempts;
+
+
+ management of actions to be taken in the event of an
+ authentication failure.
+
+
+ the reaching of the threshold for the unsuccessful
+ authentication attempts and the actions (e.g. disabling of a
+ terminal) taken and the subsequent, if appropriate,
+ restoration to the normal state (e.g. re-enabling of a
+ terminal).
+
+
+ The TSF shall detect when
+
+ positive integer number
+
+ if the assignment of a positive integer is selected,
+ the PP/ST author should specify the default number
+ (positive integer) of unsuccessful authentication
+ attempts that, when met or surpassed, will trigger
+ the events.
+ an administrator configurable positive integer within
+
+ range of acceptable values
+
+ if an administrator configurable positive integer is
+ selected, the PP/ST author should specify the range of
+ acceptable values from which the administrator of the
+ TOE may configure the number of unsuccessful
+ authentication attempts. The number of authentication
+ attempts should be less than or equal to the upper
+ bound and greater or equal to the lower bound values.
+ the PP/ST author should select either the assignment of a positive integer,
+ or the phrase ``an administrator configurable positive integer'' specifying
+ the range of acceptable values.
+ unsuccessful authentication attempts occur related to
+
+
+ list of authentication events
+
+
+
+ the PP/ST author should specify the authentication
+ events. Examples of these authentication events are:
+ the unsuccessful authentication attempts since the
+ last successful authentication for the indicated user
+ identity, the unsuccessful authentication attempts
+ since the last successful authentication for the
+ current terminal, the number of unsuccessful
+ authentication attempts in the last 10 minutes. At
+ least one authentication event must be specified.
+
+ .
+
+
+ When the defined number of unsuccessful authentication
+ attempts has been met or surpassed, the TSF shall
+
+
+ list of actions
+
+
+
+ the PP/ST author should specify the actions to be
+ taken in case the threshold is met or surpassed. These
+ actions could be disabling of an account for 5
+ minutes, disabling the terminal for an increasing
+ amount of time (2 to the power of the number of
+ unsuccessful attempts in seconds), or disabling of the
+ account until unlocked by the administrator and
+ simultaneously informing the administrator. The
+ actions should specify the measures and if applicable
+ the duration of the measure (or the conditions under
+ which the measure will be ended).
+
+ .
+
+
+
+
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that is used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that are used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+ There are dependencies on the individual security policy (SFP)
+ definitions. These individual definitions should contain the
+ listing of attributes that are necessary for policy
+ enforcement.
+
+
+
+
+
+ This component specifies the security attributes that
+ should be maintained at the level of the user. This means
+ that the security attributes listed are assigned to and
+ can be changed at the level of the user. In other words,
+ changing a security attribute in this list associated with
+ a user should have no impact on the security attributes of
+ any other user.
+
+ In case security attributes belong to a group of users
+ (such as Capability List for a group), the user will need
+ to have a reference (as security attribute) to the
+ relevant group.
+
+
+
+ , allows user security attributes
+ for each user to be maintained individually.
+
+
+ if so indicated in the assignment, the authorised
+ administrator might be able to define additional security
+ attributes for users.
+
+
+ The TSF shall maintain the following list of security
+ attributes belonging to individual users:
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that are associated to an individual
+ user. An example of such a list is
+ {``clearance'', ``group
+ identifier'', ``rights''}.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets and generate
+ secrets to satisfy the defined metric.
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets, and generate
+ secrets to satisfy the defined metric. Examples of such
+ mechanisms may include automated checking of user supplied
+ passwords, or automated password generation.
+
+ A secret can be generated outside the TOE (e.g. selected by
+ the user and introduced in the TOE). In such cases, the
+ component can be used to
+ ensure that the external generated secret adheres to certain
+ standards, for example a minimum size, not present in a
+ dictionary, and/or not previously used.
+
+ Secrets can also be generated by the TOE. In those cases,
+ the component can be used
+ to require the TOE to ensure that the secrets that will
+ adhere to some specified metrics.
+
+ Secrets contain the authentication data provided by the user
+ for an authentication mechanism that is based on knowledge
+ the user possesses. When cryptographic keys are employed,
+ the class should be used instead of this
+ family.
+
+
+
+
+
+ Secrets can be generated by the user. This component
+ ensures that those user generated secrets can be verified
+ to meet a certain quality metric.
+
+
+
+ , requires the TSF to verify that
+ secrets meet defined quality metrics.
+
+
+ the management of the metric used to verify the secrets.
+
+
+ Rejection by the TSF of any tested secret;
+
+
+ Rejection or acceptance by the TSF of any tested secret;
+
+
+ Identification of any changes to the defined quality
+ metrics.
+
+
+ The TSF shall provide a mechanism to verify that secrets
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed, or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+
+
+
+
+ This component allows the TSF to generate secrets for
+ specific functions such as authentication by means of
+ passwords.
+
+ When a pseudo-random number generator is used in a secret
+ generation algorithm, it should accept as input random
+ data that would provide output that has a high degree of
+ unpredictability. This random data (seed) can be derived
+ from a number of available parameters such as a system
+ clock, system registers, date, time, etc. The parameters
+ should be selected to ensure that the number of unique
+ seeds that can be generated from these inputs should be at
+ least equal to the minimum number of secrets that must be
+ generated.
+
+
+
+ , requires the TSF to be able to
+ generate secrets that meet defined quality metrics.
+
+
+ the management of the metric used to generate the secrets.
+
+
+
+
+
+ The TSF shall provide a mechanism to generate secrets that
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+ The TSF shall be able to enforce the use of TSF generated
+ secrets for
+
+
+ list of TSF functions
+
+
+
+ the PP/ST author should provide a list of TSF
+ functions for which the TSF generated secrets must be
+ used. An example of such a function could include a
+ password based authentication mechanism.
+
+ .
+
+
+
+
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family also defines
+ the required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family defines the
+ required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+
+
+
+
+
+ This component requires that the PP/ST author define the
+ TSF-mediated actions that can be performed by the TSF on
+ behalf of the user before the claimed identity of the user
+ is authenticated. The TSF-mediated actions should have no
+ security concerns with users incorrectly identifying
+ themselves prior to being authenticated. For all other
+ TSF-mediated actions not in the list, the user must be
+ authenticated before the action can be performed by the
+ TSF on behalf of the user.
+
+ This component cannot control whether the actions can also
+ be performed before the identification took place. This
+ requires the use of either or
+ with the appropriate assignments.
+
+
+
+ , allows a user to perform certain
+ actions prior to the authentication of the
+ user's identity.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the associated
+ user;
+
+
+ managing the list of actions that can be taken before the
+ user is authenticated.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism;
+
+
+ All TSF mediated actions performed before authentication of
+ the user.
+
+
+ The TSF shall allow
+
+
+ list of TSF mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the claimed identity of the user is
+ authenticated. This list cannot be empty. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ authenticated.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+
+
+
+
+ This component requires that a user is authenticated before any other
+ TSF-mediated action can take place on behalf of that user.
+
+
+ , requires that users are
+ authenticated before any other action will be allowed by the TSF.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the user associated
+ with this data.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+ This component addresses requirements for mechanisms that
+ provide protection of authentication data. Authentication
+ data that is copied from another user, or is in some way
+ constructed should be detected and/or rejected. These
+ mechanisms provide confidence that users authenticated by
+ the TSF are actually who they claim to be.
+
+ This component may be useful only with authentication
+ mechanisms that are based on authentication data that
+ cannot be shared (e.g. biometrics). It is impossible for a
+ TSF to detect or prevent the sharing of passwords outside
+ the control of the TSF.
+
+
+
+ Unforgeable authentication,
+ requires the authentication mechanism to be able to detect
+ and prevent the use of authentication data that has been
+ forged or copied.
+
+
+ Detection of fraudulent authentication data;
+
+
+ All immediate measures taken and results of checks on the
+ fraudulent data.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent forging of
+ authentication data.
+
+
+ use of authentication data that has been forged by any user
+ of the TSF.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent copying of
+ authentication data.
+
+
+ use of authentication data that has been copied from any
+ other user of the TSF.
+
+
+
+
+
+
+ This component addresses requirements for authentication
+ mechanisms based on single-use authentication
+ data. Single-use authentication data can be something the
+ user has or knows, but not something the user is. Examples
+ of single-use authentication data include single-use
+ passwords, encrypted time-stamps, and/or random numbers
+ from a secret lookup table.
+
+ The PP/ST author can specify to which authentication
+ mechanism(s) this requirement applies.
+
+
+
+ , requires an authentication
+ mechanism that operates with single-use authentication
+ data.
+
+
+ Attempts to reuse authentication data.
+
+
+ The TSF shall prevent reuse of authentication data related
+ to
+
+
+ identified authentication mechanism(s)
+
+
+
+ the PP/ST author should specify the list of
+ authentication mechanisms to which this requirement
+ applies. This assignment can be ``all
+ authentication mechanisms''. An example of
+ this assignment could be ``the
+ authentication mechanism employed to authenticate
+ people on the external network''.
+
+ .
+
+
+
+
+
+
+ The use of this component allows specification of
+ requirements for more than one authentication mechanism to
+ be used within a TOE. For each distinct mechanism,
+ applicable requirements must be chosen from the class to be applied to each
+ mechanism. It is possible that the same component could be
+ selected multiple times in order to reflect different
+ requirements for the different use of the authentication
+ mechanism.
+
+ The management functions in the class FMT may provide
+ maintenance capabilities for the set of authentication
+ mechanisms, as well as the rules that determine whether
+ the authentication was successful.
+
+ To allow anonymous users to interact with the TOE, a
+ ``none'' authentication mechanism can be incorporated. The
+ use of such access should be clearly explained in the
+ rules of .
+
+
+
+ , requires that different
+ authentication mechanisms be provided and used to
+ authenticate user identities for specific events.
+
+
+ the management of authentication mechanisms;
+
+
+ the management of the rules for authentication.
+
+
+ The final decision on authentication;
+
+
+ The result of each activated mechanism together with the
+ final decision.
+
+
+ The TSF shall provide
+
+
+ list of multiple authentication mechanisms
+
+
+
+ the PP/ST author should define the available
+ authentication mechanisms. An example of such a list
+ could be: ``none, password mechanism,
+ biometric (retinal scan), S/key mechanism''.
+
+
+ to support user authentication.
+
+
+ The TSF shall authenticate any user's claimed
+ identity according to the
+
+
+ rules describing how the multiple authentication
+ mechanisms provide authentication
+
+
+
+ the PP/ST author should specify the rules that
+ describe how the authentication mechanisms provide
+ authentication and when each is to be used. This means
+ that for each situation the set of mechanisms that
+ might be used for authenticating the user must be
+ described. An example of a list of such rules is:
+ ``if the user has special privileges a
+ password mechanism and a biometric mechanism both
+ shall be used, with success only if both succeed; for
+ all other users a password mechanism shall be
+ used.''
+
+ The PP/ST author might give the boundaries within
+ which the authorised administrator may specify
+ specific rules. An example of a rule is:
+ ``the user shall always be authenticated by
+ means of a token; the administrator might specify
+ additional authentication mechanisms that also must be
+ used.'' The PP/ST author also might choose
+ not to specify any boundaries but leave the
+ authentication mechanisms and their rules completely
+ up to the authorised administrator.
+
+ .
+
+
+
+
+
+
+ This component addresses potential needs to
+ re-authenticate users at defined points in time. These may
+ include user requests for the TSF to perform security
+ relevant actions, as well as requests from non-TSF
+ entities for re-authentication (e.g. a server application
+ requesting that the TSF re-authenticate the client it is
+ serving).
+
+
+
+ , requires the ability to specify
+ events for which the user needs to be re-authenticated.
+
+
+ if an authorised administrator could request
+ re-authentication, the management includes a
+ re-authentication request.
+
+
+ Failure of reauthentication;
+
+
+ All reauthentication attempts.
+
+
+ The TSF shall re-authenticate the user under the conditions
+
+
+ list of conditions under which re-authentication is
+ required
+
+
+
+ the PP/ST author should specify the list of conditions
+ requiring re-authentication. This list could include a
+ specified user inactivity period that has elapsed, the
+ user requesting a change in active security
+ attributes, or the user requesting the TSF to perform
+ some security critical function.
+
+ The PP/ST author might give the boundaries within
+ which the reauthentication should occur and leave the
+ specifics to the authorised administrator. An example
+ of such a rule is: ``the user shall always
+ be re-authenticated at least once a day; the
+ administrator might specify that the re-authentication
+ should happen more often but not more often than once
+ every 10 minutes.''
+
+ .
+
+
+
+
+
+
+
+
+
+ This component addresses the feedback on the
+ authentication process that will be provided to the
+ user. In some systems the feedback consists of indicating
+ how many characters have been typed but not showing the
+ characters themselves, in other systems even this
+ information might not be appropriate.
+
+ This component requires that the authentication data is
+ not provided as-is back to the user. In a workstation
+ environment, it could display a
+ ``dummy'' (e.g. star) for each
+ password character provided, and not the original
+ character.
+
+
+
+ , requires that only limited
+ feedback information is provided to the user during the
+ authentication.
+
+
+ The TSF shall provide only
+
+
+ list of feedback
+
+
+
+ the PP/ST author should specify the feedback related
+ to the authentication process that will be provided to
+ the user. An example of a feedback assignment is
+ ``the number of characters
+ typed'', another type of feedback is
+ ``the authentication mechanism that failed
+ the authentication''.
+
+
+ to the user while the authentication is in progress.
+
+
+
+
+
+
+
+ This family defines the conditions under which users shall
+ be required to identify themselves before performing any
+ other actions that are to be mediated by the TSF and which
+ require user identification.
+
+
+
+ This family defines the conditions under which users are
+ required to identify themselves before performing any other
+ actions that are to be mediated by the TSF and that require
+ user identification.
+
+
+
+
+
+ This component poses requirements for the user to be
+ identified. The PP/ST author can indicate specific actions
+ that can be performed before the identification takes
+ place.
+
+ If is used, the TSF-mediated
+ actions mentioned in should also
+ appear in this .
+
+
+
+ , allows users to perform certain
+ actions before being identified by the TSF.
+
+
+ the management of the user identities;
+
+
+ if an authorised administrator can change the actions
+ allowed before identification, the managing of the action
+ lists.
+
+
+ Unsuccessful use of the user identification mechanism,
+ including the user identity provided;
+
+
+ All use of the user identification mechanism, including the
+ user identity provided.
+
+
+ The TSF shall allow
+
+
+ list of TSF-mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the user has to identify itself. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ identified.
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ In this component users will be identified. A user is not
+ allowed by the TSF to perform any action before being
+ identified.
+
+
+
+ , requires that users identify
+ themselves before any other action will be allowed by the TSF.
+
+
+ the management of the user identities.
+
+
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ It is intended that a subject is
+ acting on behalf of the user who caused the subject to come into
+ being or to be activated to perform a certain task.
+ Therefore, when a subject is created, that subject is acting on
+ behalf of the user who initiated the creation. In cases where
+ anonymity is used, the subject is still acting on behalf of a
+ user, but the identity of that user is unknown. A special
+ category of subjects are those subjects that serve multiple
+ users (e.g. a server process). In such cases the user that
+ created this subject is assumed to be the ``owner''., requires the specification of any rules
+ governing the association between user attributes and the
+ subject attributes into which they are mapped.
+ an authorised administrator can define default subject security
+ attributes.
+
+ an authorised administrator can change subject security
+ attributes.
+
+ Unsuccessful binding of user security attributes to a subject
+ (e.g. creation of a subject).
+
+ Success and failure of binding of user security attributes to a
+ subject (e.g. success or failure to create a subject).
+
+ The TSF shall associate the following user security attributes
+ with subjects acting on the behalf of that user:
+
+ list of user security attributes
+
+ the PP/ST author should specify a list of the user security
+ attributes that are to be bound to subjects..
+
+ The TSF shall enforce the following rules on the initial
+ association of user security attributes with subjects acting on
+ the behalf of users:
+
+ rules for the initial association of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ upon initial association of attributes with subjects, or
+ ``none''..
+
+ The TSF shall enforce the following rules governing changes to the
+ user security attributes associated with subjects acting on the
+ behalf of users:
+
+ rules for the changing of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ when changes are made to the user security attributes
+ associated with subjects acting on behalf of users, or
+ ``none''..
+
+
+
+
+
+
+ This class is intended to specify the management of several
+ aspects of the TSF: security attributes, TSF data and
+ functions. The different management roles and their
+ interaction, such as separation of capability, can be
+ specified.
+
+ This class has several objectives:
+
+
+ management of TSF data, which include, for example,
+ banners;
+
+
+ management of security attributes, which include, for
+ example, the Access Control Lists, and Capability Lists;
+
+
+ management of functions of the TSF, which includes, for
+ example, the selection of functions, and rules or
+ conditions influencing the behaviour of the TSF;
+
+
+ definition of security roles.
+
+
+
+
+
+ This class specifies the management of several aspects of the
+ TSF: security attributes, TSF data and functions in the
+ TSF. The different management roles and their interaction,
+ such as separation of capability, can also be specified
+
+ In an environment where the TOE is made up of multiple
+ physically separated parts, the timing issues with respect to
+ propagation of security attributes, TSF data, and function
+ modification become very complex, especially if the
+ information is required to be replicated across the parts of
+ the TOE. This should be considered when selecting components
+ such as , or , where the behaviour might be
+ impaired. In such situations, use of components from is advisable.
+
+
+
+
+
+ This family allows authorised users control over the
+ management of functions in the TSF. Examples of functions in
+ the TSF include the audit functions and the multiple
+ authentication functions.
+
+
+
+ The TSF management functions enable authorised users to set
+ up and control the secure operation of the TOE. These
+ administrative functions typically fall into a number of
+ different categories:
+
+
+ Management functions that relate to access control,
+ accountability and authentication controls enforced by
+ the TOE. For example, definition and update of user
+ security characteristics (e.g. unique identifiers
+ associated with user names, user accounts, system entry
+ parameters) or definition and update of auditing system
+ controls (e.g. selection of audit events, management of
+ audit trails, audit trail analysis, and audit report
+ generation), definition and update of per-user policy
+ attributes (such as user clearance), definition of known
+ system access control labels, and control and management
+ of user groups.
+
+
+ Management functions that relate to controls over
+ availability. For example, definition and update of
+ availability parameters or resource quotas.
+
+
+ Management functions that relate to general installation
+ and configuration. For example, TOE configuration,
+ manual recovery, installation of TOE security fixes (if
+ any), repair and reinstallation of hardware.
+
+
+ Management functions that relate to routine control and
+ maintenance of TOE resources. For example, enabling and
+ disabling peripheral devices, mounting of removable
+ storage media, backup and recovery.
+
+
+
+ Note that these functions need to be present in a TOE based
+ on the families included in the PP or ST. It is the
+ responsibility of the PP/ST author to ensure that adequate
+ functions will be provided to manage the TOE in a secure
+ fashion.
+
+ The TSF might contain functions that can be controlled by an
+ administrator. For example, the auditing functions could be
+ switched off, the time synchronisation could be switchable,
+ and/or the authentication mechanism could be modifiable.
+
+
+
+
+
+
+
+
+
+ This component allows identified roles to manage the
+ security functions of the TSF. This might entail obtaining
+ the current status of a security function, disabling or
+ enabling the security function, or modifying the behaviour
+ of the security function. An example of modifying the
+ behaviour of the security functions is changing of
+ authentication mechanisms.
+
+
+
+ allows the authorised users (roles)
+ to manage the behaviour of functions in the TSF that use
+ rules or have specified conditions that may be manageable.
+
+
+ managing the group of roles that can interact with the
+ functions in the TSF;
+
+
+ All modifications in the behaviour of the functions in the
+ TSF.
+
+
+ The TSF shall restrict the ability to
+
+
+ determine the behaviour of
+
+
+ disable
+
+
+ enable
+
+
+ modify the behaviour of
+
+
+
+ the PP/ST author should select whether the role can
+ determine the behaviour of, disable, enable, and/or
+ modify the behaviour of the security functions.
+
+
+ the functions
+
+
+ list of functions
+
+
+
+ the PP/ST author should specify the functions that can
+ be modified by the identified roles. Examples include
+ auditing and time determination.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the functions in the TSF. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+ This family allows authorised users control over the
+ management of security attributes. This management might
+ include capabilities for viewing and modifying of security
+ attributes.
+
+
+
+ This family defines the requirements on the management of
+ security attributes.
+
+ Users, subjects and objects have associated security
+ attributes that will affect the behaviour of the
+ TSF. Examples of such security attributes are the groups to
+ which a user belongs, the roles he/she might assume, the
+ priority of a process (subject), and the rights belonging to
+ a role or a user. These security attributes might need to be
+ managed by the user, a subject or a specific authorised user
+ (a user with explicitly given rights for this management).
+
+ It is noted that the right to assign rights to users is
+ itself a security attribute and/or potentially subject to
+ management by .
+ can be used to ensure that any
+ accepted combination of security attributes is within a
+ secure state. The definition of what
+ ``secure'' means is left to the TOE guidance.
+
+ In some instances subjects, objects or user accounts are
+ created. If no explicit values for the related security
+ attributes are given, default values need to be used. can be used to specify that these default
+ values can be managed.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component allows users acting in certain roles to
+ manage identified security attributes. The users are
+ assigned to a role within the component .
+
+ The default value of a parameter is the value the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter, and
+ overrides the default value.
+
+
+
+ allows authorised users (roles) to
+ manage the specified security attributes.
+
+
+ managing the group of roles that can interact with the
+ security attributes.
+
+
+ All modifications of the values of security attributes.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP, information flow control SFP
+
+
+
+ the PP/ST author should list the access control SFP or
+ the information flow control SFP for which the
+ security attributes are applicable.
+
+
+ to restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example of such an operation could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified security
+ attributes. The PP/ST author can specify that the role
+ can modify the default value (change_default), query,
+ modify the security attribute, delete the security
+ attributes entirely or define their own operation.
+
+
+ the security attributes
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that can be operated on by the identified
+ roles. It is possible for the PP/ST author to specify
+ that the default value such as default access-rights
+ can be managed. Examples of these security attributes
+ are user-clearance, priority of service level, access
+ control list, default access rights.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the security attributes. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component contains requirements on the values that
+ can be assigned to security attributes. The assigned
+ values should be such that the TOE will remain in a secure
+ state.
+
+ The definition of what ``secure'' means is
+ not answered in this component but is left to the
+ development of the TOE and the resulting information in the
+ guidance. An example could be that if a user account is
+ created, it should have a non-trivial password.
+
+
+
+ ensures that values assigned to
+ security attributes are valid with respect to the secure
+ state.
+
+
+ All offered and rejected values for a security attribute;
+
+
+ All offered and accepted secure values for a security
+ attribute.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for security attributes.
+
+
+
+
+
+
+
+
+
+
+ This component requires that the TSF provide default
+ values for relevant object security attributes, which can
+ be overridden by an initial value. It may still be
+ possible for a new object to have different security
+ attributes at creation, if a mechanism exists to specify
+ the permissions at time of creation.
+
+
+
+ ensures that the default values of
+ security attributes are appropriately either permissive or
+ restrictive in nature.
+
+
+ managing the group of roles that can specify initial values;
+
+
+ managing the permissive or restrictive setting of default
+ values for a given access control SFP.
+
+
+ Modifications of the default setting of permissive or
+ restrictive rules.
+
+
+ All modifications of the initial values of security
+ attributes.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP, information flow control SFP
+
+
+
+ the PP/ST author should list the access control SFP or
+ the information flow control SFP for which the
+ security attributes are applicable.
+
+
+ to provide
+
+
+ restrictive
+
+
+ permissive
+
+
+ other property
+
+ if the PP/ST author selects another property, the PP/ST
+ author should specify the desired characteristics of the
+ default values.
+
+
+ the PP/ST author should select whether the default property
+ of the access control attribute will be restrictive,
+ permissive, or another property. Only one of these options
+ may be chosen.
+
+
+ default values for security attributes that are used to
+ enforce the SFP.
+
+
+ The TSF shall allow the
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the values of the security
+ attributes. The possible roles are specified in .
+
+
+ to specify alternative initial values to override the
+ default values when an object or information is created.
+
+
+
+
+
+
+
+ This family allows authorised users (roles) control over the
+ management of TSF data. Examples of TSF data include audit
+ information, clock and other TSF
+ configuration parameters.
+
+
+
+ This component imposes requirements on the management of TSF
+ data. Examples of TSF data are the current time and the
+ audit trail. So, for example, this family allows the
+ specification of whom can read, delete or create the audit
+ trail.
+
+
+
+
+
+
+
+
+ This component allows users with a certain role to manage
+ values of TSF data. The users are assigned to a role
+ within the component .
+
+ The default value of a parameter is the values the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter and
+ overrides the default value.
+
+
+
+ allows authorised users to manage
+ TSF data.
+
+
+ managing the group of roles that can interact with the TSF
+ data.
+
+
+ All modifications to the values of TSF data.
+
+
+ The TSF shall restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+ clear
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified TSF data. The PP/ST
+ author can specify that the role can modify the
+ default value (change_default), clear, query or modify
+ the TSF data, or delete the TSF data entirely. If so
+ desired the PP/ST author could specify any type of
+ operation. To clarify ``clear TSF data'' means that
+ the content of the TSF data is removed, but that the
+ entity that stores the TSF data remains in the
+ TOE.
+
+
+ the
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ be operated on by the identified roles. It is possible
+ for the PP/ST author to specify that the default value
+ can be managed.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the TSF data. The possible roles
+ are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies limits on TSF data, and actions
+ to be taken if these limits are exceeded. This component,
+ for example, will allow limits on the size of the audit
+ trail to be defined, and specification of the actions to
+ be taken when these limits are exceeded.
+
+
+
+ specifies the action to be taken if
+ limits on TSF data are reached or exceeded.
+
+
+ managing the group of roles that can interact with the
+ limits on the TSF data.
+
+
+ All modifications to the limits on TSF data;
+
+
+ All modifications in the actions to be taken in case of
+ violation of the limits.
+
+
+ The TSF shall restrict the specification of the limits for
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ have limits, and the value of those limits. An example
+ of such TSF data is the number of users logged-in.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the limits on the TSF data and the
+ actions to be taken. The possible roles are specified
+ in .
+
+ .
+
+
+ The TSF shall take the following actions, if the TSF data
+ are at, or exceed, the indicated limits:
+
+
+ actions to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken if the specified limit on the specified TSF data
+ is exceeded. An example of such TSF action is that the
+ authorised user is informed and an audit record is
+ generated.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component covers requirements on the values that can
+ be assigned to TSF data. The assigned values should be
+ such that the TOE will remain in a secure state.
+
+ The definition of what ``secure'' means is not
+ answered in this component but is left to the development of
+ the TOE and the
+ resulting information in the guidance.
+
+
+
+ ensures that values assigned to TSF
+ data are valid with respect to the secure state.
+
+
+ All rejected values of TSF data.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for TSF data.
+
+
+
+
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+
+
+
+
+
+ This component specifies requirements on the revocation of
+ rights. It requires the specification of the revocation
+ rules. Examples are:
+
+
+ Revocation will take place on the next login of the
+ user;
+
+
+ Revocation will take place on the next attempt to open
+ the file;
+
+
+ Revocation will take place within a fixed time. This
+ might mean that all open connections are re-evaluated
+ every x minutes.
+
+
+
+
+
+ provides for revocation of security
+ attributes to be enforced at some point in time.
+
+
+ managing the group of roles that can invoke revocation of
+ security attributes;
+
+
+ managing the lists of users, subjects, objects and other
+ resources for which revocation is possible;
+
+
+ managing the revocation rules.
+
+
+ Unsuccessful revocation of security attributes;
+
+
+ All attempts to revoke security attributes.
+
+
+ The TSF shall restrict the ability to revoke security
+ attributes associated with the
+
+
+ users
+
+
+ subjects
+
+
+ objects
+
+
+ other additional resources
+
+ the PP/ST author should, if additional resources is
+ selected, specify whether the ability to revoke their
+ security attributes shall be provided by the TSF.
+
+
+ the PP/ST author should specify whether the ability to revoke
+ security attributes from users, subjects, objects, or any
+ additional resources shall be provided by the TSF.
+
+
+ under the control of the TSF to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the functions in the TSF. The
+ possible roles are specified in .
+
+ .
+
+
+ The TSF shall enforce the rules
+
+
+ specification of revocation rules
+
+
+
+ the PP/ST author should specify the revocation
+ rules. Examples of these rules could include:
+ ``prior to the next operation on the
+ associated resource'', or ``for
+ all new subject creations''.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes.
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes. This family can be
+ applied to specify expiration requirements for access
+ control attributes, identification and authentication
+ attributes, certificates (key certificates such as ANSI X509
+ for example), audit attributes, etc.
+
+
+
+
+
+
+
+
+
+ provides the capability for an
+ authorised user to specify an expiration time on specified
+ security attributes.
+
+
+ managing the list of security attributes for which
+ expiration is to be supported;
+
+
+ the actions to be taken if the expiration time has passed.
+
+
+ Specification of the expiration time for an attribute;
+
+
+ Action taken due to attribute expiration.
+
+
+ The TSF shall restrict the capability to specify an
+ expiration time for
+
+
+ list of security attributes for which expiration is to
+ be supported
+
+
+
+ the PP/ST author should provide the list of security
+ attributes for which expiration is to be supported. An
+ example of such an attribute might be a
+ user's security clearance.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the security attributes in the
+ TSF. The possible roles are specified in .
+
+ .
+
+
+ For each of these security attributes, the TSF shall be able
+ to
+
+
+ list of actions to be taken for each security attribute
+
+
+
+ the PP/ST author should provide a list of actions to
+ be taken for each security attribute when it
+ expires. An example might be that the
+ user's security clearance, when it expires,
+ is set to the lowest allowable clearance on the
+ TOE. If immediate revocation is desired by the PP/ST,
+ the action ``immediate
+ revocation'' should be specified.
+
+
+ after the expiration time for the indicated security
+ attribute has passed.
+
+
+
+ This family allows the specification of the management
+ functions to be provided by the TOE. Management functions
+ provide TSFI that allow administrators to define the
+ parameters that control the operation of security-related
+ aspects of the TOE, such as data protection attributes, TOE
+ protection attributes, audit attributes, and identification
+ and authentication attributes. Management functions also
+ include those functions performed by an operator to ensure
+ continued operation of the TOE, such as backup and
+ recovery. This family works in conjunction with the other
+ components in the class: the component in
+ this family calls out the management functions, and other
+ families in restrict the ability to use
+ these management functions.
+ This family allows the specification of the management
+ functions to be provided by the TOE. Each security
+ management function that is listed in fulfilling the
+ assignment is either security attribute management, TSF data
+ management, or security function management.
+ This component specifies the management functions to be
+ provided.
+ PP/ST authors should consult the ``Management'' sections
+ for components included in their PP/ST to provide a basis
+ for the management functions to be listed via this
+ component. requires that the TSF provide
+ specific management functions.
+ Use of the management functions.
+
+ The TSF shall be capable of performing the following
+ management functions:
+
+ list of management functions to be provided by
+ the TSF
+
+ the PP/ST author should specify the management
+ functions to be provided by the TSF, either security
+ attribute management, TSF data management, or security
+ function management..
+
+
+
+
+
+ This family is intended to control the assignment of
+ different roles to users. The capabilities of these roles
+ with respect to security management are described in the
+ other families in this class.
+
+
+
+ This family reduces the likelihood of damage resulting from
+ users abusing their authority by taking actions outside
+ their assigned functional responsibilities. It also
+ addresses the threat that inadequate mechanisms have been
+ provided to securely administer the TSF.
+
+ This family requires that information be maintained to
+ identify whether a user is authorised to use a particular
+ security-relevant administrative function.
+
+ Some management actions can be performed by users, others
+ only by designated people within the organisation. This
+ family allows the definition of different roles, such as
+ owner, auditor, administrator, daily-management.
+
+ The roles as used in this family are security related
+ roles. Each role can encompass an extensive set of
+ capabilities (e.g. root in UNIX), or can be a single right
+ (e.g. right to read a single object such as the
+ helpfile). This family defines the roles. The capabilities
+ of the role are defined in , and .
+
+ Some type of roles might be mutually exclusive. For example
+ the daily-management might be able to define and activate
+ users, but might not be able to remove users (which is
+ reserved for the administrator (role)). This class will
+ allow policies such as two-person control to be specified.
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise. Often the system distinguishes between
+ the owner of an entity, an administrator and other users.
+
+
+
+ specifies the roles with respect to
+ security that the TSF recognises.
+
+
+ managing the group of users that are part of a role.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor and administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise, and conditions on how those roles could
+ be managed. Often the system distinguishes between the
+ owner of an entity, an administrator and other users.
+
+ The conditions on those roles specify the
+ interrelationship between the different roles, as well as
+ restrictions on when the role can be assumed by a user.
+
+
+
+ specifies that in addition to the
+ specification of the roles, there are rules that control
+ the relationship between the roles.
+
+
+ managing the group of users that are part of a role;
+
+
+ managing the conditions that the roles must satisfy.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ unsuccessful attempts to use a role due to the given
+ conditions on the roles;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles:
+
+
+ authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor, administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+ The TSF shall ensure that the conditions
+
+
+ conditions for the different roles
+
+
+
+ the PP/ST author should specify the conditions that
+ govern role assignment. Examples of these conditions
+ are: ``an account cannot have both the
+ auditor and administrator role'' or
+ ``a user with the assistant role must also
+ have the owner role''.
+
+
+ are satisfied.
+
+
+
+
+
+
+
+
+
+ This component specifies that an explicit request must be
+ given to assume the specific role.
+
+
+
+ , requires that an explicit request
+ is given to the TSF to assume a role.
+
+
+ explicit request to assume a role.
+
+
+ The TSF shall require an explicit request to assume the
+ following roles:
+
+
+ the roles
+
+
+
+ the PP/ST author should specify the roles that require
+ an explicit request to be assumed. Examples are:
+ auditor and administrator.
+
+ .
+
+
+
+
+
+
+
+ This class contains privacy requirements. These requirements
+ provide a user protection against discovery and misuse of
+ identity by other users.
+
+
+
+ This class describes the requirements that could be levied to
+ satisfy the users' privacy needs, while still allowing
+ the system flexibility as far as possible to maintain
+ sufficient control over the operation of the system.
+
+ In the components of this class there is flexibility as to
+ whether or not authorised users are covered by the required
+ security functionality. For example, a PP/ST author might
+ consider it appropriate not to require protection of the privacy
+ of users against a suitably authorised user.
+
+ This class, together with other classes (such as those
+ concerned with audit, access control, trusted path, and
+ non-repudiation) provides the flexibility to specify the
+ desired privacy behaviour. On the other hand, the requirements
+ in this class might impose limitations on the use of the
+ components of other classes, such as or . For example, if
+ authorised users are not allowed to see the user identity
+ (e.g. Anonymity or Pseudonymity), it will obviously not be
+ possible to hold individual users accountable for any security
+ relevant actions they perform that are covered by the privacy
+ requirements. However, it may still be possible to include
+ audit requirements in a PP/ST, where the fact that a
+ particular security relevant event has occurred is more
+ important than knowing who was responsible for it.
+
+ Additional information is provided in the application notes
+ for class , where it is explained that the
+ definition of ``identity'' in the context of
+ auditing can also be an alias or other information that could
+ identify a user.
+
+ This class describes four families: Anonymity, Pseudonymity,
+ Unlinkability and Unobservability. Anonymity, Pseudonymity and
+ Unlinkability have a complex interrelationship. When choosing
+ a family, the choice should depend on the threats
+ identified. For some types of privacy threats, pseudonymity
+ will be more appropriate than anonymity (e.g. if there is a
+ requirement for auditing). In addition, some types of privacy
+ threats are best countered by a combination of components from
+ several families.
+
+ All families assume that a user does not explicitly perform an
+ action that discloses the user's own identity. For
+ example, the TSF is not expected to screen the user name in
+ electronic messages or databases.
+
+ All families in this class have components that can be scoped
+ through operations. These operations allow the PP/ST author to
+ state the cooperating users/subjects to which the TSF must be
+ resistant. An example of an instantiation of anonymity could
+ be: `` The TSF shall ensure that the users and/or
+ subjects are unable to determine the user identity bound to
+ the teleconsulting application''.
+
+ It is noted that the TSF should not only provide this
+ protection against individual users, but also against users
+ cooperating to obtain the information.
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing the user's identity. The
+ requirements for Anonymity provide protection of the user
+ identity. Anonymity is not intended to protect the subject
+ identity.
+
+
+
+ Anonymity ensures that a subject may use a resource or
+ service without disclosing its user identity.
+
+ The intention of this family is to specify that a user or
+ subject might take action without releasing its user
+ identity to others such as users, subjects, or objects. The
+ family provides the PP/ST author with a means to identify
+ the set of users that cannot see the identity of someone
+ performing certain actions.
+
+ Therefore if a subject, using anonymity, performs an action,
+ another subject will not be able to determine either the
+ identity or even a reference to the identity of the user
+ employing the subject. The focus of the anonymity is on the
+ protection of the users identity, not on the protection of
+ the subject identity; hence, the identity of the subject is
+ not protected from disclosure.
+
+ Although the identity of the subject is not released to
+ other subjects or users, the TSF is not explicitly
+ prohibited from obtaining the users identity. In case the
+ TSF is not allowed to know the identity of the user, could be invoked. In that case
+ the TSF should not request the user information.
+
+ The interpretation of ``determine'' should be
+ taken in the broadest sense of the word.
+
+ The component levelling distinguishes between the users and
+ an authorised user. An authorised user is often excluded
+ from the component, and therefore allowed to retrieve a
+ user's identity. However, there is no specific
+ requirement that an authorised user must be able to have the
+ capability to determine the user's identity. For
+ ultimate privacy the components would be used to say that no
+ user or authorised user can see the identity of anyone
+ performing any action.
+
+ Although some systems will provide anonymity for all
+ services that are provided, other systems provide anonymity
+ for certain subjects/operations. To provide this
+ flexibility, an operation is included where the scope of the
+ requirement is defined. If the PP/ST author wants to address
+ all subjects/operations, the words ``all subjects and
+ all operations'' could be provided.
+
+ Possible applications include the ability to make enquiries
+ of a confidential nature to public databases, respond to
+ electronic polls, or make anonymous payments or donations.
+
+ Examples of potential hostile users or subjects are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts (e.g. Trojan Horses) into
+ systems. All of these users can investigate usage patterns
+ (e.g. which users used which services) and misuse this
+ information.
+
+
+
+
+
+ This component ensures that the identity of a user is
+ protected from disclosure. There may be instances,
+ however, that a given authorised user can determine who
+ performed certain actions. This component gives the
+ flexibility to capture either a limited or total privacy
+ policy.
+
+
+
+ , requires that other users or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation.
+
+
+ The invocation of the anonymity mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+
+
+
+
+
+ This component is used to ensure that the TSF is not
+ allowed to know the identity of the user.
+
+
+
+ enhances the
+ requirements of by
+ ensuring that the TSF does not ask for the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the anonymity requirement, for
+ example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which the real user name of the subject should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to the real user name.
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing its user identity, but can still
+ be accountable for that use.
+
+
+
+ Pseudonymity ensures that a user may use a resource or
+ service without disclosing its identity, but can still be
+ accountable for that use. The user can be accountable by
+ directly being related to a reference (alias) held by the
+ TSF, or by providing an alias that will be used for
+ processing purposes, such as an account number.
+
+ In several respects, pseudonymity resembles anonymity. Both
+ pseudonymity and anonymity protect the identity of the user,
+ but in pseudonymity a reference to the user's
+ identity is maintained for accountability or other purposes.
+
+ The component does not
+ specify the requirements on the reference to the user's
+ identity. For the purpose of specifying requirements on this
+ reference two sets of requirements are presented: and .
+
+ A way to use the reference is by being able to obtain the
+ original user identifier. For example, in a digital cash
+ environment it would be advantageous to be able to trace the
+ user's identity when a check has been issued multiple times
+ (i.e. fraud). In general, the user's identity needs to be
+ retrieved under specific conditions. The PP/ST author might
+ want to incorporate to
+ describe those services.
+
+ Another usage of the reference is as an alias for a
+ user. For example, a user who does not wish to be
+ identified, can provide an account to which the resource
+ utilisation should be charged. In such cases, the reference
+ to the user identity is an alias for the user, where other
+ users or subjects can use the alias for performing their
+ functions without ever obtaining the user's
+ identity (for example, statistical operations on use of the
+ system). In this case, the PP/ST author might wish to
+ incorporate to specify the rules to
+ which the reference must conform.
+
+ Using these constructs above, digital money can be created
+ using specifying that the user
+ identity will be protected and, if so specified in the
+ condition, that there be a requirement to trace the user
+ identity if the digital money is spent twice. When the user
+ is honest, the user identity is protected; if the user tries
+ to cheat, the user identity can be traced.
+
+ A different kind of system could be a digital credit card,
+ where the user will provide a pseudonym that indicates an
+ account from which the cash can be subtracted. In such
+ cases, for example, could be
+ used. This component would specify that the user identity
+ will be protected and, furthermore, that the same user will
+ only get assigned values for which he/she has provided money
+ (if so specified in the conditions).
+
+ It should be realised that the more stringent components
+ potentially cannot be combined with other requirements, such
+ as identification and authentication or audit. The
+ interpretation of ``determine the identity''
+ should be taken in the broadest sense of the word. The
+ information is not provided by the TSF during the operation,
+ nor can the entity determine the subject or the owner of the
+ subject that invoked the operation, nor will the TSF record
+ information, available to the users or subjects, which might
+ release the user identity in the future.
+
+ The intent is that the TSF not reveal any information that
+ would compromise the identity of the user, e.g. the identity
+ of subjects acting on the user's behalf. The
+ information that is considered to be sensitive depends on
+ the effort an attacker is capable of spending.
+
+ Possible applications include the ability to charge a caller
+ for premium rate telephone services without disclosing his
+ or her identity, or to be charged for the anonymous use of
+ an electronic payment system.
+
+ Examples of potential hostile users are providers, system
+ operators, communication partners and users, who smuggle
+ malicious parts (e.g. Trojan Horses) into systems. All of
+ these attackers can investigate which users used which
+ services and misuse this information. Additionally to
+ Anonymity services, Pseudonymity Services contains methods
+ for authorisation without identification, especially for
+ anonymous payment (``Digital Cash''). This
+ helps providers to obtain their payment in a secure way
+ while maintaining customer anonymity.
+
+
+
+
+
+ This component provides the user protection against
+ disclosure of identity to other users. The user will
+ remain accountable for its actions.
+
+
+
+ requires that a set of users and/or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation, but that this user is
+ still accountable for its actions.
+
+
+ The subject/user that requested resolution of the user
+ identity should be audited.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that under
+ specified conditions the user identity related to a
+ provided reference can be determined.
+
+ In the TSF shall provide an alias
+ instead of the user identity. When the specified
+ conditions are satisfied, the user identity to which the
+ alias belong can be determined. An example of such a
+ condition in an electronic cash environment is: ``
+ The TSF shall provide the notary a capability to determine
+ the user identity based on the provided alias only under
+ the conditions that a check has been issued
+ twice.''.
+
+
+
+ , requires the TSF to provide a
+ capability to determine the original user identity based
+ on a provided alias.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF, is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide
+
+
+ an authorised user
+
+
+
+
+ list of trusted subjects
+
+
+
+ the PP/ST author should identify the list of trusted
+ subjects that can obtain the real user name under a
+ specified condition, for example, a notary or
+ special authorised user.
+
+
+
+
+
+ the PP/ST author should select whether the authorised
+ user and/or trusted subjects can determine the real
+ user name.
+
+
+ a capability to determine the user identity based on the
+ provided alias only under the following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions under which the trusted subjects and
+ authorised user can determine the real user name based
+ on the provided reference. These conditions can be
+ conditions such as time of day, or they can be
+ administrative such as on a court order.
+
+ .
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that the provided
+ reference meets certain construction rules, and thereby
+ can be used in a secure way by potentially insecure
+ subjects.
+
+ If a user wants to use disk resources without disclosing
+ its identity, pseudonymity can be used. However, every
+ time the user accesses the system, the same alias must be
+ used. Such conditions can be specified in this component.
+
+
+
+ , requires the TSF to
+ follow certain construction rules for the alias to the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes which might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide an alias to the real user name which
+ shall be identical to an alias provided previously under the
+ following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions that indicate when the used reference for
+ the real user name shall be identical and when it
+ shall be different, for example, ``when the
+ user logs on to the same host'' it will use a
+ unique alias.
+
+
+ otherwise the alias provided shall be unrelated to
+ previously provided aliases.
+
+
+
+
+
+
+ This family ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together.
+
+
+
+ Unlinkability ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together. Unlinkability differs from pseudonymity
+ that, although in pseudonymity the user is also not known,
+ relations between different actions can be provided.
+
+ The requirements for unlinkability are intended to protect
+ the user identity against the use of profiling of the
+ operations. For example, when a telephone smart card is
+ employed with a unique number, the telephone company can
+ determine the behaviour of the user of this telephone
+ card. When a telephone profile of the users is known, the
+ card can be linked to a specific user. Hiding the
+ relationship between different invocations of a service or
+ access of a resource will prevent this kind of information
+ gathering.
+
+ As a result, a requirement for unlinkability could imply
+ that the subject and user identity of an operation must be
+ protected. Otherwise this information might be used to link
+ operations together.
+
+ Unlinkability requires that different operations cannot be
+ related. This relationship can take several forms. For
+ example, the user associated with the operation, or the
+ terminal which initiated the action, or the time the action
+ was executed. The PP/ST author can specify what kind of
+ relationships are present that must be countered.
+
+ Possible applications include the ability to make multiple
+ use of a pseudonym without creating a usage pattern that
+ might disclose the user's identity.
+
+ Examples for potential hostile subjects and users are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts, (e.g. Trojan Horses)
+ into systems, they do not operate but want to get
+ information about. All of these attackers can investigate
+ (e.g. which users used which services) and misuse this
+ information. Unlinkability protects users from linkages,
+ which could be drawn between several actions of a
+ customer. An example is a series of phone calls made by an
+ anonymous customer to different partners, where the
+ combination of the partner's identities might disclose the
+ identity of the customer.
+
+
+
+
+
+ This component ensures that users cannot link different
+ operations in the system and thereby obtain information.
+
+
+
+ , requires that users and/or subjects
+ are unable to determine whether the same user caused
+ certain specific operations.
+
+
+ the management of the unlinkability function.
+
+
+ The invocation of the unlinkability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine whether
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations which should be subjected to the
+ unlinkability requirement, for example,
+ ``sending email''.
+
+
+
+
+ were caused by the same user
+
+
+ are related as follows
+
+
+ list of relations
+
+
+
+ the PP/ST author should identify the list of
+ relations which should be protected against, for
+ example, ``originate from the same
+ terminal''.
+
+
+
+
+
+ the PP/ST author should select the relationships that
+ should be obscured. The selection allows either the
+ user identity or an assignment of relations to be
+ specified.
+
+ .
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+
+
+ Unobservability ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+ Unobservability approaches the user identity from a
+ different direction than the previous families Anonymity,
+ Pseudonymity and Unlinkability. In this case, the intent is
+ to hide the use of a resource or service, rather than to
+ hide the user's identity.
+
+ A number of techniques can be applied to implement
+ unobservability. Examples of techniques to provide
+ unobservability are:
+
+
+ Allocation of information impacting unobservability:
+ Unobservability relevant information (e.g. information
+ that describes that an operation occurred) can be
+ allocated in several locations within the TOE. The
+ information might be allocated to a single randomly
+ chosen part of the TOE such that an attacker does not
+ know which part of the TOE should be attacked. An
+ alternative system might distribute the information such
+ that no single part of the TOE has sufficient
+ information that, if circumvented, the privacy of the
+ user would be compromised. This technique is explicitly
+ addressed in .
+
+
+ Broadcast: When information is broadcast (e.g. ethernet,
+ radio), users cannot determine who actually received and
+ used that information. This technique is especially
+ useful when information should reach receivers which
+ have to fear a stigma for being interested in that
+ information (e.g. sensitive medical information).
+
+
+ Cryptographic protection and message padding: People
+ observing a message stream might obtain information from
+ the fact that a message is transferred and from
+ attributes on that message. By traffic padding, message
+ padding and encrypting the message stream, the
+ transmission of a message and its attributes can be
+ protected.
+
+
+
+ Sometimes, users should not see the use of a resource, but an
+ authorised user must be allowed to see the use of the resource
+ in order to perform his duties. In such cases, the could be used, which provides the
+ capability for one or more authorised users to see the
+ usage.
+
+ This family makes use of the concept ``parts of the
+ TOE''. This is considered any part of the TOE that is either
+ physically or logically separated from other parts of the
+ TOE.
+
+ Unobservability of communications may be an important factor
+ in many areas, such as the enforcement of constitutional
+ rights, organisational policies, or in defence related
+ applications.
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by unauthorised users.
+
+
+
+ , requires that users and/or
+ subjects cannot determine whether an operation is being
+ performed.
+
+
+ the management of the behaviour of the unobservability
+ function.
+
+
+ The invocation of the unobservability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users and/or
+ subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual user
+ or subject, but must protect with respect to cooperating
+ users and/or subjects. A set of users, for example,
+ could be a group of users which can operate under the
+ same role or can all use the same process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by specified users or
+ subjects. Furthermore this component specifies that
+ information related to the privacy of the user is
+ distributed within the TOE such that attackers might not
+ know which part of the TOE to target, or they need to
+ attack multiple parts of the TOE.
+
+ An example of the use of this component is the use of a
+ randomly allocated node to provide a function. In such a
+ case the component might require that the privacy related
+ information shall only be available to one identified part
+ of the TOE, and will not be communicated outside this part
+ of the TOE.
+
+ A more complex example can be found in some
+ ``voting algorithms''. Several parts of the
+ TOE will be involved in the service, but no individual
+ part of the TOE will be able to violate the policy. So a
+ person may cast a vote (or not) without the TOE being able
+ to determine whether a vote has been cast and what the
+ vote happened to be (unless the vote was unanimous).
+
+
+
+
+ , requires that the TSF
+ provide specific mechanisms to avoid the concentration of
+ privacy related information within the TOE. Such
+ concentrations might impact unobservability if a security
+ compromise occurs.
+
+
+
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+ The TSF shall allocate the
+
+
+ unobservability related information
+
+
+
+ the PP/ST author should identify which privacy related
+ information should be distributed in a controlled
+ manner. Examples of this information could be: IP
+ address of subject, IP address of object, time, used
+ encryption keys.
+
+
+ among different parts of the TOE such that the following
+ conditions hold during the lifetime of the information:
+
+
+ list of conditions
+
+
+
+ the PP/ST author should specify the conditions to
+ which the dissemination of the information should
+ adhere. These conditions should be maintained
+ throughout the lifetime of the privacy related
+ information of each instance. Examples of these
+ conditions could be: ``the information shall
+ only be present at a single separated part of the TOE
+ and shall not be communicated outside this part of the
+ TOE.'', ``the information shall only
+ reside in a single separated part of the TOE, but
+ shall be moved to another part of the TOE
+ periodically'', ``the information shall
+ be distributed between the different parts of the TOE
+ such that compromise of any 5 separated parts of the
+ TOE will not compromise the security policy''.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component is used to require that the TSF does not
+ try to obtain information that might compromise
+ unobservability when provided specific services. Therefore
+ the TSF will not solicit (i.e. try to obtain from other
+ entities) any information that might be used to compromise
+ unobservability.
+
+
+
+ , requires that the TSF
+ does not try to obtain privacy related information that
+ might be used to compromise unobservability.
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the unobservability requirement,
+ for example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which privacy related information should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to
+
+
+ privacy related information
+
+
+
+ the PP/ST author should specify the privacy related
+ information that will be protected from the specified
+ subjects. Examples include the identity of the subject
+ that used a service and the quantity of a service that
+ has been used such as memory resource
+ utilisation.
+
+ .
+
+
+
+
+
+
+ This component is used to require that there will be one
+ or more authorised users with the rights to view the
+ resource utilisation. Without this component, this review
+ is allowed, but not mandated.
+
+
+
+ , requires the TSF to
+ provide one or more authorised users with a capability to
+ observe the usage of resources and/or services.
+
+
+ the list of authorised users that are capable of determining
+ the occurrence of operations.
+
+
+ The observation of the use of a resource or service by a
+ user or subject.
+
+
+ The TSF shall provide
+
+
+ set of authorised users
+
+
+
+ the PP/ST author should specify the set of authorised
+ users for which the TSF must provide the capability to
+ observe the resource utilisation. A set of authorised
+ users, for example, could be a group of authorised users
+ which can operate under the same role or can all use the
+ same process(es).
+
+
+ with the capability to observe the usage of
+
+
+ list of resources and/or services
+
+
+
+ the PP/ST author should specify the set of resources
+ and/or services that the authorised user must be able
+ to observe.
+
+ .
+
+
+
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the integrity of TSF data. In some
+ sense, families in this class may appear to duplicate
+ components in the class; they may
+ even be implemented using the same mechanisms. However, focuses on user data protection, while
+ focuses on TSF data
+ protection. In fact, components from the class are necessary to provide requirements that
+ the SFPs in the TOE cannot be tampered with or
+ bypassed.
+
+ From the point of view of this class, there are three
+ significant portions for the TSF:
+
+
+ The TSF's abstract machine, which is the virtual or
+ physical machine upon which the specific TSF
+ implementation under evaluation executes.
+
+
+ The TSF's implementation, which executes on the abstract
+ machine and implements the mechanisms that enforce the
+ SFRs.
+
+
+ The TSF's data, which are the administrative databases
+ that guide the enforcement of the SFRs.
+
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the
+ integrity of TSF data. In some sense, families in this class may
+ appear to duplicate components in the
+ class; they may even be implemented using the
+ same mechanisms. However, focuses on user
+ data protection, while focuses on TSF data
+ protection. In fact, components from the
+ class are necessary to provide requirements that the SFPs in
+ the TOE cannot be tampered with or bypassed.
+
+ From the point of view of this class, there are three
+ significant portions that make up the TSF:
+
+
+ The TSF's abstract machine, which is the virtual or
+ physical machine upon which the specific TSF
+ implementation under evaluation executes.
+
+
+ The TSF's implementation, which executes on the abstract
+ machine and implements the mechanisms that enforce the
+ SFRs.
+
+
+ The TSF's data, which are the administrative databases
+ that guide the enforcement of the SFRs.
+
+
+
+ All of the families in the class can be
+ related to these areas, and fall into the following groupings:
+
+
+ , which provides an authorised user
+ with the ability to detect external attacks on the parts
+ of the TOE that comprise the TSF.
+
+
+ and , which
+ provide an authorised user with the ability to verify the
+ correct operation of the underlying abstract machine and
+ the TSF as well as the integrity of the TSF data and
+ executable code.
+
+
+ , , and , which address the behaviour of the TSF
+ when failure occurs and immediately after.
+
+
+ , , , which address the protection and
+ availability of TSF data between the TSF and a remote
+ trusted IT product.
+
+
+ , which addresses protection of TSF
+ data when it is transmitted between physically-separated
+ parts of the TOE.
+
+
+ , which addresses the replay of
+ various types of information and/or operations.
+
+
+ , which addresses the synchronisation
+ of states, based upon TSF data, between different parts of
+ a distributed TSF.
+
+
+ , which addresses reliable timing.
+
+
+ , which addresses the consistency of
+ TSF data shared between the TSF and a remote trusted IT
+ product.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to perform
+ testing to demonstrate the security assumptions made about
+ the underlying abstract machine upon which the TSF
+ relies. This ``abstract'' machine could
+ be a hardware/firmware platform, or it could be some known
+ and assessed hardware/software combination acting as a
+ virtual machine.
+
+
+
+ This family defines the requirements for the
+ TSF's testing of security assumptions made about
+ the underlying abstract machine upon which the TSF
+ relies. This ``abstract'' machine could
+ be a hardware/firmware platform, or it could be some known
+ and assessed hardware/software combination acting as a
+ virtual machine. Examples of such testing could be testing
+ hardware page protection, sending sample packets across a
+ network to ensure receipt, and verifying the behaviour of
+ the virtual machine interface. These tests can be carried
+ out either in some maintenance state, at start-up, on-line,
+ or continuously. The actions to be taken by the TOE as the
+ result of testing are defined in .
+
+ The term ``underlying abstract machine''
+ typically refers to the hardware components upon which the
+ TSF has been implemented. However, the phrase can also be
+ used to refer to an underlying, previously evaluated
+ hardware and software combination behaving as a virtual
+ machine upon which the TSF relies.
+
+ The tests of the abstract machine may take various forms:
+
+
+ Power-On Tests. These are tests that ensure the correct
+ operation of the underlying platform. For hardware and
+ firmware, this might include tests of elements such as
+ memory boards, data paths, buses, control logic,
+ processor registers, communication ports, console
+ interfaces, speakers, and peripherals. For software
+ elements (virtual machine), this would include
+ verification of correct initialisation and behaviour.
+
+
+ Loadable Tests. These are tests that might be loaded and
+ executed by an authorised user or be activated by
+ specific conditions. This might include processor
+ component stress tests (logic units, calculation units,
+ etc.) and control memory.
+
+
+
+
+
+ The tests of the underlying abstract machine should be
+ sufficient to test all of the characteristics of the
+ underlying abstract machine upon which the TSF relies.
+
+
+
+
+
+ This component provides support for the periodic testing
+ of the security assumptions of the underlying abstract
+ machine upon which the TSF's operation depends,
+ by requiring the ability to periodically invoke testing
+ functions.
+
+ The PP/ST author may refine the requirement to state
+ whether the function should be available in off-line,
+ on-line or maintenance mode.
+
+
+
+ It is acceptable for the functions for periodic testing to
+ be available only in an off-line or maintenance
+ mode. Controls should be in place to limit access, during
+ maintenance, to authorised users.
+
+
+
+ , provides for testing of the
+ underlying abstract machine.
+
+
+ management of the conditions under which abstract machine
+ test occurs, such as during initial start-up, regular
+ interval, or under specified conditions;
+
+
+ management of the time interval if appropriate.
+
+
+ Execution of the tests of the underlying machine and the
+ results of the tests.
+
+
+ The TSF shall run a suite of tests
+
+
+ during initial start-up
+
+
+ periodically during normal operation
+
+
+ at the request of an authorised user
+
+
+ other conditions
+
+ the PP/ST author should, if other conditions is
+ selected, specify the frequency with which the self
+ tests will be run.
+
+
+ the PP/ST author should specify when the TSF will execute the
+ abstract machine testing, during initial start-up,
+ periodically during normal operation, at the request of an
+ authorised user, or under other conditions. If the tests are
+ run often, then the end users should have more confidence that
+ the TOE is operating correctly than if the tests are run less
+ frequently. However, this need for confidence that the TOE is
+ operating correctly must be balanced with the potential impact
+ on the availability of the TOE, as often times, self tests may
+ delay the normal operation of a TOE.
+
+
+ to demonstrate the correct operation of the security
+ assumptions provided by the abstract machine that underlies
+ the TSF.
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TOE will always enforce
+ its SFRs in the event of identified categories of
+ failures in the TSF.
+
+
+
+ The requirements of this family ensure that the TOE will
+ always enforce its SFRs in the event of certain
+ types of failures in the TSF.
+
+
+
+
+
+ The term ``secure state'' refers to a state in which the
+ TSF data are consistent and the TSF continues correct
+ enforcement of the SFRs.
+
+ Although it is desirable to audit situations in which
+ failure with preservation of secure state occurs, it is
+ not possible in all situations. The PP/ST author should
+ specify those situations in which audit is desired and
+ feasible.
+
+ Failures in the TSF may include
+ ``hard'' failures, which indicate an
+ equipment malfunction and which may require maintenance,
+ service or repair of the TSF. Failures in the TSF may also
+ include recoverable ``soft'' failures,
+ which may only require initialisation or resetting of the
+ TSF.
+
+
+
+ This family consists of only one component, , which requires that the TSF preserve a
+ secure state in the face of the identified failures.
+
+
+ Failure of the TSF.
+
+
+ The TSF shall preserve a secure state when the following
+ types of failures occur:
+
+
+ list of types of failures in the TSF
+
+
+
+ the PP/ST author should list the types of failures in
+ the TSF for which the TSF should ``fail
+ secure,'' that is, should preserve a secure
+ state and continue to correctly enforce the SFRs.
+
+ .
+
+
+
+
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and a remote
+ trusted IT product. This data could, for example, be TSF
+ critical data such as passwords, keys, audit data, or TSF
+ executable code.
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and a remote
+ trusted IT product. This data could be TSF critical data
+ such as passwords, keys, audit data, or TSF executable code.
+
+ This family is used in a distributed context where the TSF
+ is providing TSF data to a remote trusted IT product. The
+ TSF can only take the measures at its site and cannot be
+ held responsible for the TSF at the other trusted IT
+ product.
+
+ If there are different availability metrics for different
+ types of TSF data, then this component should be iterated
+ for each unique pairing of metrics and types of TSF data.
+
+
+
+
+
+ This family consists of only one component, . This component requires that the TSF
+ ensure, to an identified degree of probability, the
+ availability of TSF data provided to a remote trusted IT
+ product.
+
+
+ management of the list of types of TSF data that must be
+ available to a remote trusted IT product.
+
+
+ the absence of TSF data when required by a TOE.
+
+
+ The TSF shall ensure the availability of
+
+
+ list of types of TSF data
+
+
+
+ the PP/ST author should specify the types of TSF data
+ that are subject to the availability metric.
+
+
+ provided to a remote trusted IT product within
+
+
+ a defined availability metric
+
+
+
+ the PP/ST should specify the availability metric for
+ the applicable TSF data.
+
+
+ given the following conditions
+
+
+ conditions to ensure availability
+
+
+
+ the PP/ST author should specify the conditions under
+ which availability must be ensured. For example:
+ there must be a connection between the TOE and the
+ remote trusted IT product.
+
+ .
+
+
+
+
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data during transmission
+ between the TSF and a remote trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data moving between the TSF
+ and a remote trusted IT product. Examples of this data are
+ TSF critical data such as passwords, keys, audit data, or
+ TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is providing TSF data to a remote trusted IT
+ product. The TSF can only take the measures at its site and
+ cannot be held responsible for the behaviour of the other
+ trusted IT product.
+
+
+
+
+
+ Confidentiality of TSF Data during transmission is
+ necessary to protect such information from
+ disclosure. Some possible implementations that could
+ provide confidentiality include the use of cryptographic
+ algorithms as well as spread spectrum techniques.
+
+
+
+ This family consists of only one component, , which requires that the TSF ensure that
+ data transmitted between the TSF and a remote trusted IT
+ product is protected from disclosure while in transit.
+
+
+ The TSF shall protect all TSF data transmitted from the TSF
+ to a remote trusted IT product from unauthorised disclosure
+ during transmission.
+
+
+
+
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and a remote trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and a remote trusted IT product. Examples of
+ this data are TSF critical data such as passwords, keys,
+ audit data, or TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is exchanging TSF data with a remote trusted IT
+ product. Note that a requirement that addresses
+ modification, detection, or recovery at the remote trusted
+ IT product cannot be specified, as the mechanisms that a
+ remote trusted IT product will use to protect its data
+ cannot be determined in advance. For this reason, these
+ requirements are expressed in terms of the ``TSF
+ providing a capability'' which the remote trusted
+ IT product can use.
+
+
+
+
+
+ This component should be used in situations where it is
+ sufficient to detect when data have been modified. An
+ example of such a situation is one in which the remote
+ trusted IT product can request the TOE's TSF to
+ retransmit data when modification has been detected, or
+ respond to such types of request.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a weak checksum
+ and parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches.
+
+
+
+ , provides the ability to detect
+ modification of TSF data during transmission between the
+ TSF and a remote trusted IT product, under the assumption
+ that the remote trusted IT product is cognisant of the
+ mechanism used.
+
+
+ the detection of modification of transmitted TSF data.
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and a
+ remote trusted IT product within the following metric:
+
+
+ a defined modification metric
+
+
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection.
+
+ .
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and a remote
+ trusted IT product and perform
+
+
+ action to be taken
+
+
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+
+
+ if modifications are detected.
+
+
+
+
+
+
+
+ This component should be used in situations where it is
+ necessary to detect or correct modifications of TSF
+ critical data.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a checksum and
+ parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches. The metric that needs to be defined can either
+ refer to the attacks it will resist (e.g. only 1 in a 1000
+ random messages will be accepted), or to mechanisms that
+ are well known in the public literature (e.g. the strength
+ must be conformant to the strength offered by Secure Hash
+ Algorithm).
+
+ The approach taken to correct modification might be done
+ through some form of error correcting checksum.
+
+
+
+ Some possible means of satisfying this requirement
+ involves the use of cryptographic functions or some form
+ of checksum.
+
+
+
+ , provides the ability for the
+ remote trusted IT product not only to detect modification,
+ but to correct modified TSF data under the assumption that
+ the remote trusted IT product is cognisant of the
+ mechanism used.
+
+
+ management of the types of TSF data that the TSF should try
+ to correct if modified in transit;
+
+
+ management of the types of action that the TSF could take if
+ TSF data is modified in transit.
+
+
+ the detection of modification of transmitted TSF data;
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ the use of the correction mechanism.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and a
+ remote trusted IT product within the following metric:
+
+
+ a defined modification metric
+
+
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection.
+
+ .
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and a remote
+ trusted IT product and perform
+
+
+ action to be taken
+
+
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+
+
+ if modifications are detected.
+
+
+ The TSF shall provide the capability to correct
+
+
+ type of modification
+
+
+
+ the PP/ST author should define the types of
+ modification from which the TSF should be capable of
+ recovering.
+
+
+ of all TSF data transmitted between the TSF and a remote
+ trusted IT product.
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+ The determination of the degree of separation (i.e.,
+ physical or logical) that would make application of this
+ family useful depends on the intended environment of use. In
+ a hostile environment, there may be risks arising from
+ transfers between parts of the TOE separated by only a
+ system bus or an inter-process communications channel. In
+ more benign environments, the transfers may be across more
+ traditional network media.
+
+
+
+ One practical mechanism available to a TSF to provide this
+ protection is cryptographically-based.
+
+
+
+
+
+ , requires that TSF data be
+ protected when transmitted between separate parts of the
+ TOE.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+ One of the ways to achieve separation of TSF data based on
+ SFP-relevant attributes is through the use of separate
+ logical or physical channels.
+
+
+
+ , requires that the TSF separate
+ user data from TSF data during transmission.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the separation mechanism.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+ The TSF shall separate user data from TSF data when such
+ data is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+
+
+ , requires that the TSF data
+ transmitted between separate parts of the TOE is monitored
+ for identified integrity errors.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the types of modification of TSF data the TSF
+ should try to detect;
+
+
+ management of the action>s that will be taken.
+
+
+ the detection of modification of TSF data;
+
+
+ the action taken following detection of an integrity error.
+
+
+ The TSF shall be able to detect
+
+
+ modification of data
+
+
+ substitution of data
+
+
+ re-ordering of data
+
+
+ deletion of data
+
+
+
+
+ other integrity errors
+
+
+
+ if the PP/ST author chooses the latter selection
+ noted in the preceding paragraph, then the author
+ should also specify what those other integrity
+ errors are that the TSF should be capable of
+ detecting.
+
+
+
+
+
+ the PP/ST author should specify the desired type of
+ modification that the TSF shall be able to detect. The
+ PP/ST author should select from: modification of data,
+ substitution of data, re-ordering of data, deletion of
+ data, or any other integrity errors.
+
+
+ for TSF data transmitted between separate parts of the TOE.
+
+
+ Upon detection of a data integrity error, the TSF shall take
+ the following actions:
+
+
+ specify the action to be taken
+
+
+
+ the PP/ST author should specify the action to be taken
+ when an integrity error is identified.
+
+ .
+
+
+
+
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements of components in this family ensure that
+ the TSF is protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is enforced. Without these
+ components, the protection functions of a TSF lose their
+ effectiveness in environments where physical damage cannot
+ be prevented. This family also provides requirements
+ regarding how the TSF shall respond to physical tampering
+ attempts.
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements in this family ensure that the TSF is
+ protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is measurable based on
+ defined work factors. Without these components, the
+ protection functions of a TSF lose their effectiveness in
+ environments where physical damage cannot be prevented. This
+ component also provides requirements regarding how the TSF
+ must respond to physical tampering attempts.
+
+ Examples of physical tampering scenarios include mechanical
+ attack, radiation, changing the temperature.
+
+ It is acceptable for the functions that are available to an
+ authorised user for detecting physical tampering to be
+ available only in an off-line or maintenance mode. Controls
+ should be in place to limit access during such modes to
+ authorised users. As the TSF may not be
+ ``operational'' during those modes, it
+ may not be able to provide normal enforcement for authorised
+ user access. The physical implementation of a TOE might
+ consist of several structures: for example an outer
+ shielding, cards, and chips. This set of
+ ``elements'' as a whole must protect
+ (protect, notify and resist) the TSF from physical
+ tampering. This does not mean that all devices must provide
+ these features, but the complete physical construct as a
+ whole should.
+
+ Although there is only minimal auditing associating with
+ these components, this is solely because there is the
+ potential that the detection and alarm mechanisms may be
+ implemented completely in hardware, below the level of
+ interaction with an audit subsystem (for example, a
+ hardware-based detection system based on breaking a circuit
+ and lighting a light emitting diode (LED) if the circuit is
+ broken when a button is pressed by the authorised
+ user). Nevertheless, a PP/ST author may determine that for a
+ particular anticipated threat environment, there is a need
+ to audit physical tampering. If this is the case, the PP/ST
+ author should include appropriate requirements in the list
+ of audit events. Note that inclusion of these requirements
+ may have implications on the hardware design and its
+ interface to the software.
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are not
+ countered by procedural methods. It addresses the threat of
+ undetected physical tampering with the TSF. Typically, an
+ authorised user would be given the function to verify whether
+ tampering took place. As written, this component simply provides
+ a TSF capability to detect tampering. Specification of
+ management functions in should be
+ considered to specify who can make use of that capability, and
+ how they can make use of that capability. If this function is
+ realised by non-IT mechanisms (e.g. physical inspection)
+ management functions are not required.
+
+
+
+ , provides for features that
+ indicate when a TSF device or TSF element is subject to
+ tampering. However, notification of tampering is not
+ automatic; an authorised user must invoke a security
+ administrative function or perform manual inspection to
+ determining if tampering has occurred.
+
+ management of the user or role that determines whether physical
+ tampering has occurred.
+
+
+ if detection by IT means, detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether
+ physical tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+
+
+
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are
+ not countered by procedural methods, and it is required
+ that designated individuals be notified of physical
+ tampering. It addresses the threat that physical tampering
+ with TSF elements, although detected, may not be noticed.
+
+
+
+ , provides for automatic
+ notification of tampering for an identified subset of
+ physical penetrations.
+
+
+ management of the user or role that gets informed about
+ intrusions;
+
+
+ management of the list of devices that should inform the
+ indicated user or role about the intrusion.
+
+
+ detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether physical
+ tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+ For
+
+
+ list of TSF devices/elements for which active detection
+ is required
+
+
+
+ the PP/ST author should provide a list of TSF
+ devices/elements for which active detection of
+ physical tampering is required.
+
+ , the TSF shall monitor the devices and
+ elements and notify
+
+
+ a designated user or role
+
+
+
+ the PP/ST author should designate a user or role that
+ is to be notified when tampering is detected. The type
+ of user or role may vary depending on the particular
+ security administration component (from the family) included in the PP/ST.
+
+
+ when physical tampering with the
+ TSF's devices or TSF's elements has
+ occurred.
+
+
+
+
+
+
+ For some forms of tampering, it is necessary that the TSF
+ not only detects the tampering, but actually resists it or
+ delays the attacker.
+
+ This component should be used when TSF devices and TSF
+ elements are expected to operate in an environment where a
+ physical tampering (e.g. observation, analysis, or
+ modification) of the internals of a TSF device or TSF
+ element itself is a threat.
+
+
+
+ , provides for features that prevent
+ or resist physical tampering with TSF devices and TSF
+ elements.
+
+
+ management of the automatic responses to physical tampering.
+
+
+ The TSF shall resist
+
+
+ physical tampering scenarios
+
+
+
+ the PP/ST author should specify tampering scenarios to
+ a list of TSF devices/elements for which the TSF
+ should resist physical tampering. This list may be
+ applied to a defined subset of the TSF physical
+ devices and elements based on considerations such as
+ technology limitations and relative physical exposure
+ of the device. Such subsetting should be clearly
+ defined and justified. Furthermore, the TSF should
+ automatically respond to physical tampering. The
+ automatic response should be such that the policy of
+ the device is preserved; for example, with a
+ confidentiality policy, it would be acceptable to
+ physically disable the device so that the protected
+ information may not be retrieved.
+
+
+ to the
+
+
+ list of TSF devices/elements
+
+
+
+ the PP/ST author should specify the list of TSF
+ devices/elements for which the TSF should resist
+ physical tampering in the scenarios that have been
+ identified.
+
+
+ by responding automatically such that the SFRs are always enforced.
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started-up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+ Recovery components reconstruct the TSF secure states, or
+ prevent transitions to insecure states, as a direct response
+ to occurrences of expected failures, discontinuity of
+ operation or start-up. Failures that must be generally
+ anticipated include the following:
+
+
+ Unmaskable action failures that always result in a
+ system crash (e.g. persistent inconsistency of critical
+ system tables, uncontrolled transfers within the TSF
+ code caused by transient failures of hardware or
+ firmware, power failures, processor failures,
+ communication failures).
+
+
+ Media failures causing part or all of the media
+ representing the TSF objects to become inaccessible or
+ corrupt (e.g. parity errors, disk head crash, persistent
+ read/write failure caused by misaligned disk heads,
+ worn-out magnetic coating, dust on the disk surface).
+
+
+ Discontinuity of operation caused by erroneous
+ administrative action or lack of timely administrative
+ action (e.g. unexpected shutdowns by turning off power,
+ ignoring the exhaustion of critical resources,
+ inadequate installed configuration).
+
+
+
+ Note that recovery may be from either a complete or partial
+ failure scenario. Although a complete failure might occur in
+ a monolithic operating system, it is less likely to occur in
+ a distributed environment. In such environments, subsystems
+ may fail, but other portions remain operational. Further,
+ critical components may be redundant (disk mirroring,
+ alternative routes), and checkpoints may be available. Thus,
+ recovery is expressed in terms of recovery to a secure
+ state.
+ There are different interactions between
+ and components to be considered when
+ selecting :
+
+ The need for trusted recovery may be indicated through
+ the results of TSF self-testing, where the results of
+ the self-tests indicate that the TSF is in an insecure
+ state and return to a secure state or entrance in
+ maintenance mode is required.
+
+ A failure, as discussed above, may be identified by an
+ administrator. Either the administrator may perform
+ the actions to return the TOE to a secure state and
+ then invoke TSF self-tests to confirm that the secure
+ state has been achieved. Or, the TSF self-tests may be
+ invoked to complete the recovery process.
+
+ A combination of a. and b. above, where the need for
+ trusted recovery is indicated through the results of
+ TSF self-testing, the administrator performs the
+ actions to return the TOE to a secure state and then
+ invokes TSF self-tests to confirm that the secure
+ state has been achieved.
+
+ Self tests detect a failure/service discontinuity,
+ then either automated recovery or entrance to a
+ maintenance mode.
+
+
+ This family identifies a maintenance mode. In this
+ maintenance mode normal operation might be impossible or
+ severely restricted, as otherwise insecure situations might
+ occur. Typically, only authorised users should be allowed
+ access to this mode but the real details of who can access
+ this mode is a function of . If does not put any controls on who can access this
+ mode, then it may be acceptable to allow any user to restore
+ the system if the TOE enters such a state. However, in
+ practice, this is probably not desirable as the user
+ restoring the system has an opportunity to configure the TOE
+ in such a way as to violate the SFRs.
+
+ Mechanisms designed to detect exceptional conditions during
+ operation fall under , , and other areas that address the
+ concept of ``Software Safety.'' It is likely that the use of
+ one of these families will be required to support the adoption
+ of . This is to ensure that
+ the TOE will be able to detect when recovery is
+ required.
+
+ Throughout this family, the phrase ``secure state'' is
+ used. This refers to some state in which the TOE has
+ consistent TSF data and a TSF that can correctly enforce the
+ policy. This state may be the initial ``boot'' of a clean
+ system, or it might be some checkpointed state.
+
+ Following recovery, it may be necessary to confirm that the
+ secure state has been achieved through self-testing of the
+ TSF. However, if the recovery is performed in a manner such
+ that only a secure state can be achieved, else recovery
+ fails, then the dependency to the TSF
+ self-test component may be argued away.
+
+
+
+
+
+
+
+
+ In the hierarchy of the trusted recovery family, recovery
+ that requires only manual intervention is the least
+ desirable, for it precludes the use of the system in an
+ unattended fashion.
+
+ This component is intended for use in TOEs that do not
+ require unattended recovery to a secure state. The
+ requirements of this component reduce the threat of
+ protection compromise resulting from an attended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+
+
+ , allows a TOE to only provide
+ mechanisms that involve human intervention to return to a
+ secure state.
+
+
+ management of who can access the restore capability within
+ the maintenance mode.
+
+
+ the fact that a failure or service discontinuity occurred;
+
+
+ resumption of the regular operation;
+
+
+ type of failure or service discontinuity.
+
+
+ After
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion, any failure or discontinuity)
+ following which the TOE will enter a maintenance mode. the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, as it allows the machine to operate in an
+ unattended fashion.
+
+ The component extends the feature
+ coverage of by requiring that there
+ be at least one automated method of recovery from failure
+ or service discontinuity. It addresses the threat of
+ protection compromise resulting from an unattended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ For , it is the responsibility of
+ the developer of the TSF to determine the set of
+ recoverable failures and service discontinuities.
+
+ It is assumed that the robustness of the automated
+ recovery mechanisms will be verified.
+
+
+
+ , provides, for at least one type of
+ service discontinuity, recovery to a secure state without
+ human intervention; recovery for other discontinuities may
+ require human intervention.
+
+
+ management of who can access the restore capability within
+ the maintenance mode;
+
+
+ management of the list of failures/service discontinuities
+ that will be handled through the automatic procedures.
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode. is not possible, the TSF shall enter a
+ maintenance mode where the ability to return to a secure state
+ is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, but it runs the risk of losing a
+ substantial number of objects. Preventing undue loss of
+ objects provides additional utility to the recovery
+ effort.
+
+ The component extends the feature
+ coverage of by requiring that there
+ not be undue loss of TSF data or objects under the control
+ of the TSF. At , the automated recovery
+ mechanisms could conceivably recover by deleting all
+ objects and returning the TSF to a known secure
+ state. This type of drastic automated recovery is
+ precluded in .
+
+ This component addresses the threat of protection
+ compromise resulting from an unattended TOE returning to
+ an insecure state after recovery from a failure or other
+ discontinuity with a large loss of TSF data or objects
+ under the control of the TSF.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ It is assumed that the evaluators will verify the
+ robustness of the automated recovery mechanisms.
+
+
+
+ , also provides for automated
+ recovery, but strengthens the requirements by disallowing
+ undue loss of protected objects.
+
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode.
+ is not possible, the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+ The functions provided by the TSF to recover from failure or
+ service discontinuity shall ensure that the secure initial
+ state is restored without exceeding
+
+
+ quantification
+
+
+
+ the PP/ST author should provide a quantification for
+ the amount of loss of TSF data or objects that is
+ acceptable.
+
+
+ for loss of TSF data or objects under the control of the TSF.
+
+
+ The TSF shall provide the capability to determine the
+ objects that were or were not capable of being recovered.
+
+
+
+
+
+
+ Function recovery requires that if there should be some
+ failure in the TSF, that certain functions in the TSF should
+ either complete successfully or recover to a secure state.
+
+
+
+ , provides for recovery at the level
+ of particular functions, ensuring either successful completion
+ or rollback of TSF data to a secure state.
+
+
+ if possible, the impossibility to return to a secure state
+ after a failure of the TSF;
+
+
+ if possible, the detection of a failure of a function.
+
+
+ The TSF shall ensure that
+
+
+ list of functions and failure scenarios
+
+
+
+ the PP/ST author should specify a list the functions and
+ failure scenarios. In the event that any of the
+ identified failure scenarios happen, the functions that have
+ been specified must either complete successfully or
+ recover to a consistent and secure state.
+
+
+ have the property that the function either completes successfully,
+ or for the indicated failure scenarios, recovers to a
+ consistent and secure state.
+
+
+
+
+
+
+
+ This family addresses detection of replay for various types
+ of entities (e.g. messages, service requests, service
+ responses) and subsequent actions to correct. In the case
+ where replay may be detected, this effectively prevents it.
+
+
+
+ This family addresses detection of replay for various types
+ of entities and subsequent actions to correct.
+
+
+
+
+
+ The entities included here are, for example, messages,
+ service requests, service responses, or sessions.
+
+
+
+ The family consists of only one component, , which requires that the TSF shall be
+ able to detect the replay of identified entities.
+
+
+ management of the list of identified entities for which
+ replay shall be detected;
+
+
+ management of the list of actions that need to be taken in
+ case of replay.
+
+
+ Detected replay attacks.
+
+
+ Action to be taken based on the specific actions.
+
+
+ The TSF shall detect replay for the following entities:
+
+
+ list of identified entities
+
+
+
+ the PP/ST author should provide a list of identified
+ entities for which detection of replay should be
+ possible. Examples of such entities might include:
+ messages, service requests, service responses, and
+ user sessions.
+
+ .
+
+
+ The TSF shall perform
+
+
+ list of specific actions
+
+
+
+ the PP/ST author should specify the list of actions to
+ be taken by the TSF when replay is detected. The
+ potential set of actions that can be taken includes:
+ ignoring the replayed entity, requesting confirmation
+ of the entity from the identified source, and
+ terminating the subject from which the re-played
+ entity originated.
+
+
+ when replay is detected.
+
+
+
+
+
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use this trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases, synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use a trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+ Some states may never be synchronised, or the transaction
+ cost may be too high for practical use; encryption key
+ revocation is an example, where knowing the state after the
+ revocation action is initiated can never be known. Either
+ the action was taken and acknowledgment cannot be sent, or
+ the message was ignored by hostile communication partners
+ and the revocation never occurred. Indeterminacy is unique
+ to distributed TOEs. Indeterminacy and state synchrony
+ are related, and the same solution may apply. It is futile
+ to design for indeterminate states; the PP/ST author should
+ express other requirements in such cases (e.g. raise an
+ alarm, audit the event).
+
+
+
+
+
+
+
+
+ In this component, the TSF must supply an acknowledgement
+ to another part of the TSF when requested. This
+ acknowledgement should indicate that one part of a
+ distributed TOE successfully received an unmodified
+ transmission from a different part of the distributed TOE.
+
+
+
+ , requires only a simple
+ acknowledgment by the data recipient.
+
+
+ failure to receive an acknowledgement when expected.
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data transmission.
+
+
+
+
+
+
+
+
+
+
+ In this component, in addition to the TSF being able to
+ provide an acknowledgement for the receipt of a data
+ transmission, the TSF must comply with a request from
+ another part of the TSF for an acknowledgement to the
+ acknowledgement.
+
+ For example, the local TSF transmits some data to a remote
+ part of the TSF. The remote part of the TSF acknowledges
+ the successful receipt of the data and requests that the
+ sending TSF confirm that it receives the
+ acknowledgement. This mechanism provides additional
+ confidence that both parts of the TSF involved in the data
+ transmission know that the transmission completed
+ successfully.
+
+
+
+ , requires mutual acknowledgment of
+ the data exchange.
+
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data
+ transmission.
+
+
+ The TSF shall ensure that the relevant parts of the TSF know
+ the correct status of transmitted data among its different
+ parts, using acknowledgements.
+
+
+
+
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+ It is the responsibility of the PP/ST author to clarify the
+ meaning of the phrase ``reliable time
+ stamp'', and to indicate where the responsibility
+ lies in determining the acceptance of trust.
+
+
+
+
+
+ Some possible uses of this component include providing
+ reliable time stamps for the purposes of audit as well as
+ for security attribute expiration.
+
+
+
+ This family consists of only one component, , which requires that the TSF provide
+ reliable time stamps for TSF functions.
+
+
+ management of the time.
+
+
+ changes to the time;
+
+
+ providing a timestamp.
+
+
+ The TSF shall be able to provide reliable time stamps.
+
+
+
+
+
+
+
+ In a distributed environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and a different trusted IT product.
+
+
+
+ In a distributed or composite environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT Product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and that of a different trusted IT Product.
+
+ The components in this family are intended to provide
+ requirements for automated support for TSF data consistency
+ when such data is transmitted between the TSF of the TOE and
+ another trusted IT Product. It is also possible that wholly
+ procedural means could be used to produce security attribute
+ consistency, but they are not provided for here.
+
+ This family is different from FDP_ETC and FDP_ITC, as those
+ two families are concerned only with resolving the security
+ attributes between the TSF and its import/export medium.
+
+ If the integrity of the TSF data is of concern, requirements
+ should be chosen from the family. These
+ components specify requirements for the TSF to be able to
+ detect or detect and correct modifications to TSF data in
+ transit.
+
+
+
+
+
+ The TSF is responsible for maintaining the consistency of
+ TSF data used by or associated with the specified function
+ and that are common between two or more trusted
+ systems. For example, the TSF data of two different
+ systems may have different conventions internally. For the
+ TSF data to be used properly (e.g. to afford the user data
+ the same protection as within the TOE) by the receiving
+ trusted IT product, the TOE and the other trusted IT
+ product must use a pre-established protocol to exchange
+ TSF data.
+
+
+
+ , requires that the TSF provide the
+ capability to ensure consistency of attributes between
+ TSFs.
+
+
+ Successful use of TSF data consistency mechanisms.
+
+
+ Use of the TSF data consistency mechanisms.
+
+
+ Identification of which TSF data have been interpreted.
+
+
+ Detection of modified TSF data.
+
+
+ The TSF shall provide the capability to consistently
+ interpret
+
+
+ list of TSF data types
+
+
+
+ the PP/ST author should define the list of TSF data
+ types, for which the TSF shall provide the capability
+ to consistently interpret, when shared between the TSF
+ and another trusted IT product.
+
+
+ when shared between the TSF and another trusted IT product.
+
+
+ The TSF shall use
+
+
+ list of interpretation rules to be applied by the TSF
+
+
+
+ the PP/ST should assign the list of interpretation
+ rules to be applied by the TSF,
+
+
+ when interpreting the TSF data from another trusted IT
+ product.
+
+
+
+
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if
+ the internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network and parts of the TOE network connections are broken,
+ this may occur when parts become disabled.
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if an
+ internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network of parts of the TOE, this can occur when parts
+ become disabled, network connections are broken, and so on.
+
+ The method of ensuring consistency is not specified in this
+ component. It could be attained through a form of
+ transaction logging (where appropriate transactions are
+ ``rolled back'' to a site upon
+ reconnection); it could be updating the replicated data
+ through a synchronisation protocol. If a particular protocol
+ is necessary for a PP/ST, it can be specified through
+ refinement.
+
+ It may be impossible to synchronise some states, or the cost
+ of such synchronisation may be too high. Examples of this
+ situation are communication channel and encryption key
+ revocations. Indeterminate states may also occur; if a
+ specific behaviour is desired, it should be specified via
+ refinement.
+
+
+
+
+
+
+
+
+ This family consists of only one component, , which requires that the TSF ensure the
+ consistency of TSF data that is replicated in multiple
+ locations.
+
+
+ restoring consistency upon reconnection.
+
+
+ Detected inconsistency between TSF data.
+
+
+ The TSF shall ensure that TSF data is consistent when
+ replicated between parts of the TOE.
+
+
+ When parts of the TOE containing replicated TSF data are
+ disconnected, the TSF shall ensure the consistency of the
+ replicated TSF data upon reconnection before processing any
+ requests for
+
+
+ list of functions dependent on TSF data replication
+ consistency
+
+
+
+ the PP/ST author should specify the list of functions
+ dependent on TSF data replication consistency.
+
+ .
+
+
+
+
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of the authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF executable code (i.e. TSF software)
+ and TSF data by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of an authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF executable code (i.e. TSF software)
+ and TSF data by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+ In addition, use of this component may, with appropriate
+ conditions, help to prevent inappropriate or damaging TSF
+ changes being applied to an operational TOE as the result of
+ maintenance activities.
+
+ The term ``correct operation of the
+ TSF'' refers primarily to the operation of the TSF
+ software and the integrity of the TSF data. The abstract
+ machine upon which the TSF software is implemented is tested
+ via dependency on .
+
+
+
+
+
+
+
+
+ This component provides support for the testing of the
+ critical functions of the TSF's operation by
+ requiring the ability to invoke testing functions and
+ check the integrity of TSF data and executable code.
+
+
+
+ It is acceptable for the functions that are available to
+ the authorised user for periodic testing to be available
+ only in an off-line or maintenance mode. Controls should
+ be in place to limit access during these modes to
+ authorised users.
+
+
+
+ , provides the ability to test the
+ TSF's correct operation. These tests may be
+ performed at start-up, periodically, at the request of the
+ authorised user, or when other conditions are met. It also
+ provides the ability to verify the integrity of TSF data
+ and executable code.
+
+
+ management of the conditions under which TSF self testing
+ occurs, such as during initial start-up, regular interval,
+ or under specified conditions;
+
+
+ management of the time interval if appropriate.
+
+
+ Execution of the TSF self tests and the results of the
+ tests.
+
+
+ The TSF shall run a suite of self tests
+
+ during initial start-up
+
+ periodically during normal operation
+
+ at the request of the authorised user
+
+ at the conditions
+
+ conditions under which self test should occur
+
+ the PP/ST author should, if selected, specify the
+ conditions under which the self test should take
+ place.
+ the PP/ST author should specify when the TSF will execute
+ the TSF test; during initial start-up, periodically during
+ normal operation, at the request of an authorised user, at
+ other conditions. In the case of the latter option, the
+ PP/ST author should also assign what those conditions are
+ via the following assignment.
+ to demonstrate the correct operation of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of parts of the TSF that will be subject to TSF
+ self-testing.
+ the TSF
+
+ the PP/ST author should specify whether the self tests
+ are to be carried out to demonstrate the correct
+ operation of the entire TSF, or of only specified parts
+ of TSF..
+
+
+ The TSF shall provide authorised users with the capability to
+ verify the integrity of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of TSF data that will be verified for
+ integrity.
+ TSF data
+
+ the PP/ST author should specify whether data integrity
+ is to be verified for all TSF data, or only for selected
+ data..
+
+
+ The TSF shall provide authorised users with the capability
+ to verify the integrity of stored TSF executable code.
+
+
+
+
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks, and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+
+
+ The requirements of this family ensure that the TOE will
+ maintain correct operation even in the event of failures.
+
+
+
+ This family provides requirements for the availability of
+ capabilities even in the case of failures. Examples of such
+ failures are power failure, hardware failure, or software
+ error. In case of these errors, if so specified, the TOE
+ will maintain the specified capabilities. The PP/ST author
+ could specify, for example, that a TOE used in a nuclear
+ plant will continue the operation of the shut-down procedure
+ in the case of power-failure or communication-failure.
+
+ Because the TOE can only continue its correct operation if
+ the SFRs are enforced, there is a requirement that the system
+ must remain in a secure state after a failure. This
+ capability is provided by .
+
+ The mechanisms to provide fault tolerance could be active or
+ passive. In case of an active mechanism, specific functions
+ are in place that are activated in case the error
+ occurs. For example, a fire alarm is an active mechanism:
+ the TSF will detect the fire and can take action such as
+ switching operation to a backup. In a passive scheme, the
+ architecture of the TOE is capable of handling the
+ error. For example, the use of a majority voting scheme with
+ multiple processors is a passive solution; failure of one
+ processor will not disrupt the operation of the TOE
+ (although it needs to be detected to allow correction).
+
+ For this family, it does not matter whether the failure has
+ been initiated accidentally (such as flooding or unplugging
+ the wrong device) or intentionally (such as monopolising).
+
+
+
+
+
+
+
+
+ This component is intended to specify which capabilities
+ the TOE will still provide after a failure of the
+ system. Since it would be difficult to describe all
+ specific failures, categories of failures may be
+ specified. Examples of general failures are flooding of
+ the computer room, short term power interruption,
+ breakdown of a CPU or host, software failure, or buffer
+ overflow.
+
+
+
+ , requires the TOE to continue
+ correct operation of identified capabilities in the event
+ of identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ All TOE capabilities being discontinued due to a failure.
+
+
+ The TSF shall ensure the operation of
+
+
+ list of TOE capabilities
+
+
+
+ the PP/ST author should specify the list of TOE
+ capabilities the TOE will maintain during and after a
+ specified failure.
+
+
+ when the following failures occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component is intended to specify against what type of
+ failures the TOE must be resistant. Since it would be
+ difficult to describe all specific failures, categories of
+ failures may be specified. Examples of general failures
+ are flooding of the computer room, short term power
+ interruption, breakdown of a CPU or host, software
+ failure, or overflow of buffer.
+
+
+
+ , requires the TOE to continue
+ correct operation of all capabilities in the event of
+ identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ The TSF shall ensure the operation of all the
+ TOE's capabilities when the following failures
+ occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without undue interference or delay caused by
+ low priority activities.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without interference or delay due to low
+ priority activities. In other words, time critical tasks
+ will not be delayed by tasks that are less time critical.
+
+ This family could be applicable to several types of
+ resources, for example, processing capacity, and
+ communication channel capacity.
+
+ The Priority of Service mechanism might be passive or
+ active. In a passive Priority of Service system, the system
+ will select the task with the highest priority when given a
+ choice between two waiting applications. While using passive
+ Priority of Service mechanisms, when a low priority task is
+ running, it cannot be interrupted by a high priority
+ task. While using an active Priority of Service mechanisms,
+ lower priority tasks might be interrupted by new high
+ priority tasks.
+
+ The audit requirement states that all reasons for rejection
+ should be audited. It is left to the developer to argue that
+ an operation is not rejected but delayed.
+
+
+
+
+
+ This component defines priorities for a subject, and the
+ resources for which this priority will be used. If a
+ subject attempts to take action on a resource controlled
+ by the Priority of Service requirements, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of a subset of the resources
+ under the control of the TSF.
+
+
+ assignment of priorities to each subject in the TSF.
+
+
+ Rejection of operation based on the use of priority within
+ an allocation.
+
+
+ All attempted uses of the allocation function which involves
+ the priority of the service functions.
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which the TSF enforces priority of service
+ (e.g. resources such as processes, disk space, memory,
+ bandwidth).
+
+
+ shall be mediated on the basis of the subjects assigned
+ priority.
+
+
+
+
+
+
+
+ This component defines priorities for a subject. All
+ shareable resources under the control of the TSF will be subjected to the
+ Priority of Service mechanism. If a subject attempts to
+ take action on a shareable TSF resource, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of all of the resources under the control of the TSF.
+
+
+
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to all shareable
+ resources shall be mediated on the basis of the subjects
+ assigned priority.
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources by users and subjects such that denial of
+ service will not occur because of unauthorised
+ monopolisation of resources.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that unauthorised denial of service will not take place by
+ means of monopolisation of resources by other users or
+ subjects.
+
+ Resource allocation rules allow the creation of quotas or
+ other means of defining limits on the amount of resource
+ space or time that may be allocated on behalf of a specific
+ user or subjects. These rules may, for example:
+
+
+ Provide for object quotas that constrain the number
+ and/or size of objects a specific user may allocate.
+
+
+ Control the allocation/deallocation of preassigned
+ resource units where these units are under the control
+ of the TSF.
+
+
+
+ In general, these functions will be implemented through the
+ use of attributes assigned to users and resources.
+
+ The objective of these components is to ensure a certain
+ amount of fairness among the users (e.g. a single user
+ should not allocate all the available space) and
+ subjects. Since resource allocation often goes beyond the
+ lifespan of a subject (i.e. files often exist longer than
+ the applications that generated them), and multiple
+ instantiations of subjects by the same user should not
+ negatively affect other users too much, the components allow
+ that the allocation limits are related to the users. In some
+ situations the resources are allocated by a subject
+ (e.g. main memory or CPU cycles). In those instances the
+ components allow that the resource allocation be on the
+ level of subjects.
+
+ This family imposes requirements on resource allocation, not
+ on the use of the resource itself. The audit requirements
+ therefore, as stated, also apply to the allocation of the
+ resource, not to the use of the resource.
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to only a specified set of the shareable
+ resources in the TOE. The requirements allow the quotas to
+ be associated with a user, possibly assigned to groups of
+ users or subjects as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will not
+ monopolise a controlled resource.
+
+
+ specifying maximum limits for a resource for groups and/or
+ individual users and/or subjects by an administrator.
+
+
+ Rejection of allocation operation due to resource limits.
+
+
+ All attempted uses of the resource allocation functions for
+ resources that are under control of the TSF.
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources:
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which maximum resource allocation limits
+ are required (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to a specified set of the shareable resources
+ in the TOE. The requirements allow the quotas to be
+ associated with a user, or possibly assigned to groups of
+ users as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will always
+ have at least a minimum of a specified resource and that
+ they will not be able to monopolise a controlled resource.
+
+
+ specifying minimum and maximum limits for a resource for
+ groups and/or individual users and/or subjects by an
+ administrator.
+
+
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which maximum and minimum resource
+ allocation limits are required (e.g. processes, disk
+ space, memory, bandwidth). If all resources under the control of the TSF
+ need to be included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+ The TSF shall ensure the provision of minimum quantity of
+ each
+
+
+ controlled resource
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which a minimum allocation limit needs
+ to be set (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included the words ``all TSF resources''
+ can be specified.
+
+
+ that is available for
+
+
+ an individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ to use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This family specifies functional requirements for controlling
+ the establishment of a user's session.
+
+
+
+ The establishment of a user's session typically
+ consists of the creation of one or more subjects that perform
+ operations in the TOE on behalf of the user. At the end of the
+ session establishment procedure, provided the TOE access
+ requirements are satisfied, the created subjects bear the
+ attributes determined by the identification and authentication
+ functions. This family specifies functional requirements for
+ controlling the establishment of a user's session.
+
+ A user session is defined as the period starting at the time
+ of the identification/authentication, or if more appropriate,
+ the start of an interaction between the user and the system,
+ up to the moment that all subjects (resources and attributes)
+ related to that session have been deallocated.
+
+
+
+
+
+ This family defines requirements to limit the scope of
+ session security attributes that a user may select for a
+ session.
+
+
+
+ This family defines requirements that will limit the session
+ security attributes a user may select, and the subjects to
+ which a user may be bound, based on: the method of access;
+ the location or port of access; and/or the time
+ (e.g. time-of-day, day-of-week).
+
+ This family provides the capability for a PP/ST author to
+ specify requirements for the TSF to place limits on the
+ domain of an authorised user's security attributes
+ based on an environmental condition. For example, a user may
+ be allowed to establish a ``secret session''
+ during normal business hours but outside those hours the
+ same user may be constrained to only establishing
+ ``unclassified sessions''. The identification of
+ relevant constraints on the domain of selectable attributes
+ can be achieved through the use of the selection
+ operation. These constraints can be applied on an
+ attribute-by-attribute basis. When there exists a need to
+ specify constraints on multiple attributes this component
+ will have to be replicated for each attribute. Examples of
+ attributes that could be used to limit the session security
+ attributes are:
+
+
+ The method of access can be used to specify in which
+ type of environment the user will be operating
+ (e.g. file transfer protocol, terminal, vtam).
+
+
+ The location of access can be used to constrain the
+ domain of a user's selectable attributes based
+ on a user's location or port of access. This
+ capability is of particular use in environments where
+ dial-up facilities or network facilities are available.
+
+
+ The time of access can be used to constrain the domain
+ of a user's selectable attributes. For example,
+ ranges may be based upon time-of-day, day-of-week, or
+ calendar dates. This constraint provides some
+ operational protection against user actions that could
+ occur at a time where proper monitoring or where proper
+ procedural measures may not be in place.
+
+
+
+
+
+
+
+ , provides the requirement for a TOE
+ to limit the scope of the session security attributes
+ during session establishment.
+
+
+ management of the scope of the session security attributes
+ by an administrator.
+
+
+ All failed attempts at selecting a session security
+ attributes;
+
+
+ All attempts at selecting a session security attributes;
+
+
+ Capture of the values of each session security attributes.
+
+
+ The TSF shall restrict the scope of the session security
+ attributes
+
+
+ session security attributes
+
+
+
+ the PP/ST author should specify the set of session
+ security attributes that are to be
+ constrained. Examples of these session security
+ attributes are user clearance level, integrity level
+ and roles.
+
+ , based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the set of attributes
+ that can be use to determine the scope of the session
+ security attributes. Examples of such attributes are
+ user identity, originating location, time of access,
+ and method of access.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements to place limits on the
+ number of concurrent sessions that belong to the same user.
+
+
+
+ This family defines how many sessions a user may have at the
+ same time (concurrent sessions). This number of concurrent
+ sessions can either be set for a group of users or for each
+ individual user.
+
+
+
+
+
+
+
+
+ This component allows the system to limit the number of
+ sessions in order to effectively use the resources of the
+ TOE.
+
+
+
+ , provides limitations that apply to
+ all users of the TSF.
+
+
+ management of the maximum allowed number of concurrent user
+ sessions by an administrator.
+
+
+ Rejection of a new session based on the limitation of
+ multiple concurrent sessions.
+
+
+ Capture of the number of currently concurrent user sessions
+ and the user security attribute(s).
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user.
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+
+
+
+ This component provides additional capabilities over those
+ of , by allowing further constraints
+ to be placed on the number of concurrent sessions that
+ users are able to invoke. These constraints are in terms
+ of a user's security attributes, such as a
+ user's identity, or membership of a role.
+
+
+
+ extends by
+ requiring the ability to specify limitations on the number
+ of concurrent sessions based on the related security
+ attributes.
+
+
+ management of the rules that govern the maximum allowed
+ number of concurrent user sessions by an administrator.
+
+
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user according to the rules
+
+
+ rules for the number of maximum concurrent sessions
+
+
+
+ the PP/ST author should specify the rules that
+ determine the maximum number of concurrent
+ sessions. An example of a rule is ``maximum
+ number of concurrent sessions is one if the user has a
+ classification level of ``secret''
+ and five otherwise''.
+
+ .
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to provide the
+ capability for TSF-initiated and user-initiated locking and
+ unlocking of interactive sessions.
+
+
+
+ This family defines requirements for the TSF to provide the
+ capability for locking and unlocking of interactive sessions
+ (e.g. keyboard locking).
+
+ When a user is directly interacting with subjects in the TOE
+ (interactive session), the user's terminal is
+ vulnerable if left unattended. This family provides
+ requirements for the TSF to disable (lock) the terminal or
+ terminate the session after a specified period of
+ inactivity, and for the user to initiate the disabling
+ (locking) of the terminal. To reactivate the terminal, an
+ event specified by the PP/ST author, such as the user
+ re-authentication must occur.
+
+ A user is considered inactive, if he/she has not provided
+ any stimulus to the TOE for a period of time.
+
+ A PP/ST author should consider whether should be included. In that case, the
+ function ``session locking'' should be
+ included in the operation in .
+
+
+
+
+
+
+
+
+ , provides the capability for the
+ TSF to lock an active user session after a specified
+ period of time. Locking a terminal would prevent any
+ further interaction with an existing active session
+ through the use of the locked terminal.
+
+ If display devices are overwritten, the replacement
+ contents need not be static (i.e. ``screen
+ savers'' are permitted).
+
+ This component allows the PP/ST author to specify what
+ events will unlock the session. These events may be
+ related to the terminal (e.g. fixed set of keystrokes to
+ unlock the session), the user (e.g. reauthentication), or
+ time.
+
+
+
+ includes system initiated locking
+ of an interactive session after a specified period of user
+ inactivity.
+
+
+ specification of the time of user inactivity after which
+ lock-out occurs for an individual user;
+
+
+ specification of the default time of user inactivity after
+ which lock-out occurs;
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+ Locking of an interactive session by the session locking
+ mechanism.
+
+
+ Successful unlocking of an interactive session.
+
+
+ Any attempts at unlocking an interactive session.
+
+
+ The TSF shall lock an interactive session after
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the locking of an
+ interactive session. If so desired the PP/ST author
+ could, through the assignment, specify that the time
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+
+ by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'' or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+
+
+
+ , provides the capability for an
+ authorised user to lock and unlock his/her own
+ terminal. This would provide authorised users with the
+ ability to effectively block further use of their active
+ sessions without having to terminate the active session.
+
+ If devices are overwritten, the replacement contents need
+ not be static (i.e. ``screen savers''
+ are permitted).
+
+
+
+ , provides capabilities for the user
+ to lock and unlock the user's own interactive
+ sessions.
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+
+
+ The TSF shall allow user-initiated locking of the
+ user's own interactive session, by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'', or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+ , requires that the TSF terminate an
+ interactive user session after a period of inactivity.
+
+ The PP/ST author should be aware that a session may
+ continue after the user terminated his/her activity, for
+ example, background processing. This requirement would
+ terminate this background subject after a period of
+ inactivity of the user without regard to the status of the
+ subject.
+
+
+
+ , provides requirements for the TSF
+ to terminate the session after a period of user
+ inactivity.
+
+
+ specification of the time of user inactivity after which
+ termination of the interactive session occurs for an
+ individual user;
+
+
+ specification of the default time of user inactivity after
+ which termination of the interactive session occurs.
+
+
+ Termination of an interactive session by the session locking
+ mechanism.
+
+
+ The TSF shall terminate an interactive session after a
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the termination of an
+ interactive session. If so desired, the PP/ST author
+ could, through the assignment, specify that the
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements to display a configurable
+ advisory warning message to users regarding the appropriate
+ use of the TOE.
+
+
+
+ Prior to identification and authentication, TOE access
+ requirements provide the ability for the TOE to display an
+ advisory warning message to potential users pertaining to
+ appropriate use of the TOE.
+
+
+
+
+
+ This component requires that there is an advisory warning
+ regarding the unauthorised use of the TOE. A PP/ST author
+ could refine the requirement to include a default banner.
+
+
+
+ , provides the requirement for a TOE
+ Access Banner. This banner is displayed prior to the
+ establishment dialogue for a session.
+
+
+ maintenance of the banner by the authorised administrator.
+
+
+ Before establishing a user session, the TSF shall display an
+ advisory warning message regarding unauthorised use of the
+ TOE.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to display to a
+ user, upon successful session establishment, a history of
+ successful and unsuccessful attempts to access the
+ user's account.
+
+
+
+ This family defines requirements for the TSF to display to
+ users, upon successful session establishment to the TOE, a
+ history of unsuccessful attempts to access the account. This
+ history may include the date, time, means of access, and
+ port of the last successful access to the TOE, as well as
+ the number of unsuccessful attempts to access the TOE since
+ the last successful access by the identified user.
+
+
+
+
+
+
+ This family can provide authorised users with information
+ that may indicate the possible misuse of their user
+ account.
+
+ This component request that the user is presented with the
+ information. The user should be able to review the
+ information, but is not forced to do so. If a user so
+ desires he might, for example, create scripts that ignore
+ this information and start other processes.
+
+
+
+ , provides the requirement for a TOE
+ to display information related to previous attempts to
+ establish a session.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last successful session establishment that will
+ be shown at the user interface. The items are: date,
+ time, method of access (such as ftp), and/or location
+ (e.g. terminal 50).
+
+
+ of the last successful session establishment to the user.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last unsuccessful session establishment that
+ will be shown at the user interface. The items are:
+ date, time, method of access (such as ftp), and/or
+ location (e.g. terminal 50).
+
+
+ of the last unsuccessful attempt to session establishment
+ and the number of unsuccessful attempts since the last
+ successful session establishment.
+
+
+ The TSF shall not erase the access history information from
+ the user interface without giving the user an opportunity to
+ review the information.
+
+
+
+
+
+
+ This family defines requirements to deny a user permission
+ to establish a session with the TOE.
+
+
+
+ This family defines requirements to deny an user permission
+ to establish a session with the TOE based on attributes such
+ as the location or port of access, the user's security
+ attribute (e.g. identity, clearance level, integrity level,
+ membership in a role), ranges of time (e.g. time-of-day,
+ day-of-week, calendar dates) or combinations of parameters.
+
+ This family provides the capability for the PP/ST author to
+ specify requirements for the TOE to place constraints on the
+ ability of an authorised user to establish a session with
+ the TOE. The identification of relevant constraints can be
+ achieved through the use of the selection
+ operation. Examples of attributes that could be used to
+ specify the session establishment constraints are:
+
+
+ The location of access can be used to constrain the
+ ability of a user to establish an active session with
+ the TOE, based on the user's location or port
+ of access. This capability is of particular use in
+ environments where dial-up facilities or network
+ facilities are available.
+
+
+ The user's security attributes can be used to
+ place constraints on the ability of a user to establish
+ an active session with the TOE. For example, these
+ attributes would provide the capability to deny session
+ establishment based on any of the following:
+
+
+ a user's identity;
+
+
+ a user's clearance level;
+
+
+ a user's integrity level; and
+
+
+ a user's membership in a role.
+
+
+
+
+
+ This capability is particularly relevant in situations where
+ authorisation or login may take place at a different
+ location from where TOE access checks are performed.
+
+
+ The time of access can be used to constrain the ability
+ of a user to establish an active session with the TOE
+ based on ranges of time. For example, ranges may be
+ based upon time-of-day, day-of-week, or calendar
+ dates. This constraint provides some operational
+ protection against actions that could occur at a time
+ where proper monitoring or where proper procedural
+ measures may not be in place.
+
+
+
+
+
+
+
+ , provides requirements for denying
+ users access to the TOE based on attributes.
+
+
+ management of the session establishment conditions by the
+ authorised administrator.
+
+
+ Denial of a session establishment due to the session
+ establishment mechanism.
+
+
+ All attempts at establishment of a user session.
+
+
+ Capture of the value of the selected access parameters
+ (e.g. location of access, time of access).
+
+
+ The TSF shall be able to deny session establishment based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the attributes that
+ can be used to restrict the session
+ establishment. Example of possible attributes are user
+ identity, originating location (e.g. no remote
+ terminals), time of access (e.g. outside hours), or
+ method of access (e.g. X-windows).
+
+ .
+
+
+
+
+
+
+
+ Families in this class provide requirements for a trusted
+ communication path between users and the TSF, and for a
+ trusted communication channel between the TSF and other
+ trusted IT products. Trusted paths and channels have the
+ following general characteristics:
+
+
+ The communications path is constructed using internal and
+ external communications channels (as appropriate for the
+ component) that isolate an identified subset of TSF data
+ and commands from the remainder of the TSF and user data.
+
+
+ Use of the communications path may be initiated by the
+ user and/or the TSF (as appropriate for the component).
+
+
+ The communications path is capable of providing assurance
+ that the user is communicating with the correct TSF, and
+ that the TSF is communicating with the correct user (as
+ appropriate for the component).
+
+
+
+ In this paradigm, a trusted channel is a communication channel
+ that may be initiated by either side of the channel, and
+ provides non-repudiation characteristics with respect to the
+ identity of the sides of the channel.
+
+ A trusted path provides a means for users to perform functions
+ through an assured direct interaction with the TSF. Trusted
+ path is usually desired for user actions such as initial
+ identification and/or authentication, but may also be desired
+ at other times during a user's session. Trusted
+ path exchanges may be initiated by a user or the TSF. User
+ responses via the trusted path are guaranteed to be protected
+ from modification by or disclosure to untrusted applications.
+
+
+
+ Users often need to perform functions through direct
+ interaction with the TSF. A trusted path provides confidence
+ that a user is communicating directly with the TSF whenever it
+ is invoked. A user's response via the trusted path
+ guarantees that untrusted applications cannot intercept or
+ modify the user's response. Similarly, trusted
+ channels are one approach for secure communication between the
+ TSF and remote IT products.
+
+ Absence of a trusted path may allow breaches of accountability
+ or access control in environments where untrusted applications
+ are used. These applications can intercept user-private
+ information, such as passwords, and use it to impersonate
+ other users. As a consequence, responsibility for any system
+ actions cannot be reliably assigned to an accountable
+ entity. Also, these applications could output erroneous
+ information on an unsuspecting user's display,
+ resulting in subsequent user actions that may be erroneous and
+ may lead to a security breach.
+
+
+
+
+
+ This family defines requirements for the creation of a
+ trusted channel between the TSF and other trusted IT
+ products for the performance of security critical
+ operations. This family should be included whenever there
+ are requirements for the secure communication of user or TSF
+ data between the TOE and other trusted IT products.
+
+
+
+ This family defines the rules for the creation of a trusted
+ channel connection that goes between the TSF and another
+ trusted IT product for the performance of security critical
+ operations between the products. An example of such a
+ security critical operation is the updating of the TSF
+ authentication database by the transfer of data from a
+ trusted product whose function is the collection of audit
+ data.
+
+
+
+
+
+ This component should be used when a trusted communication
+ channel between the TSF and another trusted IT product is
+ required.
+
+
+
+ , requires that the TSF provide a
+ trusted communication channel between itself and another
+ trusted IT product.
+
+
+ Configuring the actions that require trusted channel, if
+ supported.
+
+
+ Failure of the trusted channel functions.
+
+
+ Identification of the initiator and target of failed trusted
+ channel functions.
+
+
+ All attempted uses of the trusted channel functions.
+
+
+ Identification of the initiator and target of all trusted
+ channel functions.
+
+
+ The TSF shall provide a communication channel between itself
+ and a remote trusted IT product that is logically distinct
+ from other communication channels and provides assured
+ identification of its end points and protection of the
+ channel data from modification or disclosure.
+
+
+ The TSF shall permit
+
+
+ the TSF
+
+
+ the remote trusted IT product
+
+
+
+ the PP/ST author must specify whether the local TSF,
+ the remote trusted IT product, or both shall have the
+ capability to initiate the trusted channel.
+
+
+ to initiate communication via the trusted channel.
+
+
+ The TSF shall initiate communication via the trusted channel
+ for
+
+
+ list of functions for which a trusted channel is
+ required
+
+
+
+ the PP/ST author should specify the functions for
+ which a trusted channel is required. Examples of these
+ functions may include transfer of user, subject,
+ and/or object security attributes and ensuring
+ consistency of TSF data.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+
+
+ This component should be used when trusted communication
+ between a user and the TSF is required, either for initial
+ authentication purposes only or for additional specified
+ user operations.
+
+
+
+ , requires that a trusted path
+ between the TSF and a user be provided for a set of events
+ defined by a PP/ST author. The user and/or the TSF may
+ have the ability to initiate the trusted path.
+
+
+ Configuring the actions that require trusted path, if
+ supported.
+
+
+ Failures of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ failures, if available.
+
+
+ All attempted uses of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ invocations, if available.
+
+
+ The TSF shall provide a communication path between itself
+ and
+
+
+ remote
+
+
+ local
+
+
+
+ the PP/ST author should specify whether the trusted
+ path must be extended to remote and/or local users.
+
+
+ users that is logically distinct from other communication
+ paths and provides assured identification of its end points
+ and protection of the communicated data from modification or
+ disclosure.
+
+
+ The TSF shall permit
+
+
+ the TSF
+
+
+ local users
+
+
+ remote users
+
+
+
+ the PP/ST author should specify whether the TSF, local
+ users, and/or remote users should be able to initiate
+ the trusted path.
+
+
+ to initiate communication via the trusted path.
+
+
+ The TSF shall require the use of the trusted path for
+
+
+ initial user authentication
+
+
+
+
+ other services for which trusted path is required
+
+
+
+ if selected, the PP/ST author should identify
+ other services for which trusted path is required,
+ if any.
+
+
+
+
+
+ the PP/ST author should specify whether the trusted
+ path is to be used for initial user authentication
+ and/or for other specified services.
+
+ .
+
+
+
+
+
+
+
+ The class encompasses five
+ families. These families specify assurance requirements that
+ are designed to provide confidence that a composed TOE will
+ operate securely when relying upon security functionality
+ provided by previously evaluated software, firmware or
+ hardware components.
+
+ Composition involves taking two or more IT entities
+ successfully evaluated against CC security assurance
+ requirements packages (base components and dependent
+ components, see ) and
+ combining them for use, with no further development of either
+ IT entity. The development of additional IT entities is not
+ included (entities that have not previously been the subject
+ of a component evaluation). The composed TOE forms a new
+ product that can be installed and integrated into any specific
+ environment instance that meets the objectives for the
+ environment.
+
+ This approach does not provide an alternative approach for the
+ evaluation of components. Composition under provides a composed TOE integrator a method, which
+ can be used as an alternative to other assurance levels
+ specified in the CC, to gain confidence in a TOE that is the
+ combination of two or more successfully evaluated components
+ without having to re-evaluate the composite TSF. (The composed
+ TOE integrator is referred to as ``developer'' throughout the
+ class, with any references to the
+ developer of the base or dependent components clarified as
+ such.)
+
+ Composed Assurance Packages, as defined in Clauses and , is an
+ assurance scale for composed TOEs. This assurance scale is
+ required in addition to EALs because to combine components
+ evaluated against EALs and gain a resulting EAL assurance, all
+ SARs in the EAL have to be applied to the composed
+ TOE. Although reuse can be made of the component TOE
+ evaluation results, there are often additional aspects of the
+ components that have to be considered in the composed TOE, as
+ described in Annex . Due to the different parties involved in a
+ composed TOE evaluation activity it is generally not possible
+ to gain all necessary evidence about these additional aspects
+ of the components to apply the appropriate EAL. Hence, CAPs
+ have been defined to address the issue of combining evaluated
+ components and gaining a meaningful result. This is discussed
+ further in .
+
+
+
+
+ In a composed TOE it is generally the case that one component
+ relies on the services provided by another component. The
+ component requiring services is termed the dependent component
+ and the component providing the services is termed the base
+ component. This interaction and distinct is discussed further
+ in Annex B. It is assumed to be the case that the developer of
+ the dependent component is supporting the composed TOE
+ evaluation in some manner (as developer, sponsor, or just
+ cooperating and providing the necessary evaluation evidence
+ from the dependent component evaluation) The components included in the CAP assurance packages
+ should not be used as augmentations for component TOE
+ evaluations, as this would provide no meaningful assurance for
+ the component.
+
+ The families within the class
+ interact in a similar manner to the , and classes in a component TOE evaluation and hence
+ leverage from the specification of requirements from those
+ classes where applicable. There are however a few items
+ specific to composed TOE evaluations. To determine how the
+ components interact and identify any deviations from the
+ evaluations of the components, the dependencies that the
+ dependent component has upon the underlying base component are
+ identified (). This reliance on
+ the base component is specified in terms of the interfaces
+ through which the dependent component makes calls for services
+ in support of the dependent component SFRs. The interfaces,
+ and at higher levels the supporting behaviour, provided by the
+ base component in response to those service requests are
+ analysed in . The family is based on the family, as at the simplest level the
+ TSF of each component can be viewed as a subsystem of the
+ composed TOE, with additional portions of each component seen
+ as additional subsystems. Therefore, the interfaces between
+ the components are seen as interactions between subsystems in
+ a component TOE evaluation.
+
+ It is possible that the interfaces and supporting behaviour
+ descriptions provided for are
+ incomplete. This is determined during the conduct of . The
+ family takes the outputs of and
+ and determines whether the
+ components are being used in their evaluated configuration and
+ identifies where any specifications are incomplete, which are
+ then identified as inputs into testing () and vulnerability analysis () activities of the composed TOE.
+
+ Testing of the composed TOE is performed to determine that the
+ composed TOE exhibits the expected behaviour as determined by
+ the composed TOE SFRs, and at higher levels demonstrates the
+ compatibility of the interfaces between the components of the
+ composed TOE.
+
+ The vulnerability analysis of the composed TOE leverages from
+ the outputs of the vulnerability analysis of the component
+ evaluations. The composed TOE vulnerability analysis considers
+ any residual vulnerabilities from the component evaluations to
+ determine that the residual vulnerabilities are not applicable
+ to the composed TOE. A search of publicly available
+ information relating to the components is also performed to
+ identify any issues reported in the components since the
+ completion of the respective evaluations.
+
+ The interaction between the
+ families is depicted in Figure below. This shows by solid arrowed lines where
+ the evidence and understanding gained in one family feeds into
+ the next activity and the dashed arrows identify where an
+ activity explicitly traces back to the composed TOE SFRs, as
+ described above.
+
+
+
+
+ Further discussion of the definition and interactions within
+ composed TOEs is provided in .
+
+
+
+ Assurance class defines
+ requirements of the information necessary to ensure that two
+ or more components, which have themselves been the subject of
+ a CC evaluation, can be integrated in a secure manner.
+
+ The assurance requirements will
+ be applied to the composed TOE to:
+
+
+ determine that the required assurance is provided by the
+ base component;
+
+ determine that the base component and dependent component
+ are compatible; and
+
+ search for any vulnerabilities introduced through
+ composing the base and dependent components into a single
+ composed TOE entity.
+
+
+
+ The goal of this activity is to determine whether the
+ components can be integrated in a secure manner, as defined in
+ the ST for the composed TOE. This is achieved through
+ examination and testing of the interfaces between the
+ components, supported by examination of the design of the
+ components and the conduct of vulnerability analysis.
+
+
+
+ The family identifies where
+ the dependent component is reliant upon IT in its operational
+ environment (satisfied by a base component in the composed TOE
+ evaluation) in order to provide its own security
+ services. This reliance is identified in terms of the
+ interfaces expected by the dependent component to be provided
+ by the base component. then
+ determines which interfaces of the base component were
+ considered (as TSFI) during the component evaluation of the
+ base component.
+
+ It should be noted that does
+ not cover other evidence that may be needed to address the
+ technical integration problem of composing components
+ (e.g. descriptions of non-TSF interfaces of the operating
+ system, rules for integration, etc.). This is outside the
+ security assessment of the composition and is a functional
+ composition issue.
+
+ As part of the evaluator will
+ perform testing of the composed TOE SFRs at the composed TOE
+ interfaces and of the interfaces of the base component relied
+ upon by the dependent component to confirm they operate as
+ specified. The subset selected will consider the possible
+ effects of changes to the configuration/use of the base
+ component as used in the composed TOE. These changes are
+ identified from the configuration of the base component
+ determined during the base component evaluation. The developer
+ will provide test evidence for each of the base component
+ interfaces (the requirements for coverage are consistent with
+ those applied to the evaluation of the base component).
+
+ requires the evaluator to
+ determine whether the appropriate assurance measures have been
+ applied to the base component, and whether the base component
+ is being used in its evaluated configuration. This includes
+ determination of whether all security functionality required
+ by the dependent component was within the TSF of the base
+ component. The requirement
+ may be met through the production of evidence that each of
+ these is demonstrated to be upheld. This evidence may be in
+ the form of the security target and a public report of the
+ component evaluation (e.g. certification report).
+
+ If, on the other hand, one of the above have not been upheld,
+ then it may be possible that an argument can be made as to why
+ the assurance gained during an original evaluation is
+ unaffected. If this is not possible then additional evaluation
+ evidence for those aspects of the base component not covered
+ may have to be provided. This material is then assessed in
+ .
+
+ For example, it may be the case as described in the
+ Interactions between entities (see Annex in CC Part 3) that the
+ dependent component requires the base component to provide
+ more security functionality in the composed TOE than included
+ in the base component evaluation. This would be determined
+ during the application of the
+ and families. In this case
+ the composition rationale evidence provided for would demonstrate that the
+ assurance gained from the base component evaluation is
+ unaffected. This may be achieved by means including:
+
+
+ Performing a re-evaluation of the base component focusing
+ on the evidence relating to the extended part of the
+ TSF;
+
+ Demonstrating that the extended part of the TSF cannot
+ affect other portions of the TSF, and providing evidence
+ that the extended part of the TSF provides the necessary
+ security functionality.
+
+
+
+
+ This family addresses the requirement to demonstrate that
+ the base component can provide an appropriate level of
+ assurance for use in composition.
+
+
+
+ The family is used to
+ determine whether or not the appropriate assurance measures
+ have been applied to the base component for successful
+ integration in the composed TOE. That is, the SARs claimed
+ by the base component are consistent with the SARs in the
+ assurance package for the composed TOE. (e.g. if the
+ assurance package for the composed TOE included , a base component that was
+ evaluated against would
+ not have had the appropriate assurance measures applied, as
+ insufficient design evidence would have been
+ examined.)
+
+ The family calls for
+ evidence that the appropriate assurance is provided, without
+ being specific about how this is achieved. If the
+ appropriate evidence is not available, then it may be
+ necessary to report an assessment of the residual risk to
+ assist consumers of the composed TOE
+ (e.g. accreditors). This report would need to identify the
+ change to the base component that may have an effect on the
+ assurance gained during the original evaluation, along with
+ any known effects.
+
+
+
+
+ There is only a single component in this family.
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+ the composition rationale;
+
+ the reliance information;
+
+ the development information;
+
+ unique identifier.
+
+
+
+
+ The developer shall provide composition rationale for the
+ base component.
+
+
+ The composition rationale shall demonstrate that a level of
+ assurance at least as high as that of the dependent
+ component has been obtained for the support functionality of
+ the base component, when the base component is configured as
+ required to support the TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the correspondence analysis
+ with the development information and the reliance
+ information to identify the interfaces that are relied
+ upon by the dependent component which are not detailed
+ in the development information.
+
+ The evaluator's goal in this work unit is two fold:
+
+
+ to determine which interfaces relied upon by the
+ dependent component have had the appropriate
+ assurance measures applied.
+
+ to determine that the assurance package applied to
+ the base component during the base component
+ evaluation contained either the same assurance
+ requirements as those in the package applied to the
+ dependent component during its' evaluation, or
+ hierarchically higher assurance requirements.
+
+
+ The evaluator may use the correspondence tracing in the
+ development information developed during the activities (e.g. , , ) to
+ help identify the interfaces identified in the reliance
+ information that are not considered in the development
+ information.
+
+ The evaluator will record the SFR-enforcing interfaces
+ described in the reliance information that are not
+ included in the development information. These will
+ provide input to
+ work unit, helping to identify the portions of the base
+ component in which further assurance is required.
+
+ If the both the base and dependent components were
+ evaluated against the same assurance package, then the
+ determination of whether the level of assurance in the
+ portions within the base component evaluation is at
+ least as high as that of the dependent component is
+ trivial. If however, the assurance packages applied to
+ the components during the component evaluations differ,
+ the evaluator needs to determine that the assurance
+ requirements applied to the base component are all
+ hierarchically higher to the assurance requirements
+ applied to the dependent component.
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine, for those included base component interfaces
+ on which the dependent TSF relies, whether the interface
+ was considered during the evaluation of the base
+ component.
+
+ The ST, component public evaluation report
+ (e.g. certification report) and guidance documents for
+ the base component all provide information on the scope
+ and boundary of the base component. The ST provides
+ details of the logical scope and boundary of the
+ composed TOE, allowing the evaluator to determine
+ whether an interface relates to a portion of the product
+ that was within the scope of the evaluation. The
+ guidance documentation provides details of use of all
+ interfaces for the composed TOE. Although the guidance
+ documentation may include details of interfaces in the
+ product that are not within the scope of the evaluation,
+ any such interfaces should be identifiable, either from
+ the scoping information in the ST or through a portion
+ of the guidance that deals with the evaluated
+ configuration. The public evaluation report should
+ provide any additional constraints on the use of the
+ composed TOE that are necessary.
+
+ Therefore, the combination of these inputs allows the
+ evaluator to determine whether an interface described in
+ the composition rationale has the necessary assurance
+ associated with it, or whether further assurance is
+ required. The evaluator will record those interfaces of
+ the base component for which additional assurance is
+ required, for consideration during .
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine that the necessary assurance measures have
+ been applied to the base component.
+
+ The evaluation verdicts, and resultant assurance, for
+ the base component can be reused provided the same
+ portions of the base component are used in the composed
+ TOE and they are used in a consistent manner.
+
+ In order to determine whether the necessary assurance
+ measures have already been applied to the component, and
+ the portions of the component for which assurance
+ measures still need to be applied, the evaluator should
+ use the output of the .*.2E action and the work units and :
+
+
+
+ For those interfaces identified in the reliance
+ information (), but
+ not discussed in development information (), additional information
+ is required. (Identified in .)
+
+ For those interfaces used inconsistently in the
+ composed TOE from the base component (difference
+ between the information provided in and the impact of the differences in use
+ need to be considered. (Identified in .*.2E.)
+
+ For those interfaces identified in composition
+ rationale for which no assurance has previously been
+ gained, additional information is
+ required. (Identified in .)
+
+ For those interfaces consistently described in the
+ reliance information, composition rationale and the
+ development information, no further action is
+ required as the results from the base component
+ evaluation can be re-used.
+
+ The interfaces of the base component reported to be
+ required by the reliance information but not included in
+ the development information indicate the portions of the
+ base component where further assurance is required. The
+ interfaces identify the entry points into the base
+ component.
+
+ For those interfaces included in both the development
+ information and reliance information, the evaluator is
+ to determine whether the interfaces are being used in
+ the composed TOE in a manner that is consistent with the
+ base component evaluation. The method of use of the
+ interface will be considered during the activities to determine that
+ the use of the interface is consistent in both the base
+ component and the composed TOE. The remaining
+ consideration is the determination of whether the
+ configurations of the base component and the composed
+ TOE are consistent. To determine this, the evaluator
+ will consider the guidance documentation of each to
+ ensure they are consistent (see further guidance below
+ regarding consistent guidance documentation). Any
+ deviation in the documentation will be further analysed
+ by the evaluation to determine the possible
+ effects.
+
+ For those interfaces that are consistently described in
+ the reliance information and development information,
+ and for which the guidance is consistent for the base
+ component and the composed TOE, the required level of
+ assurance has been provided.
+
+ The following subsubclauses provide guidance on how to
+ determine consistency between assurance gained in the
+ base component, the evidence provided for the composed
+ TOE, and the analysis performed by the evaluator in the
+ instances where inconsistencies are identified.
+
+
+ The reliance information identifies the interfaces in
+ the dependent component that are to be matched by the
+ base component. If an interface identified in the
+ reliance information is not identified in the
+ development information, then the composition
+ rationale is to provide a justification of how the
+ base component provides the required
+ interfaces.
+
+ If an interface identified in the reliance information
+ is identified in the development information, but
+ there are inconsistencies between the descriptions,
+ further analysis is required. The evaluator identifies
+ the differences in use of the base component as
+ considered in the base component evaluation and the
+ composed TOE evaluation. The evaluator will devise
+ testing to be performed (during the conduct of ) to test the
+ interface.
+
+ The patch status of the base and dependent components
+ as used in the composed TOE should be compared to the
+ patch status of the components during the component
+ evaluations. If any patches have been applied to the
+ components, the composition rationale is to include
+ details of the patches, including any potential impact
+ to the SFRs of the evaluated component. The evaluator
+ should consider the details of the changes provided
+ and verify the accuracy of the potential impact of the
+ change on the component SFRs. The evaluator should
+ then consider whether the changes made by the patch
+ should be verified through testing, and will identify
+ the necessary testing approach. The testing may take
+ the form of repeating the applicable
+ evaluator/developer testing performed for the
+ component evaluation of the component or it may be
+ necessary for the evaluator to devise new tests to
+ confirm the modified component.
+
+ If any of the individual components have been the
+ subject of assurance continuity activities since the
+ completion of the component evaluation, the evaluator
+ will consider the changes assessed in the assurance
+ continuity activities during the independent
+ vulnerability analysis activity for the composed TOE
+ (in ).
+
+
+
+ The guidance for the composed TOE is likely to make
+ substantial reference out to the guidance for the
+ individual components. The minimal guidance expected
+ to be necessary is the identification of any ordering
+ dependencies in the application of guidance for the
+ dependent and base components, particularly during the
+ preparation (installation) of the composed TOE.
+
+ In addition to the application of the and families to the guidance for the
+ composed TOE, it is necessary to analyse the
+ consistency between the guidance for the components
+ and the composed TOE, to identify any
+ deviations.
+
+ If the composed TOE guidance refers out to the base
+ component and dependent component guidance, then the
+ consideration for consistency is limited to
+ consistency between the guidance documentation
+ provided for each of the components (i.e. consistency
+ between the base component guidance and the dependent
+ component guidance). However, if additional guidance
+ is provided for the composed TOE, to that provided for
+ the components, greater analysis is required, as
+ consistency is also required between the guidance
+ documentation for the components and guidance
+ documentation for the composed TOE.
+
+ Consistent in this instance is
+ understood to mean that either the guidance is the
+ same or it places additional constraints on the
+ operation of the individual components when combined,
+ in a similar manner to refinement of
+ functional/assurance components.
+
+ With the information available (that used as input for
+ or the development
+ aspects discussed above) the evaluator may be able to
+ determine all possible impacts of the deviation from
+ the configuration of the base component specified in
+ the component evaluation. However, for high EALs
+ (where evaluation of the base component included requirements) it is
+ possible that, unless detailed design abstractions for
+ the base component are delivered as part of the
+ development information for the composed TOE, the
+ possible impacts of the modification to the guidance
+ cannot be fully determined as the internals are
+ unknown. In this case the evaluator will report the
+ residual risk of the analysis.
+
+ These residual risks are to be included in any public
+ evaluation report for the composed TOE.
+
+ The evaluator will note these variances in the
+ guidance for input into evaluator independent testing
+ activities ().
+
+ The guidance for the composed TOE may add to the
+ guidance for the components, particularly in terms of
+ installation and the ordering of installation steps
+ for the base component in relation to the installation
+ steps for the dependent component. The ordering of
+ the steps for the installation of the individual
+ components should not change, however they may need to
+ be interleaved. The evaluator will examine this
+ guidance to ensure that it still meets the requirement
+ of the activity
+ performed during the evaluations of the
+ components.
+
+ It may be the case that the reliance information
+ identifies that interfaces of the base component, in
+ addition to those identified as TSFIs of the base
+ component, are relied upon by the dependent component
+ are identified in the reliance information. It may be
+ necessary for guidance to be provided for the use of
+ any such additional interfaces in the base
+ component. Provided the consumer of the composed TOE
+ is to receive the guidance documentation for the base
+ component, then the results of the and
+ verdicts for the base component can be reused for
+ those interfaces considered in the evaluation of the
+ base component. However, for the additional interfaces
+ relied upon by the dependent component, the evaluator
+ will need to determine that the guidance documentation
+ for the base component meets the requirements of and , as applied in the base component
+ evaluations.
+
+ For those interfaces considered during the base
+ component evaluation, and therefore, for which
+ assurance has already been gained, the evaluator will
+ ensure that the guidance for the use of each interface
+ for the composed TOE is consistent with that provided
+ for the base component. To determine the guidance for
+ the composed TOE is consistent with that for the base
+ component, the evaluator should perform a mapping for
+ each interface to the guidance provided for both the
+ composed TOE and the base component. The evaluator
+ then compares the guidance to determine
+ consistency.
+
+ Examples of additional constraints provided in
+ composed TOE guidance that would be considered to be
+ consistent with component guidance are (guidance for a
+ component is given followed by an example of guidance
+ for a composed TOE that would be considered to provide
+ additional constraints):
+
+
+ Component: The password length must be set to a
+ minimum of 8 characters length, including
+ alphabetic and numeric characters.
+
+ Composed TOE: The password length must be set to a
+ minimum of 10 characters in length, including
+ alphabetic and numeric characters and at
+ least one of the following special characters: ( )
+ { } ^ < > - _
+
+ NOTE: It would only be acceptable to increase the
+ password length to [integer >
+ 8] characters while removing the mandate
+ for the inclusion of both alphabetic and numeric
+ characters for the composed TOE, if the same or a
+ higher metric was achieved for the strength rating
+ (taking into account the likelihood of the
+ password being guessed).
+
+ Component: The following services are to be
+ disabled in the registry settings: WWW Publishing
+ Service and ICDBReporter service.
+
+ Composed TOE: The following services are to be
+ disabled in the registry settings:
+ Publishing Service, ICDBReporter service,
+ Remote Procedure Call (RPC) Locator and Procedure
+ Call (RPC) Service.
+
+ Component: Select the following attributes to be
+ included in the accounting log files: date, time,
+ type of event, subject identity and
+ success/failure.
+
+ Composed TOE: Select the following attributes to
+ be included in the accounting log files: date,
+ time, type of event, subject identity,
+ success/failure, event message and process
+ thread.
+
+ If the guidance for the composed TOE deviates (is not
+ a refinement) from that provided for the base
+ component, the evaluator will assess the potential
+ risks of the modification to the guidance. The
+ evaluator will use the information available
+ (including that provided in the public domain, the
+ architectural description of the base component in the
+ public evaluation report (e.g. certification report),
+ the context of the guidance from the remainder of the
+ guidance documentation) to identify likely impact of
+ the modification to the guidance on the SFRs of the
+ composed TOE.
+
+ If during the dependent component evaluation the trial
+ installation used the base component to satisfy the
+ environment requirements of the dependent component
+ this work unit for the composed TOE is considered to
+ be satisfied. If the base component was not used in
+ satisfaction of the work unit during the dependent component
+ evaluation, the evaluator will apply the user
+ procedures provided for the composed TOE to prepare
+ the composed TOE, in accordance with the guidance
+ specified in . This will allow the evaluator to
+ determine that the preparative guidance provided for
+ the composed TOE is sufficient to prepare the composed
+ TOE and its operational environment securely.
+
+
+
+
+ If there is a different delivery mechanism used for
+ the delivery of the composed TOE (i.e. the
+ components are not delivered to the consumer in
+ accordance with the secure delivery procedures
+ defined and assessed during the evaluation of the
+ components), the delivery procedures for the
+ composed TOE will require evaluation against the
+ requirements
+ applied during the components evaluations.
+
+ The composed TOE may be delivered as an integrated
+ product or may require the components to be
+ delivered separately.
+
+ If the components are delivered separately, the
+ results of the delivery of the base component and
+ dependent component are reused. The delivery of the
+ base component is checked during the evaluator trial
+ installation of the dependent component, using the
+ specified guidance and checking the aspects of
+ delivery that are the responsibility of the user, as
+ described in the guidance documentation for the base
+ component.
+
+ If the composed TOE is delivered as a new entity,
+ then the method of delivery of that entity must be
+ considered in the composed TOE evaluation
+ activities.
+
+ The assessment of the delivery procedures for
+ composed TOE items is to be performed in accordance
+ with the methodology for as for any other [component] TOE,
+ ensuring any additional items (e.g. additional
+ guidance documents for the composed TOE) are
+ considered in the delivery procedures.
+
+
+
+ The unique identification of the composed TOE is
+ considered during the application of and the items from
+ which that composed TOE is comprised are considered
+ during the application of .
+
+ Although additional guidance may be produced for the
+ composed TOE, the unique identification of this
+ guidance (considered as part of the unique
+ identification of the composed TOE during ) is considered
+ sufficient control of the guidance.
+
+ The verdicts of the remaining (not considered above)
+ activities can be
+ reused from the base component evaluation, as no
+ further development is performed during integration
+ of the composed TOE.
+
+ There are no additional considerations for
+ development security as the integration is assumed
+ to take place at either the consumer's site or, in
+ the instance that the composed TOE is delivered as
+ an integrated product, at the site of the dependent
+ component developer. Control at the consumer's site
+ is outside the consideration of the CC. No
+ additional requirements or guidance are necessary if
+ integration is at the same site as that for the
+ dependent component, as all components are
+ considered to be configuration items for the
+ composed TOE, and should therefore be considered
+ under the dependent component developer's security
+ procedures anyway.
+
+ Tools and techniques adopted during integration will
+ be considered in the evidence provided by the
+ dependent component developer. Any tools/techniques
+ relevant to the base component will have been
+ considered during the evaluation of the base
+ component. For example, if the base component is
+ delivered as source code and requires compilation by
+ the consumer (e.g. dependent component developer who
+ is performing integration) the compiler would have
+ been specified and assessed, along with the
+ appropriate arguments, during evaluation of the base
+ component.
+
+ There is no life-cycle definition applicable to the
+ composed TOE, as no further development of items is
+ taking place.
+
+ The results of flaw remediation for a component are
+ not applicable to the composed TOE. If flaw
+ remediation is included in the assurance package for
+ the composed TOE, then the requirements are to be applied during
+ the composed TOE evaluation (as for any
+ augmentation).
+
+
+
+
+ The composed TOE will have been tested during the
+ conduct of the activities
+ for evaluation of the dependent component, as the
+ configurations used for testing of the dependent
+ component should have included the base component to
+ satisfy the requirements for IT in the operational
+ environment. If the base component was not used in the
+ testing of the dependent component for the dependent
+ component evaluation, or the configuration of either
+ component varied from their evaluated configurations,
+ then the developer testing performed for evaluation of
+ the dependent component to satisfy the requirements is to be repeated
+ on the composed TOE.
+
+
+
+
+
+
+
+
+ This family sets out requirements for a specification of the
+ base component in increasing levels of detail. Such
+ information is required to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component (as identified
+ in the reliance information).
+
+
+
+ provides details of the
+ base component interfaces and internals in increasing levels
+ of detail, mirroring the level of detail provided by . The application of these two
+ families will provide the specifications of security
+ services from each perspective of the TSF making the call
+ and the TSF servicing the call.
+
+ Having the two descriptions then allows a determination to
+ be made, as part of the
+ activities (.*.2E actions),
+ that these two descriptions are consistent.
+
+
+
+ The components are levelled on the basis of increasing
+ amounts of detail about the interfaces provided, and how
+ they are implemented.
+
+
+
+ The TSF of the base component is often defined without
+ knowledge of the dependencies of the possible applications
+ with which it may by composed. The TSF of this base
+ component is defined to include all parts of the base
+ component that have to be relied upon for enforcement of the
+ base component SFRs. This will include all parts of the base
+ component required to implement the base component
+ SFRs.
+
+ The functional specification of the base component will
+ describe the TSFI in terms of the interfaces the base
+ component provides to allow an external entity to invoke
+ operations of the TSF. This includes interfaces to the
+ human user to permit interaction with the operation of the
+ TSF invoking SFRs and also interfaces allowing an external
+ IT entity to make calls into the TSF.
+
+ The functional specification only provides a description of
+ what the TSF provides at its interface and the means by
+ which that TSF functionality are invoked. Therefore, the
+ functional specification does not necessarily provide a
+ complete interface specification of all possible interfaces
+ available between an external entity and the base
+ component. It does not include what the TSF expects/requires
+ from the operational environment. The description of what a
+ dependent component TSF relies upon of a base component is
+ considered in and the
+ development information evidence provides a response to the
+ interfaces specified.
+
+ The development information evidence includes a
+ specification of the base component. This may be the
+ evidence used during evaluation of the base component to
+ satisfy the requirements, or may
+ be another form of evidence produced by either the base
+ component developer or the composed TOE developer. This
+ specification of the base component is used during to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component. The level of
+ detail required of this evidence increases to reflect the
+ level of required assurance in the composed TOE. This is
+ expected to broadly reflect the increasing confidence gained
+ from the application of the assurance packages to the
+ components. The evaluator determines that this description
+ of the base component is consistent with the reliance
+ information provided for the dependent component.
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces of the base
+ component to determine that they are consistent with the
+ interfaces specified in the reliance information; those
+ required by the dependent component.
+
+ The description of the interfaces into the base component
+ is to be provided at a level of detail consistent with
+ although not all of the
+ aspects necessary for satisfaction of are required for , as once the interface has been identified
+ and the purpose described the remaining detail of the
+ interface specification can be reused from evaluation of
+ the base component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose of
+ each interface of the base component used in the composed
+ TOE.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during activity).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ In addition, the security behaviour of the base component
+ that supports the dependent component TSF is
+ described.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component, which
+ supports the enforcement of the dependent component SFRs.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component that supports the enforcement of the dependent
+ component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ The interface description of the architecture of the base
+ component is provided to enable the evaluator to determine
+ whether or not that interface formed part of the TSF of
+ the base component.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+ In addition to the interface description, the subsystems
+ of the base component that provide the security
+ functionality required by the dependent component will be
+ described to enable the evaluator to determine whether or
+ not that interface formed part of the TSF of the base
+ component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall identify the subsystems of
+ the base component that provide interfaces of the base
+ component used in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component
+ subsystems, which support the enforcement of the dependent
+ component SFRs.
+
+
+ The development information shall provide a mapping from the
+ interfaces to the subsystems of the base component.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that all subsystems of the base component
+ that provide interfaces to the dependent component are
+ identified.
+
+ For those interfaces that are considered to form part of
+ the TSFI of the base component, the subsystems
+ associated with the interface will be subsystems
+ considered in the
+ activity during the base component evaluation. The
+ interfaces on which the dependent component relies that
+ did not form part of the TSFI of the base component will
+ map to subsystems outside of the base component
+ TSF.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component subsystems that support the enforcement of the
+ dependent component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that the correspondence between the
+ interfaces and subsystems of the base component is
+ accurate.
+
+ If the TOE design and functional specification evidence
+ from the base component evaluation is available, this
+ can be used to verify the accuracy of the correspondence
+ between the interfaces and subsystems of the base
+ component as used in the composed TOE. Those interfaces
+ of the base component, which formed part of the base
+ component TSFI will be described in the base component
+ functional specification, and the associated subsystems
+ will be described in the base component TOE design
+ evidence. The tracing between the two will be provided
+ in the base component TOE design evidence.
+
+ If, however, the base component interface did not form
+ part of the TSFI of the base component, the description
+ of the subsystem behaviour provided in the development
+ information will be used to verify the accuracy of the
+ correspondence.
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+ The purpose of this family is to provide evidence that
+ describes the reliance that a dependent component has upon
+ the base component. This information is useful to persons
+ responsible for integrating the component with other
+ evaluated IT components to form the composed TOE, and for
+ providing insight into the security properties of the
+ resulting composition.
+
+ This provides a description of the interface between the
+ dependent and base components of the composed TOE that may
+ not have been analysed during evaluation of the individual
+ components, as the interfaces were not TSFIs of the
+ individual component TOEs.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant during
+ evaluation of the component, either because of the inherent
+ purpose of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces when evaluating the base component, and are in
+ addition to the security interfaces (TSFIs) considered in
+ the functional specification.
+
+
+
+ The components in this family are levelled according to the
+ amount of detail provided in the description of the reliance
+ by the dependent component upon the base component.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant in the
+ component evaluation, either because of the inherent purpose
+ of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces in the evaluation of the base component, and are
+ in addition to the security interfaces (TSFI) considered in
+ the functional specification.
+
+ In summary, the TSFIs described in the functional
+ specification only include the calls made into a TSF by
+ external entities and responses to those calls. Calls made
+ by a TSF, which were not explicitly considered during
+ evaluation of the components, are described by the reliance
+ information provided to satisfy .
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. These are
+ provided in terms of a high-level description.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF
+ protects itself from interference and tampering by the
+ base component describes the method of use for each
+ interface.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. This is
+ provided in terms of the interfaces between the
+ dependent and base component and the return values from
+ those interfaces called by the dependent component.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component implementation representation;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe each interaction in
+ terms of the interface used and the return values from those
+ interfaces.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see Annex in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The reliance information shall describe each interaction
+ in terms of the interface used and the return values
+ from those interfaces.
+
+ The identification of the interfaces used by the
+ dependent component TSF when making services requests of
+ the base component allows an integrator to determine
+ whether the base component provides all the necessary
+ corresponding interfaces. This understanding is further
+ gained through the specification of the return values
+ expected by the dependent component. The evaluator
+ ensures that interfaces are described for each
+ interaction specified (as analysed in ).
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF
+ protects itself from interference and tampering by the
+ base component describes the method of use for each
+ interface.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ This family requires that testing of composed TOE and
+ testing of the base component, as used in the composed TOE,
+ is performed.
+
+
+
+ The family details
+ requirements for testing to demonstrate that the composed
+ TOE operates as specified in the composed TOE SFRs and the
+ base component interfaces match the design descriptions as
+ provided in the development information (). Testing evidence is to be provided of all
+ SFRs specified in the composed TOE ST and to exercise all
+ base component interfaces used by the dependent component,
+ as identified in .
+
+
+
+ The components in this family are levelled on the basis of
+ increasing rigour of interface testing and increasing rigour
+ of the analysis of the sufficiency of the tests to
+ demonstrate that the composed TSF operates in accordance
+ with the reliance information and the composed TOE
+ SFRs.
+
+
+
+ There are two distinct aspects of testing associated with
+ this family:
+
+
+ testing of the interfaces between the base component and
+ the dependent component, which the dependent component
+ rely upon for enforcement of security functionality, to
+ demonstrate their compatibility;
+
+
+ testing of the composed TOE to demonstrate that the TOE
+ behaves in accordance with the SFRs for the composed
+ TOE.
+
+
+
+ If the test configurations used during evaluation of the
+ dependent component included use of the base component as a
+ ``platform'' and the test analysis sufficiently demonstrates
+ that the TSF behaves in accordance with the SFRs, the
+ developer need perform no further testing of the composed
+ TOE functionality. However, if the base component was not
+ used in the testing of the dependent component, or the
+ configuration of either component varied, then the developer
+ is to perform testing of the composed TOE. This may take
+ the form of repeating the dependent component developer
+ testing of the dependent component, provided this adequately
+ demonstrates the composed TOE TSF behaves in accordance with
+ the SFRs.
+
+ The developer is to provide evidence of testing the base
+ component interfaces used in the composition. The operation
+ of base component TSFIs would have been tested as part of
+ the activities during
+ evaluation of the base component. Therefore, provided the
+ appropriate interfaces were included within the test sample
+ of the base component evaluation and it was determined in
+ that the base component is
+ operating in accordance with the base component evaluated
+ configuration, with all security functionality required by
+ the dependent component included in the TSF, the evaluator
+ action may be met
+ through reuse of the base component verdicts.
+
+ If this is not the case, the base component interfaces used
+ relevant to the composition that are affected by any
+ variations to the evaluated configuration and any additional
+ security functionally will be tested to ensure they
+ demonstrate the expected behaviour. The expected behaviour
+ to be tested is that described in the reliance information
+ ( evidence).
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to ensure the expected behaviour of all composed TOE SFRs
+ and interfaces of the base component relied upon by the
+ dependent component is demonstrated.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the SFRs specified
+ for the composed TOE to identify which SFRs have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the interfaces of
+ the base component relied upon by the dependent
+ component (as specified in the reliance information,
+ examined under ) to
+ identify which base component interfaces have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The tests are to be selected and executed in accordance
+ with , to
+ demonstrate the correct behaviour of the SFRs specified
+ in the composed TOE security target.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing, in accordance with
+ , for a subset of
+ the SFRs specified in the composed TOE security target
+ to operate as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to fully demonstrate the expected behaviour of the
+ composed TOE and the interfaces of the base component
+ relied upon by the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified and is complete.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified and is complete.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the composed TOE and the composed TOE
+ SFRs in the composed TOE security target.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and SFRs presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the base component interfaces relied upon
+ by the dependent component and the interfaces specified
+ in the reliance information.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and interfaces presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The tests are to be selected and executed in accordance
+ with , to
+ demonstrate the correct behaviour of the SFRs specified
+ in the composed TOE security target.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing, in accordance with
+ , for a subset of
+ the SFRs specified in the composed TOE security target
+ to operate as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+ The evaluator shall perform testing, in accordance with
+ , for a subset of the
+ interfaces to the base component to confirm they operate
+ as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the base component to test,
+ the evaluator should take into account any modifications
+ to the base component from the evaluated version or
+ configuration. In particular, the evaluator should
+ consider the development of tests to demonstrate the
+ correct behaviour of interfaces of the base component
+ that were not considered during the evaluation of the
+ base component. These additional interfaces and other
+ modifications to the base component will have been
+ identified during the
+ activity.
+
+
+
+
+
+
+
+ This family calls for an analysis of vulnerability
+ information available in the public domain and of
+ vulnerabilities that may be introduced as a result of the
+ composition.
+
+
+
+ The vulnerability analysis in includes determination of two different
+ aspects of resistance by the composed TOE, namely:
+
+
+ Residual vulnerabilities in the base and dependent
+ components remain unexploitable in the operational
+ environment of the composed TOE;
+
+ The composed TOE is resistant to attackers with a given
+ level of attack potential.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing scrutiny of vulnerability information from the
+ public domain and independent vulnerability analysis.
+
+
+
+ The developer will provide details of any residual
+ vulnerabilities reported during evaluation of the
+ components. These may be gained from the component
+ developers or evaluation reports for the components. These
+ will be used as inputs into the evaluator's vulnerability
+ analysis of the composed TOE in the operational
+ environment.
+
+
+ The operational environment of the composed TOE is examined
+ to ensure that the assumptions and objectives for the
+ component operational environment (specified in each
+ component ST) are satisfied in the composed TOE. An initial
+ analysis of the consistency of assumptions and objectives
+ between the components and the composed TOE STs will have
+ been performed during the conduct of the activities for the composed TOE. However, this
+ analysis is revisited with the knowledge acquired during the
+ , and the
+ activities to ensure that, for example, assumptions of the
+ dependent component that were addressed by the environment
+ in the dependent component ST are not reintroduced as a
+ result of composition (i.e. that the base component
+ adequately addresses the assumptions of the dependent
+ component ST in the composed TOE).
+
+ A search by the evaluator for issues in each component will
+ identify potential vulnerabilities reported in the public
+ domain since completion of the evaluation of the components.
+ Any potential vulnerabilities will then be subject to
+ testing.
+
+ If the base component used in the composed TOE has been the
+ subject of assurance continuity activities since
+ certification, the evaluator will consider during the
+ composed TOE vulnerability analysis activities the changes
+ made in base component.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ easily exploitable vulnerabilities.
+
+ The developer provides details of any residual
+ vulnerabilities reported from evaluation of the
+ components. The evaluator performs an analysis of the
+ disposition the residual vulnerabilities reported and also
+ performs a search of the public domain, to identify any
+ new potential vulnerabilities in the components
+ (i.e. those issues that have been reported in the public
+ domain since evaluation of the base component). The
+ evaluator then performs penetration testing to demonstrate
+ that the potential vulnerabilities cannot be exploited in
+ the TOE, in its operational environment, by an attacker
+ with basic attack potential.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities;
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes a component from the
+ family, then the
+ evaluator may refer to the result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the base component
+ that have become known since the completion of
+ evaluation of the base component.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the
+ dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (i.e. ), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing basic
+ attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the evaluation
+ of the components). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the base component
+ that have become known since the completion of the base
+ component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the
+ dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components of the composed TOE
+ in the independent evaluator vulnerability analysis will
+ take a slightly different form to that documented in
+ for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the components, but the evidence may
+ not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the individual
+ components. The focus of the vulnerability analysis
+ during the composed TOE evaluation is to identify any
+ vulnerabilities introduced as a result of the
+ integration of the components or due to any changes in
+ the use of the components between the evaluated
+ component configuration to the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ development information and composition rationale for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact and
+ identify potential vulnerabilities that may be
+ introduced as a result of this interaction.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch(es) in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report) will be the main source of
+ input material of the change. This will be supplemented
+ by any updates to the guidance documentation resulting
+ from the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ extended-basic attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the component
+ evaluations). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the base component
+ that have become known since the completion of the base
+ component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since completion of the
+ dependent component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the
+ dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components in the independent
+ evaluator vulnerability analysis will take a slightly
+ different form to that documented in for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the base component, but the evidence
+ may not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the components. The focus
+ of the vulnerability analysis during the composed TOE
+ evaluation is to identify any vulnerabilities introduced
+ as a result of the integration of the components or due
+ to any changes in the use of the components between the
+ configuration of the component determined during the
+ component evaluation and the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ composition rationale and development information for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report). This will be supplemented by
+ any updates to the guidance documentation resulting from
+ the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ extended-basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The requirements of the Development class provide information
+ about the TOE. The knowledge obtained by this information is
+ used as the basis for conducting vulnerability analysis and
+ testing upon the TOE, as described in the and classes.
+
+ The Development class encompasses six families of requirements
+ for structuring and representing the TSF at various levels and
+ varying forms of abstraction. These families include:
+
+ requirements for the description (at the various
+ levels of abstraction) of the design and implementation of
+ the SFRs (, , )
+ requirements for the description of the
+ architecture-oriented features of domain separation, TSF
+ self-protection and non-bypassability of the security
+ functionality ()
+ requirements for a security policy model and for correspondence
+ mappings between security policy model and the functional
+ specification ()
+ requirements on the internal structure of the TSF,
+ which covers aspects such as modularity, layering, and
+ minimisation of complexity ()
+
+ When documenting the security functionality of a TOE, there
+ are two properties that need to be demonstrated. The first
+ property is that the security functionality works correctly;
+ that is, it performs as specified. The second property, and
+ one that is arguably harder to demonstrate, is that the TOE
+ cannot be used in a way such that the security functionality
+ can be corrupted or bypassed. These two properties require
+ somewhat different approaches in analysis, and so the families
+ in are structured to support these
+ different approaches. The families , , , and deal with the first property: the specification
+ of the security functionality. The families and deal with
+ the second property: the specification of the design of the
+ TOE demonstrating the security functionality cannot be
+ corrupted or bypassed. It should be noted that both properties
+ need to be realised: the more confidence one has that the
+ properties are satisfied, the more trustworthy the TOE is. The
+ components in the families are designed so that more assurance
+ can be gained as the components hierarchically
+ increase.
+
+ The paradigm for the families targeted at the first property
+ is one of design decomposition. At the highest level, there is
+ a functional specification of the TSF in terms of its
+ interfaces (describing what the TSF does in
+ terms of requests to the TSF for services and resulting
+ responses), decomposing the TSF into smaller units (dependent
+ on the assurance desired and the complexity of the TOE) and
+ describing how the TSF accomplishes its
+ functions (to a level of detail commensurate with the
+ assurance level), and showing the implementation of the TSF. A
+ formal model of the security behaviour also may be given. All
+ levels of decomposition are used in determining the
+ completeness and accuracy of all other levels, ensuring that
+ the levels are mutually supportive. The requirements for the
+ various TSF representations are separated into different
+ families, to allow the PP/ST author to specify which TSF
+ representations are required. The level chosen will dictate
+ the assurance desired/gained.
+
+ Figure indicates the
+ relationships among the various TSF representations of the
+ class, as well as their
+ relationships with other classes. As the figure indicates, the
+ and
+ classes define the requirements for the correspondence between
+ the SFRs and the security objectives for the TOE. Class also defines requirements for the
+ correspondence between both the security objectives and SFRs,
+ and for the TOE summary specification which explains how the
+ TOE meets its SFRs. The activities of include the verification that the TSF that is
+ tested under the and classes is in fact the one described by all of the
+ decomposition levels.
+
+
+ The requirements for all other correspondence shown in Figure
+ are defined in the
+ class. The family defines the requirements for formally
+ modelling selected SFRs, and providing correspondence between
+ the functional specification and the formal model. Each
+ assurance family specific to a TSF representation (i.e., ,
+ and ) defines requirements
+ relating that TSF representation to the SFRs. All
+ decompositions must accurately reflect all other
+ decompositions (i.e., be mutually supportive); the developer
+ supplies the tracings in the last .C elements of the
+ components. Assurance relating to this factor is obtained
+ during the analysis for each of the levels of decomposition by
+ referring to other levels of decomposition (in a recursive
+ fashion) while the analysis of a particular level of
+ decomposition is being performed; the evaluator verifies the
+ correspondence as part of the second E element. The
+ understanding gained from these levels of decomposition form
+ the basis of the functional and penetration testing
+ efforts.
+
+ The family is not represented
+ in this figure, as it is related to the internal structure of
+ the TSF, and is only indirectly related to the process of
+ refinement of the TSF representations. Similarly, the family is not represented in the
+ figure because it relates to the architectural soundness,
+ rather than representation, of the TSF. Both and
+ relate to the analysis of the property that the TOE cannot be
+ made to circumvent or corrupt its security
+ functionality.
+
+ The TOE security functionality (TSF) consists of all parts of
+ the TOE that have to be relied upon for enforcement of the
+ SFRs. The TSF includes both functionality that directly
+ enforces the SFRs, as well as functionality that, while not
+ directly enforcing the SFRs, contributes to their enforcement
+ in a more indirect manner, including functionality with the
+ capability to cause the SFRs to be violated. This includes
+ portions of the TOE that are invoked on start-up that are
+ responsible for putting the TSF into its initial secure
+ state.
+
+ Several important concepts were used in the development of the
+ components of the families. These
+ concepts, while introduced briefly here, are explained more
+ fully in the application notes for the families.
+
+ One over-riding notion is that, as more information becomes
+ available, greater assurance can be obtained that the security
+ functionality 1) is correctly implemented; 2) cannot be
+ corrupted; and 3) cannot be bypassed. This is done through the
+ verification that the documentation is correct and consistent
+ with other documentation, and by providing information that
+ can be used to ensure that the testing activities (both
+ functional and penetration testing) are comprehensive. This is
+ reflected in the levelling of the components of the
+ families. In general, components are levelled based on the
+ amount of information that is to be provided (and subsequently
+ analysed).
+
+ While not true for all TOEs, it is generally the case that the
+ TSF is sufficiently complex that there are portions of the TSF
+ that deserve more intense examination than other portions of
+ the TSF. Determining those portions is unfortunately somewhat
+ subjective, thus terminology and components have been defined
+ such that as the level of assurance increases, the
+ responsibility for determining what portions of the TSF need
+ to be examined in detail shifts from the developer to the
+ evaluator. To aid in expressing this concept, the following
+ terminology is introduced. It should be noted that in the
+ families of the class, this terminology is used when
+ expressing SFR-related portions of the TOE (that is, elements
+ and work units embodied in the , , and families). While the general
+ concept (that some portions of the TOE are more
+ interesting than others) applies to other
+ families, the criteria are expressed differently in order to
+ obtain the assurance required.
+
+ All portions of the TSF are security
+ relevant, meaning that they must preserve the
+ security of the TOE as expressed by the SFRs and
+ requirements for domain separation and
+ non-bypassability. One aspect of security relevance is the
+ degree to which a portion of the TSF enforces a security
+ requirement. Since different portions of the TOE play
+ different roles (or no apparent role at all) in enforcing
+ security requirements, this creates a continuum of SFR
+ relevance: at one end of this continuum are portions of the
+ TOE that are termed SFR-enforcing. Such
+ portions play a direct role in implementing any SFR on the
+ TOE. Such SFRs refer to any functionality provided by one of
+ the SFRs contained in the ST. It should be noted that the
+ definition of plays a role in for
+ SFR-enforcing functionality is impossible to express
+ quantitatively. For example, in the implementation of a
+ Discretionary Access Control (DAC) mechanism, a very narrow
+ view of SFR-enforcing might be the several
+ lines of code that actually perform the check of a subject's
+ attributes against the object's attributes. A broader view
+ would include the software entity (e.g., C function) that
+ contained the several lines of code. A broader view still
+ would include callers of the C function, since they would be
+ responsible for enforcing the decision returned by the
+ attribute check. A still broader view would include any code
+ in the call tree (or programming equivalent for the
+ implementation language used) for that C function (e.g., a
+ sort function that sorted access control list entries in a
+ first-match algorithm implementation). At some point, the
+ component is not so much enforcing the
+ security policy but rather plays a
+ supporting role; such components are termed
+ SFR supporting.
+
+ One of the characteristics of SFR-supporting functionality is
+ that it is trusted to preserve the correctness of the SFR
+ implementation by operating without error. Such functionality
+ may be depended on by SFR-enforcing functionality, but the
+ dependence is generally at a functional level; for example,
+ memory management, buffer management, etc. Further down on the
+ security relevance continuum is functionality termed
+ SFR non-interfering. Such functionality has
+ no role in implementing the SFRs, and is likely part of the
+ TSF because of its environment; for example, any code running
+ in a privileged hardware mode on an operating system. It needs
+ to be considered part of the TSF because, if compromised (or
+ replaced by malicious code), it could compromise the correct
+ operation of an SFR by virtue of its operating in the
+ privileged hardware mode. An example of SFR non-interfering
+ functionality might be a set of mathematical floating point
+ operations implemented in kernel mode for speed
+ considerations.
+
+ The architecture family ()
+ provides for requirements and analysis of the TOE based on
+ properties of TSF trusted initialisation, self-protection, and
+ non-bypassability. These properties relate to the SFRs in
+ that, if these properties are not present, it will likely lead
+ to the failure of mechanisms implementing SFRs. Functionality
+ and design relating to these properties is
+ not considered a part of the continuum described
+ above, but instead is treated separately due to its
+ fundamentally different nature and analysis
+ requirements.
+
+ The difference in analysis of the implementation of SFRs
+ (SFR-enforcing and SFR-supporting functionality) and the
+ implementation of somewhat fundamental security properties of
+ the TOE, which include the initialisation, self-protection,
+ and non-bypassability concerns, is that the SFR-related
+ functionality is more or less directly visible and relatively
+ easy to test, while the above-mentioned properties require
+ varying degrees of analysis on a much broader set of
+ functionality. Further, the depth of analysis for such
+ properties will vary depending on the design of the TOE. The
+ families are constructed to address
+ this by a separate family ()
+ devoted to analysis of the initialisation, self-protection,
+ and non-bypassability requirements, while the other families
+ are concerned with analysis of the functionality supporting
+ SFRs.
+
+ Even in cases where different descriptions are necessary for
+ the multiple levels of abstraction, it is not absolutely
+ necessary for each and every TSF representation to be in a
+ separate document. Indeed, it may be the case that a single
+ document meets the documentation requirements for more than
+ one TSF representation, since it is the information about each
+ of these TSF representations that is required, rather than the
+ resulting document structure. In cases where multiple TSF
+ representations are combined within a single document, the
+ developer should indicate which portions of the documents meet
+ which requirements.
+
+ Three types of specification style are mandated by this class:
+ informal, semiformal and formal. The functional specification
+ and TOE design documentation are always written in either
+ informal or semiformal style. A semiformal style reduces the
+ ambiguity in these documents over an informal presentation. A
+ formal specification may also be required in addition
+ to the semi-formal presentation; the value is that a
+ description of the TSF in more than one way will add increased
+ assurance that the TSF has been completely and accurately
+ specified.
+
+ An informal specification is written as prose in natural
+ language. Natural language is used here as meaning
+ communication in any commonly spoken tongue (e.g. Spanish,
+ German, French, English, Dutch). An informal specification is
+ not subject to any notational or special restrictions other
+ than those required as ordinary conventions for that language
+ (e.g. grammar and syntax). While no notational restrictions
+ apply, the informal specification is also required to provide
+ defined meanings for terms that are used in a context other
+ than that accepted by normal usage.
+
+ The difference between semiformal and informal documents is
+ only a matter of formatting or presentation: a semiformal
+ notation includes such things as an explicit glossary of
+ terms, a standardised presentation format, etc. A semiformal
+ specification is written to a standard presentation
+ template. The presentation should use terms consistently if
+ written in a natural language. The presentation may also use
+ more structured languages/diagrams (e.g. data-flow diagrams,
+ state transition diagrams, entity-relationship diagrams, data
+ structure diagrams, and process or program structure
+ diagrams). Whether based on diagrams or natural language, a
+ set of conventions must be used in the presentation. The
+ glossary explicitly identifies the words that are being used
+ in a precise and constant manner; similarly, the standardised
+ format implies that extreme care has been taken in
+ methodically preparing the document in a manner that maximises
+ clarity. It should be noted that fundamentally different
+ portions of the TSF may have different semiformal notation
+ conventions and presentation styles (as long as the number of
+ different ``semiformal notations'' is small); this still
+ conforms to the concept of a semiformal
+ presentation.
+
+ A formal specification is written in a notation based upon
+ well-established mathematical concepts, and is typically
+ accompanied by supporting explanatory (informal) prose. These
+ mathematical concepts are used to define the syntax and
+ semantics of the notation and the proof rules that support
+ logical reasoning. The syntactic and semantic rules supporting
+ a formal notation should define how to recognise constructs
+ unambiguously and determine their meaning. There needs to be
+ evidence that it is impossible to derive contradictions, and
+ all rules supporting the notation need to be defined or
+ referenced.
+
+
+
+ The purpose of the Development class is to provide evidence
+ about the TOE. Without the knowledge about the TOE that is
+ gained from this information, there could be no useful
+ vulnerability analysis or testing conducted upon the TOE (as
+ described in the and classes).
+
+
+ The purpose of the development activity is to assess the
+ design documentation in terms of its adequacy to understand
+ how the TSF meets the SFRs and how the implementation of these
+ SFRs cannot be tampered with or bypassed. This understanding
+ is achieved through examination of increasingly refined
+ descriptions of the TSF design documentation. Design
+ documentation consists of a functional specification (which
+ describes the interfaces of the TSF), a TOE design description
+ (which describes the architecture of the TSF in terms of how
+ it works in order to perform the functions related to the SFRs
+ being claimed), and an implementation description (a source
+ code level description). In addition, there is a security
+ architecture description (which describes the architectural
+ properties of the TSF to explain how its security enforcement
+ cannot be compromised or bypassed), an internals description
+ (which describes how the TSF was constructed in a manner that
+ encourages understandability), and a security policy model
+ (which formally describes the security policies enforced by
+ the TSF).
+
+
+
+ The CC requirements for design documentation are levelled by
+ the amount, and detail of information provided, and the degree
+ of formality of the presentation of the information. At lower
+ levels, the most security-critical portions of the TSF are
+ described with the most detail, while less security-critical
+ portions of the TSF are merely summarised; added assurance is
+ gained by increasing the amount of information about the most
+ security-critical portions of the TSF, and increasing the
+ details about the less security-critical portions. The most
+ assurance is achieved when thorough details and information of
+ all portions are provided.
+
+ The CC considers a document's degree of formality (that is,
+ whether it is informal or semiformal) to be hierarchical. An
+ informal document is one that is expressed in a natural
+ language. The methodology does not dictate the specific
+ language that must be used; that issue is left for the
+ scheme. The following paragraphs differentiate the contents of
+ the different informal documents.
+
+ A functional specification provides a description of the
+ purpose and method-of-use of interfaces to the TSF. For
+ example, if an operating system presents the user with a means
+ of self-identification, of creating files, of modifying or
+ deleting files, of setting permissions defining what other
+ users may access files, and of communicating with remote
+ machines, its functional specification would contain
+ descriptions of each of these and how they are realised
+ through interactions with the externally-visible interfaces to
+ the TSF. If there is also audit functionality that detects and
+ record the occurrences of such events, descriptions of this
+ audit functionality would also be expected to be part of the
+ functional specification; while this functionality is
+ technically not directly invoked by the user at the external
+ interface, it certainly is affected by what occurs at the
+ user's external interface.
+
+ A design description is expressed in terms of logical
+ divisions (subsystems or components) that each provide a
+ comprehensible service or function. For example, a firewall
+ might be composed of subsystems that deal with packet
+ filtering, with remote administration, with auditing, and with
+ connection-level filtering. The design description of the
+ firewall would describe the actions that are taken, in terms
+ of what actions each subsystem takes when an incoming packet
+ arrives at the firewall.
+
+
+
+
+ The objective of this family is for the developer to provide
+ a description of the security architecture of the TSF. This
+ will allow analysis of the information that, when coupled
+ with the other evidence presented for the TSF, will confirm
+ the TSF achieves the desired properties. The security
+ architecture descriptions supports the implicit claim that
+ security analysis of the TOE can be achieved by examining
+ the TSF; without a sound architecture, the entire TOE
+ functionality would have to be examined.
+
+
+
+ The information presented for the security architecture of
+ the TOE is related to the information contained in other
+ decomposition documentation (functional specification and
+ TOE design documentation) provided for the TSF, but presents
+ the design in a manner that supports architectural arguments
+ (e.g., the TSF cannot be compromised; the TSF provides
+ security domains consistent with its SFRs; the TSF cannot be
+ bypassed).
+
+
+
+ This family contains only one component.
+
+
+
+ The properties of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed by Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the TSF
+ that are achieved through the design of the TOE and TSF, and
+ enforced by the correct implementation of that
+ design.
+
+ The approach used in this family is for the developer to
+ design and provide a TSF that exhibits the above-mentioned
+ properties, and to provide evidence (in the form of
+ documentation) that explains these properties of the
+ TSF. This explanation is provided at the same level of
+ detail as the description of the SFR-enforcing elements of
+ the TOE in the TOE design document. The evaluator has the
+ responsibility for looking at the evidence and, coupled with
+ other evidence delivered for the TOE and TSF, determining
+ that the properties are achieved.
+
+ Specification of security functionality implementing the
+ SFRs (in the and ) will not necessarily describe
+ mechanisms employed in implementing self-protection and
+ non-bypassability (e.g. memory management
+ mechanisms). Therefore, the material needed to provide the
+ assurance that these requirements are being achieved is
+ better suited to a presentation separate from the design
+ decomposition of the TSF as embodied in and . This is not
+ to imply that the security architecture description called
+ for by this component cannot reference or make use of the
+ design decomposition material; but it is likely that much of
+ the detail present in the decomposition documentation will
+ not be relevant to the argument being provided for the
+ security architecture description document.
+
+ The description of architectural soundness can be thought of
+ as a developer's vulnerability analysis, in that it provides
+ the justification for why the TSF is sound and enforces all
+ of its SFRs. Where the soundness is achieved through
+ specific security mechanisms, these will be tested as part
+ of the requirements; where
+ the soundness is achieved solely through the architecture,
+ the behaviour will be tested as part of the requirements.
+
+ This family consists of requirements for a security
+ architecture description that describes the self-protection,
+ domain separation, non-bypassability principles, including a
+ description of how these principles are supported by the
+ parts of the TOE that are used for TSF
+ initialisation.
+ Additional information on the security architecture
+ properties of self-protection, domain separation, and
+ non-bypassability can be found in Annex .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is structured such that it cannot be tampered with
+ or bypassed, and whether TSFs that provide security
+ domains isolate those domains from each other.
+
+
+
+ The notions of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed in Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the
+ TSF that are achieved through the design of the TOE, and
+ enforced by the correct implementation of that
+ design. Also, the evaluation of these properties is less
+ straight-forward than the evaluation of mechanisms; it is
+ more difficult to check for the absence of functionality
+ than for its presence. However, the determination that
+ these properties are being satisfied is just as critical
+ as the determination that the mechanisms are properly
+ implemented.
+
+ The overall approach used is that the developer provides a
+ TSF that meets the above-mentioned properties, and
+ provides evidence (in the form of documentation) that can
+ be analysed to show that the properties are indeed
+ met. The evaluator has the responsibility for looking at
+ the evidence and, coupled with other evidence delivered
+ for the TOE, determining that the properties are
+ achieved. The work units can be characterised as those
+ detailing with what information has to be provided, and
+ those dealing with the actual analysis the evaluator
+ performs.
+
+ The security architecture description describes how
+ domains are defined and how the TSF keeps them
+ separate. It describes what prevents untrusted processes
+ from getting to the TSF and modifying it. It describes
+ what ensures that all resources under the TSF's control
+ are adequately protected and that all actions related to
+ the SFRs are mediated by the TSF. It explains any role the
+ environment plays in any of these (e.g. presuming it gets
+ correctly invoked by its underlying environment, how is
+ its security functionality invoked?). In short, it
+ explains how the TOE is considered to be providing any
+ kind of security service.
+
+ The analyses the evaluator performs must be done in the
+ context of all of the development evidence provided for
+ the TOE, at the level of detail the evidence is
+ provided. At lower assurance levels there should not be
+ the expectation that, for example, TSF self-protection is
+ completely analysed, because only high-level design
+ representations will be available. The evaluator also
+ needs to be sure to use information gleaned from other
+ portions of their analysis (e.g., analysis of the TOE
+ design) in making their assessments for the properties
+ being examined in the following work units.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation (if available);
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall design and implement the TOE so that the
+ security features of the TSF cannot be bypassed.
+
+
+ The developer shall design and implement the TSF so that it
+ is able to protect itself from tampering by untrusted active
+ entities.
+
+
+ The developer shall provide a security architecture
+ description of the TSF.
+
+
+ The security architecture description shall be at a level of
+ detail commensurate with the description of the
+ SFR-enforcing abstractions described in the TOE design
+ document.
+
+
+ The security architecture description shall describe the
+ security domains maintained by the TSF consistently with the
+ SFRs.
+
+
+ The security architecture description shall describe how the
+ TSF initialisation process is secure.
+
+
+ The security architecture description shall demonstrate that
+ the TSF protects itself from tampering.
+
+
+ The security architecture description shall demonstrate that
+ the TSF prevents bypass of the SFR-enforcing functionality.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the information provided
+ in the evidence is presented at a level of detail
+ commensurate with the descriptions of the SFR-enforcing
+ abstractions contained in the functional specification
+ and TOE design document.
+
+ With respect to the functional specification, the
+ evaluator should ensure that the self-protection
+ functionality described cover those effects that are
+ evident at the TSFI. Such a description might include
+ protection placed upon the executable images of the TSF,
+ and protection placed on objects (e.g., files used by
+ the TSF). The evaluator ensures that the functionality
+ that might be invoked through the TSFI is
+ described.
+
+ If or is included, the evaluator
+ ensures the security architecture description contains
+ information on how any subsystems that contribute to TSF
+ domain separation work.
+
+ If or higher is
+ available, the evaluator ensures that the security
+ architecture description also contains
+ implementation-dependent information. For example, such
+ a description might contain information pertaining to
+ coding conventions for parameter checking that would
+ prevent TSF compromises (e.g. buffer overflows), and
+ information on stack management for call and return
+ operations. The evaluator checks the descriptions of the
+ mechanisms to ensure that the level of detail is such
+ that there is little ambiguity between the description
+ in the security architecture description and the
+ implementation representation.
+
+ This work unit fails if the security architecture
+ description mentions any module, subsystem, or interface
+ that is not described in the functional specification or
+ TOE design document.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it describes the security
+ domains maintained by the TSF.
+
+ Security domains refer to environments supplied by the
+ TSF for use by potentially-harmful entities; for
+ example, a typical secure operating system supplies a
+ set of resources (address space, per-process environment
+ variables) for use by processes with limited access
+ rights and security properties. The evaluator determines
+ that the developer's description of the security domains
+ takes into account all of the SFRs claimed by the
+ TOE.
+
+ For some TOEs such domains do not exist because all of
+ the interactions available to users are severely
+ constrained by the TSF. A packet-filter firewall is an
+ example of such a TOE. Users on the LAN or WAN do not
+ interact with the TOE, so there need be no security
+ domains; there are only data structures maintained by
+ the TSF to keep the users' packets separated. The
+ evaluator ensures that any claim that there are no
+ domains is supported by the evidence and that no such
+ domains are, in fact, available.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the initialisation process
+ preserves security.
+
+ The information provided in the security architecture
+ description relating to TSF initialisation is directed
+ at the TOE components that are involved in bringing the
+ TSF into an initial secure state (i.e. when all parts of
+ the TSF are operational) when power-on or a reset is
+ applied. This discussion in the security architecture
+ description should list the system initialisation
+ components and the processing that occurs in
+ transitioning from the ``down'' state to the initial
+ secure state.
+
+ It is often the case that the components that perform
+ this initialisation function are not accessible after
+ the secure state is achieved; if this is the case then
+ the architectural design identifies the components and
+ explains how they are not reachable by untrusted
+ entities after the TSF has been established. In this
+ respect, the property that needs to be preserved is that
+ these components either 1) cannot be accessed by
+ untrusted entities after the secure state is achieved,
+ or 2) if they provide interfaces to untrusted entities,
+ these TSFI cannot be used to tamper with the TSF.
+
+ The TOE components related to TSF initialisation, then,
+ are treated themselves as part of the TSF, and analysed
+ from that perspective. It should be noted that even
+ though these are treated as part of the TSF, it is
+ likely that a justification (as allowed by ) can be made that they do not
+ have to meet the internal structuring requirements of
+ .
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it contains information
+ sufficient to support a determination that the TSF is
+ able to protect itself from tampering by untrusted
+ active entities.
+
+ ''Self-protection'' refers to the ability of the TSF to
+ protect itself from manipulation from external entities
+ that may result in changes to the TSF. For TOEs that
+ have dependencies on other IT entities, it is often the
+ case that the TOE uses services supplied by the other IT
+ entities in order to perform its functions. In such
+ cases, the TSF alone does not protect itself because it
+ depends on the other IT entities to provide some of the
+ protection. For the purposes of the security
+ architecture description, the notion of
+ self-protection applies only to the
+ services provided by the TSF through its TSFI, and not
+ to services provided by underlying IT entities that it
+ uses.
+
+ Self-protection is typically achieved by a variety of
+ means, ranging from physical and logical restrictions on
+ access to the TOE; to hardware-based means (e.g.
+ ``execution rings'' and memory management
+ functionality); to software-based means (e.g. boundary
+ checking of inputs on a trusted server). The evaluator
+ determines that all such mechanisms are
+ described.
+
+ The evaluator determines that the design description
+ covers how user input is handled by the TSF in such a
+ way that the TSF does not subject itself to being
+ corrupted by that user input. For example, the TSF might
+ implement the notion of privilege and protect itself by
+ using privileged-mode routines to handle user data. The
+ TSF might make use of processor-based separation
+ mechanisms such as privilege levels or rings. The TSF
+ might implement software protection constructs or coding
+ conventions that contribute to implementing separation of
+ software domains, perhaps by delineating user address
+ space from system address space. And the TSF might have
+ reliance its environment to provide some support to the
+ protection of the TSF.
+
+ All of the mechanisms contributing to the domain
+ separation functions are described. The evaluator should
+ use knowledge gained from other evidence (functional
+ specification, TOE design, TSF internals description,
+ other parts of the security architecture description, or
+ implementation representation, as included in the
+ assurance package for the TOE) in determining if any
+ functionality contributing to self-protection was
+ described that is not present in the security
+ architecture description.
+
+ Accuracy of the description of the self-protection
+ mechanisms is the property that the description
+ faithfully describes what is implemented. The evaluator
+ should use other evidence (functional specification, TOE
+ design, TSF Internals documentation, other parts of the
+ security architectural description, implementation
+ representation, as included in the ST for the TOE) in
+ determining whether there are discrepancies in any
+ descriptions of the self-protection mechanisms. If is included in the assurance
+ package for the TOE, the evaluator will choose a sample
+ of the implementation representation; the evaluator
+ should also ensure that the descriptions are accurate
+ for the sample chosen. If an evaluator cannot
+ understand how a certain self-protection mechanism works
+ or could work in the system architecture, it may be the
+ case that the description is not accurate.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it presents an analysis
+ that adequately describes how the SFR-enforcing
+ mechanisms cannot be bypassed.
+
+ Non-bypassability is a property that the security
+ functionality of the TSF (as specified by the SFRs) is
+ always invoked. For example, if access control to files
+ is specified as a capability of the TSF via an SFR,
+ there must be no interfaces through which files can be
+ accessed without invoking the TSF's access control
+ mechanism (such as an interface through which a raw disk
+ access takes place).
+
+ Describing how the TSF mechanisms cannot be bypassed
+ generally requires a systematic argument based on the
+ TSF and the TSFIs. The description of how the TSF works
+ (contained in the design decomposition evidence, such as
+ the functional specification, TOE design documentation)
+ - along with the information in the TSS - provides the
+ background necessary for the evaluator to understand
+ what resources are being protected and what security
+ functions are being provided. The functional
+ specification provides descriptions of the TSFIs through
+ which the resources/functions are accessed.
+
+ The evaluator assesses the description provided (and
+ other information provided by the developer, such as the
+ functional specification) to ensure that no available
+ interface can be used to bypass the TSF. This means that
+ every available interface must be either unrelated to
+ the SFRs that are claimed in the ST (and does not
+ interact with anything that is used to satisfy SFRs) or
+ else uses the security functionality that is described
+ in other development evidence in the manner
+ described. For example, a game would likely be unrelated
+ to the SFRs, so there must be an explanation of how it
+ cannot affect security. Access to user data, however, is
+ likely to be related to access control SFRs, so the
+ explanation would describe how the security
+ functionality works when invoked through the data-access
+ interfaces. Such a description in needed for every
+ available interface.
+
+ An example of a description follows. Suppose the TSF
+ provides file protection. Further suppose that although
+ the ``traditional'' system call TSFIs for open, read,
+ and write invoke the file protection mechanism described
+ in the TOE design, there exists a TSFI that allows
+ access to a batch job facility (creating batch jobs,
+ deleting jobs, modifying unprocessed jobs). The
+ evaluator should be able to determine from the
+ vendor-provided description that this TSFI invokes the
+ same protection mechanisms as do the ``traditional''
+ interfaces. This could be done, for example, by
+ referencing the appropriate subclauses of the TOE design
+ that discuss how the batch job facility
+ TSFI achieves its security objectives.
+
+ Using this same example, suppose there is a TSFI whose
+ sole purpose is to display the time of day. The
+ evaluator should determine that the description
+ adequately argues that this TSFI is not capable of
+ manipulating any protected resources and should not
+ invoke any security functionality.
+
+ Another example of bypass is when the TSF is supposed to
+ maintain confidentiality of a cryptographic key (one is
+ allowed to use it for cryptographic operations, but is
+ not allowed to read/write it). If an attacker has direct
+ physical access to the device, he might be able to
+ examine side-channels such as the power usage of the
+ device, the exact timing of the device, or even any
+ electromagnetic emanations of the device and, from this,
+ infer the key.
+
+ If such side-channels may be present, the demonstration
+ should address the mechanisms that prevent these
+ side-channels from occurring, such as random internal
+ clocks, dual-line technology etc. Verification of these
+ mechanisms would be verified by a combination of purely
+ design-based arguments and testing.
+
+ For a final example using security functionality rather
+ than a protected resource, consider an ST that contains
+ , which requires that
+ the TSF provides evidence of origination for information
+ types specified in the ST. Suppose that the
+ ``information types'' included all information that is
+ sent by the TOE via e-mail. In this case the evaluator
+ should examine the description to ensure that all TSFI
+ that can be invoked to send e-mail perform the
+ ``evidence of origination generation'' function are
+ detailed. The description might point to user guidance
+ to show all places where e-mail can originate (e.g.,
+ e-mail program, notification from scripts/batch jobs)
+ and then how each of these places invokes the evidence
+ generation function.
+
+ The evaluator should also ensure that the description is
+ comprehensive, in that each interface is analysed with
+ respect to the entire set of claimed SFRs. This may
+ require the evaluator to examine supporting information
+ (functional specification, TOE design, other parts of
+ the security architectural description, operational user
+ guidance, and perhaps even the implementation
+ representation, as provided for the TOE) to determine
+ that the description has correctly capture all aspects
+ of an interface. The evaluator should consider what SFRs
+ each TSFI might affect (from the description of the TSFI
+ and its implementation in the supporting documentation),
+ and then examine the description to determine whether it
+ covers those aspects.
+
+
+
+
+
+
+
+ This family levies requirements upon the functional
+ specification, which describes the TSF interfaces
+ (TSFI). The TSFI consist of all means for users to invoke a
+ service from the TSF (by supplying data that is processed by
+ the TSF) and the corresponding responses to those service
+ invocations. It does not describe how the
+ TSF processes those service requests, nor does it describe
+ the communication when the TSF invokes services from its
+ operational environment; this information is addressed by
+ the and families, respectively.
+
+ This family provides assurance directly by allowing the
+ evaluator to understand how the TSF meets the claimed
+ SFRs. It also provides assurance indirectly, as input to
+ other assurance families and classes:
+ , where the
+ description of the TSFI may be used to gain better
+ understanding of how the TSF is protected against
+ corruption (i.e. subversion of self-protection or domain
+ separation) and/or bypass;
+ , where the description of
+ the TSFI is an important input for both developer and
+ evaluator testing;
+ , where the description of
+ the TSFI is used to search for
+ vulnerabilities.
+
+
+
+ The information presented in the functional specification
+ describes the interfaces through which the TSF services are
+ invoked. At the lower levels of assurance, there is an
+ effort to reduce the amount of information that must be
+ supplied by requiring only the most security-critical
+ information.
+
+
+
+ The components in this family are levelled on the degree of
+ detail required of the description of the TSFI, and the
+ degree of formalism required of the description of the
+ TSFI.
+
+
+
+ Once the TSFIs are determined (see for guidance and
+ examples of determining TSFI), they are described. At
+ lower-level components, developers focus their documentation
+ (and evaluators focus their analysis) on the more
+ security-relevant aspects of the TOE. Three categories of
+ TSFIs are defined, based upon the relevance the services
+ available through them have to the SFRs being claimed:
+ If a service available through an interface can be
+ traced to one of the SFRs levied on the TSF, then that
+ interface is termed SFR-enforcing.
+ Note that it is possible that an interface may have
+ various services and results, some of which may be
+ SFR-enforcing and some of which may not.
+ interfaces to (or services available through an
+ interface relating to) services that SFR-enforcing
+ functionality depends upon, but need only to function
+ correctly in order for the security policies of the TOE
+ to be preserved, are termed
+ SFR-supporting.
+ Interfaces to services on which SFR-enforcing
+ functionality has no dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR-supporting or SFR non-interfering it must have
+ no SFR-enforcing services or results. In
+ contrast, an SFR-enforcing interface may have SFR-supporting
+ services (for example, the ability to set the system clock
+ may be an SFR-enforcing service of an interface, but if that
+ same interface is used to display the system date that
+ service may be only SFR-supporting). An example of a purely
+ SFR-supporting interface is a system call interface that is
+ used both by users and by a portion of the TSF that is
+ running on behalf of users.
+
+ As more information about the TSFI becomes available, the
+ greater the assurance that can be gained that the interfaces
+ are correctly categorised/analysed. The requirements are
+ structured such that, at the lowest level, the information
+ required for SFR non-interfering interfaces is the minimum
+ necessary in order for the evaluator to make this
+ determination in an effective manner. At higher levels, more
+ information becomes available so that the evaluator has
+ greater confidence in the designation.
+
+ The purpose in defining these labels (SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering) and for levying
+ different requirements upon each (at the lower assurance
+ components) is to provide a first approximation of where to
+ focus the analysis and the evidence upon which that analysis
+ is performed. If the developer's documentation of the TSF
+ interfaces describes all of the interfaces to the degree
+ specified in the requirements for the SFR-enforcing
+ interfaces (that is, if the documentation exceeds the
+ requirements), there is no need for the developer to create
+ new evidence to match the requirements. Similarly, because
+ the labels are merely a means of differentiating the
+ interface types within the requirements, there is no need
+ for the developer to update the evidence solely to label the
+ interfaces as SFR-enforcing, SFR-supporting, and
+ SFR-non-interfering. The primary purpose of this labelling
+ is to allow developers with less mature development
+ methodologies (and associated artifacts, such as detailed
+ interface and design documentation) to provide only the
+ necessary evidence without undue cost.
+
+ The last C element of each component within this family
+ provides a direct correspondence between the SFRs and the
+ functional specification; that is, an indication of which
+ interfaces are used to invoke each of the claimed SFRs. In
+ the cases where the ST contains such functional requirements
+ as , whose functionality may
+ not manifest itself at the TSFI, the functional
+ specification and/or the tracing is expected to identify
+ these SFRs; including them in he functional specification
+ helps to ensure that they are not lost at lower levels of
+ decomposition, where they will be relevant.
+
+
+ The requirements define collections of details about TSFI
+ to be provided. For the purposes of the requirements,
+ interfaces are specified (in varying degrees of detail) in
+ terms of their purpose, method of use, parameters,
+ parameter descriptions, and error messages.
+
+ The purpose of an interface is a
+ high-level description of the general goal of the
+ interface (e.g. process GUI commands, receive network
+ packets, provide printer output, etc.)
+
+ The interface's method of use describes
+ how the interface is supposed to be used. This description
+ should be built around the various interactions available
+ at that interface. For instance, if the interface were a Unix
+ command shell, ls, mv
+ and cp would be interactions for that
+ interface. For each interaction the method of use
+ describes what the interaction does, both for behaviour
+ seen at the interface (e.g. the programmer calling the
+ API, the Windows users changing a setting in the registry,
+ etc.) as well as behaviour at other interfaces
+ (e.g. generating an audit record).
+
+ Parameters are explicit inputs to and
+ outputs from an interface that control the behaviour of
+ that interface. For example, parameters are the arguments
+ supplied to an API; the various fields in a packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; the flags that can be set for the
+ ls, etc. The parameters are
+ ``identified'' with a simple list of what they are.
+
+ A parameter description tells what the
+ parameter is in some meaningful way. For instance, an
+ acceptable parameter description for interface
+ foo(i) would be ``parameter i is an
+ integer that indicates the number of users currently
+ logged in to the system''. A description such as
+ ``parameter i is an integer'' is not an acceptable.
+
+ The description of an interface's actions
+ describes what the interface does. This is more detailed
+ than the purpose in that, while the ``purpose'' reveals
+ why one might want to use it, the ``actions'' reveals
+ everything that it does. These actions might be related to
+ the SFRs or not. In cases where the interface's action is
+ not related to SFRs, its description is said to be
+ summarised, meaning the description
+ merely makes clear that it is indeed not SFR-related.
+
+ The error message description identifies
+ the condition that generated it, what the message is, and
+ the meaning of any error codes. An error message is
+ generated by the TSF to signify that a problem or
+ irregularity of some degree has been encountered. The
+ requirements in this family refer to different kinds of
+ error messages:
+ a ``direct'' error message is a security-relevant
+ response that can be tied to a specific TSFI
+ invocation.
+ an ``indirect'' error cannot be tied to a
+ specific TSFI invocation because it results from
+ system-wide conditions (e.g. resource exhaustion,
+ connectivity interruptions, etc.). Error messages that
+ are not security-relevant are also considered
+ ``indirect''.
+ ``remaining'' errors are any other errors, such
+ as those that might be referenced within the code. For
+ example, the use of condition-checking code that
+ checks for conditions that would not logically occur
+ (e.g. a final ``else'' after a list of ``case''
+ statements), would provide for generating a catch-all
+ error message); in an operational TOE, these error
+ messages should never be seen.
+
+ An example functional specification is provided in .
+
+
+
+ Increasing assurance through increased completeness and
+ accuracy in the interface specification is reflected in
+ the documentation required from the developer as detailed
+ in the various hierarchical components of this
+ family.
+
+ At , the only
+ documentation required is a characterisation of all TSFI
+ and a high level description of SFR-enforcing and
+ SFR-supporting TSFI. To provide some assurance that the
+ ``important'' aspects of the TSF have been correctly
+ characterised at the TSFI, the developer is required to
+ provide the purpose and method of use, parameters and
+ parameter descriptions for the SFR-enforcing and
+ SFR-supporting TSFI.
+
+ At , the developer is
+ required to provide the purpose, method of use,
+ parameters, and parameter descriptions for all
+ TSFI. Additionally, for the SFR-enforcing TSFI the
+ developer has to describe the SFR-enforcing actions and
+ direct messages.
+
+ At , the developer must
+ now, in addition to the information required at , provide enough information
+ about the SFR-supporting and SFR-non-interfering actions
+ and error messages to show that they are not
+ SFR-enforcing. Further, the developer must now document
+ all of the direct error messages resulting from the
+ invocation of SFR-enforcing TSFI.
+
+ At , all TSFI - whether
+ SFR-enforcing, SFR-supporting, SFR-non-interfering - must
+ be described to the same degree, including all of the
+ direct error messages.
+
+ At , the TSFI
+ descriptions also include indirect error messages.
+
+ At , in addition to the
+ information required by ,
+ all remaining error messages are included. The developer
+ must also provide a formal description of the TSFI. This
+ provides an alternative view of the TSFI that may expose
+ inconsistencies or incomplete specification.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a high-level description of at
+ least the SFR-enforcing and SFR-supporting TSFI, in terms
+ of descriptions of their parameters. There is no other
+ required evidence that can be expected to be available to
+ measure the accuracy of these descriptions; the evaluator
+ merely ensures the descriptions seem plausible.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall describe the purpose and
+ method of use for each SFR-enforcing and SFR-supporting
+ TSFI.
+
+
+ The functional specification shall identify all parameters
+ associated with each SFR-enforcing and SFR-supporting TSFI.
+
+
+ The functional specification shall provide rationale for the
+ implicit categorisation of interfaces as
+ SFR-non-interfering.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ SFR-supporting and SFR-enforcing TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of the parameters; this can be done in
+ association with other work units for this
+ component.
+
+ If an action available through an interface can be
+ traced to one of the SFRs levied on the TSF), then that
+ interface is SFR-enforcing. Such
+ policies are not limited to the access control policies,
+ but also refer to any functionality specified by one of
+ the SFRs contained in the ST. Note that it is possible
+ that an interface may have various actions and results,
+ some of which may be SFR-enforcing and some of which may
+ not.
+
+ Interfaces to (or actions available through an interface
+ relating to) actions that SFR-enforcing functionality
+ depends on, but need only to function correctly in order
+ for the security policies of the TOE to be preserved,
+ are termed SFR supporting. Interfaces
+ to actions on which SFR-enforcing functionality has no
+ dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR supporting or SFR non-interfering it must have
+ no SFR-enforcing actions or results. In
+ contrast, an SFR-enforcing interface may have
+ SFR-supporting actions (for example, the ability to set
+ the system clock may be an SFR-enforcing action of an
+ interface, but if that same interface is used to display
+ the system date that action may only be SFR
+ supporting). An example of a purely SFR-supporting
+ interface is a system call interface that is used both
+ by untrusted users and by a portion of the TSF that is
+ running in user mode.
+
+ At this level, it is unlikely that a developer will have
+ expended effort to label interfaces as SFR-enforcing and
+ SFR-supporting. In the case that this has been done,
+ the evaluator should verify to the extent that
+ supporting documentation (e.g., operational user
+ guidance) allows that this identification is correct.
+ Note that this identification activity is necessary for
+ several work units for this component.
+
+ In the more likely case that the developer has not
+ labelled the interfaces, the evaluator must perform
+ their own identification of the interfaces first, and
+ then determine whether the required information (for
+ this work unit, the purpose) is present. Again, because
+ of the lack of supporting evidence this identification
+ will be difficult and have low assurance that all
+ appropriate interfaces have been correctly identified,
+ but nonetheless the evaluator examines other evidence
+ available for the TOE to ensure as complete coverage as
+ is possible.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each
+ SFR-supporting and SFR-enforcing TSFI is given.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is
+ documented as being inaccessible to untrusted users, the
+ evaluator ensures that the method of making the
+ functions inaccessible is described in the functional
+ specification. It should be noted that this
+ inaccessibility should be tested by the developer in
+ their test suite.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it identifies all parameters
+ associated with each SFR-enforcing and SFR-supporting
+ TSFI.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for
+ identified TSFI. Parameters are explicit inputs or
+ outputs to an interface that control the behaviour of
+ that interface. For examples, parameters are the
+ arguments supplied to an API; the various fields in
+ packet for a given network protocol; the individual key
+ values in the Windows Registry; the signals across a set
+ of pins on a chip; etc.
+
+ While difficult to obtain much assurance that all
+ parameters for the applicable TSFI have been identified,
+ the evaluator should also check other evidence provided
+ for the evaluation (e.g., operational user guidance) to
+ see if behaviour or additional parameters are described
+ there but not in the functional specification.
+
+
+
+
+ The evaluator shall examine the rationale provided by
+ the developer for the implicit categorisation of
+ interfaces as SFR-non-interfering to determine that it
+ is accurate.
+
+ In the case where the developer has provided adequate
+ documentation to perform the analysis called for by the
+ rest of the work units for this component without
+ explicitly identifying SFR-enforcing and SFR-supporting
+ interfaces, this work unit should be considered
+ satisfied.
+
+ This work unit is intended to apply to cases where the
+ developer has not described a portion of the TSFI,
+ claiming that it is SFR-non-interfering and therefore
+ not subject to other requirements of this component. In
+ such a case, the developer provides a rationale for this
+ characterisation in sufficient detail such that the
+ evaluator understands the rationale, the characteristics
+ of the interfaces affected (e.g., their high-level
+ function with respect to the TOE, such as ``colour
+ palette manipulation''), and that the claim that these
+ are SFR-non-interfering is supported. Given the level
+ of assurance the evaluator should not expect more detail
+ than is provided for the non-SFR-non-interfering
+ interfaces, and in fact the detail should be much less.
+ In most cases, individual interfaces should not need to
+ be addressed in the developer-provided rationale
+ subclause.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functionality
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the SFR-enforcing actions, results and error
+ messages of each TSFI that is SFR-enforcing are also
+ described.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For SFR-enforcing TSFIs, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For SFR-enforcing TSFIs, the functional specification shall
+ describe direct error messages resulting from processing
+ associated with the SFR-enforcing actions.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is
+ documented as being inaccessible to untrusted users, the
+ evaluator ensures that the method of making the
+ functions inaccessible is described in the functional
+ specification. It should be noted that this
+ inaccessibility should be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer"; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface plays a role
+ in enforcing any security policy on the TOE (that is, if
+ one of the actions of the interface can be traced to one
+ of the SFRs levied on the TSF), then that interface is
+ SFR-enforcing. Such policies are not
+ limited to the access control policies, but also refer
+ to any functionality specified by one of the SFRs
+ contained in the ST. Note that it is possible that an
+ interface may have various actions and results, some of
+ which may be SFR-enforcing and some of which may
+ not.
+
+ The developer is not required to ``label'' interfaces as
+ SFR-enforcing, and likewise is not required to identify
+ actions available through an interface as SFR-enforcing.
+ It is the evaluator's responsibility to examine the
+ evidence provided by the developer and determine that
+ the required information is present. In the case where
+ the developer has identified the SFR-enforcing TSFI and
+ SFR-enforcing actions available through those TSFI, the
+ evaluator must judge completeness and accuracy based on
+ other information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and on the other information presented
+ for the interfaces (parameters and parameter
+ descriptions, error messages, etc.).
+
+ In this case (where the developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing.
+
+ In the case where the developer has provided the same
+ level of information on all interfaces, the evaluator
+ performs the same type of analysis mentioned in the
+ previous paragraphs. The evaluator should determine
+ which interfaces are SFR-enforcing and which are not,
+ and subsequently ensure that the SFR-enforcing aspects
+ of the SFR-enforcing actions are appropriately
+ described.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from SFR-enforcing
+ actions associated with each SFR-enforcing TSFI.
+
+ This work unit should be performed in conjunction with,
+ or after, work unit
+ in order to ensure the set of SFR-enforcing TSFI and
+ SFR-enforcing actions is correctly identified. The
+ developer may provide more information than is required
+ (for example, all error messages associated with each
+ interface), in which the case the evaluator should
+ restrict their assessment of completeness and accuracy
+ to only those that they determine to be associated with
+ SFR-enforcing actions of SFR-enforcing TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+ In order to determine that the description of the
+ error messages of a TSFI is accurate and complete, the
+ evaluator measures the interface description against the
+ other evidence provided for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), as well as other evidence available for
+ that TSFI (parameters, analysis from work unit ).
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functionality
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the actions, results and error messages of each
+ TSFI are also described sufficiently that it can be
+ determined whether they are SFR-enforcing, with the
+ SFR-enforcing TSFI being described in more detail than
+ other TSFIs.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For SFR-enforcing TSFIs, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For SFR-enforcing TSFIs, the functional specification shall
+ describe direct error messages resulting from security
+ enforcing effects and exceptions associated with invocation of
+ the TSFI.
+
+
+ The functional specification shall summarise the
+ non-SFR-enforcing actions associated with each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is
+ documented as being inaccessible to untrusted users, the
+ evaluator ensures that the method of making the
+ functions inaccessible is described in the functional
+ specification. It should be noted that this
+ inaccessibility should be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface plays a role
+ in enforcing any security policy on the TOE (that is, if
+ one of the actions of the interface can be traced to one
+ of the SFRs levied on the TSF), then that interface is
+ SFR-enforcing. Such policies are not
+ limited to the access control policies, but also refer
+ to any functionality specified by one of the SFRs
+ contained in the ST. Note that it is possible that an
+ interface may have various actions and results, some of
+ which may be SFR-enforcing and some of which may
+ not.
+ The developer is not required to ``label''
+ interfaces as SFR-enforcing, and likewise is not
+ required to identify actions available through an
+ interface as SFR-enforcing. It is the evaluator's
+ responsibility to examine the evidence provided by the
+ developer and determine that the required information is
+ present. In the case where the developer has identified
+ the SFR-enforcing TSFI and SFR-enforcing actions
+ available through those TSFI, the evaluator must judge
+ completeness and accuracy based on other information
+ supplied for the evaluation (e.g., TOE design, security
+ architecture description, operational user guidance),
+ and on the other information presented for the
+ interfaces (parameters and parameter descriptions, error
+ messages, etc.).
+
+ In this case (developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing. The analysis
+ done for work units
+ and are also used in
+ making this determination.
+ In the case where the developer has provided the
+ same level of information on all interfaces, the
+ evaluator performs the same type of analysis mentioned
+ in the previous paragraphs. The evaluator should
+ determine which interfaces are SFR-enforcing and which
+ are not, and subsequently ensure that the SFR-enforcing
+ aspects of the SFR-enforcing actions are appropriately
+ described. Note that in this case, the evaluator should
+ be able to perform the bulk of the work associated with
+ work unit in the
+ course of performing this SFR-enforcing analysis.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from an invocation of
+ each SFR-enforcing TSFI.
+ This work unit should be performed in conjunction
+ with, or after, work unit in order to ensure the set of
+ SFR-enforcing TSFI is correctly identified. The
+ evaluator should note that the requirement and
+ associated work unit is that all error messages
+ associated with an SFR-enforcing TSFI must be described,
+ not just those associated with SFR-enforcing actions.
+ This is because at this level of assurance, the
+ ``extra'' information provided by the error message
+ descriptions should be used in determining whether all
+ of the SFR-enforcing aspects of an interface have been
+ appropriately described. For instance, if an error
+ message associated with a TSFI (e.g., ``access denied'')
+ indicated that an SFR-enforcing decision or action had
+ taken place, but in the description of the SFR-enforcing
+ actions there was no mention of that particular
+ SFR-enforcing mechanism, then the description may not be
+ complete.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+
+ In order to determine that the description of the error
+ messages of a TSFI is accurate and complete, the
+ evaluator measures the interface description against the
+ other evidence provided for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), as well as for other evidence supplied
+ for that TSFI (description of SFR-enforcing actions,
+ summary of non-SFR-enforcing actions and
+ results).
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it summarises the non-SFR-enforcing
+ actions associated with each TSFI.
+
+ The purpose of this work unit is to supplement the
+ details about the SFR-enforcing actions (provided in
+ work unit ) with a
+ summary of the remaining actions (i.e., those that are
+ not SFR-enforcing). This covers all
+ non-SFR-enforcing actions, whether invokable through
+ SFR-enforcing TSFI or through non-SFR-enforcing
+ TSFI. Such a summary about all non-SFR-enforcing actions
+ helps to provide a more complete picture of the
+ functions provided by the TSF, and is to be used by the
+ evaluator in determining whether an action or TSFI may
+ have been mis-categorised.
+
+ The information to be provided is more abstract than
+ that required for SFR-enforcing actions. While it
+ should still be detailed enough so that the reader can
+ understand what the action does, the description does
+ not have to be detailed enough to support writing tests
+ against it, for instance. For the evaluator, the key is
+ that the information must be sufficient to make a
+ positive determination that the action is
+ non-SFR-enforcing. If that level of information is
+ missing, the summary is insufficient and more
+ information must be obtained.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functionality
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST.
+
+
+
+ The functional specification describes the interfaces to
+ the TSF (the TSFI) in a structured manner. Because of the
+ dependency on , the
+ evaluator is expected to have identified the TSF prior to
+ beginning work on this sub-activity. Without firm
+ knowledge of what comprises the TSF, it is not possible to
+ assess the completeness of the TSFI.
+
+ In performing the various work units included in this
+ family, the evaluator is asked to make assessments of
+ accuracy and completeness of several factors (the TSFI
+ itself, as well as the individual components (parameters,
+ actions, error messages, etc.) of the TSFI). In doing this
+ analysis, the evaluator is expected to use the
+ documentation provided for the evaluation. This includes
+ the ST, the TOE design, and may include other
+ documentation such as the user and administrative
+ guidance, security architecture description, and
+ implementation representation. The documentation should be
+ examined in an iterative fashion. The evaluator may read,
+ for example, in the TOE design how a certain function is
+ implemented, but see no way to invoke that function from
+ the interface. This might cause the evaluator to question
+ the completeness of a particular TSFI description, or
+ whether an interface has been left out of the functional
+ specification altogether. Describing analysis activities
+ of this sort in the ETR is a key method in providing
+ rationale that the work units have been performed
+ appropriately.
+
+ It should be recognised that there exist functional
+ requirements whose functionality is manifested wholly or
+ in part architecturally, rather than through a specific
+ mechanism. An example of this is the implementation of
+ mechanisms implementing the requirements. Such mechanisms typically are
+ implemented to ensure a behaviour isn't present, which is
+ difficult to test and typically is verified through
+ analysis. In the cases where such functional requirements
+ are included in the ST, it is expected that the evaluator
+ recognise that there may be SFRs of this type that have no
+ interfaces, and that this should not be considered a
+ deficiency in the functional specification.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from security enforcing effects and
+ exceptions associated with an invocation of each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is
+ documented as being inaccessible to untrusted users, the
+ evaluator ensures that the method of making the
+ functions inaccessible is described in the functional
+ specification. It should be noted that this
+ inaccessibility should be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ Actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the meaning of all errors associated with each
+ TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation
+ (e.g. TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functionality
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST. The completeness of the interfaces
+ is judged based upon the implementation
+ representation.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the implementation representation.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ semi-formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+ The functional specification
+ shall describe all error messages that do not result from an
+ invocation of a TSFI.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation yet
+ does not result from an invocation of a TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is presented using a semiformal
+ style.
+
+ A semi-formal presentation is characterised by a
+ standardised format with a well-defined syntax that
+ reduces ambiguity that may occur in informal
+ presentations. Since the intent of the semi-formal
+ format is to enhance the reader's ability to understand
+ the presentation, use of certain structured presentation
+ methods (pseudo-code, flow charts, block diagrams) are
+ appropriate, though not required.
+
+ For the purposes of this activity, the evaluator should
+ ensure that the interface descriptions are formatted in
+ a structured, consistent manner and use common
+ terminology. A semiformal presentation of the interfaces
+ also implies that the level of detail of the
+ presentation for the interfaces is largely consistent
+ across all TSFI. For the functional specification, it is
+ acceptable to refer to external specifications for
+ portions of the interface as long as those external
+ specifications are themselves semiformal.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is
+ documented as being inaccessible to untrusted users, the
+ evaluator ensures that the method of making the
+ functions inaccessible is described in the functional
+ specification. It should be noted that this
+ inaccessibility should be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system''. is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the meaning of all errors associated with each
+ TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation (e.g.,
+ TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it completely and accurately describes
+ all errors messages that do not result from an
+ invocation of any TSFI.
+
+ This work unit complements work unit , which describes those
+ error messages that result from an invocation of the
+ TSFI. Taken together, these work units cover all error
+ messages that might be generated by the TSF.
+
+ The evaluator assesses the completeness and accuracy of
+ the functional specification by comparing its contents
+ to instances of error message generation within the
+ implementation representation. Most of these error
+ messages will have already been covered by work unit
+ .
+
+ The error messages related to this work unit are
+ typically those that are not expected to be generated,
+ but are constructed as a matter of good programming
+ practises. For example, a case statement that defines
+ actions resulting from each of a list of cases may end
+ with a final else statement to apply
+ to anything that might not be expected; this practise
+ ensures the TSF does not get into an undefined state.
+ However, it is not expected that the path of execution
+ would ever get to this else
+ statement; therefore, any error message generation
+ within this else statement would
+ never be generated. Although it would not get
+ generated, it must still be included in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it provides a rationale for each error
+ message contained in the TSF implementation yet does not
+ result from an invocation of a TSFI.
+
+ The evaluator ensures that every error message found
+ under work unit
+ contains a rationale describing why it cannot be invoked
+ from the TSFI.
+
+ As was described in the previous work unit, this
+ rationale might be as straightforward as the fact that
+ the error message in question is provided for
+ completeness of execution logic and that it is never
+ expected to be generated. The evaluator ensures that the
+ rationale for each such error message is logical.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functionality
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ (Need Objectives text for FSP.6 methodology)
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a formal presentation of the
+ functional specification of the TSF.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+ The functional specification
+ shall describe all error messages contained in the TSF
+ implementation that are not otherwise described in the
+ functional specification.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation that
+ is not otherwise described in the functional specification
+ justifying why it is not associated with a TSFI.
+
+
+ The formal presentation of the functional specification of
+ the TSF shall describe the TSFI using a formal style,
+ supported by informal, explanatory text where appropriate.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+
+
+
+
+ The function of the family
+ is for the developer to make available the implementation
+ representation (and, at higher levels, the implementation
+ itself) of the TOE in a form that can be analysed by the
+ evaluator. The implementation representation is used in
+ analysis activities for other families (analysing the TOE
+ design, for instance) to demonstrate that the TOE conforms
+ its design and to provide a basis for analysis in other
+ areas of the evaluation (e.g., the search for
+ vulnerabilities). The implementation representation is
+ expected to be in a form that captures the detailed internal
+ workings of the TSF. This may be software source code,
+ firmware source code, hardware diagrams and/or IC hardware
+ design language code or layout data.
+
+
+
+ The implementation representation of the TOE is made
+ available so that it can be analysed by the evaluator to
+ demonstrate that the TOE conforms its design and to provide
+ a basis for analysis in other areas of the evaluation (e.g.,
+ the search for vulnerabilities). The implementation
+ representation captures the detailed internal workings of
+ the TSF. This may be software source code, firmware source
+ code, hardware diagrams and/or chip specifications.
+
+
+
+ The components in this family are levelled on the amount of
+ implementation that is mapped to the TOE design
+ description.
+
+
+
+ Source code or hardware diagrams and/or IC hardware design
+ language code or layout data that are used to build the
+ actual hardware are examples of parts of an implementation
+ representation. It is important to note that while the
+ implementation representation must be made available to the
+ evaluator, this does not imply that the evaluator needs to
+ possess that representation. For instance, the developer may
+ require that the evaluator review the implementation
+ representation at a site of the developer's choosing.
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due to
+ lack of information. This does not, however, imply that all
+ of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. The implementation representation is made
+ available to allow analysis of other TOE design
+ decompositions (e.g., functional specification, TOE design),
+ and to gain confidence that the security functionality
+ described at a higher level in the design actually appear to
+ be implemented in the TOE. Conventions in some forms of the
+ implementation representation may make it difficult or
+ impossible to determine from just the implementation
+ representation itself what the actual result of the
+ compilation or run-time interpretation will be. For example,
+ compiler directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code. For this reason, it is important that such ``extra''
+ information or related tools (scripts, compilers, etc.) be
+ provided so that the implementation representation can be
+ accurately determined.
+
+ The purpose of the mapping between the implementation
+ representation and the TOE design description is to aid the
+ evaluator's analysis. The internal workings of the TOE may
+ be better understood when the TOE design is analysed with
+ corresponding portions of the implementation representation.
+ The mapping serves as an index into the implementation
+ representation. At the lower component, only a subset of the
+ implementation representation is mapped to the TOE design
+ description. Because of the uncertainty of which portions of
+ the implementation representation will need such a mapping,
+ the developer may choose either to map the entire
+ implementation representation beforehand, or to wait to see
+ which portions of the implementation representation the
+ evaluator requires to be mapped.
+
+ The implementation representation is manipulated by the
+ developer in a form that is suitable for transformation to
+ the actual implementation. For instance, the developer may
+ work with files containing source code, which is eventually
+ compiled to become part of the TSF. The developer makes
+ available the implementation representation in the form used
+ by the developer, so that the evaluator may use automated
+ techniques in the analysis. This also increases the
+ confidence that the implementation representation examined
+ is actually the one used in the production of the TSF (as
+ opposed to the case where it is supplied in an alternate
+ presentation format, such as a word processor document). It
+ should be noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to supply
+ the evaluator with the information that will maximise the
+ effectiveness of the evaluator's analysis efforts.
+
+ Some forms of the implementation representation may require
+ additional information because they introduce significant
+ barriers to understanding and analysis. Examples include
+ ``shrouded'' source code or source code that has been
+ obfuscated in other ways such that it prevents understanding
+ and/or analysis. These forms of implementation
+ representation typically result from the TOE developer
+ taking a version of the implementation representation and
+ running a shrouding or obfuscation program on it. While the
+ shrouded representation is what is compiled and may be
+ closer to the implementation (in terms of structure) than
+ the original, un-shrouded representation, supplying such
+ obfuscated code may cause significantly more time to be
+ spent in analysis tasks involving the representation. When
+ such forms of representation are created, the components
+ require details on the shrouding tools/algorithms used so
+ that the un-shrouded representation can be supplied, and the
+ additional information can be used to gain confidence that
+ the shrouding process does not compromise any security
+ functionality.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer is suitable for use in other analysis
+ activities; suitability is judged by its
+ conformance to the requirements for this component.
+
+
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due
+ to lack of information. This does not, however, imply that
+ all of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. For this sub-activity, this is even
+ truer. It would not be productive for the evaluator to
+ spend large amounts of time verifying the requirements for
+ one portion of the implementation representation, and then
+ use a different portion of the implementation
+ representation in performing analysis for other work
+ units. Therefore, the evaluator is encouraged to select
+ the sample of the implementation representation from the
+ areas of the TOE that will be of most interest during the
+ analysis performed during work units from other families
+ (e.g. , and ).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the sample of the implementation
+ representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ sample of the implementation representation shall
+ demonstrate their correspondence.
+
+
+ The evaluator shall confirm that, for the selected sample of
+ the implementation representation, the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the implementation
+ representation defines the TSF to a level of detail such
+ that the TSF can be generated without further design
+ decisions.
+
+ Source code or hardware diagrams and/or IC hardware
+ design language code or layout data that are used to
+ build the actual hardware are examples of parts of an
+ implementation representation. The evaluator samples the
+ implementation representation to gain confidence that it
+ is at the appropriate level and not, for instance, a
+ pseudo-code level which requires additional design
+ decisions to be made. The evaluator is encouraged to
+ perform a quick check when first looking at the
+ implementation representation to assure themselves that
+ the developer is on the right track. However, the
+ evaluator is also encourage to perform the bulk of this
+ check while working on other work units that call for
+ examining the implementation; this will ensure the
+ sample examined for this work unit is relevant.
+
+
+
+
+ The evaluator shall check that the implementation
+ representation is in the form used by development
+ personnel.
+
+ The implementation representation is manipulated by the
+ developer in form that it suitable for transformation to
+ the actual implementation. For instance, the developer
+ may work with files containing source code, which is
+ eventually compiled to become part of the TSF. The
+ developer makes available the implementation
+ representation in the form they use, so that the
+ evaluator may use automated techniques in the
+ analysis. This also increases the confidence that the
+ implementation representation examined is actually the
+ one used in the production of the TSF (as opposed to the
+ case where it is supplied in an alternate presentation
+ format, such as a word processor document). It should be
+ noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to
+ supply the evaluator with the information that will
+ maximise the evaluator's analysis efforts.
+
+ The evaluator samples the implementation representation
+ to gain confidence that it is the version that is usable
+ by the developer. The sample is such that the evaluator
+ has assurance that all areas of the implementation
+ representation are in conformance with the requirement;
+ however, a complete examination of the entire
+ implementation representation is unnecessary.
+
+ Conventions in some forms of the implementation
+ representation may make it difficult or impossible to
+ determine from just the implementation representation
+ itself what the actual result of the compilation or
+ run-time interpretation will be. For example, compiler
+ directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code.
+
+ Some forms of the implementation representation may
+ require additional information because they introduce
+ significant barriers to understanding and
+ analysis. Examples include shrouded source code or
+ source code that has been obfuscated in other ways such
+ that it prevents understanding and/or analysis. These
+ forms of implementation representation typically result
+ from by taking a version of the implementation
+ representation that is used by the TOE developer and
+ running a shrouding or obfuscation program on it. While
+ the shrouded representation is what is compiled and may
+ be closer to the implementation (in terms of structure)
+ than the original, un-shrouded representation, supplying
+ such obfuscated code may cause significantly more time
+ to be spent in analysis tasks involving the
+ representation. When such forms of representation are
+ created, the components require details on the shrouding
+ tools/algorithms used so that the un-shrouded
+ representation can be supplied, and the additional
+ information can be used to gain confidence that the
+ shrouding process does not compromise any security
+ mechanisms.
+
+ The evaluator samples the implementation representation
+ to gain confidence that all of the information needed to
+ interpret the implementation representation has been
+ supplied. Note that the tools are among those referenced
+ by components. The
+ evaluator is encouraged to perform a quick check when
+ first looking at the implementation representation to
+ assure themselves that the developer is on the right
+ track. However, the evaluator is also encouraged to
+ perform the bulk of this check while working on other
+ work units that call for examining the implementation;
+ this will ensure the sample examined for this work unit
+ is relevant.
+
+
+
+
+ The evaluator shall examine the mapping between the TOE
+ design description and the sample of the implementation
+ representation to determine that it is accurate.
+
+ The evaluator augments the determination of existence
+ (specified in work unit ) by verifying the accuracy of a portion of
+ the implementation representation and the TOE design
+ description. For parts of the TOE design description
+ that are interesting, the evaluator would verify the
+ implementation representation accurately reflects the
+ description provided in the TOE design
+ description.
+
+ For example, the TOE design description might identify a
+ login module that is used to identify and authenticate
+ users. If user authentication is sufficiently
+ significant, the evaluator would verify that the
+ corresponding code in fact implements that service as
+ described in the TOE design description. It might also
+ be worthwhile to verify that the code accepts the
+ parameters as described in the functional
+ specification.
+
+ It is worth pointing out the developer must choose
+ whether to perform the mapping for the entire
+ implementation representation, thereby guaranteeing that
+ the chosen sample will be covered, or waiting for the
+ sample to be chosen before performing the mapping. The
+ first option is likely more work, but may be completed
+ before the evaluation begins. The second option is less
+ work, but will produce a suspension of evaluation
+ activity while the necessary evidence is being
+ produced.
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer can be transformed into the implementation that
+ is used in the testing activities.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the entire implementation representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ entire implementation representation shall demonstrate their
+ correspondence.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ This family addresses the assessment of the internal
+ structure of the TSF. A TSF whose internals are
+ well-structured is easier to implement and less likely to
+ contain flaws that could lead to vulnerabilities; it is also
+ easier to maintain without the introduction of flaws.
+
+
+
+ The internal structure of the TSF can aid or hamper
+ understandability of the implementation representation.
+ Source code that conforms to coding standards, that exhibit
+ a minimum of interactions, and that is written in modules
+ each with a single purpose, is much easier to understand
+ than poorly-structured code with unnecessary or
+ loosely-defined interactions.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of structure and minimisation of complexity
+ required. places
+ requirements for well-structured internals on only selected
+ parts of the TSF. This component is not included in an EAL
+ because this component is viewed for use in special
+ circumstances (e.g., the sponsor has a specific concern
+ regarding a cryptographic module, which is isolated from the
+ rest of the TSF) and would not be widely applicable.
+
+ At the next level, the requirements for well-structured
+ internals are placed on the entire TSF. Finally,
+ minimisation of complexity is introduced in the highest
+ component.
+
+
+
+ These requirements, when applied to the internal structure
+ of the TSF, typically result in improvements that aid both
+ the developer and the evaluator in understanding the TSF,
+ and also provide the basis for designing and evaluating test
+ suites. Further, improving understandability of the TSF
+ should assist the developer in simplifying its
+ maintainability.
+
+ The requirements in this family are presented at a fairly
+ abstract level. The wide variety of TOEs makes it impossible
+ to codify anything more specific than ``well-structured'' or
+ ``minimum complexity''. Judgements on structure and
+ complexity are expected to be derived from the specific
+ technologies used in the TOE. For example, software is
+ likely to be considered well-structured if it exhibits the
+ characteristics cited in the software engineering
+ disciplines. The components within this family call for
+ identifying the standards for measuring the characteristic
+ of being well-structured and not overly-complex.
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring specific portions of the TSF to be
+ well-structured. The intent is that the entire TSF has
+ been designed and implemented using sound engineering
+ principles, but the analysis is performed upon only a
+ specific subset.
+
+
+
+ This component requires the PP or ST author to fill in an
+ assignment with the subset of the TSF. This subset may be
+ identified in terms of the internals of the TSF at any
+ layer of abstraction. For example:
+
+ the structural elements of the TSF as identified
+ in the TOE design (e.g. ``The developer shall design
+ and implement the audit subsystem
+ such that it has well-structured internals.'')
+ the implementation (e.g. ``The developer shall
+ design and implement the encrypt.c and
+ decrypt.c files such that it has
+ well-structured internals.'' or ``The developer shall
+ design and implement the 6227 IC chip
+ such that it has well-structured
+ internals.'')
+
+ It is likely this would not be readily accomplished by
+ referencing the claimed SFRs (e.g. ``The developer shall
+ design and implement the portion of the TSF that
+ provide anonymity as defined in
+ such that it has well-structured
+ internals.'') because this does not indicate where to
+ focus the analysis.
+
+ This component has limited value and would be suitable in
+ cases where potentially-malicious users/subjects have
+ limited or strictly controlled access to the TSFIs or
+ where there is another means of protection (e.g., domain
+ isolation) that ensures the chosen subset of the TSF
+ cannot be adversely affected by the rest of the TSF (e.g.,
+ the cryptographic functionality, which is isolated from
+ the rest of the TSF, is well-structured).
+
+
+
+ The objective of this sub-activity is to determine whether
+ the defined subset of the TSF is designed and structured
+ such that the likelihood of flaws is reduced and that
+ maintenance can be more readily performed without the
+ introduction of flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The use of the assignment in this component levies
+ stricter constraints on the identified subset of the TSF
+ than on the remainder of the TSF. The TSF subset that is
+ explicitly identified in the assignment . While the entire TSF is to
+ be designed using good engineering principles and result
+ in a well-structured TSF, only the specified subset is
+ specifically analysed for this characteristic. The
+ evaluator determines that the developer's application of
+ coding standards result in a TSF that is
+ understandable.
+
+ The primary goal of this component is to ensure the TSF
+ subset's implementation representation is understandable
+ to facilitate maintenance and analysis (of both the
+ developer and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance);
+
+
+ the architectural description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement subset
+ of the TSF such that it has well-structured
+ internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall explain the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ assigned subset of the TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF subset:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ subset
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the TSF
+ subset
+
+ For other types of technologies used in the TOE - such
+ as non-procedural software (e.g. object-oriented
+ programming), widespread commodity hardware (e.g. PC
+ microprocessors), and special-purpose hardware
+ (e.g. smart-card processors) - the evaluation authority
+ should be consulted for determining the adequacy of
+ criteria for being ``well-structured''.
+
+
+
+ The evaluator shall check the TSF internals
+ description to determine that it identifies the Assigned
+ subset of the TSF.
+
+ This subset may be identified in terms of the internals
+ of the TSF at any layer of abstraction. For example, it
+ may be in terms of the structural elements of the TSF as
+ identified in the TOE design (e.g. the audit subsystem),
+ or in terms of the implementation
+ (e.g. encrypt.c and
+ decrypt.c files, or the 6227 IC
+ chip).
+
+ It is insufficient to identify this subset in terms of
+ the claimed SFRs (e.g. the portion of the TSF that
+ provide anonymity as defined in ) because this does not indicate where to
+ focus the analysis.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ assigned TSF subset is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF subset meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF subset meets the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF subset and
+ the modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ assigned subset of the TSF.
+
+
+ The evaluator shall determine that the TOE design for
+ the assigned TSF subset is well-structured.
+
+ The evaluator examines a sample of the TOE design to
+ verify the accuracy of the justification. For example, a
+ sample of the TOE design is analysed to determine its
+ adherence to the design standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the assigned TSF
+ subset is well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF subset to
+ verify the accuracy of the internals description. For
+ example, a sample of the procedural software portions of
+ the TSF subset is analysed to determine its cohesion and
+ coupling, its adherence to the coding standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured. The intent is
+ that the entire TSF has been designed and implemented
+ using sound engineering principles.
+
+
+
+ Judgements on the adequacy of the structure are expected to
+ be derived from the specific technologies used in the TOE.
+ This component calls for identifying the standards for
+ measuring the characteristic of being
+ well-structured.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is designed and structured such that the
+ likelihood of flaws is reduced and that maintenance can be
+ more readily performed without the introduction of
+ flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The primary goal of this component is to ensure the TSF's
+ implementation representation is understandable to
+ facilitate maintenance and analysis (of both the developer
+ and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance));
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall explain the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the
+ TSF
+
+ For other types of technologies used in the TOE - such
+ as non-procedural software (e.g. object-oriented
+ programming), widespread commodity hardware (e.g. PC
+ microprocessors), and special-purpose hardware
+ (e.g. smart-card processors) - the evaluation authority
+ should be consulted for determining the adequacy of
+ criteria for being ``well-structured''.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ TSF is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF meet the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF and the
+ modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ TSF.
+
+
+ The evaluator shall determine that the TOE design is
+ well-structured.
+
+ The evaluator examines the TOE design of a sample of the
+ TSF to verify the accuracy of the justification. For
+ example, a sample of the TOE design is analysed to
+ determine its adherence to the design standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the TSF is
+ well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF to verify the
+ accuracy of the internals description. For example, a
+ sample of the procedural software portions of the TSF is
+ analysed to determine its cohesion and coupling, its
+ adherence to the coding standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured and of minimal
+ complexity. The intent is that the entire TSF has been
+ designed and implemented using sound engineering
+ principles.
+
+
+
+ Judgements on the adequacy of the structure and complexity
+ are expected to be derived from the specific technologies
+ used in the TOE. This component calls for identifying the
+ standards for measuring the structure and
+ complexity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall explain the characteristics used to
+ judge the meaning of ``well-structured'' and ``complex''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured and is not overly complex.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform an internals analysis on the
+ entire TSF.
+
+
+
+
+
+
+ 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.
+
+
+
+ A formal security model precisely describes important
+ aspects of security and their relationship to the behaviour
+ of the TSF. Formalism helps to prove mathematically the
+ thoroughness of the security.
+
+
+
+ This family contains only one component.
+
+
+
+ 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.
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+ 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.
+
+ 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. contains an assignment for identifying these
+ policies that are formally modelled.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the formal TOE security policy model clearly and
+ consistently describes the rules of operation, states,
+ transition, invariants, and other security properties of
+ the claimed SFRs and whether this description corresponds
+ with the description of the security functionality in the
+ functional specification.
+
+
+
+ This activity applies to cases where the developer has
+ formally modelled all security policies of the TOE that
+ are capable of being modelled formally.
+
+ A formal TOE security policy model is a representation of
+ the rules (synonymously termed ``principles'') and
+ characteristics of security policies in mathematical
+ terms. Their formal counterparts are called security
+ properties and security features, respectively. The
+ representation includes but is not limited to algebraic
+ specifications, finite state machines and logic formalisms
+ strong enough to formally infer the properties from the
+ features. The formal security policy model is accompanied
+ by an informal interpretation explaining how the rules and
+ characteristics are mapped to the respective properties
+ and features.
+
+ It is recognised that not all policies (see work unit
+ ) can be formally
+ modelled for all TOEs. This is because either the state of
+ the art is insufficient to formally model a given policy,
+ or because the nature of the TOE renders impossible the
+ modelling of policies that would otherwise be possible to
+ model. If none of the SFRs can be formally modelled, this
+ component cannot be met.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a formal security policy model
+ for the list of policies that are formally
+ modelled, identifying the relevant portions of the statement
+ of SFRs that comprise each of the modelled
+ policies.
+
+
+ The developer shall provide a formal proof of correspondence
+ between the model and any formal functional specification.
+
+
+ The developer shall provide a demonstration of
+ correspondence between the model and the functional
+ specification.
+
+
+ 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.
+
+
+ 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.
+
+
+ The correspondence between the model and the functional
+ specification shall be at the correct level of formality.
+
+
+ The correspondence shall show that the functional
+ specification is consistent and complete with respect to the
+ model.
+
+
+ The demonstration of correspondence shall show that the
+ interfaces in the functional specification are consistent
+ and complete with respect to the policies in the assignment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it is written in a formal
+ style.
+
+ The evaluator identifies the formal framework upon which
+ the TOE security policy model is based and ensures that
+ it is founded on well established mathematical concepts,
+ and identifies the security properties and features
+ addressed in the application notes and ensures the
+ formalisation of at least one security policy. If no
+ policy is formally modelled, this component cannot be
+ successfully claimed.
+
+ For additional guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all necessary
+ informal explanatory text.
+
+ Supporting narrative descriptions are necessary for all
+ parts of the model (for example, to make clear the
+ meaning of any formal notation and how they are used)
+ including the security properties and features.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all policies that
+ can be formally modelled.
+
+ It is recognised that not all policies can be formally
+ modelled for all TOEs. This is because either the state
+ of the art is insufficient to formally model a given
+ policy, or because the nature of the TOE renders
+ impossible the modelling of policies that would
+ otherwise be possible to model.
+
+ While access control, information flow control, and data
+ integrity policies have all been formally modelled
+ successfully, the possibility of modelling other
+ policies is based on a case by case decision. Abstention
+ from formally modelling security relevant policies
+ requires argumentation and rests the burden of proof
+ entirely on the developer's side.
+
+ For any security policy where formal models are not
+ possible, the policy must be identified in the
+ assignment of .
+
+
+
+
+ The evaluator shall examine the model to determine that
+ the security behaviour of the TOE is clearly
+ articulated.
+
+ The security policy model's properties describe the
+ TOE's behaviour in enforcing the principles of the
+ policy. For example, a policy that is modelled on the
+ basis of state transitions would include principles of
+ its states, identify its initial state, and define what
+ it means to be a secure state.
+
+ The security policy model's features describe the
+ attributes and conditions of the TOE that come into
+ consideration when enforcing its policy's
+ characteristics. For example, a policy that is modelled
+ on the basis of state transitions would describe the
+ necessary conditions to transform the TOE from one state
+ to the next.
+
+ An informal interpretation of all formal concepts
+ (including attributes, predicates and variables, if
+ available) must also be provided in order to make clear
+ their intended meaning.
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the formal functional
+ specification to determine that it is presented in a
+ formal style.
+
+ If no part of the functional specification is formal,
+ this work unit is not applicable and is therefore
+ considered to be satisfied. The corresponding work will
+ be performed under work unit .
+
+ For any part of the functional specification that is
+ formally presented, the correspondence between that part
+ of the functional specification and the security policy
+ model must be formal. Analysis of the content is
+ performed as part of work units through .
+
+ For guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the semiformal functional
+ specification to determine that it is presented in a
+ semiformal style.
+
+ If the entire functional specification is formal, this
+ work unit is not applicable and is therefore considered
+ to be satisfied. The corresponding work will be
+ performed under work unit .
+
+ For formally-modelled policies whose corresponding
+ description in the functional specification is not
+ formally presented, the correspondence between the model
+ and the functional specification must be a semiformal
+ demonstration. Analysis of the content is performed as
+ part of work units
+ through .
+
+ If a security policy model exists, either this work unit
+ or the previous work unit (or both) will be
+ applicable.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it formally proves the
+ correspondence between the security properties and the
+ security features.
+
+ The proof shall show that the security features enforce
+ the security properties. To determine the enforcement,
+ the evaluator considers the security properties and the
+ security features and verifies that the arguments used
+ in the proof are valid. The proof of correspondence
+ between the security properties and the security
+ features shall be formal.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it proves the internal
+ consistency of the TOE security policy model.
+
+ The proof shall show the absence of contradictions
+ within the TOE security policy model. In determining the
+ absence of contradictions, the evaluator verifies that
+ the arguments used in the proof are valid.
+
+ Since the TOE security policy model is formal, the proof
+ of its internal consistency shall be formal. It is
+ recognised that a complete formal proof of the internal
+ consistency of the TOE security policy model usually is
+ not possible due to the fundamental nature of formal
+ frameworks. Generally, it is sufficient to generate
+ evidence using formal proofs based on the specific TOE
+ security policy model that prove the internal
+ consistency by means of a combination with generic
+ arguments of the formal framework.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is consistent with respect to policies described by the
+ security policies (as articulated by the functional
+ requirements in the ST).
+
+ The examination considers the informal relationships of
+ the model. Hence the meaning of consistency reflects
+ the conventional understanding in contrast to the
+ internal consistency concept of the previous work
+ unit.
+
+ In determining consistency, the evaluator verifies that
+ the rationale shows that each description of properties
+ and features in the security policy model accurately
+ reflects the intent of the security policies. For
+ example, if a policy stated that access control was
+ necessary to the granularity of a single individual,
+ then a security policy model describing the security
+ behaviour of a TOE in the context of controlling groups
+ of users would not be consistent. Likewise, if the
+ policy stated that access control for groups of users
+ was necessary, then a security policy model describing
+ the security behaviour of a TOE in the context of
+ controlling individual users would also not be
+ consistent.
+
+ The evaluator also examines whether the security
+ policies are reflected within their formal counterparts
+ of the security policy model.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is complete with respect to the policies described by
+ the security policies (i.e. as articulated by the
+ functional requirements in the ST).
+
+ In determining completeness of this rationale, the
+ evaluator considers the properties and features of the
+ security policy model and maps those properties and
+ features to explicit policy statements (i.e. functional
+ requirements). The rationale should show that all
+ policies that are required to be modelled have an
+ associated property or feature description in the TOE
+ security policy model.
+
+ Abstention from formally modelling policy statements
+ always calls for justification on the developer's side
+ (also confer the application notes above).
+
+
+
+
+ The evaluator shall examine the demonstration of
+ correspondence to determine that all Assigned policies
+ are mapped to functions within the functional
+ specification.
+
+ If all policies are included within the security policy
+ model (i.e. they are all formally modelled) and the
+ assignment in is
+ therefore empty, this work unit is not applicable and is
+ therefore considered to be satisfied.
+
+ The evaluator verifies that the correspondence
+ demonstrates that the descriptions of the SFR-related
+ functions in the functional specification correspond to
+ the SFRs. This may be done as part of the work units addressing
+ correspondence to the SFRs. However, if the developer
+ provides a well-structured semiformal or informal
+ security policy model to better articulate the notions
+ of security enforced by the TOE, the evaluator will
+ verify that such a model is consistent with the
+ SFRs.
+
+
+
+
+
+
+
+ The design description of a TOE provides both context for a
+ description of the TSF, and a thorough description of the
+ TSF. As assurance needs increase, the level of detail
+ provided in the description also increases. As the size and
+ complexity of the TSF increase, multiple levels of
+ decomposition are appropriate. The design requirements are
+ intended to provide information (commensurate with the given
+ assurance level) so that a determination can be made that
+ the security functional requirements are realised.
+
+
+
+ The design description provides a further-refined
+ description of the TSF from that presented in the functional
+ specification. The functional specification provides a
+ description of what the TSF does at its
+ interface; the design description provides more insight into
+ the TSF by describing how the TSF works in
+ order to perform the functions supporting the SFRs. At lower
+ assurance levels, complete details relating to all portions
+ of the TSF are not required. As the desired assurance
+ increases, more detail is made available so that analysis
+ can be performed that supports the assurance claims being
+ made.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of information that is required to be presented
+ with respect to the TSF, and on the degree of formalism
+ required of the design description.
+
+
+
+ The goal of design documentation is to provide sufficient
+ information to determine the TSF boundary, and to describe
+ how the TSF implements the Security
+ Functional Requirements. The amount and structure of the
+ design documentation will depend on the complexity of the
+ TOE and the number of SFRs; in general, a very complex TOE
+ with a large number of SFRs will require more design
+ documentation than a very simple TOE implementing only a few
+ SFRs. Very complex TOEs will benefit (in terms of the
+ assurance provided) from the production of differing levels
+ of decomposition in describing the design, while very simple
+ TOEs do not require both high-level and low-level
+ descriptions of its implementation.
+
+ This family uses two levels of decomposition: the
+ subsystem and the module.
+ A module is the most specific description of functionality:
+ it is a description of the implementation. A developer
+ should be able to implement the part of the TOE described by
+ the module with no further design decisions. A subsystem is
+ a description of the design of the TOE; it helps to provide
+ a high-level description of what a portion of the TOE is
+ doing and how. As such, a subsystem may be further divided
+ into lower-level subsystems, or into modules. Very complex
+ TOEs might require several levels of subsystems in order to
+ adequately convey a useful description of how the TOE works.
+ Very simple TOEs, in contrast, might not require a subsystem
+ level of description; the module might clearly describe how
+ the TOE works.
+
+ The general approach adopted for design documentation is
+ that, as the level of assurance increases, the emphasis of
+ description shifts from the general (subsystem level) to
+ more (module level) detail. In cases where a module-level
+ of abstraction is appropriate because the TOE is simple
+ enough to be described at the module level, yet the level of
+ assurance calls for a subsystem level of description, the
+ module-level description alone will suffice. For complex
+ TOEs, however, this is not the case: an enormous amount of
+ (module-level) detail would be incomprehensible without an
+ accompanying subsystem level of description.
+
+ This approach follows the general paradigm that providing
+ additional detail about the implementation of the TSF will
+ result in greater assurance that the SFRs are implemented
+ correctly, and provide information that can be used to
+ demonstrate this in testing ().
+
+ In the requirements for this family, the term
+ interface is used as the means of
+ communication (between two subsystems or modules). It
+ describes how the communication is invoked; this is similar
+ to the details of TSFI (see ). The term interaction is
+ used to identify the purpose for communication; it
+ identifies why two subsystems or modules are
+ communicating.
+
+
+ The requirements define collections of details about
+ subsystems and modules to be provided:
+
+ The subsystems and modules are
+ identified with a simple list of what
+ they are.
+ A subsystem may be categorised
+ (either implicitly or explicitly) as
+ ``SFR-enforcing'', ``SFR-supporting'', or
+ ``SFR-non-interfering''; these terms are used the same
+ as they are used in .
+ A subsystem's behaviour is what
+ it does. The behaviour may also be categorised as
+ SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering. The behaviour of the subsystem is
+ never categorised as more SFR-relevant than the
+ category of the subsystem itself. For example, an
+ SFR-enforcing subsystem can have SFR-enforcing
+ behaviour as well as non-SFR-enforcing
+ behaviour.
+ A behaviour summary of a
+ subsystem is an overview of the actions it performs
+ (e.g. ``The TCP subsystem assembles IP datagrams into
+ reliable byte streams'').
+ A behaviour description of a
+ subsystem is an explanation of everything it
+ does. This description should be at a level of detail
+ that one can readily determine whether the behaviour
+ has any relevance to the enforcement of the
+ SFRs.
+ A description of interactions
+ among or between subsystems identifies the reason that
+ subsystems communicate, and characterises the
+ information that is passed. It need not define the
+ information to the same level of detail as an
+ interface specification. For example, it would be
+ sufficient to say ``subsystem X requests a block of
+ memory from the memory manager, which responds with
+ the location of the allocated memory.''
+ The purpose of a module provides
+ sufficient detail that no further design decisions are
+ needed. The correspondence between the source code
+ that implements the module, and the purpose of the
+ module should be readily apparent.
+ A module is otherwise described
+ in terms of whatever is identified in the
+ element. Subsystems and modules, and
+ ``SFR-enforcing'', etc. are all further explained in
+ greater detail in .
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each
+ SFR-supporting or SFR-non-interfering TSF subsystem in
+ sufficient detail to determine that it is not SFR-enforcing.
+
+
+ The design shall summarise the SFR-enforcing behaviour of
+ the SFR-enforcing subsystems.
+
+
+ The design shall provide a description of the interactions
+ among SFR-enforcing subsystems of the TSF, and between the
+ SFR-enforcing subsystems of the TSF and other subsystems of
+ the TSF.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each non-SFR-enforcing subsystem of the TSF is
+ described such that the evaluator can determine that the
+ subsystem is non-SFR-enforcing.
+
+ Non-SFR-enforcing subsystems do not need to be described
+ in detail as to how they function in the system.
+ However, the evaluator makes a determination, based on
+ the evidence provided by the developer, that the
+ subsystems that do not have high-level descriptions are
+ non-SFR-enforcing (that is, either SFR-supporting or
+ SFR-non-interfering). Note that if the developer
+ provides a uniform level of detailed documentation then
+ this work unit will be largely satisfied, since the
+ point of categorising the subsystems is to allow the
+ developer to provide less information for
+ non-SFR-enforcing subsystems than for SFR-enforcing
+ subsystems.
+
+ An SFR-supporting subsystem is one that is depended on
+ by an SFR-enforcing subsystem in order to implement an
+ SFR, but does not play as direct a role as an
+ SFR-supporting requirement. An SFR-non-interfering
+ subsystem is one that is not depended upon, in either a
+ supporting or enforcing role, to implement an
+ SFR.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and high-level
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. A high-level description need not refer to
+ specific data structures (although it may), but instead
+ talks about more general data flow, message flow, and
+ control relationships within a subsystem. The goal of
+ these descriptions is to give the evaluator enough
+ information to understand how the
+ SFR-enforcing behaviour is achieved. Note that the
+ evaluator should find unacceptable asserts of
+ SFR-enforcement in the TOE design documentation for this
+ work unit. It should be noted that it is the
+ evaluator's determination with respect to what
+ ``high-level'' means for a particular TOE, and the
+ evaluator obtains enough information from the developer
+ to make a sound verdict for this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work
+ unit
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the
+ SFR-enforcing subsystems and other subsystems is to help
+ provide the reader a better understanding of how the TSF
+ performs it functions. These interactions do not need to
+ be characterised at the implementation level (e.g.,
+ parameters passed from one routine in a subsystem to a
+ routine in a different subsystem; global variables;
+ hardware signals (e.g., interrupts) from a hardware
+ subsystem to an interrupt-handling subsystem), but the
+ data elements identified for a particular subsystem that
+ are going to be used by another subsystem should be
+ covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the
+ subsystem that actually implements these rules) should
+ also be described.
+
+ The evaluators should use their own judgement in
+ assessing the completeness of the description. If the
+ reason for an interaction is unclear, or if there are
+ SFR-related interactions (discovered, for instance, in
+ examining the descriptions of subsystem behaviour) that
+ do not appear to be described, the evaluator ensures
+ that this information is provided by the
+ developer. However, if the evaluator can determine that
+ interactions among a particular set of subsystems, while
+ incompletely described by the developer, will not aid in
+ understanding the overall functionality nor security
+ functionality provided by the TSF, then the evaluator
+ may choose to consider the description sufficient, and
+ not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems. Note that this map may have to be
+ at a level of detail below the subsystem or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ subsystem contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each SFR
+ non-interfering subsystem of the TSF in detail sufficient to
+ determine that it is SFR non-interfering.
+
+
+ The design shall describe the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+
+ The design shall summarise the non-SFR-enforcing behaviour
+ of the SFR-enforcing subsystems.
+
+
+ The design shall summarise the behaviour of the
+ SFR-supporting subsystems.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each SFR-non-interfering subsystem of the TSF is
+ described such that the evaluator can determine that the
+ subsystem is SFR-non-interfering.
+
+ SFR-non-interfering subsystems do not need to be
+ described in detail as to how they function in the
+ system. However, the evaluator makes a determination,
+ based on the evidence provided by the developer, that
+ the subsystems that do not have detailed descriptions
+ are SFR-non-interfering. Note that if the developer
+ provides a uniform level of detailed documentation then
+ this work unit will be largely satisfied, since the
+ point of categorising the subsystems is to allow the
+ developer to provide less information for
+ SFR-non-interfering subsystems than for SFR-enforcing
+ and SFR-supporting subsystems.
+
+ An SFR-non-interfering subsystem is one on which the
+ SFR-enforcing and SFR-supporting subsystems have no
+ dependence; that is, they play no role in implementing
+ SFR functionality.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and detailed
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. While not at the level of an algorithmic
+ description, a detailed description of behaviour
+ typically discusses how the functionality is provided in
+ terms of what key data and data structures are, what
+ control relationships exist within a subsystem, and how
+ these elements work together to provide the
+ SFR-enforcing behaviour. Such a description also
+ references SFR-supporting behaviour, which the evaluator
+ should consider in performing subsequent work
+ units.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work
+ unit
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete and accurate high-level
+ description of the non-SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous work unit, this work unit
+ calls for the evaluator to assess the information
+ provided for SFR-enforcing subsystems that is
+ non-SFR-enforcing. The goal of this assessment is
+ two-fold. First, it should provide the evaluator
+ greater understanding of the way each subsystem works.
+ Second, the evaluator determines that all SFR-enforcing
+ behaviour exhibited by a subsystem has been described.
+ Unlike the previous work unit, the information provided
+ for non-SFR-enforcing behaviour does not have to be as
+ detailed as that provided by the SFR-enforcing
+ behaviour. For example, data structures or data items
+ that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all.
+ It is the evaluator's determination, however, with
+ respect to what ``high-level'' means for a particular
+ TOE, and the evaluator obtains enough information from
+ the developer (even if it turns out to be equivalent to
+ information provided for the parts of the subsystem that
+ are SFR-enforcing) to make a sound verdict for this work
+ unit.
+
+ The evaluator is cautioned, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work unit.
+ In particular, the functional specification should be
+ used to determine that the behaviour required to
+ implement the TSF Interfaces described by the functional
+ specification are completely described by the subsystem,
+ since the behaviour will either be SFR-enforcing or
+ non-SFR-enforcing.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete and accurate high-level
+ description of the behaviour of the SFR-supporting
+ subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous two work units, this work
+ unit calls for the developer to provide (and the
+ evaluator to assess) information about SFR supporting
+ subsystems. Such subsystems should be referenced by the
+ descriptions of the SFR-enforcing subsystems, as well as
+ by the descriptions of interactions in work unit . The goal of evaluator's
+ assessment, like that for the previous work unit, is
+ two-fold. First, it should provide the evaluator with
+ an understanding of the way each SFR-supporting
+ subsystem works. Second, the evaluator determines that
+ the behaviour is described in enough detail so that the
+ way in which the subsystem supports the SFR-enforcing
+ behaviour is clear, and that the behaviour is not itself
+ SFR-enforcing. The information provided for
+ SFR-supporting subsystem's behaviour does not have to be
+ as detailed as that provided by the SFR-enforcing
+ behaviour. For example, data structures or data items
+ that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all.
+ It is the evaluator's determination, however, with
+ respect to what ``high-level'' means for a particular
+ TOE, and the evaluator obtains enough information from
+ the developer (even if it turns out to be equivalent to
+ information provided for the parts of the subsystem that
+ are SFR-enforcing) to make a sound verdict for this work
+ unit.
+
+ The evaluator is cautions, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work unit.
+ In particular, the functional specification should be
+ used to determine that the behaviour required to
+ implement the TSF Interfaces described by the functional
+ specification are completely described by the
+ subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the
+ subsystems is to help provide the reader a better
+ understanding of how the TSF performs it
+ functions. These interactions do not need to be
+ characterised at the implementation level (e.g.,
+ parameters passed from one routine in a subsystem to a
+ routine in a different subsystem; global variables;
+ hardware signals (e.g., interrupts) from a hardware
+ subsystem to an interrupt-handling subsystem), but the
+ data elements identified for a particular subsystem that
+ are going to be used by another subsystem should be
+ covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the
+ subsystem that actually implements these rules) should
+ also be described.
+
+ It should be noted while the developer should
+ characterise all interactions between subsystems, the
+ evaluators should use their own judgement in assessing
+ the completeness of the description. If the reason for
+ an interaction is unclear, or if there are SFR-related
+ interactions (discovered, for instance, in examining the
+ descriptions of subsystem behaviour) that do not appear
+ to be described, the evaluator ensures that this
+ information is provided by the developer. However, if
+ the evaluator can determine that interactions among a
+ particular set of subsystems, while incompletely
+ described by the developer, will not aid in
+ understanding the overall functionality nor security
+ functionality provided by the TSF, then the evaluator
+ may choose to consider the description sufficient, and
+ not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems. Note that this map may have to be
+ at a level of detail below the subsystem or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ subsystem contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing
+ modules and enough information about the SFR-supporting
+ and SFR-non-interfering modules for the evaluator to
+ determine that the SFRs are completely and accurately
+ implemented; as such, the TOE design provides an
+ explanation of the implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the
+ evaluator determines that the TSF boundary has been
+ adequately described. Second, the evaluator determines
+ that the developer has provided documentation that
+ conforms to the content and presentation requirements for
+ this subsystem, and that is consistent with other
+ documentation provided for the TOE. Finally, the evaluator
+ must analyse the design information provided for the
+ SFR-enforcing modules (at a detailed level) and the
+ non-SFR-enforcing modules (at a less detailed level) to
+ understand how the system is implemented, and with that
+ knowledge ensure that the TSFI in the functional
+ specification are adequately described, and that the test
+ information adequately tests the TSF (done in the work units).
+
+ It is important to note that while the developer is
+ obligated to provide a complete description of the TSF
+ (although SFR-enforcing modules will have more detail than
+ the non-SFR-enforcing modules), the evaluator is expected
+ to use their judgement in performing their analysis. While
+ the evaluator is expected to look at every module, the
+ detail to which they examine each module may vary. The
+ evaluator analyses each module in order to gain enough
+ understanding to determine the effect of the functionality
+ of the module on the security of the system, and the depth
+ to which they need to analyse the module may vary
+ depending on the module's role in the system. An important
+ aspect of this analysis is that the evaluator should use
+ the other documentation provided (TSS, functional
+ specification, security architecture description, and the
+ TSF internal document) in order to determine that the
+ functionality that is described is correct, and that the
+ implicit designation of non-SFR-enforcing modules (see
+ below) is supported by their role in the system
+ architecture.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a description of each subsystem of
+ the TSF.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing module in terms
+ of its purpose.
+
+
+ The design shall describe each SFR-enforcing module in terms
+ of its SFR-related interfaces, return values from those
+ interfaces, and called interfaces to other modules.
+
+
+ The design shall describe each SFR-supporting or
+ SFR-non-interfering module in terms of its purpose and
+ interaction with other modules.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . For a very
+ simple TOE that can be described solely at the
+ ``module'' level (see ), this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ architectural description) in making this
+ determination. For example, if the
+ functional specification contains interfaces to
+ functionality that does not appear to be described in
+ the TOE design description, it may be the case that a
+ portion of the TSF has not been included
+ appropriately. Making this determination will likely be
+ an iterative process, where as more analysis is done on
+ the other evidence, more confidence can be gained with
+ respect to the completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation
+ in a level of detail that can serve as a guide to
+ reviewing the implementation representation. A
+ description of a module should be such that one could
+ create an implementation of the module from the
+ description, and the resulting implementation would be
+ 1) identical to the actual TSF implementation in terms
+ of the interfaces presented and used by the module, and
+ 2) algorithmically identical to the TSF module. For
+ instance, RFC 793 provides a high-level description of
+ the TCP protocol. It is necessarily implementation
+ independent. While it provides a wealth of detail, it is
+
+ not a suitable design
+ description because it is not specific to an
+ implementation. An actual implementation can add to the
+ protocol specified in the RFC, and implementation
+ choices (for instance, the use of global data vs. local
+ data in various parts of the implementation) may have an
+ impact on the analysis that is performed. The design
+ description of the TCP module would list the interfaces
+ presented by the implementation (rather than just those
+ defined in RFC 793), as well as an algorithm description
+ of the processing associated with the modules
+ implementing TCP (assuming it was part of the
+ TSF).
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of describing the
+ interactions between the subsystems is to help provide
+ the reader a better understanding of how the TSF
+ performs it functions. These interactions do not need to
+ be characterised at the implementation level (e.g.,
+ parameters passed from one routine in a subsystem to a
+ routine in a different subsystem; global variables;
+ hardware signals (e.g., interrupts) from a hardware
+ subsystem to an interrupt-handling subsystem), but the
+ data elements identified for a particular subsystem that
+ are going to be used by another subsystem should be
+ covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the
+ subsystem that actually implements these rules) should
+ also be described.
+
+ It should be noted while the developer should
+ characterise all interactions between subsystems, the
+ evaluators should use their own judgement in assessing
+ the completeness of the description. If the reason for
+ an interaction is unclear, or if there are SFR-related
+ interactions (discovered, for instance, in examining the
+ module-level documentation) that do not appear to be
+ described, the evaluator ensures that this information
+ is provided by the developer. However, if the evaluator
+ can determine that interactions among a particular set
+ of subsystems, while incompletely described by the
+ developer, and a complete description will not aid in
+ understanding the overall functionality nor security
+ functionality provided by the TSF, then the evaluator
+ may choose to consider the description sufficient, and
+ not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF to
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF to
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing module is complete and accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for subsystems. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing module contain an accurate and complete
+ description of the SFR-related parameters, the
+ invocation conventions for each interface, and any
+ values returned directly by the interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are
+ fixed).
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of SFR-related
+ parameters, and descriptions of these parameters. Note
+ that global data would also be considered parameters if
+ used by the module (either as inputs or outputs) when
+ invoked. If a parameter were expected to take on a set
+ of values (e.g., a ``flag'' parameter), the complete set
+ of values the parameter could take on that would have an
+ effect on module processing would be
+ specified. Likewise, parameters representing data
+ structures are described such that each field of the
+ data structure is identified and described. Note that
+ different programming languages may have additional
+ ``interfaces'' that would be non-obvious; an example
+ would be operator/function overloading in C++. This
+ ``implicit interface'' in the class description would
+ also be described as part of the low-level TOE
+ design. Note that although a module could present only
+ one interface, it is more common that a module presents
+ a small set of related interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TOE design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+ Because the modules are at such a low level, it may be
+ difficult determine completeness and accuracy impacts
+ from other documentation, such as administrative
+ guidance, the functional specification, the TSF
+ internals, or the security architecture
+ description. However, the evaluator uses the information
+ present in those documents to the extent possible to
+ help ensure that the purpose is accurately and
+ completely described. This analysis can be aided by the
+ analysis performed for the work units for the element, which maps the
+ TSFI in the functional specification to the modules of
+ the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that non-SFR-supporting modules are correctly
+ categorised.
+
+ In the cases where the developer has provided different
+ amounts of information for different modules, an
+ implicit categorisation has been done. That is, modules
+ (for instance) with detail presented on their
+ SFR-related interfaces (see ) are candidate SFR-enforcing modules,
+ although examination by the evaluator may lead to a
+ determination that some set of them are
+ non-SFR-enforcing. Those with only a description of
+ their purpose and interaction with other modules (for
+ instance) are ``implicitly categorised'' as
+ non-SFR-enforcing.
+
+ In these cases, a key focus of the evaluator for this
+ work unit is attempting to determine from the evidence
+ provided for each module implicitly categorised as
+ non-SFR-enforcing and the evaluation information about
+ other modules (in the TOE design, the functional
+ specification, the security architecture description,
+ and the administrative guidance), whether the module is
+ indeed non-SFR-enforcing. At this level of assurance
+ some error should be tolerated; the evaluator does not
+ have to be absolutely sure that a given module is
+ non-SFR-enforcing, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ non-SFR-enforcing module is SFR-enforcing, the evaluator
+ requests additional information from the developer in
+ order to resolve the apparent inconsistency. For
+ instance, suppose the documentation for Module A (an
+ SFR-enforcing module) indicates that it calls Module B
+ to perform an access check on a certain type of
+ construct. When the evaluator examines the information
+ associated with Module B, they find that all the
+ developer has provided is a purpose and a set of
+ interactions (thus implicitly categorising Module B as
+ non-SFR-enforcing). On examining the purpose and
+ interactions from Module A, the evaluator finds no
+ mention of Module B performing any access checks, and
+ Module A is not listed as a module with which Module B
+ interacts. At this point the evaluator should approach
+ the developer to resolve the discrepancies between the
+ information provided in Module A and that in Module
+ B.
+
+ Another example would be where the evaluator examines
+ the mapping of the TSFI to the modules as provided by
+ . This examination
+ shows that Module C is associated with an SFR requiring
+ identification of the user. Again, when the evaluator
+ examines the information associated with Module C, they
+ find that all the developer has provided is a purpose
+ and a set of interactions (thus implicitly categorising
+ Module C as non-SFR-enforcing). Examining the purpose
+ and interactions presented for Module C, the evaluator
+ is unable to determine why Module C, listed as mapping
+ to a TSFI concerned with user identification, would not
+ be classified as SFR-enforcing. Again, the evaluator
+ should approach the developer to resolve this
+ discrepancy.
+
+
+ A final example from the opposite point of view. As
+ before, the developer has provided information
+ associated with Module D consisting of a purpose and a
+ set of interactions (thus implicitly categorising Module
+ D as non-SFR-enforcing). The evaluator examines all of
+ the evidence provided, including the purpose and
+ interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the
+ TOE, the interactions are consistent with that
+ description, and there is nothing to indicate that
+ Module D is SFR-enforcing. In this case, the evaluator
+ should not demand more information about Module D ``just
+ be to sure'' it is correctly categorised. The developer
+ has met their obligations and the resulting assurance
+ the evaluator has in the implicit categorisation of
+ Module D is (by definition) appropriate for this
+ assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ non-SFR-supporting module is complete and
+ accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ Because the modules are at such a low level, it may be
+ difficult determine completeness and accuracy impacts
+ from other documentation, such as administrative
+ guidance, the functional specification, the security
+ architecture description, or the TSF internals
+ document. However, the evaluator uses the information
+ present in those documents to the extent possible to
+ help ensure that the function is accurately and
+ completely described. This analysis can be aided by the
+ analysis performed for the work units for the element, which maps the
+ TSFI in the functional specification to the modules of
+ the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of a non-SFR-supporting module's
+ interaction with other modules is complete and
+ accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ A module's interaction with other modules can be
+ captured in many ways. The intent for the TOE design is
+ to allow the evaluator to understand (in part through
+ analysis of module interactions) the role of the
+ non-SFR-enforcing modules in the overall TOE
+ design. Understanding of this role will aid the
+ evaluator in performing work unit .
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+ Because the modules are at such a low level, it may be
+ difficult determine completeness and accuracy impacts
+ from other documentation, such as administrative
+ guidance, the functional specification, the security
+ architecture description, or the TSF internals
+ document. However, the evaluator uses the information
+ present in those documents to the extent possible to
+ help ensure that the interactions are accurately and
+ completely described.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a
+ description of the implementation of the TSF. The TSFI
+ provide a description of how the implementation is
+ exercised. The evidence from the developer identifies
+ the module that is initially invoked when an operation
+ is requested at the TSFI, and identify the chain of
+ modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However,
+ a complete call tree for each TSFI is not required for
+ this work unit. The cases in which more than one module
+ would have to be identified are where there are ``entry
+ point'' modules or wrapper modules that have no
+ functionality other than conditioning inputs or
+ de-multiplexing an input. Mapping to one of these
+ modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a module at the TSF boundary. This determination can
+ be made by reviewing the module description and its
+ interfaces/interactions. The next aspect of accuracy is
+ that each TSFI identifies a chain of modules between the
+ initial module identified and a module that is primarily
+ responsible for implementing the function presented at
+ the TSF. Note that this may be the initial module, or
+ there may be several modules, depending on how much
+ pre-conditioning of the inputs is done. It should be
+ noted that one indicator of a pre-conditioning module is
+ that it is invoked for a large number of the TSFI, where
+ the TSFI are all of similar type (e.g., system
+ call). The final aspect of accuracy is that the mapping
+ makes sense. For instance, mapping a TSFI dealing with
+ access control to a module that checks passwords is not
+ accurate. The evaluator should again use judgement in
+ making this determination. The goal is that this
+ information aids the evaluator in understanding the
+ system and implementation of the SFRs, and ways in which
+ entities at the TSF boundary can interact with the
+ TSF. The bulk of the assessment of whether the SFRs are
+ described accurately by the modules is performed in
+ other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems. Note that this map may have to be
+ at a level of detail below the subsystem or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ subsystem contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing and
+ SFR-supporting modules and enough information about the
+ SFR-non-interfering modules for the evaluator to determine
+ that the SFRs are completely and accurately implemented;
+ as such, the TOE design provides an explanation of the
+ implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the
+ evaluator determines that the TSF boundary has been
+ adequately described. Second, the evaluator determines
+ that the developer has provided documentation that
+ conforms to the content and presentation requirements this
+ subsystem, and that is consistent with other documentation
+ provided for the TOE. Finally, the evaluator must analyse
+ the design information provided for the SFR-enforcing
+ modules (at a detailed level) and the non-SFR-enforcing
+ modules (at a less detailed level) to understand how the
+ system is implemented, and with that knowledge ensure that
+ the TSFI in the functional specification are adequately
+ described, and that the test information adequately tests
+ the TSF (done in the work
+ units).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a description of each subsystem of
+ the TSF.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing and
+ SFR-supporting module in terms of its purpose.
+
+
+ The design shall describe each SFR-enforcing and
+ SFR-supporting module in terms of its SFR-related
+ interfaces, return values from those interfaces, and called
+ interfaces to other modules.
+
+
+ The design shall describe each SFR-non-interfering module in
+ terms of its purpose and interaction with other modules.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . For a very
+ simple TOE that can be described solely at the
+ ``module'' level (see ), this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ architectural description) in making this
+ determination. For example, if the functional
+ specification contains interfaces to functionality that
+ does not appear to be described in the TOE design
+ description, it may be the case that a portion of the
+ TSF has not been included appropriately. Making this
+ determination will likely be an iterative process, where
+ as more analysis is done on the other evidence, more
+ confidence can be gained with respect to the
+ completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation
+ in a level of detail that can serve as a guide to
+ reviewing the implementation representation. A
+ description of a module should be such that one could
+ create an implementation of the module from the
+ description, and the resulting implementation would be
+ 1) identical to the actual TSF implementation in terms
+ of the interfaces presented and used by the module, and
+ 2) algorithmically identical to the TSF module. For
+ instance, RFC 793 provides a high-level description of
+ the TCP protocol. It is necessarily implementation
+ independent. While it provides a wealth of detail, it is
+
+ not a suitable design
+ description because it is not specific to an
+ implementation. An actual implementation can add to the
+ protocol specified in the RFC, and implementation
+ choices (for instance, the use of global data vs. local
+ data in various parts of the implementation) may have an
+ impact on the analysis that is performed. The design
+ description of the TCP module would list the interfaces
+ presented by the implementation (rather than just those
+ defined in RFC 793), as well as an algorithm description
+ of the processing associated with the modules
+ implementing TCP (assuming it was part of the
+ TSF).
+
+
+
+
+ The evaluator shall check the TOE design to determine
+ that the TSF modules are identified as either
+ SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The purpose of designating each module (according to the
+ role a particular module plays in the enforcement of the
+ SFRs) is to allow developers to provide less information
+ about the parts of the TSF that have little role in
+ security. It is always permissible for the developer to
+ provide more information or detail than the requirements
+ demand, as might occur when the information has been
+ gathered outside the evaluation context). In such cases
+ the developer must still designate the modules as either
+ SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The accuracy of these designations is continuously
+ reviewed as the evaluation progresses. The concern is
+ the mis-designation of modules as being less important
+ (and hence, having less information) than is really the
+ case. While blatant mis-designations may be immediately
+ apparent (e.g., designating an authentication module as
+ anything but SFR-enforcing when is one of the SFRs being claimed), other
+ mis-designations might not be discovered until the TSF
+ is better understood. The evaluator must therefore keep
+ in mind that these designations are the developer's
+ initial best effort, but are subject to change. Further
+ guidance is provided under work unit , which examines the
+ accuracy of these designations.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of describing the
+ interactions between the subsystems is to help provide
+ the reader a better understanding of how the TSF
+ performs it functions. These interactions do not need to
+ be characterised at the implementation level (e.g.,
+ parameters passed from one routine in a subsystem to a
+ routine in a different subsystem; global variables;
+ hardware signals (e.g., interrupts) from a hardware
+ subsystem to an interrupt-handling subsystem), but the
+ data elements identified for a particular subsystem that
+ are going to be used by another subsystem should be
+ covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the
+ subsystem that actually implements these rules) should
+ also be described.
+
+ It should be noted while the developer should
+ characterise all interactions between subsystems, the
+ evaluators should use their own judgement in assessing
+ the completeness of the description. If the reason for
+ an interaction is unclear, or if there are SFR-related
+ interactions (discovered, for instance, in examining the
+ module-level documentation) that do not appear to be
+ described, the evaluator ensures that this information
+ is provided by the developer. However, if the evaluator
+ can determine that interactions among a particular set
+ of subsystems, while incompletely described by the
+ developer, and a complete description will not aid in
+ understanding the overall functionality nor security
+ functionality provided by the TSF, then the evaluator
+ may choose to consider the description sufficient, and
+ not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF to
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF to
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing and SFR-supporting module is complete and
+ accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the modules
+ have been categorised by the developer or not, it is the
+ evaluator's responsibility to determine that the modules
+ have the appropriate information for their role
+ (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for subsystems. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing and SFR-supporting module contain an
+ accurate and complete description of the SFR-related
+ parameters, the invocation conventions for each
+ interface, and any values returned directly by the
+ interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are
+ fixed).
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of parameters, and
+ descriptions of these parameters. Note that global data
+ would also be considered parameters if used by the
+ module (either as inputs or outputs) when invoked. If a
+ parameter were expected to take on a set of values
+ (e.g., a ``flag'' parameter), the complete set of values
+ the parameter could take on that would have an effect on
+ module processing would be specified. Likewise,
+ parameters representing data structures are described
+ such that each field of the data structure is identified
+ and described. Note that different programming languages
+ may have additional ``interfaces'' that would be
+ non-obvious; an example would be operator/function
+ overloading in C++. This ``implicit interface'' in the
+ class description would also be described as part of the
+ low-level TOE design. Note that although a module could
+ present only one interface, it is more common that a
+ module presents a small set of related
+ interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TDS design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+ Because the modules are at such a low level, it may be
+ difficult determine completeness and accuracy impacts
+ from other documentation, such as administrative
+ guidance, the functional specification, the TSF
+ internals, or the security architecture
+ description. However, the evaluator uses the information
+ present in those documents to the extent possible to
+ help ensure that the purpose is accurately and
+ completely described. This analysis can be aided by the
+ analysis performed for the work units for the element, which maps the
+ TSFI in the functional specification to the modules of
+ the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that SFR-non-interfering modules are correctly
+ categorised.
+
+ As mentioned in work unit , less information is required about modules
+ that are SFR-non-interfering. A key focus of the
+ evaluator for this work unit is attempting to determine
+ from the evidence provided for each module implicitly
+ categorised as SFR-non-interfering and the evaluation
+ (information about other modules in the TOE design, the
+ functional specification, the security architecture
+ description, the administrative guidance, the TSF
+ internals document, and perhaps even the implementation
+ representation) whether the module is indeed
+ SFR-non-interfering. At this level of assurance some
+ error should be tolerated; the evaluator does not have
+ to be absolutely sure that a given module is
+ SFR-non-interfering, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ SFR-non-interfering module is SFR-enforcing or
+ SFR-supporting, the evaluator requests additional
+ information from the developer in order to resolve the
+ apparent inconsistency. For example, suppose the
+ documentation for Module A (an SFR-enforcing module)
+ indicates that it calls Module B to perform an access
+ check on a certain type of construct. When the evaluator
+ examines the information associated with Module B, it is
+ discovered that the only information the developer has
+ provided is a purpose and a set of interactions (thus
+ implicitly categorising Module B as
+ non-SFR-enforcing). On examining the purpose and
+ interactions from Module A, the evaluator finds no
+ mention of Module B performing any access checks, and
+ Module A is not listed as a module with which Module B
+ interacts. At this point the evaluator should approach
+ the developer to resolve the discrepancies between the
+ information provided in Module A and that in Module
+ B.
+
+ Another example would be where the evaluator examines
+ the mapping of the TSFI to the modules as provided by
+ . This examination
+ shows that Module C is associated with an SFR requiring
+ identification of the user. Again, when the evaluator
+ examines the information associated with Module C, they
+ find that all the developer has provided is a purpose
+ and a set of interactions (thus implicitly categorising
+ Module C as SFR-non-interfering). Examining the purpose
+ and interactions presented for Module C, the evaluator
+ is unable to determine why Module C, listed as mapping
+ to a TSFI concerned with user identification, would not
+ be classified as SFR-enforcing or SFR-supporting. Again,
+ the evaluator should approach the developer to resolve
+ this discrepancy.
+
+ A final example illustrates the opposite situation. As
+ before, the developer has provided information
+ associated with Module D consisting of a purpose and a
+ set of interactions (thus implicitly categorising Module
+ D as SFR-non-interfering). The evaluator examines all of
+ the evidence provided, including the purpose and
+ interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the
+ TOE, the interactions are consistent with that
+ description, and there is nothing to indicate that
+ Module D is SFR-enforcing or SFR-supporting. In this
+ case, the evaluator should not demand more information
+ about Module D ``just be to sure'' it is correctly
+ categorised. The developer has met the obligations and
+ the resulting assurance the evaluator has in the
+ implicit categorisation of Module D is (by definition)
+ appropriate for this assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-non-interfering module is complete and
+ accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ Because the modules are at such a low level, it may be
+ difficult determine completeness and accuracy impacts
+ from other documentation, such as administrative
+ guidance, the functional specification, the security
+ architecture description, or the TSF internals
+ document. However, the evaluator uses the information
+ present in those documents to the extent possible to
+ help ensure that the function is accurately and
+ completely described. This analysis can be aided by the
+ analysis performed for the work units for the element, which maps the
+ TSFI in the functional specification to the modules of
+ the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of a SFR-non-interfering module's
+ interaction with other modules is complete and
+ accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ A module's interaction with other modules can be
+ captured in many ways. The intent for the TOE design is
+ to allow the evaluator to understand (in part through
+ analysis of module interactions) the role of the
+ non-SFR-enforcing modules in the overall TOE
+ design. Understanding of this role will aid the
+ evaluator in performing work unit .
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+ Because the modules are at such a low level, it may be
+ difficult determine completeness and accuracy impacts
+ from other documentation, such as administrative
+ guidance, the functional specification, the security
+ architecture description, or the TSF internals
+ document. However, the evaluator uses the information
+ present in those documents to the extent possible to
+ help ensure that the interactions are accurately and
+ completely described.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a
+ description of the implementation of the TSF. The TSFI
+ provide a description of how the implementation is
+ exercised. The evidence from the developer identifies
+ the module that is initially invoked when an operation
+ is requested at the TSFI, and identify the chain of
+ modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However,
+ a complete call tree for each TSFI is not required for
+ this work unit. The cases in which more than one module
+ would have to be identified are where there are ``entry
+ point'' modules or wrapper modules that have no
+ functionality other than conditioning inputs or
+ de-multiplexing an input. Mapping to one of these
+ modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a module at the TSF boundary. This determination can
+ be made by reviewing the module description and its
+ interfaces/interactions. The next aspect of accuracy is
+ that each TSFI identifies a chain of modules between the
+ initial module identified and a module that is primarily
+ responsible for implementing the function presented at
+ the TSF. Note that this may be the initial module, or
+ there may be several modules, depending on how much
+ pre-conditioning of the inputs is done. It should be
+ noted that one indicator of a pre-conditioning module is
+ that it is invoked for a large number of the TSFI, where
+ the TSFI are all of similar type (e.g., system
+ call). The final aspect of accuracy is that the mapping
+ makes sense. For instance, mapping a TSFI dealing with
+ access control to a module that checks passwords is not
+ accurate. The evaluator should again use judgement in
+ making this determination. The goal is that this
+ information aids the evaluator in understanding the
+ system and implementation of the SFRs, and ways in which
+ entities at the TSF boundary can interact with the
+ TSF. The bulk of the assessment of whether the SFRs are
+ described accurately by the modules is performed in
+ other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems. Note that this map may have to be
+ at a level of detail below the subsystem or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ subsystem contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of all modules for the
+ evaluator to determine that the SFRs are completely and
+ accurately implemented; as such, the TOE design provides
+ an explanation of the implementation
+ representation.
+
+
+
+ At this level, there is no differentiation of required
+ information according to SFR-relevance.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a description of each subsystem of
+ the TSF.
+
+
+ The design shall provide a description of the interactions
+ among subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each module in terms of its
+ purpose, interfaces, return values from those interfaces,
+ and called interfaces to other modules.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The developer shall provide a formal specification of the
+ TSF subsystems.
+
+
+ The developer shall provide a proof of correspondence
+ between the formal specifications of the TSF subsystems and
+ of the functional specification.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a description of each subsystem of
+ the TSF.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each module in terms of its
+ purpose, interfaces, return values from those interfaces,
+ and called interfaces to other modules.
+
+
+ The formal specification of the TSF subsystems shall
+ describe the TSF using a formal style, supported by
+ informal, explanatory text where appropriate.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The proof of correspondence between the formal
+ specifications of the TSF subsystems and of the functional
+ specification shall demonstrate that all behaviour described
+ in the TOE design is a correct and complete refinement of
+ the TSFI that invoked it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The guidance documents class provides the requirements for
+ guidance documentation for all user roles. For the secure
+ preparation and operation of the TOE it is necessary to
+ describe all relevant aspects for the secure handling of the
+ TOE. The class also addresses the possibility of unintended
+ incorrect configuration or handling of the TOE.
+
+ In many cases it may be appropriate that guidance is provided
+ in separate documents for preparation and operation of the
+ TOE, or even separate for different user roles as end-users,
+ administrators, application programmers using software or
+ hardware interfaces, etc.
+
+ The guidance documents class is subdivided into two families
+ which are concerned with the preparative user guidance (what
+ has to be done to transform the delivered TOE into its
+ evaluated configuration in the operational environment as
+ described in the ST) and with the operational user guidance
+ (what has to be done during the operation of the TOE in its
+ evaluated configuration).
+
+
+
+ Assurance class defines
+ requirements directed at the understandability, coverage and
+ completeness of the preparative and operational documentation
+ provided by the developer. This documentation, which provides
+ information for all user roles, is an important factor in the
+ secure preparation and operation of the TOE.
+
+
+
+ The purpose of the guidance document activity is to judge the
+ adequacy of the documentation describing how the user can
+ handle the TOE in a secure manner. Such documentation should
+ take into account the various types of users (e.g. those who
+ accept, install, administrate or operate the TOE) whose
+ incorrect actions could adversely affect the security of the
+ TOE or of their own data.
+
+ The guidance documents class is subdivided into two families
+ which are concerned firstly with the preparative user guidance
+ (all that has to be done to transform the delivered TOE into
+ its evaluated configuration in the environment as described in
+ the ST, i.e. accepting and installing the TOE) and secondly
+ with the operational user guidance (all that has to be done
+ during the operation of the TOE in its evaluated
+ configuration, i.e. operation and administration).
+
+
+
+ The guidance documents activity applies to those functions and
+ interfaces which are related to the security of the TOE. The
+ secure configuration of the TOE is described in the ST.
+
+
+
+
+ Operational user guidance refers to written material that is
+ intended to be used by all types of users of the TOE in its
+ evaluated configuration: end-users, persons responsible for
+ maintaining and administering the TOE in a correct manner
+ for maximum security, and by others (e.g. programmers) using
+ the TOE's external interfaces. Operational user guidance
+ describes the security functionality provided by the TSF,
+ provides instructions and guidelines (including warnings),
+ helps to understand the TSF and includes the
+ security-critical information, and the security-critical
+ actions required, for its secure use. Misleading and
+ unreasonable guidance should be absent from the guidance
+ documentation, and secure procedures for all modes of
+ operation should be addressed. Insecure states should be
+ easy to detect.
+
+ The operational user guidance provides a measure of
+ confidence that non-malicious users, administrators,
+ application providers and others exercising the external
+ interfaces of the TOE will understand the secure operation
+ of the TOE and will use it as intended. The evaluation of
+ the user guidance includes investigating whether the TOE can
+ be used in a manner that is insecure but that the user of
+ the TOE would reasonably believe to be secure. The objective
+ is to minimise the risk of human or other errors in
+ operation that may deactivate, disable, or fail to activate
+ security functionality, resulting in an undetected insecure
+ state.
+
+
+
+ Requirements for operational user guidance help ensure that
+ all types of users are able to operate the TOE in a secure
+ manner (e.g. the usage constraints assumed by the PP or ST
+ must be clearly explained and illustrated). It should be
+ excluded that the TOE can be used in a manner that is
+ insecure but that the user of the TOE would reasonably
+ believe to be secure. Operational user guidance is the
+ primary vehicle available to the developer for providing the
+ TOE users with the necessary background and specific
+ information on how to correctly use the TOE's protection
+ functions.
+
+ Operational user guidance must do two things. First, it
+ needs to explain what the security functionality accessible
+ by the user does and how it is to be used, so that users are
+ able to consistently and effectively protect their
+ information. Second, it needs to explain the user's role in
+ maintaining the TOE's security.
+
+
+
+ This family contains only one component.
+
+
+
+ There may be different user roles or groups that are
+ recognised by the TOE and that can interact with the
+ TSF. These user roles and groups should be taken into
+ consideration by the operational user guidance. They may be
+ roughly grouped into administrators and non-administrative
+ users, or more specifically grouped into persons responsible
+ for receiving, accepting, installing and maintaining the
+ TOE, application programmers, revisors, auditors,
+ daily-management, end-users. Each role can encompass an
+ extensive set of capabilities, or can be a single
+ one.
+
+ The requirement
+ encompasses the aspect that any warnings to the users during
+ operation of a TOE with regard to the TOE security
+ environment and the security objectives for the operational
+ environment described in the PP/ST are appropriately covered
+ in the user guidance.
+
+ The concept of secure values, as employed in , has relevance where a user
+ has control over security parameters. Guidance needs to be
+ provided on secure and insecure settings for such
+ parameters.
+
+ requires that the
+ user guidance describes the appropriate reactions to all
+ security-relevant events. Although many security-relevant
+ events are the result of performing functions, this need not
+ always be the case (e.g. the audit log fills up, an
+ intrusion is detected). Furthermore, a security-relevant
+ event may happen as a result of a specific chain of
+ functions or, conversely, several security-relevant events
+ may be triggered by one function.
+
+ requires that the
+ user guidance is clear and reasonable. Misleading or
+ unreasonable guidance may result in a user of the TOE
+ believing that the TOE is secure when it is not.
+
+ An example of misleading guidance would be the description
+ of a single guidance instruction that could be parsed in
+ more than one way, one of which may result in an insecure
+ state.
+
+ An example of unreasonable guidance would be a
+ recommendation to follow a procedure that is so complicated
+ that it cannot reasonably be expected that users will follow
+ this guidance.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the user guidance describes for each user role the
+ security functionality and interfaces provided by the TSF,
+ provides instructions and guidelines for the secure use of
+ the TOE, addresses secure procedures for all modes of
+ operation, facilitates prevention and detection of
+ insecure TOE states, or whether it is misleading or
+ unreasonable.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design, if applicable;
+
+
+ the user guidance;
+
+
+
+
+ The developer shall provide operational user guidance.
+
+
+ The operational user guidance shall describe, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+
+ The operational user guidance shall describe, for each user
+ role, how to use the available interfaces provided by the
+ TOE in a secure manner.
+
+
+ The operational user guidance shall describe, for each user
+ role, the available functions and interfaces, in particular
+ all security parameters under the control of the user,
+ indicating secure values as appropriate.
+
+
+ The operational user guidance shall, for each user role,
+ clearly present each type of security-relevant event
+ relative to the user-accessible functions that need to be
+ performed, including changing the security characteristics
+ of entities under the control of the TSF.
+
+
+ The operational user guidance shall identify all possible
+ modes of operation of the TOE (including operation following
+ failure or operational error), their consequences and
+ implications for maintaining secure operation.
+
+
+ The operational user guidance shall, for each user role,
+ describe the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+
+ The operational user guidance shall be clear and reasonable.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+ The configuration of the TOE may allow different user
+ roles to have dissimilar privileges in making use of the
+ different functions of the TOE. This means that some
+ users are authorised to perform certain functions, while
+ other users may not be so authorised. These functions
+ and privileges should be described, for each user role,
+ by the user guidance.
+
+ The user guidance identifies, for each user role, the
+ functions and privileges that must be controlled, the
+ types of commands required for them, and the reasons for
+ such commands. The user guidance should contain warnings
+ regarding the use of these functions and
+ privileges. Warnings should address expected effects,
+ possible side effects, and possible interactions with
+ other functions and privileges.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the secure use of the available interfaces
+ provided by the TOE.
+
+ The user guidance should provide advice regarding
+ effective use of the TSF (e.g. reviewing password
+ composition practises, suggested frequency of user file
+ backups, discussion on the effects of changing user
+ access privileges).
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the available security functionality and
+ interfaces, in particular all security parameters under
+ the control of the user, indicating secure values as
+ appropriate.
+
+ The user guidance should contain an overview of the
+ security functionality that is visible at the user
+ interfaces.
+
+ The user guidance should identify and describe the
+ purpose, behaviour, and interrelationships of the
+ security interfaces and functionality.
+
+ For each user-accessible interface, the user guidance
+ should:
+
+
+ describe the method(s) by which the interface is
+ invoked (e.g. command-line, programming-language
+ system call, menu selection, command button);
+
+
+ describe the parameters to be set by the user, their
+ particular purposes, valid and default values, and
+ secure and insecure use settings of such parameters,
+ both individually or in combination;
+
+
+ describe the immediate TSF response, message, or
+ code returned.
+
+
+
+ The evaluator should consider the functional
+ specification and the ST to determine that the TSF
+ described in these documents is consistent to the
+ operational user guidance. The evaluator has to ensure
+ that the operational user guidance is complete to allow
+ the secure use through the TSFI available to all types
+ of human users. The evaluator may, as an aid, prepare an
+ informal mapping between the guidance and these
+ documents. Any omissions in this mapping may indicate
+ incompleteness.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, each type of security-relevant event relative to
+ the user functions that need to be performed, including
+ changing the security characteristics of entities under
+ the control of the TSF and operation following failure
+ or operational error.
+
+ All types of security-relevant events are detailed for
+ each user role, such that each user knows what events
+ may occur and what action (if any) he may have to take
+ in order to maintain security. Security-relevant events
+ that may occur during operation of the TOE (e.g. audit
+ trail overflow, system crash, updates to user records,
+ such as when a user account is removed when the user
+ leaves the organisation) are adequately defined to allow
+ user intervention to maintain secure operation.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance and other evaluation evidence to determine that
+ the guidance identifies all possible modes of operation
+ of the TOE (including, if applicable, operation
+ following failure or operational error), their
+ consequences and implications for maintaining secure
+ operation.
+
+ Other evaluation evidence, particularly the functional
+ specification, provide an information source that the
+ evaluator should use to determine that the guidance
+ contains sufficient guidance information.
+
+ If test documentation is included in the assurance
+ package, then the information provided in this evidence
+ can also be used to determine that the guidance contains
+ sufficient guidance documentation. The detail provided
+ in the test steps can be used to confirm that the
+ guidance provided is sufficient for the use and
+ administration of the TOE.
+
+ The evaluator should focus on a single human visible
+ TSFI at a time, comparing the guidance for securely
+ using the TSFI with other evaluation evidence, to
+ determine that the guidance related to the TSFI is
+ sufficient for the secure usage (i.e. consistent with
+ the SFRs) of that TSFI. The evaluator should also
+ consider the relationships between interfaces, searching
+ for potential conflicts.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+ The evaluator analyses the security objectives for the
+ operational environment in the ST and determines that
+ for each user role, the relevant security measures are
+ described appropriately in the user guidance.
+
+ The security measures described in the user guidance
+ should include all relevant external procedural,
+ physical, personnel and connectivity measures.
+
+ Note that those measures relevant for secure
+ installation of the TOE are examined in .
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is clear.
+
+ The guidance is unclear if it can reasonably be
+ misconstrued by an administrator or user, and used in a
+ way detrimental to the TOE, or to the security provided
+ by the TOE.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is reasonable.
+
+ The guidance is unreasonable if it makes demands on the
+ TOE's usage or operational environment that are
+ inconsistent with the ST or unduly onerous to maintain
+ security.
+
+
+
+
+
+
+
+ Preparative procedures are useful for ensuring that the TOE
+ has been received and installed in a secure manner as
+ intended by the developer. The requirements for preparation
+ call for a secure transition from the delivered TOE to its
+ initial operational environment. This includes investigating
+ whether the TOE can be configured or installed in a manner
+ that is insecure but that the user of the TOE would
+ reasonably believe to be secure.
+
+
+
+ Preparation requires that the delivered copy of the TOE is
+ accepted, configured and activated by the user to exhibit
+ the protection properties as needed during operation of the
+ TOE. The preparative procedures provide confidence that the
+ user will be aware of the TOE configuration parameters and
+ how they can affect the TSF.
+
+
+
+ This family contains only one component.
+
+
+
+ It is recognised that the application of these requirements
+ will vary depending on aspects such as whether the TOE is
+ delivered in an operational state, or whether it has to be
+ installed at the TOE owner's site, etc.
+
+ The first process covered by the preparative procedures is
+ the consumer's secure acceptance of the received TOE in
+ accordance with the developer's delivery procedures. If the
+ developer has not defined delivery procedures, security of
+ the acceptance has to be ensured otherwise.
+
+ Installation of the TOE includes transforming its
+ operational environment into a state that conforms to the
+ security objectives for the operational environment provided
+ in the ST.
+
+ It might also be the case that no installation is necessary,
+ for example a smart card. In this case it may be
+ inappropriate to require and analyse installation
+ procedures.
+
+ The requirements in this assurance family are presented
+ separately from those in the family, due to the infrequent, possibly
+ one-time use of the preparative procedures.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the procedures and steps for the secure preparation of the
+ TOE have been documented and result in a secure
+ configuration.
+
+
+
+ The preparative procedures refer to all acceptance and
+ installation procedures, that are necessary to progress
+ the TOE to the secure configuration as described in the
+ ST.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE including its preparative procedures;
+
+
+ the description of developer's delivery procedures, if
+ applicable;
+
+
+
+
+ The developer shall provide the TOE including its
+ preparative procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure acceptance
+ of the delivered TOE in accordance with the developer's
+ delivery procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure
+ installation of the TOE and for the secure preparation of
+ the operational environment in accordance with the security
+ objectives for the operational environment as described in
+ the ST.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the procedures necessary
+ for the secure acceptance of the delivered TOE have been
+ provided.
+
+ If it is not anticipated by the developer's delivery
+ procedures that acceptance procedures will or can be
+ applied, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+ The evaluator shall examine the provided acceptance
+ procedures to determine that they describe the steps
+ necessary for secure acceptance of the TOE in accordance
+ with the developer's delivery procedures.
+
+ The acceptance procedures should include as a minimum,
+ that the user has to check that all parts of the TOE as
+ indicated in the ST have been delivered in the correct
+ version.
+
+ The acceptance procedures should reflect the steps the
+ user has to perform in order to accept the delivered TOE
+ that are implied by the developer's delivery
+ procedures.
+
+ The acceptance procedures should provide detailed
+ information about the following, if applicable:
+
+
+ making sure that the delivered TOE is the complete
+ evaluated instance;
+
+
+ detecting modification/masquerading of the delivered
+ TOE.
+
+
+
+
+
+
+ The evaluator shall check that the procedures necessary
+ for the secure installation of the TOE have been
+ provided.
+
+ If it is not anticipated that installation procedures
+ will or can be applied for the TOE and the operational
+ environment (e.g. because the TOE may already be
+ delivered in an operational state and there are no
+ requirements for the environment) this work unit is not
+ applicable, and is therefore considered to be
+ satisfied.
+
+
+
+
+ The evaluator shall examine the provided installation
+ procedures to determine that they describe the steps
+ necessary for secure installation of the TOE and the
+ secure preparation of the operational environment in
+ accordance with the security objectives in the
+ ST.
+
+ If it is not anticipated that installation procedures
+ will or can be applied (e.g. because the TOE may already
+ be delivered in an operational state), this work unit is
+ not applicable, and is therefore considered to be
+ satisfied.
+
+ The installation procedures should provide detailed
+ information about the following, if applicable:
+
+
+ minimum system requirements for secure installation;
+
+
+ requirements for the operational environment in
+ accordance with the security objectives provided by
+ the ST;
+
+
+ changing the installation specific security
+ characteristics of entities under the control of the
+ TSF (for example parameters, settings, passwords);
+
+
+ handling exceptions and problems.
+
+
+
+
+
+ The evaluator shall apply the preparative procedures to
+ confirm that the TOE can be prepared securely for operation.
+
+
+ The evaluator shall perform all user procedures
+ necessary to prepare the TOE to determine that the TOE
+ and its operational environment can be prepared securely
+ using only the supplied preparative user
+ guidance.
+ Preparation requires the evaluator to advance the
+ TOE from a deliverable state to the state in which it is
+ operational, including acceptance and installation of
+ the TOE, and enforcing the SFRs consistent with the
+ security objectives for the TOE specified in the
+ ST.
+
+ The evaluator should follow only the developer's
+ procedures and may perform the activities that customers
+ are usually expected to perform to accept and install
+ the TOE, using the supplied preparative guidance
+ documentation only. Any difficulties encountered during
+ such an exercise may be indicative of incomplete,
+ unclear or unreasonable guidance.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+ If it is known that the TOE will be used as a dependent
+ component for a composed TOE evaluation, then the
+ evaluator should ensure that the operational environment
+ is satisfied by the base component used in the composed
+ TOE.
+
+
+
+
+
+
+
+
+ Life-cycle support is an aspect of establishing discipline and
+ control in the processes of refinement of the TOE during its
+ development and maintenance. Confidence in the correspondence
+ between the TOE security requirements and the TOE is greater
+ if security analysis and the production of the evidence are
+ done on a regular basis as an integral part of the development
+ and maintenance activities.
+
+ In the product life-cycle it is distinguished whether the TOE
+ is under the responsibility of the developer or the user
+ rather than whether it is located in the development or user
+ environment. The point of transition is the moment where the
+ TOE is handed over to the user. This is also the point of
+ transition from the to the class.
+
+ The class consists of seven
+ families. is the high-level
+ description of the TOE life-cycle; a more detailed description of the management
+ of the configuration items.
+ requires a minimum set of configuration items to be managed in
+ the defined way. is
+ concerned with the developer's physical, procedural,
+ personnel, and other security measures; with the development tools and implementation
+ standards used by the developer; with the handling of security flaws. defines the procedures used for
+ the delivery of the TOE to the consumer. Delivery processes
+ occurring during the development of the TOE are denoted rather
+ as transportations, and are handled in the context of
+ integration and acceptance procedures in other families of
+ this class.
+
+ Throughout this class, development and related terms
+ (developer, develop) are meant in the more general sense to
+ comprise development and production, whereas
+ production specifically means the process of transforming the
+ implementation representation into the final TOE.
+
+
+
+ Assurance class defines
+ requirements for assurance through the adoption of a well
+ defined life-cycle model for all the steps of the TOE
+ development, including flaw remediation procedures and
+ policies, correct use of tools and techniques and the security
+ measures used to protect the development environment.
+
+ Configuration management (CM) helps to ensure that the
+ integrity of the TOE is preserved, by preventing unauthorised
+ modifications, additions, or deletions to the TOE, thus
+ providing assurance that the TOE and documentation used for
+ evaluation are the ones prepared for distribution.
+
+ The delivery procedures define requirements for the measures,
+ procedures, and standards concerned with secure delivery of
+ the TOE, ensuring that the security protection offered by the
+ TOE is not compromised during the transfer to the user.
+
+
+
+ The purpose of the life-cycle support activity is to determine
+ the adequacy of the security procedures that the developer
+ uses during the development and maintenance of the TOE. These
+ procedures include the life-cycle model used by the developer,
+ the configuration management, the security measures used
+ throughout TOE development, the tools used by the developer
+ throughout the life-cycle of the TOE, the handling of security
+ flaws, and the delivery activity.
+
+ Poorly controlled development and maintenance of the TOE can
+ result in vulnerabilities in the implementation. Conformance
+ to a defined life-cycle model can help to improve controls in
+ this area. A measurable life-cycle model used for the TOE can
+ remove ambiguity in assessing the development progress of the
+ TOE.
+
+ The purpose of the configuration management activity is to
+ assist the consumer in identifying the evaluated TOE, to
+ ensure that configuration items are uniquely identified, and
+ the adequacy of the procedures that are used by the developer
+ to control and track changes that are made to the TOE. This
+ includes details on what changes are tracked, how potential
+ changes are incorporated, and the degree to which automation
+ is used to reduce the scope for error.
+
+ Developer security procedures are intended to protect the TOE
+ and its associated design information from interference or
+ disclosure. Interference in the development process may allow
+ the deliberate introduction of vulnerabilities. Disclosure of
+ design information may allow vulnerabilities to be more easily
+ exploited. The adequacy of the procedures will depend on the
+ nature of the TOE and the development process.
+
+ The use of well-defined development tools and the application
+ of implementation standards by the developer and by third
+ parties involved in the development process help to ensure
+ that vulnerabilities are not inadvertently introduced during
+ refinement.
+
+ The flaw remediation activity is intended to track security
+ flaws, to identify corrective actions, and to distribute the
+ corrective action information to TOE users.
+
+ The purpose of the delivery activity is to judge the adequacy
+ of the documentation of the procedures used to ensure that the
+ TOE is delivered to the consumer without modification.
+
+
+
+
+ Configuration management (CM) is one means for increasing
+ assurance that the TOE meets the SFRs. CM establishes this
+ by requiring discipline and control in the processes of
+ refinement and modification of the TOE and the related
+ information. CM systems are put in place to ensure the
+ integrity of the portions of the TOE that they control, by
+ providing a method of tracking any changes, and by ensuring
+ that all changes are authorised.
+
+ The objective of this family is to require the developer's
+ CM system to have certain capabilities. These are meant to
+ reduce the likelihood that accidental or unauthorised
+ modifications of the configuration items will occur. The CM
+ system should ensure the integrity of the TOE from the early
+ design stages through all subsequent maintenance
+ efforts.
+
+ The objective of introducing automated CM tools is to
+ increase the effectiveness of the CM system. While both
+ automated and manual CM systems can be bypassed, ignored, or
+ proven insufficient to prevent unauthorised modification,
+ automated systems are less susceptible to human error or
+ negligence.
+
+ The objectives of this family include the following:
+
+
+ ensuring that the TOE is correct and complete before it
+ is sent to the consumer;
+
+
+ ensuring that no configuration items are missed during
+ evaluation;
+
+
+ preventing unauthorised modification, addition, or
+ deletion of TOE configuration items.
+
+
+
+
+
+ Configuration management capabilities define the
+ characteristics of the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ the CM system capabilities, the scope of the CM
+ documentation and the evidence provided by the
+ developer.
+
+
+
+ While it is desired that CM be applied from the early design
+ stages and continue into the future, this family requires
+ that CM be in place and in use prior to the end of the
+ evaluation.
+
+ In the case where the TOE is a subset of a product, the
+ requirements of this family apply only to the TOE
+ configuration items, not to the product as a whole.
+
+ For developers that have separate CM systems for different
+ life-cycle phases (for example development, production
+ and/or the final product), it is required to document all of
+ them. For evaluation purposes, the separate CM systems
+ should be regarded as parts of an overall CM system which is
+ addressed in the criteria.
+
+ Similarly, if parts of the TOE are produced by different
+ developers or at different sites, the CM systems being in
+ use at the different places should be regarded as parts of
+ an overall CM system which is addressed in the criteria. In
+ this situation, integration aspects have also to be taken
+ into account.
+
+ Several elements of this family refer to configuration
+ items. These elements identify CM requirements to be imposed
+ on all items identified in the configuration list, but leave
+ the contents of the list to the discretion of the
+ developer. can be used to
+ narrow this discretion by identifying specific items that
+ must be included in the configuration list, and hence
+ covered by CM.
+
+ introduces a
+ requirement that the CM system uniquely identify all
+ configuration items. This also requires that modifications
+ to configuration items result in a new, unique identifier
+ being assigned to the configuration item.
+
+ introduces the
+ requirement that the evidence shall demonstrate that the CM
+ system operates in accordance with the CM plan. Examples of
+ such evidence might be documentation such as screen
+ snapshots or audit trail output from the CM system, or a
+ detailed demonstration of the CM system by the
+ developer. The evaluator is responsible for determining that
+ this evidence is sufficient to show that the CM system
+ operates in accordance with the CM plan.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ support the production of the TOE. This requires that the CM
+ system provide an automated means to assist in determining
+ that the correct configuration items are used in generating
+ the TOE.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ ascertain the changes between the TOE and its preceding
+ version. If no previous version of the TOE exists, the
+ developer still needs to provide an automated means to
+ ascertain the changes between the TOE and a future version
+ of the TOE.
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the
+ TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items.
+
+
+
+ This component contains an implicit evaluator action to
+ determine that the CM system is being used. As the
+ requirements here are limited to identification of the TOE
+ and provision of a configuration list, this action is
+ already covered by, and limited to, the existing work
+ units. At the
+ requirements are expanded beyond these two items, and more
+ explicit evidence of operation is required.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+ Assurance that the CM system uniquely identifies
+ all configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items, and whether the
+ ability to modify these items is properly
+ controlled.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide measures such that only
+ authorised changes are made to the configuration items.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan to determine that they
+ are effective in preventing unauthorised access to the
+ configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan. The CM plan needs not to be
+ a connected document, but it is recommended that there
+ is a single document that describes where the various
+ parts of the CM plan can be found. If the CM plan is no
+ single document, the list in the following work unit
+ gives hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain
+ the integrity of the TOE. The evaluator should check
+ that for each type of configuration item (e.g. design
+ documents or source code modules) contained in the
+ configuration list there are examples of the evidence
+ generated by the procedures described in the CM plan. In
+ this case, the approach to sampling will depend upon the
+ level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules
+ are identified in the configuration list, a different
+ sampling strategy should be applied compared to the case
+ in which there are only 5, or even 1. The emphasis of
+ this activity should be on ensuring that the CM system
+ is being operated correctly, rather than on the
+ detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM
+ system and the effective maintenance of configuration
+ items may be established by means of interview with
+ selected development staff. In conducting such
+ interviews, the evaluator should aim to gain a deeper
+ understanding of how the CM system is used in practise
+ as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that
+ such interviews should complement rather than replace
+ the examination of documentary evidence, and may not be
+ necessary if the documentary evidence alone satisfies
+ the requirement. However, given the wide scope of the CM
+ plan it is possible that some aspects (e.g. roles and
+ responsibilities) may not be clear from the CM plan and
+ records alone. This is one case where clarification may
+ be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that they
+ are automated and effective in preventing unauthorised
+ access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan. The CM plan needs not to be
+ a connected document, but it is recommended that there
+ is a single document that describes where the various
+ parts of the CM plan can be found. If the CM plan is no
+ single document, the list in the following work unit
+ gives hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+ If this work unit is applied to a dependent component
+ that is going to be integrated in a composed TOE, the CM
+ plan should consider the control of base components
+ obtained by the dependent TOE developer.
+
+ When obtaining the components the evaluators are to
+ verify the following:
+
+
+ Transfer of each base component from the base
+ component developer to the integrator (dependent TOE
+ developer) was performed in accordance with the base
+ component TOE's secure delivery procedures, as
+ reported in the base component TOE certification
+ report.
+
+
+ The component received has the same identifiers as
+ those stated in the ST and Certification Report for
+ the component TOE.
+
+
+ All additional material required by a developer for
+ composition (integration) is provided. This is to
+ include the necessary extract of the component TOE's
+ functional specification.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain
+ the integrity of the TOE. The evaluator should check
+ that for each type of configuration item (e.g. design
+ documents or source code modules) contained in the
+ configuration list there are examples of the evidence
+ generated by the procedures described in the CM plan. In
+ this case, the approach to sampling will depend upon the
+ level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules
+ are identified in the configuration list, a different
+ sampling strategy should be applied compared to the case
+ in which there are only 5, or even 1. The emphasis of
+ this activity should be on ensuring that the CM system
+ is being operated correctly, rather than on the
+ detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM
+ system and the effective maintenance of configuration
+ items may be established by means of interviews with
+ selected development staff. In conducting such
+ interviews, the evaluator should aim to gain a deeper
+ understanding of how the CM system is used in practise
+ as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that
+ such interviews should complement rather than replace
+ the examination of documentary evidence, and may not be
+ necessary if the documentary evidence alone satisfies
+ the requirement. However, given the wide scope of the CM
+ plan it is possible that some aspects (e.g. roles and
+ responsibilities) may not be clear from the CM plan and
+ records alone. This is one case where clarification may
+ be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+ Requiring that the CM system be able to identify the
+ version of the implementation representation from which
+ the TOE is generated helps to ensure that the integrity of
+ this material is preserved by the appropriate technical,
+ physical and procedural safeguards.
+
+ Providing an automated means of ascertaining changes
+ between versions of the TOE and identifying which
+ configuration items are affected by modifications to other
+ configuration items assists in determining the impact of
+ the changes between successive versions of the TOE. This
+ in turn can provide valuable information in determining
+ whether changes to the TOE result in all configuration
+ items being consistent with one another.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM documentation shall justify that the acceptance
+ procedures provide for an adequate and appropriate review of
+ changes to all configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM system shall ensure that the person responsible for
+ accepting a configuration item into CM is not the person who
+ developed it.
+
+
+ The CM system shall identify the configuration items that
+ comprise the TSF.
+
+
+ The CM system shall support the audit of all changes to the
+ TOE by automated means, including the originator, date, and
+ time in the audit trail.
+
+
+ The CM system shall provide an automated means to identify
+ all other configuration items that are affected by the
+ change of a given configuration item.
+
+
+ The CM system shall be able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the CM documentation to
+ determine that it justifies that the acceptance
+ procedures provide for an adequate and appropriate
+ review of changes to all configuration items.
+
+ The CM documentation should make it sufficiently clear
+ that by following the acceptance procedures only parts
+ of adequate quality are incorporated into the
+ TOE.
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that
+ they are automated and effective in preventing
+ unauthorised access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it ensures that the person responsible for
+ accepting a configuration item is not the person who
+ developed it.
+
+ The acceptance procedures describe who is responsible
+ for accepting a configuration item. From these
+ descriptions, the evaluator should be able to determine
+ that the person who developed a configuration item is in
+ no case responsible for its acceptance.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it identifies the configuration items that comprise
+ the TSF.
+
+ The CM documentation should describe how the CM system
+ identifies the configuration items that comprise the
+ TSF. The evaluator should select a sample of
+ configuration items covering each type of items,
+ particularly containing TSF and non-TSF items, and check
+ that they are correctly classified by the CM
+ system.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it supports the audit of all changes to the TOE by
+ automated means, including the originator, date, and
+ time in the audit trail.
+
+ The evaluator should inspect a sample of audit trails
+ and check, if they contain the minimum
+ information.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it provides an automated means to identify all
+ other configuration items that are affected by the
+ change of a given configuration item.
+
+ The CM documentation should describe how the CM system
+ identifies all other configuration items that are
+ affected by the change of a given configuration
+ item. The evaluator should select a sample of
+ configuration items, covering all types of items, and
+ exercise the automated means to determine that it
+ identifies all items that are affected by the change of
+ the selected item.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it is able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+ The CM documentation should describe how the CM system
+ identifies the version of the implementation
+ representation from which the TOE is generated. The
+ evaluator should select a sample of the parts used to
+ produce the TOE and should apply the CM system to verify
+ that it identifies the corresponding implementation
+ representation in the correct version.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan. The CM plan needs not to be
+ a connected document, but it is recommended that there
+ is a single document that describes where the various
+ parts of the CM plan can be found. If the CM plan is no
+ single document, the list in the following work unit
+ gives hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain
+ the integrity of the TOE. The evaluator should check
+ that for each type of configuration item (e.g. design
+ documents or source code modules) contained in the
+ configuration list there are examples of the evidence
+ generated by the procedures described in the CM plan. In
+ this case, the approach to sampling will depend upon the
+ level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules
+ are identified in the configuration list, a different
+ sampling strategy should be applied compared to the case
+ in which there are only 5, or even 1. The emphasis of
+ this activity should be on ensuring that the CM system
+ is being operated correctly, rather than on the
+ detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include
+ change control forms, or configuration item access
+ approval forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM
+ system and the effective maintenance of configuration
+ items may be established by means of interview with
+ selected development staff. In conducting such
+ interviews, the evaluator should aim to gain a deeper
+ understanding of how the CM system is used in practise
+ as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that
+ such interviews should complement rather than replace
+ the examination of documentary evidence, and may not be
+ necessary if the documentary evidence alone satisfies
+ the requirement. However, given the wide scope of the CM
+ plan it is possible that some aspects (e.g. roles and
+ responsibilities) may not be clear from the CM plan and
+ records alone. This is one case where clarification may
+ be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+ The evaluator shall determine that the application of the
+ production support procedures results in a TOE as provided
+ by the developer for testing activities.
+
+
+ The evaluator shall examine the production support
+ procedures to determine that by following these
+ procedures a TOE would be produced like that one
+ provided by the developer for testing activities.
+
+ If the TOE is a small software TOE and production
+ consists of compiling and linking, the evaluator might
+ confirm the adequacy of the production support
+ procedures by reapplying them himself.
+
+ If the production process of the TOE is more complicated
+ (as for example in the case of a smart card), but has
+ already started, the evaluator should inspect the
+ application of the production support procedures during
+ a visit of the development site. He might compare a copy
+ of the TOE produced in his presence with the samples
+ used for his testing activities.
+
+ For guidance on site visits see .
+
+ Otherwise the evaluator's determination should be based
+ on the documentary evidence provided by the
+ developer.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+ The objective of this family is to identify items to be
+ included as configuration items and hence placed under the
+ CM requirements of .
+ Applying configuration management to these additional items
+ provides additional assurance that the integrity of TOE is
+ maintained.
+
+
+
+ Configuration management scope indicates the TOE items that
+ need to be controlled by the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ which of the following are required to be included as
+ configuration items: the TOE and the evaluation evidence
+ required by the SARs; the parts of the TOE; the
+ implementation representation; security flaws; and
+ development tools and related information.
+
+
+
+ While mandates a list of
+ configuration items and that each item on this list be under
+ CM, leaves the contents of
+ the configuration list to the discretion of the
+ developer. narrows this
+ discretion by identifying items that must be included in the
+ configuration list, and hence come under the CM requirements
+ of .
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself and the evaluation evidence required by the other
+ SARs in the ST under CM provides assurance that they have
+ been modified in a controlled manner with proper
+ authorisations.
+
+
+
+ introduces the
+ requirement that the TOE itself and the evaluation
+ evidence required by the other SARs in the ST be included
+ in the configuration list and hence be subject to the CM
+ requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer performs configuration management on the TOE
+ and the evaluation evidence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; and the evaluation evidence required by the SARs.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, and the
+ evaluation evidence required by the other SARs under CM
+ provides assurance that they have been modified in a
+ controlled manner with proper authorisations.
+
+
+
+ introduces the
+ requirement that the parts that comprise the TOE (all
+ parts that are delivered to the consumer, for example
+ hardware parts or executable files) be included in the
+ configuration list and hence be subject to the CM
+ requirements of .
+
+ introduces the
+ requirement that the configuration list indicate the
+ developer of each TSF relevant configuration
+ item. ``Developer'' here does not refer to a person, but
+ to the organisation responsible for the development of the
+ item.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, and the evaluation evidence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; and
+ the parts that comprise the TOE.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration item
+ list includes the set of items required by the
+ CC.
+
+ The list includes at least the following:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the evaluation evidence required by the SARs.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+
+
+ introduces the
+ requirement that the TOE implementation representation be
+ included in the list of configuration items and hence be
+ subject to the CM requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ and the evaluation evidence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; and the implementation
+ representation.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+
+
+ introduces the
+ requirement that security flaws be included in the
+ configuration list and hence be subject to the CM
+ requirements of . This
+ requires that information regarding previous security
+ flaws and their resolution be maintained, as well as
+ details regarding current security flaws.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, and the evaluation evidence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; and security flaw reports and resolution
+ status.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database).
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+ Development tools play an important role in ensuring the
+ production of a quality version of the TOE. Therefore, it
+ is important to control modifications to these
+ tools.
+
+
+
+ introduces the
+ requirement that development tools and other related
+ information be included in the list of configuration items
+ and hence be subject to the CM requirements of . Examples of development tools
+ are programming languages and compilers. Information
+ pertaining to TOE generation items (such as compiler
+ options, generation options, and build options) is an
+ example of information relating to development
+ tools.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, development tools and related information,
+ and the evaluation evidence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; security flaw reports and resolution status;
+ and development tools and related information.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database);
+
+
+ all tools (incl. test software, if applicable)
+ involved in the development and production of the
+ TOE including the names, versions, configurations
+ and roles of each development tool, and related
+ documentation. E.g. for a software TOE:
+ ``development tools'' are usually programming
+ languages and compiler and ``related documentation''
+ comprises compiler and linker options. For a
+ hardware TOE, ``development tools'' might be
+ hardware design languages, simulation and synthesis
+ tools, compilers, and ``related documentation''
+ might comprise compiler options again.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ The concern of this family is the secure transfer of the
+ finished TOE from the development environment into the
+ responsibility of the user.
+
+ The requirements for delivery call for system control and
+ distribution facilities and procedures that detail the
+ measures necessary to provide assurance that the security of
+ the TOE is maintained during distribution of the TOE to the
+ user. For a valid distribution of the TOE, the procedures
+ used for the distribution of the TOE address the objectives
+ identified in the PP/ST relating to the security of the TOE
+ during delivery.
+
+
+
+ Delivery covers the procedures used to maintain security
+ during transfer of the TOE to the user, both on initial
+ delivery and as part of subsequent modification. It includes
+ special procedures or operations required to demonstrate the
+ authenticity of the delivered TOE. Such procedures and
+ measures are the basis for ensuring that the security
+ protection offered by the TOE is not compromised during
+ transfer. While compliance with the delivery requirements
+ cannot always be determined when a TOE is evaluated, it is
+ possible to evaluate the procedures that a developer has
+ developed to distribute the TOE to users.
+
+
+
+ This family contains only one component. An increasing level
+ of protection is established by requiring commensurability
+ of the delivery procedures with the assumed attack potential
+ in the family .
+
+
+
+ Transportations from subcontractors to the developer or
+ between different development sites are not considered here,
+ but in the family .
+
+ The end of the delivery phase is marked by the transfer of
+ the TOE into the responsibility of the user. This does not
+ necessarily coincide with the arrival of the TOE at the
+ user's location.
+
+ The delivery procedures should consider, if applicable,
+ issues such as:
+
+
+ ensuring that the TOE received by the consumer
+ corresponds precisely to the evaluated version of the
+ TOE;
+
+
+ avoiding or detecting any tampering with the actual
+ version of the TOE;
+
+
+ preventing submission of a false version of the TOE;
+
+
+ avoiding unwanted knowledge of distribution of the TOE
+ to the consumer: there might be cases where potential
+ attackers should not know when and how it is delivered;
+
+
+ avoiding or detecting the TOE being intercepted during
+ delivery; and
+
+
+ avoiding the TOE being delayed or stopped during
+ distribution.
+
+
+
+ The delivery procedures should include the recipient's
+ actions implied by these issues. The consistent description
+ of these implied actions is examined in the family, if present.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the delivery documentation describes all procedures used
+ to maintain security of the TOE when distributing the TOE
+ to the user.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the delivery documentation.
+
+
+
+
+ The developer shall document procedures for delivery of the
+ TOE or parts of it to the consumer.
+
+
+ The developer shall use the delivery procedures.
+
+
+ The evaluator shall examine aspects of the delivery
+ process to determine that the delivery procedures are
+ used.
+
+ The approach taken by the evaluator to check the
+ application of delivery procedures will depend on the
+ nature of the TOE, and the delivery process itself. In
+ addition to examination of the procedures themselves,
+ the evaluator seeks some assurance that they are applied
+ in practise. Some possible approaches are:
+
+
+ a visit to the distribution site(s) where practical
+ application of the procedures may be observed;
+
+
+ examination of the TOE at some stage during
+ delivery, or after the user has received it
+ (e.g. checking for tamper proof seals);
+
+
+ observing that the process is applied in practise
+ when the evaluator obtains the TOE through regular
+ channels;
+
+
+ questioning end users as to how the TOE was
+ delivered.
+
+
+
+ For guidance on site visits see .
+
+ It may be the case of a newly developed TOE that the
+ delivery procedures have yet to be exercised. In these
+ cases, the evaluator has to be satisfied that
+ appropriate procedures and facilities are in place for
+ future deliveries and that all personnel involved are
+ aware of their responsibilities. The evaluator may
+ request a ``dry run'' of a delivery if this is
+ practical. If the developer has produced other similar
+ products, then an examination of procedures in their use
+ may be useful in providing assurance.
+
+
+
+ The delivery documentation shall describe all procedures
+ that are necessary to maintain security when distributing
+ versions of the TOE to the consumer.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the delivery documentation
+ to determine that it describes all procedures that are
+ necessary to maintain security when distributing
+ versions of the TOE or parts of it to the
+ consumer.
+
+ The delivery documentation describes proper procedures
+ to maintain security of the TOE during transfer of the
+ TOE or its component parts and to determine the
+ identification of the TOE.
+
+ The delivery documentation should cover the entire TOE,
+ but may contain different procedures for different parts
+ of the TOE. The evaluation should consider the totality
+ of procedures.
+
+ The delivery procedures should be applicable across all
+ phases of delivery from the production environment to
+ the installation environment (e.g. packaging, storage
+ and distribution). Standard commercial practise for
+ packaging and delivery may be acceptable. This includes
+ shrink wrapped packaging, a security tape or a sealed
+ envelope. For the distribution, physical (e.g. public
+ mail or a private distribution service) or electronic
+ (e.g. electronic mail or downloading off the Internet)
+ procedures may be used.
+
+ Cryptographic checksums or a software signature may be
+ used by the developer to ensure that tampering or
+ masquerading can be detected. Tamper proof seals
+ additionally indicate if the confidentiality has been
+ broken. For software TOEs, confidentiality might be
+ assured by using encryption. If availability is of
+ concern, a secure transportation might be
+ required.
+
+ Interpretation of the term ``necessary to maintain
+ security'' will need to consider:
+
+
+ The nature of the TOE (e.g. whether it is software
+ or hardware).
+
+
+ The overall security level stated for the TOE by the
+ chosen level of the Vulnerability Assessment. If the
+ TOE is required to be resistant against attackers of
+ a certain potential in its intended environment,
+ this should also apply to the delivery of the
+ TOE. The evaluator should determine that a balanced
+ approach has been taken, such that delivery does not
+ present a weak point in an otherwise secure
+ development process.
+
+
+ The security objectives provided by the ST. In
+ particular, the security aspects (integrity,
+ confidentiality, availability) relevant for the
+ actual TOE should be derived from the security
+ objectives for the development environment defined
+ in the ST. The emphasis in the delivery
+ documentation is likely to be on measures related to
+ integrity, as integrity of the TOE is always
+ important. However, confidentiality and availability
+ of the delivery will be of concern in the delivery
+ of some TOEs; procedures relating to these aspects
+ of the secure delivery should also be discussed in
+ the procedures.
+
+
+
+
+
+
+
+
+
+ Development security is concerned with physical, procedural,
+ personnel, and other security measures that may be used in
+ the development environment to protect the TOE and its
+ parts. It includes the physical security of the development
+ location and any procedures used to select development
+ staff.
+
+
+
+ Development security covers the physical, procedural,
+ personnel, and other security measures used in the
+ development environment. It includes physical security of
+ the development location(s) and controls on the selection
+ and hiring of development staff.
+
+
+
+ The components in this family are levelled on the basis of
+ whether justification of the sufficiency of the security
+ measures is required.
+
+
+
+ This family deals with measures to remove or reduce threats
+ existing at the developer's site.
+
+ The evaluator should visit the site(s) in order to assess
+ evidence for development security. This may include sites of
+ subcontractors involved in the TOE development and
+ production. Any decision not to visit shall be agreed with
+ the evaluation authority.
+
+ Although development security deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, the requirements specify only that the
+ development security measures be in place at the time of
+ evaluation. Furthermore,
+ does not contain any requirements related to the sponsor's
+ intention to apply the development security measures in the
+ future, after completion of the evaluation.
+
+ It is recognised that confidentiality may not always be an
+ issue for the protection of the TOE in its development
+ environment. The use of the word ``necessary'' allows for
+ the selection of appropriate safeguards.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first
+ referring to the ST for any information that may assist
+ in the determination of necessary protection, especially
+ the security objectives for the development
+ environment.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material within and out of
+ the development environment and between
+ different development sites in accordance with
+ defined acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ These include the policies governing:
+
+
+ what information relating to the TOE development
+ needs to be kept confidential, and which members of
+ the development staff are allowed to access such
+ material;
+
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the , mandating only necessary measures, are
+ dependent on the nature of the TOE, and on information
+ that may be provided in the ST. For example, the ST may
+ identify a security objective for the development
+ environment that requires the TOE to be developed by
+ staff that has security clearance. The evaluators would
+ then determine that such a policy had been applied under
+ this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised. Additionally, sufficiency of the measures
+ as applied is intended be justified.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The development security documentation shall justify that
+ the security measures provide the necessary level of
+ protection to maintain the confidentiality and integrity of
+ the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first
+ referring to the ST for any information that may assist
+ in the determination of necessary protection, especially
+ the security objectives for the development
+ environment.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material out of the
+ development environment and between different
+ development sites in accordance with defined
+ acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by the ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in the .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that an appropriate
+ justification is given why the security measures provide
+ the necessary level of protection to maintain the
+ confidentiality and integrity of the TOE.
+
+ Since attacks on the TOE or its related information are
+ assumed in different design and production stages,
+ measures and procedures need to have an appropriate
+ level necessary to prevent those attacks or to make them
+ more difficult.
+
+ Since this level depends on the overall attack potential
+ claimed for the TOE (cf. the component chosen), the development
+ security documentation should justify the necessary
+ level of protection to maintain the confidentiality and
+ integrity of the TOE. This level has to be achieved by
+ the security measures applied.
+
+ The concept of protection measures should be consistent,
+ and the justification should include an analysis of how
+ the measures are mutually supportive. All aspects of
+ development and production on all the different sites
+ with all roles involved up to delivery of the TOE should
+ be analysed.
+
+ Justification may include an analysis of potential
+ vulnerabilities taking the applied security measures
+ into account.
+
+ There may be a convincing argument showing that e.g.
+
+
+ The technical measures and mechanisms of the
+ developer's infrastructure are sufficient for
+ keeping the appropriate security level
+ (e.g. cryptographic mechanisms as well as physical
+ protection mechanisms, properties of the CM system
+ (cf. ));
+
+ The system containing the implementation
+ representation of the TOE (including concerning
+ guidance documents) provides effective protection
+ against logical attacks e.g. by ``Trojan'' code or
+ viruses. It might be adequate, if the implementation
+ representation is kept on an isolated system where
+ only the software necessary to maintain it is
+ installed and where no additional software is
+ installed afterwards.
+
+ Data brought into this system should be carefully
+ considered to prevent the installation of hidden
+ functionality onto the system. The effectiveness of
+ these measures should be tested, e.g. by
+ independently trying to get access to the machine,
+ install some additional executable (program, macro
+ etc.) or get some information out of the machine
+ using logical attacks.
+
+ The appropriate organisational (procedural and
+ personal) measures are unconditionally
+ enforced.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ These include the policies governing:
+
+
+ what information relating to the TOE development
+ needs to be kept confidential, and which members of
+ the development staff are allowed to access such
+ material;
+
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the , mandating only necessary measures, are
+ dependent on the nature of the TOE, and on information
+ that may be provided in the ST. For example, the ST may
+ identify a security objective for the development
+ environment that requires the TOE to be developed by
+ staff that has security clearance. The evaluators would
+ then determine that such a policy had been applied under
+ this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ Flaw remediation requires that discovered security flaws be
+ tracked and corrected by the developer. Although future
+ compliance with flaw remediation procedures cannot be
+ determined at the time of the TOE evaluation, it is possible
+ to evaluate the policies and procedures that a developer has
+ in place to track and correct flaws, and to distribute the
+ flaw information and corrections.
+
+
+
+ Flaw remediation ensures that flaws discovered by the TOE
+ consumers will be tracked and corrected while the TOE is
+ supported by the developer. While future compliance with the
+ flaw remediation requirements cannot be determined when a
+ TOE is evaluated, it is possible to evaluate the procedures
+ and policies that a developer has in place to track and
+ repair flaws, and to distribute the repairs to
+ consumers.
+
+
+
+ The components in this family are levelled on the basis of
+ the increasing extent in scope of the flaw remediation
+ procedures and the rigour of the flaw remediation
+ policies.
+
+
+
+ This family provides assurance that the TOE will be
+ maintained and supported in the future, requiring the TOE
+ developer to track and correct flaws in the
+ TOE. Additionally, requirements are included for the
+ distribution of flaw corrections. However, this family does
+ not impose evaluation requirements beyond the current
+ evaluation.
+
+ The TOE user is considered to be the focal point in the user
+ organisation that is responsible for receiving and
+ implementing fixes to security flaws. This is not
+ necessarily an individual user, but may be an organisational
+ representative who is responsible for the handling of
+ security flaws. The use of the term TOE user recognises that
+ different organisations have different procedures for
+ handling flaw reporting, which may be done either by an
+ individual user, or by a central administrative body.
+
+ The flaw remediation procedures should describe the methods
+ for dealing with all types of flaws encountered. These flaws
+ may be reported by the developer, by users of the TOE, or by
+ other parties with familiarity with the TOE. Some flaws may
+ not be reparable immediately. There may be some occasions
+ where a flaw cannot be fixed and other (e.g. procedural)
+ measures must be taken. The documentation provided should
+ cover the procedures for providing the operational sites
+ with fixes, and providing information on flaws where fixes
+ are delayed (and what to do in the interim) or when fixes
+ are not possible.
+
+ Changes applied to a TOE after its release render it
+ unevaluated; although some information from the original
+ evaluation may still apply. The phrase ``release of the
+ TOE'' used in this family therefore refers to a version of a
+ product that is a release of a certified TOE, to which
+ changes have been applied.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE users.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation.
+
+
+
+
+ The developer shall document flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+ While these requirements do not mandate that there be a
+ publicised means for TOE users to report security flaws,
+ they do mandate that all security flaws that are
+ reported be tracked. That is, a reported security flaw
+ cannot be ignored simply because it comes from outside
+ the developer's organisation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACK DOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer. Flaw remediation guidance from the developer to
+ the TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, and for assurance that the corrections introduce no
+ new security flaws.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that they describe procedures
+ for the developer to accept reports of security flaws or
+ requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure every reported flaw is
+ corrected.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is corrected. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+
+ The procedures describe the process that is taken from
+ the point at which a security flaw is resolved to the
+ point at which the remediation procedures are
+ provided. The procedures for delivering corrective
+ actions should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer, and how to register themselves with the
+ developer so that they may receive these corrective
+ fixes. Flaw remediation guidance from the developer to the
+ TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, for assurance that the corrections introduce no new
+ security flaws, for the establishment of a point of
+ contact for each TOE user, and for the timely issue of
+ corrective actions to TOE users.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The flaw remediation procedures shall include a procedure
+ requiring timely response and the automatic distribution of
+ security flaw reports and the associated corrections to
+ registered users who might be affected by the security flaw.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users may register with the developer, to be
+ eligible to receive security flaw reports and corrections.
+
+
+ The flaw remediation guidance shall identify the specific
+ points of contact for all reports and enquiries about
+ security issues involving the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+ For TOE users who register with the developer (see work
+ unit ), the
+ passive availability of this information is not
+ sufficient. Developers must actively send the
+ information (or a notification of its availability) to
+ registered TOE users.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a means for the developer to
+ receive from TOE user reports of suspected security
+ flaws or requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a timely means of providing
+ the registered TOE users who might be affected with
+ reports about, and associated corrections to, each
+ security flaw.
+
+ The issue of timeliness applies to the issuance of both
+ security flaw reports and the associated
+ corrections. However, these need not be issued at the
+ same time. It is recognised that flaw reports should be
+ generated and issued as soon as an interim solution is
+ found, even if that solution is as drastic as turn off
+ the TOE. Likewise, when a more permanent (and less
+ drastic) solution is found, it should be issued without
+ undue delay.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done in a timely manner.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in automatic distribution of the
+ reports and associated corrections to the registered TOE
+ users who might be affected.
+
+ Automatic distribution does not mean
+ that human interaction with the distribution method is
+ not permitted. In fact, the distribution method could
+ consist entirely of manual procedures, perhaps through a
+ closely monitored procedure with prescribed escalation
+ upon the lack of issue of reports or corrections.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done automatically.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that every reported flaw
+ is remediated.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is remediated. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+ The procedures describe the process that is taken
+ from the point at which a security flaw is resolved to
+ the point at which the remediation procedures are
+ provided. The procedures for delivering remediation
+ procedures should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it describes a means of
+ enabling the TOE users to register with the
+ developer.
+
+ Enabling the TOE users to register with the
+ developer simply means having a way for each
+ TOE user to provide the developer with a point of
+ contact; this point of contact is to be used to
+ provide the TOE user with information related to
+ security flaws that might affect that TOE user, along
+ with any corrections to the security flaw. Registering
+ the TOE user may be accomplished as part of the
+ standard procedures that TOE users undergo to identify
+ themselves to the developer, for the purposes of
+ registering a software licence, or for obtaining
+ update and other useful information.
+
+ There need not be one registered TOE user per
+ installation of the TOE; it would be sufficient if there
+ were one registered TOE user for an organisation. For
+ example, a corporate TOE user might have a centralised
+ acquisition office for all of its sites. In this case,
+ the acquisition office would be a sufficient point of
+ contact for all of that TOE user's sites, so that all of
+ the TOE user's installations of the TOE have a
+ registered point of contact.
+
+ In either case, it must be possible to associate each
+ TOE that is delivered with an organisation in order to
+ ensure that there is a registered user for each TOE. For
+ organisations that have many different addresses, this
+ assures that there will be no user who is erroneously
+ presumed to be covered by a registered TOE user.
+ It should be noted that TOE users need not
+ register; they must only be provided with a means of
+ doing so. However, users who choose to register must be
+ directly sent the information (or a notification of its
+ availability).
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it identifies specific points
+ of contact for user reports and enquiries about security
+ issues involving the TOE.
+
+ The guidance includes a means whereby registered TOE
+ users can interact with the developer to report
+ discovered security flaws in the TOE or to make
+ enquiries regarding discovered security flaws in the
+ TOE.
+
+
+
+
+
+
+
+ Poorly controlled development and maintenance of the TOE can
+ result in a TOE that does not meet all of its
+ SFRs. Therefore, it is important that a model for the
+ development and maintenance of a TOE be established as early
+ as possible in the TOE's life-cycle.
+
+ Using a model for the development and maintenance of a TOE
+ does not guarantee that the TOE meets all of its SFRs. It is
+ possible that the model chosen will be insufficient or
+ inadequate and therefore no benefits in the quality of the
+ TOE can be observed. Using a life-cycle model that has been
+ approved by a group of experts (e.g. academic experts,
+ standards bodies) improves the chances that the development
+ and maintenance models will contribute to the TOE meeting
+ its SFRs. The use of a life-cycle model including some
+ quantitative valuation adds further assurance in the overall
+ quality of the TOE development process.
+
+
+
+ Life-cycle definition establishes that the engineering
+ practises used by a developer to produce the TOE include the
+ considerations and activities identified in the development
+ process and operational support requirements. Confidence in
+ the correspondence between the requirements and the TOE is
+ greater when quality control and the production of evidence
+ are done on a regular basis as an integral part of the
+ development process and operational support activities. It
+ is not the intent of this component to dictate any specific
+ development process.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements for measurability of the life-cycle
+ model, and for compliance with that model.
+
+
+
+ A life-cycle model encompasses the procedures, tools and
+ techniques used to develop and maintain the TOE. Aspects of
+ the process that may be covered by such a model include
+ design methods, review procedures, project management
+ controls, change control procedures, test methods and
+ acceptance procedures. An effective life-cycle model will
+ address these aspects of the development and maintenance
+ process within an overall management structure that assigns
+ responsibilities and monitors progress.
+
+ There are different types of acceptance situations that are
+ dealt with at different locations in the criteria:
+ acceptance of parts delivered by subcontractors
+ (``integration'') should be treated in this family , acceptance subsequent to
+ internal transportations in , acceptance of parts into the CM system in
+ , and acceptance of the
+ delivered TOE by the consumer in . The first three types may overlap.
+
+ Although life-cycle definition deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, its evaluation adds assurance
+ through an analysis of the life-cycle information for the
+ TOE provided at the time of the evaluation.
+
+ A life-cycle model provides for the necessary control over
+ the development and maintenance of the TOE, if the model
+ enables sufficient minimisation of the danger that the TOE
+ will not meet its security requirement.
+
+ A measurable life-cycle model is a model using some
+ quantitative valuation (arithmetic parameters and/or
+ metrics) of the managed product in order to measure
+ development properties of the product. Typical metrics are
+ source code complexity metrics, defect density (errors per
+ size of code) or mean time to failure. For the security
+ evaluation all those metrics are of relevance, which are
+ used to increase quality by decreasing the probability of
+ faults and thereby in turn increasing assurance in the
+ security of the TOE.
+
+ One should take into account that there exist standardised
+ life cycle models on the one hand (like the waterfall model)
+ and standardised metrics on the other hand (like error
+ density), which may be combined. The CC does not require the
+ life cycle to follow exactly one standard defining both
+ aspects.
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented model of the
+ TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process.
+
+ The description of the life-cycle model should include:
+
+
+ information on the life-cycle phases of the TOE and
+ the boundaries between the subsequent phases;
+
+
+ information on the procedures, tools and techniques
+ used by the developer (e.g. for design, coding,
+ testing, bug-fixing);
+
+
+ overall management structure governing the
+ application of the procedures (e.g. an
+ identification and description of the individual
+ responsibilities for each of the procedures required
+ by the development and maintenance process covered
+ by the life-cycle model);
+
+
+ information on which parts of the TOE are delivered
+ by subcontractors, if subcontractors are involved.
+
+
+
+ does not require the
+ model used to conform to any standard life-cycle
+ model.
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented and measurable
+ model of the TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation;
+
+
+ information about the standard used;
+
+
+ the life-cycle output documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE, that is based
+ on a measurable life-cycle model.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The developer shall measure the TOE development using the
+ measurable life-cycle model.
+
+
+ The developer shall provide life-cycle output documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE, including the
+ details of its arithmetic parameters and/or metrics used to
+ measure the quality of the TOE and/or its development.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The life-cycle output documentation shall provide the
+ results of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process, including the
+ details of its arithmetic parameters and/or metrics used
+ to measure the TOE development.
+
+ The description of the life-cycle model should include:
+
+
+ information on the life-cycle phases of the TOE and
+ the boundaries between the subsequent phases;
+
+
+ information on the procedures, tools and techniques
+ used by the developer (e.g. for design, coding,
+ testing, bug-fixing);
+
+
+ overall management structure governing the
+ application of the procedures (e.g. an
+ identification and description of the individual
+ responsibilities for each of the procedures required
+ by the development and maintenance process covered
+ by the life-cycle model);
+
+
+ information on which parts of the TOE are delivered
+ by subcontractors, if subcontractors are involved;
+
+
+ information on the parameters/metrics that are used
+ to measure the TOE development. Metrics standards
+ typically include guides for measuring and producing
+ reliable products and cover the aspects reliability,
+ quality, performance, complexity and cost. For the
+ evaluation all those metrics are of relevance, which
+ are used to increase quality by decreasing the
+ probability of faults and thereby in turn increase
+ assurance in the security of the TOE.
+
+
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+ For the metrics/measurements used in the life-cycle
+ model, evidence has to be provided that shows how those
+ metrics/measurements usefully contribute to the
+ minimisation of the likelihood of flaws. This can be
+ viewed as the overall goal for measurement in an context. As a consequence the
+ metrics/measurements have to be selected based on their
+ capability to achieve that overall goal or contribute to
+ that. In the first place a metric/measure is suitable
+ with respect to if a
+ correlation between the metric/measure and the number of
+ flaws can be stated with a certain degree of
+ reliability. But also a metric/measure useful for
+ management purposes as for planning and monitoring the
+ TOE development are helpful since badly managed projects
+ are endangered to produce bad quality and to introduce
+ flaws.
+
+ It may be possible to use metrics for quality
+ improvement, for which this use is not obvious. For
+ example a metric to estimate the expected cost of a
+ product development may help quality, if the developer
+ can show that this is used to provide an adequate budget
+ for development projects and that this helps to avoid
+ quality problems arising from resource shortages.
+
+ It is not required that every single step in the life
+ cycle of the TOE is measurable. However the evaluator
+ should see from the description of the measures and
+ procedures that the metrics are appropriate to control
+ the overall quality of the TOE and to minimise possible
+ security flaws by this.
+
+
+
+
+ The evaluator shall examine the life-cycle output
+ documentation to determine that it provides the results
+ of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+ The results of the measurements and the life-cycle
+ progress of the TOE should be in accordance with the
+ life-cycle model.
+
+ The output documentation should not only include numeric
+ values of the metrics but should also document actions
+ taken as a result of the measurements and in accordance
+ with the model. For example there may be a requirement
+ that a certain design phase needs to be repeated, if
+ some error rates measured during testing are outside of
+ a defined threshold. In this case the documentation
+ should show that such action was taken, if indeed the
+ thresholds were not met.
+
+ If the evaluation is conducted in parallel with the
+ development of the TOE it may be possible that quality
+ measurements have not been used in the past. In this
+ case the evaluator should use the documentation of the
+ planned procedures in order to gain confidence that
+ corrective actions are defined if results of quality
+ measurements deviate from some threshold.
+
+
+
+
+
+
+
+ Tools and techniques is an aspect of selecting tools that
+ are used to develop, analyse and implement the TOE. It
+ includes requirements to prevent ill-defined, inconsistent
+ or incorrect development tools from being used to develop
+ the TOE. This includes, but is not limited to, programming
+ languages, documentation, implementation standards, and
+ other parts of the TOE such as supporting runtime
+ libraries.
+
+
+
+ Tools and techniques addresses the need to define the
+ development tools being used to analyse and implement the
+ TOE. It includes requirements concerning the development
+ tools and implementation dependent options of those
+ tools.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements on the description and scope of the
+ implementation standards and the documentation of
+ implementation-dependent options.
+
+
+
+ There is a requirement for well-defined development
+ tools. These are tools that are clearly and completely
+ described. For example, programming languages and computer
+ aided design (CAD) systems that are based on a standard
+ published by standards bodies are considered to be
+ well-defined. Self-made tools would need further
+ investigation to clarify whether they are
+ well-defined.
+
+ The requirement in is
+ especially applicable to programming languages so as to
+ ensure that all statements in the source code have an
+ unambiguous meaning.
+
+ In and , implementation guidelines may be accepted
+ as an implementation standard if they have been approved by
+ some group of experts (e.g. academic experts, standards
+ bodies). Implementation standards are normally public, well
+ accepted and common practise in a specific industry, but
+ developer-specific implementation guidelines may also be
+ accepted as a standard; the emphasis is on the
+ expertise.
+ Tools and techniques distinguishes between the
+ implementation standards applied by the developer () and the implementation
+ standards for ``all parts of the TOE'' () which include third party software,
+ hardware, or firmware. The configuration list introduced in
+ requires that for each TSF
+ relevant configuration item to indicate if it has been
+ generated by the TOE developer or by third party
+ developers.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable
+ results.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the subset of the implementation representation.
+
+
+
+
+ The developer shall identify each development tool being
+ used for the TOE.
+
+
+ The developer shall document the selected
+ implementation-dependent options of each development tool.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tools is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable results,
+ and whether implementation standards have been
+ applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall identify each development tool being
+ used for the TOE.
+
+
+ The developer shall document the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe the implementation standards
+ that are being applied by the developer.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is not required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, but only those parts
+ that are developed by the TOE developer himself. The
+ evaluator may consult the configuration list required by
+ the to get the
+ information which parts are developed by the TOE
+ developer, and which by third party developers.
+
+ If the referenced implementation standards are not
+ applied for at least parts of the provided
+ implementation representation, this work unit
+ fails.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer and his subcontractors have used
+ well-defined development tools (e.g. programming languages
+ or computer-aided design (CAD) systems) that yield
+ consistent and predictable results, and whether
+ implementation standards have been applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall identify each development tool being
+ used for the TOE.
+
+
+ The developer shall document the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe the implementation standards
+ that are being applied by the developer and by any
+ third-party providers for all parts of the TOE.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, including third party
+ contributions. This may require the evaluator to visit
+ the sites of contributors. The evaluator may consult the
+ configuration list required by the to see who has developed which part of
+ the TOE.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more other PPs or on packages, that the PP is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ writing an ST or another PP.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an PP to demonstrate that
+ the PP is sound and internally consistent, and, if the PP is
+ based on one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of a PP. The
+ requirements and methodology for PP evaluation are identical
+ for each PP evaluation, regardless of the EAL (or other set of
+ assurance requirements) that is claimed in the PP. The
+ evaluation methodology in this Clause is based on the
+ requirements on the PP as specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The PP is the description of a TOE type. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ an ST or another PP.
+
+
+
+
+ While evaluating a PP that is based on one or more certified
+ PPs, it may be possible to re-use the fact that these PPs
+ were certified. The potential for re-use of the result of a
+ certified PP is greater if the PP under evaluation does not
+ add threats, OSPs, assumptions, security objectives and/or
+ security requirements to those of the PP that conformance is
+ being claimed to. If the PP under evaluation contains much
+ more than the certified PP, re-use may not be useful at
+ all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP that conformance is being
+ claimed to contains a set of security requirements, and
+ these were determined to be internally consistent during its
+ evaluation. If the PP under evaluation uses the exact same
+ requirements, the consistency analysis does not have to be
+ repeated during the ST evaluation. If the PP under
+ evaluation adds one or more requirements, or performs
+ operations on these requirements, the analysis will have to
+ be repeated. However, it may be possible to save work in
+ this consistency analysis by using the fact that the
+ original requirements are internally consistent. If the
+ original requirements are internally consistent, the
+ evaluator only has to determine that:
+
+
+ the set of all new and/or changed requirements is
+ internally consistent, and
+
+
+ the set of all new and/or changed requirements is
+ consistent with the original requirements.
+
+ The evaluator notes in the ETR each case where analyses
+ are not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way.
+
+ Evaluation of the PP introduction is required to demonstrate
+ that the PP is correctly identified, and that the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The PP introduction describes the TOE in a narrative
+ way.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the PP is correctly identified, and whether the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a PP introduction.
+
+
+ The PP introduction shall contain a PP reference and a TOE
+ overview.
+
+
+ The PP reference shall uniquely identify the PP.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware available to the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the PP introduction
+ contains a PP reference and a TOE overview.
+
+
+
+
+ The evaluator shall examine the PP reference to
+ determine that it uniquely identifies the PP.
+
+ The evaluator determines that the PP reference
+ identifies the PP itself, so that it may be easily
+ distinguished from other PPs, and that it also uniquely
+ identifies each version of the PP, e.g. by including a
+ version number and/or a date of publication.
+
+ The PP should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features expected of the TOE. The TOE overview should
+ enable consumers and potential TOE developers to quickly
+ determine whether the PP is of interest to them.
+
+ The evaluator determines that the overview is clear
+ enough for TOE developers and consumers, and sufficient
+ to give them a general understanding of the intended
+ usage and major security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware available to the TOE.
+
+ While some TOEs may run stand-alone, other TOEs (notably
+ software TOEs) need additional hardware, software or
+ firmware to operate. In this subclause of the PP, the PP
+ author lists all hardware, software, and/or firmware
+ that will be available for the TOE to run on.
+
+ This identification should be detailed enough for
+ potential consumers and TOE developers to determine
+ whether their TOE may operate with the listed hardware,
+ software and firmware.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs and other PPs are to claim conformance with the
+ PP.
+
+
+
+ Conformance claims describes how the Protection Profile
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the PP conforms to the CC, other PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP;
+
+
+ the PP(s) that the PP claims conformance to;
+
+
+ the package(s) that the PP claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The developer shall provide a conformance statement.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the PP claims
+ conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the PP claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ PP to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance statement shall describe the conformance
+ required of any PPs/STs to the PP as strict-PP or
+ demonstrable-PP conformance.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the PP claims
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this PP. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the PP.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the PP.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the PP claims conformance.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+ The evaluator determines that any referenced PPs
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the PP claims conformance.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The relation between the types may be simple: a firewall
+ PP claiming conformance to another firewall PP, or more
+ complex: a smart card PP claiming conformance to a number
+ of other PPs at the same time: a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the PP under evaluation does not claim conformance
+ with another PP, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If the PP to which conformance is being claimed does not
+ have a statement of security problem definition, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether
+
+
+ the threats in the PP under evaluation are a
+ superset of or identical to the threats in the PP to
+ which conformance is being claimed;
+
+
+ the OSPs in the PP under evaluation are a superset
+ of or identical to the OSPs in the PP to which
+ conformance is being claimed;
+
+ the assumptions in the PP under evaluation are
+ identical to the OSPs in the PP to which conformance
+ is being claimed;
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ problem definition of the PP under evaluation is
+ equivalent or more restrictive than the statement of
+ security problem definition in the PP to which
+ conformance is being claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PPs, with the statement of security
+ objectives in the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether:
+
+ The PP under evaluation contains all security
+ objectives for the TOE of the PP to which
+ conformance is being claimed. Note that it is
+ allowed for the PP under evaluation to have
+ additional security objectives for the TOE;
+ The PP under evaluation contains exactly all
+ security objectives for the operational environment
+ (with one exception in the next bullet). Note that
+ it is not allowed for the PP under evaluation to
+ have additional security objectives for the
+ operational environment;
+ The PP under evaluation may specify that certain
+ objectives for the operational environment in the PP
+ that conformance is being claimed to are security
+ objectives for the TOE in the PP under
+ evaluation. This is a valid exception to the
+ previous bullet.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ objectives in the PP to which conformance is being
+ claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+
+
+ The evaluator shall examine the PP to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the PP
+ under evaluation is a superset of or identical to the
+ statement of security requirements in the PP to which
+ conformance is being claimed (for strict
+ conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ requirements in the PP to which conformance is being
+ claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+
+
+
+ The evaluator shall check that the PP conformance
+ statement states a claim of strict-PP or demonstrable-PP
+ conformance.
+
+
+
+
+
+
+
+ This part of the PP defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or its operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and/or threats only, OSPs need not be present in the
+ PP. In this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition and that
+ the division of this problem between the TOE and its
+ operational environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat, this
+ work unit fails.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP, this
+ work unit fails.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ If no security objectives for the operational
+ environment trace back to the assumption, this work unit
+ fails.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author. This family is used to determine that these extended
+ components are defined similarly to the existing CC Part 2
+ or CC Part 3 components.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the PP.
+
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the PP, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the PP defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+
+ a member of a new class defined in the PP.
+
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ PP, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the PP author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the PP does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations,
+ the evaluator determines that the extended functional
+ component is consistent with CC Part 1 .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the PP does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the PP does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance
+ component is consistent with CC Part 1 .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the PP does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the PP does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance to
+ this requirement.
+
+
+
+ The evaluator shall confirm that no extended component may
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component may
+ not be clearly expressed using existing
+ components.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the PP, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is, or whether the SFRs are derived from
+ security objectives for the TOE.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.Guidance on the
+ correct performance of operations may be found in CC
+ Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it justifies that the SFRs are suitable to
+ meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the
+ TOE, this work unit fails.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ If the SFRs that trace back to a security objective for
+ the TOE have any uncompleted assignments, or uncompleted
+ or restricted selections, the evaluator determines that
+ for every conceivable completion or combination of
+ completions of these operations, the security objective
+ is still met.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+ The evaluator is reminded that any explanation is
+ correct, as long as it is coherent and neither the SARs
+ nor the explanation have obvious inconsistencies with
+ the remainder of the PP.
+ An example of an obvious inconsistency between the
+ SARs and the remainder of the PP would be to have threat
+ agents that are very capable, but an SAR that does not protect against these
+ threat agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an ST, to demonstrate that
+ the ST is sound and internally consistent, and, if the ST is
+ based on one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of an ST. The ST
+ evaluation should be started prior to any TOE evaluation
+ sub-activities since the ST provides the basis and context to
+ perform these sub-activities. The evaluation methodology in
+ this subclause is based on the requirements on the ST as
+ specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The ST describes the security features of a TOE. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+
+
+
+ While evaluating an ST that is based on one or more
+ certified PPs, it may be possible to re-use the fact that
+ these PPs were certified. The potential for re-use of the
+ result of a certified PP is greater if the ST does not add
+ threats, OSPs, assumptions, security objectives and/or
+ security requirements to those of the PP. If the ST
+ contains much more than the certified PP, re-use may not be
+ useful at all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP contains a set of security
+ requirements, and these were determined to be internally
+ consistent during the PP evaluation. If the ST uses the
+ exact same requirements, the consistency analysis does not
+ have to be repeated during the ST evaluation. If the ST adds
+ one or more requirements, or performs operations on these
+ requirements, the analysis will have to be
+ repeated. However, it may be possible to save work in this
+ consistency analysis by using the fact that the original
+ requirements are internally consistent. If the original
+ requirements are internally consistent, the evaluator only
+ has to determine that:
+
+
+ the set of all new and/or changed requirements is
+ internally consistent, and
+
+
+ the set of all new and/or changed requirements is
+ consistent with the original requirements.
+
+
+ The evaluator notes in the ETR each case where analyses are
+ not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way on three levels of abstraction: TOE reference,
+ TOE overview and TOE description.
+
+ Evaluation of the ST introduction is required to demonstrate
+ that the ST and the TOE are correctly identified, that the
+ TOE is correctly described at three levels of abstraction
+ and that these three descriptions are consistent with each
+ other.
+
+
+
+ The ST introduction describes the TOE in a narrative way on
+ three levels of abstraction: TOE reference, TOE overview and
+ TOE description.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the ST and the TOE are correctly identified, whether the
+ TOE is correctly described in a narrative way at three
+ levels of abstraction (TOE reference, TOE overview and TOE
+ description), and whether these three descriptions are
+ consistent with each other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide an ST introduction.
+
+
+ The ST introduction shall contain an ST reference, a TOE
+ reference, a TOE overview and a TOE description.
+
+
+ The ST reference shall uniquely identify the ST.
+
+
+ The TOE reference shall identify the TOE.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware required by the TOE.
+
+
+ The TOE description shall describe the physical scope of the
+ TOE.
+
+
+ The TOE description shall describe the logical scope of the
+ TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the ST introduction
+ contains an ST reference, a TOE reference, a TOE
+ overview and a TOE description.
+
+
+
+
+ The evaluator shall examine the ST reference to
+ determine that it uniquely identifies the ST.
+
+ The evaluator determines that the ST reference
+ identifies the ST itself, so that it may be easily
+ distinguished from other STs, and that it also uniquely
+ identifies each version of the ST, e.g. by including a
+ version number and/or a date of publication.
+
+ In evaluations where a CM system is provided, the
+ evaluator may validate the uniqueness of the reference
+ by checking the configuration list. In the other cases,
+ the ST should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it identifies the TOE.
+
+ The evaluator determines that the TOE reference
+ identifies the TOE, so that it is clear to which TOE the
+ ST refers, and that it also identifies the version of
+ the TOE, e.g. by including a version/release/build
+ number, or a date of release.
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it is not misleading.
+
+ If the TOE is related to one or more well-known
+ products, it is allowed to reflect this in the TOE
+ reference. However, this should not be used to mislead
+ consumers: situations where only a small part of a
+ product is evaluated, yet the TOE reference does not
+ reflect this, are not allowed.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features of the TOE. The TOE overview should enable
+ potential consumers to quickly determine whether the TOE
+ may be suitable for their security needs.
+
+ The TOE overview in an ST for a composed TOE should
+ describe the usage and major security feature of the
+ composed TOE, rather than those of the individual
+ component TOEs.
+
+ The evaluator determines that the overview is clear
+ enough for consumers, and sufficient to give them a
+ general understanding of the intended usage and major
+ security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that the TOE type is not misleading.
+
+ There are situations where the general consumer would
+ expect certain functionality of the TOE because of its
+ TOE type. If this functionality is absent in the TOE,
+ the evaluator determines that the TOE overview
+ adequately discusses this absence.
+
+ There are also TOEs where the general consumer would
+ expect that the TOE should be able to operate in a
+ certain operational environment because of its TOE
+ type. If the TOE is unable to operate in such an
+ operational environment, the evaluator determines that
+ the TOE overview adequately discusses this.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware required by the TOE.
+
+ While some TOEs are able to run stand-alone, other TOEs
+ (notably software TOEs) need additional hardware,
+ software or firmware to operate. If the TOE does not
+ require any hardware, software or firmware, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the TOE overview
+ identifies any additional hardware, software and
+ firmware needed by the TOE to operate. This
+ identification does not have to be exhaustive, but
+ detailed enough for potential consumers of the TOE to
+ determine whether their current hardware, software and
+ firmware support use of the TOE, and, if this is not the
+ case, which additional hardware, software and/or
+ firmware is needed.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the physical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description lists
+ the hardware, firmware, software and guidance parts that
+ constitute the TOE and describes them at a level of
+ detail that is sufficient to give the reader a general
+ understanding of those parts.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any hardware, firmware,
+ software or guidance part is part of the TOE or
+ not.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the logical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description
+ discusses the logical security features offered by the
+ TOE at a level of detail that is sufficient to give the
+ reader a general understanding of those features.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any logical security
+ feature is offered by the TOE or not.
+
+ An ST for a composed TOE may refer out to the
+ description of the logical scope of the component TOEs,
+ provided in the component TOE STs to provide the
+ majority of this description for the composed TOE.
+ However, the evaluator determines that the composed TOE
+ ST clearly discusses which features of the individual
+ components are not within the composed TOE, and
+ therefore not a feature of the composed TOE.
+
+
+
+ The evaluator shall confirm that the TOE reference, the TOE
+ overview, and the TOE description are consistent with each
+ other.
+
+
+ The evaluator shall examine the TOE reference, TOE
+ overview and TOE description to determine that they are
+ consistent with each other.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs are to claim conformance with the PP.
+
+
+
+ Conformance claims describes how the Security Target
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the ST and the TOE conform to the CC and how the ST
+ conforms to PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the PP(s) that the ST claims conformance to;
+
+
+ the package(s) that the ST claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the ST and
+ the TOE claim conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the ST claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ ST to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the ST and the TOE claim
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this ST. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+ For a composed TOE, the evaluator will consider any
+ differences between the version of the CC claimed for a
+ component and the version of the CC claimed for the
+ composed TOE. If the versions differ the evaluator will
+ assess whether the differences between the versions will
+ lead to conflicting claims.
+
+ For instances where the CC conformance claims for the
+ base TOE and dependent TOE are for different major
+ releases of the CC (e.g. one component TOE conformance
+ claim is CC v2.x and the other component TOE conformance
+ claim is CC v3.x), the conformance claim for the
+ composed TOE will be the earlier release of the CC, as
+ the CC is developed with an aim to provide backwards
+ compatibility (although this may not be achieved in the
+ strictest sense, it is understood to be achieved in
+ principle).
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the ST.
+
+ For a composed TOE, the evaluator will consider whether
+ this claim is consistent not only with the CC Part 2,
+ but also with the claims of conformance to CC Part 2 by
+ each of the component TOEs. I.e. if one or more
+ component TOEs claims to be CC Part 2 extended, then the
+ composed TOE should also claim to be CC Part 2
+ extended.
+
+ The CC conformance claim for the composed TOE may be CC
+ Part 2 extended, even though the component TOEs are Part
+ 2 conformant, in the event that additional SFRs are
+ claimed for the base TOE (see composed TOE guidance for
+ )
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the ST.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the ST claims conformance.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that any referenced PPs are
+ unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted. Therefore,
+ conformance to a PP requiring a composite solution may
+ be claimed in an ST for a composed TOE. Conformance to
+ such a PP would not have been possible during the
+ evaluation of the component TOEs, as these components
+ would not have satisfied the composed solution. This is
+ only possible in the instances where the ``composite'' PP
+ permits use of the composition evaluation approach (use
+ of components).
+
+ The ST for a composed TOE will identify the STs of the
+ component TOEs from which the composed ST is comprised.
+ The composed TOE is essentially claiming conformance to
+ the STs of the component TOEs.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the ST claims conformance.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator determines that the component TOE STs from
+ which the composed TOE is derived are also unambiguously
+ identified.
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the ST
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package then the ST
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The relation between the types may be simple: a firewall
+ ST claiming conformance to a firewall PP, or more
+ complex: a smart card ST claiming conformance to a number
+ of PPs at the same time (a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card).
+
+ For a composed TOE, the evaluator will determine whether
+ the conformance claim rationale demonstrates that the
+ TOE types of the component TOEs are consistent with the
+ composed TOE type. This does not mean that both the
+ component and the composed TOE types have to be the
+ same, but rather that the component TOEs are suitable
+ for integration to provide the composed TOE. It should be made clear in the composed TOE ST which SFRs are only included as a result of composition, and were not examined as SFRs in the base and dependent TOE (e.g. EALx) evaluation.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the ST does not claim conformance with a PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the PP does not have a statement of security problem
+ definition, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether:
+
+
+ the threats in the ST are a superset of or identical
+ to the threats in the PP to which conformance is
+ being claimed;
+
+
+ the OSPs in the ST are a superset of or identical to
+ the OSPs in the PP to which conformance is being
+ claimed;
+
+ the assumptions in the ST are identical to the
+ assumptions in the PP to which conformance is being
+ claimed;
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security problem definition of the ST is equivalent or
+ more restrictive than the statement of security problem
+ definition in the PP to which conformance is being
+ claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+ For a composed TOE, the evaluator will consider whether
+ the security problem definition of the composed TOE is
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ Threat statements and OSPs in the composed TOE ST do
+ not contradict those from the component STs.
+
+ Any assumptions made in the component STs are upheld
+ in the composed TOE ST. That is, either the
+ assumption should also be present in the composed
+ ST, or the assumption should be positively addressed
+ in the composed ST. The assumption may be
+ positively addressed through specification of
+ requirements in the composed TOE to provide
+ functionality fulfilling the concern captured in the
+ assumption.
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PP, with the statement of security
+ objectives in the PPs.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP, no
+ conformance claim rationale is required. Instead, the
+ evaluator determines whether:
+
+ The ST contains all security objectives for the
+ TOE of the PP to which conformance is being
+ claimed. Note that it is allowed for the ST under
+ evaluation to have additional security objectives
+ for the TOE;
+ The ST contains exactly all security objectives
+ for the operational environment (with one exception
+ in the next bullet). Note that it is not allowed for
+ the ST under evaluation to have additional security
+ objectives for the operational environment;
+ The ST may specify that certain objectives for
+ the operational environment in the PP that
+ conformance is being claimed to are security
+ objectives for the TOE in the ST. This is a valid
+ exception to the previous bullet.
+
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the ST is equivalent or more restrictive
+ than the statement of security objectives in the PP to
+ which conformance is being claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+ For a composed TOE, the evaluator will consider whether
+ the security objectives of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment are consistent with the
+ statement of security objectives for the TOE in the
+ base TOE ST. It is not expected that the statement
+ of security objectives for the environment within in
+ the dependent TOE ST will cover all aspects of the
+ statement of security objectives for the TOE in the
+ base TOE ST.
+
+ The statement of security objectives in the composed
+ ST is consistent with the statements of security
+ objectives in the STs for the component TOEs.
+
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security objectives of the ST is at least equivalent to
+ the statement of security objectives in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+ The evaluator shall examine the ST to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the ST
+ is a superset of or identical to the statement of
+ security requirements in the PP to which conformance is
+ being claimed (for strict conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is equivalent or more restrictive
+ than the statement of security requirements in the PP to
+ which conformance is being claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+ For a composed TOE, the evaluator will consider whether
+ the security requirements of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance rationale to determine that:
+
+
+ The statement of security requirements in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security requirements for the
+ environment within in the dependent TOE ST will
+ cover all aspects of the statement of security
+ requirements for the TOE in the base TOE ST, as
+ some SFRs may need to be added to the statement of
+ security requirements in the composed TOE ST.
+ However, the statement of security requirements in
+ the base should support the operation of the dependent
+ component.
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security objectives for the environment
+ within in the dependent TOE ST will cover all
+ aspects of the statement of security requirements
+ for the TOE in the base TOE ST.
+
+ The statement of security requirements in the
+ composed is consistent with the statements of
+ security requirements in the STs for the component
+ TOEs.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is at least equivalent to the
+ statement of security requirements in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+
+
+
+ This part of the ST defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and threats only, OSPs need not be present in the ST. In
+ this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition, that the
+ division of this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat, this
+ work unit fails.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP, this
+ work unit fails.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ If no security objectives for the operational
+ environment trace back to the assumption, this work unit
+ fails.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the ST
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended components are defined wherever it is impossible to
+ clearly express requirements using only components from CC
+ Part 2 and/or CC Part 3.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the ST.
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the ST, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the ST defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+ a member of a new class defined in the ST.
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ ST, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the ST author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the ST does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations,
+ the evaluator determines that the extended functional
+ component is consistent with CC Part 1 .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the ST does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the ST does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance
+ component is consistent with CC Part 1 Subclause .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the ST does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the ST does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance
+ with this requirement.
+
+
+
+ The evaluator shall confirm that no extended component can
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component can
+ not be clearly expressed using existing
+ components.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the ST, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and canonical
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that a
+ security requirements rationale is provided which justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+ All subjects, objects,
+ operations, security attributes, external entities and other
+ terms that are used in the SFRs and the SARs shall be
+ defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFRs is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that all SARs are identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it demonstrates that the SFRs are suitable
+ to meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the
+ TOE, this work unit fails.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+
+ The evaluator is reminded that any explanation is correct,
+ as long as it is coherent and neither the SARs nor the
+ explanation have obvious inconsistencies with the
+ remainder of the PP.
+
+ An example of an obvious inconsistency between the SARs
+ and the remainder of the PP would be to have threat agents
+ that are very capable, but an SAR that does not protect against these threat
+ agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended assurance requirement
+ specifying an open source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+ The TOE summary specification enables evaluators and
+ potential consumers to gain a general understanding of how
+ the TOE is implemented.
+
+ Evaluation of the TOE summary specification is necessary to
+ determine whether it is adequately described how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass. and whether the TOE
+ summary specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The TOE Summary specification allows evaluators and
+ potential consumers of the TOE to gain a general
+ understanding of how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass.
+
+
+
+ The components in this family are levelled on whether the
+ TOE summary specification only needs to describe how the TOE
+ meets the SFRs, or whether the TOE summary specification
+ also needs to describe how the TOE protects itself against
+ logical tampering and bypass. This additional description
+ may be used in special circumstances where there might be a
+ specific concern regarding the TOE security architecture.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, and
+ whether the TOE summary specification is consistent with
+ other narrative descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ satisfy each SFR and that the descriptions therefore
+ should not be overly detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, whether
+ the TOE summary specification addresses interference,
+ logical tampering and bypass, and whether the TOE summary
+ specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against interference and logical tampering.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against bypass.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ satisfy each SFR and that the descriptions therefore
+ should not be overly detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against interference and logical
+ tampering.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against interference and logical
+ tampering and that the descriptions therefore should not
+ be overly detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against bypass.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against bypass and that the
+ descriptions therefore should not be overly
+ detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+ The class ``Tests'' encompasses four families: , ,
+ (i.e. functional testing
+ performed by evaluators), and . Testing provides assurance that the TSF
+ behaves as described (in the functional specification, TOE
+ design, and implementation representation).
+
+ The emphasis in this class is on confirmation that the TSF
+ operates according to its design descriptions. This class does
+ not address penetration testing, which is based upon an
+ analysis of the TSF that specifically seeks to identify
+ vulnerabilities in the design and implementation of the
+ TSF. Penetration testing is addressed separately as an aspect
+ of vulnerability assessment in the class.
+
+ The class separates testing into
+ developer testing and evaluator testing. The and families address the completeness of developer
+ testing. addresses the rigour
+ with which the functional specification is tested; addresses whether testing against
+ other design descriptions (security architecture, TOE design,
+ implementation representation) is required.
+
+ addresses the performing of
+ the tests by the developer and how this testing should be
+ documented. Finally, then
+ addresses evaluator testing: whether the evaluator should
+ repeat part or all of the developer testing and how much
+ independent testing the evaluator should do.
+
+
+
+ Assurance class states testing
+ requirements that demonstrate that the TOE matches its design
+ descriptions as provided in the
+ class.
+
+
+
+ The goal of this activity is to determine whether the TOE
+ behaves as described in the ST and as specified in the
+ evaluation evidence (described in the class). This determination is achieved through
+ some combination of the developer's own functional testing of
+ the TSF () and independent
+ testing the TSF by the evaluator (). At the lowest level of assurance, there is no
+ requirement for developer involvement, so the only testing is
+ conducted by the evaluator, using the limited available
+ information about the TOE. Additional assurance is gained as
+ the developer becomes increasingly involved both in testing
+ and in providing additional information about the TOE, and as
+ the evaluator increases the independent testing
+ activities.
+
+
+
+ Testing of the TSF is conducted by the evaluator and, in most
+ cases, by the developer. The evaluator's testing efforts
+ consist not only of creating and running original tests, but
+ also of assessing the adequacy of the developer's tests and
+ re-running a subset of them.
+
+ The evaluator analyses the developer's tests to determine the
+ extent to which they are sufficient to demonstrate that TSFI
+ (see ) perform as specified,
+ and to understand the developer's approach to
+ testing. Similarly, the evaluator analyses the developer's
+ tests to determine the extent to which they are sufficient to
+ demonstrate the internal behaviour and properties of the
+ TSF.
+ The evaluator also executes a subset of the developer's
+ tests as documented to gain confidence in the developer's test
+ results: the evaluator will use the results of this analysis
+ as an input to independently testing a subset of the TSF. With
+ respect to this subset, the evaluator takes a testing approach
+ that is different from that of the developer, particularly if
+ the developer's tests have shortcomings.
+
+ To determine the adequacy of developer's test documentation or
+ to create new tests, the evaluator needs to understand the
+ desired expected behaviour of the TSF, both internally and as
+ seen at the TSFI, in the context of the SFRs it is to
+ satisfy. The evaluator may choose to divide the TSF and TSFI
+ into subsets according to functional areas of the ST (audit
+ subsystem, audit-related TSFI, authentication module,
+ authentication-related TSFI, etc.) if they were not already
+ divided in the ST, and focus on one subset of the at a time,
+ examining the ST requirement and the relevant parts of the
+ development and guidance documentation to gain an
+ understanding of the way the TOE is expected to behave. This
+ reliance upon the development documentation underscores the
+ need for the dependencies on by
+ and .
+
+ The CC has separated coverage and depth from functional tests
+ to increase the flexibility when applying the components of
+ the families. However, the requirements of the families are
+ intended to be applied together to confirm that the TSF
+ operates according to its specification. This tight coupling
+ of families has led to some duplication of evaluator work
+ units across sub-activities. These application notes are used
+ to minimise duplication of text between sub-activities.
+
+
+ Before the adequacy of test documentation can be accurately
+ evaluated, or before new tests can be created, the evaluator
+ has to understand the desired expected behaviour of a
+ security function in the context of the requirements it is
+ to satisfy.
+
+ As mentioned earlier, the evaluator may choose to subset the
+ TSF and TSFI according to SFRs (audit, authentication, etc.)
+ in the ST and focus on one subset at a time. The evaluator
+ examines each ST requirement and the relevant parts of the
+ functional specification and guidance documentation to gain
+ an understanding of the way the related TSFI is expected to
+ behave. Similarly, the evaluator examines the relevant parts
+ of the TOE design and security architecture documentation to
+ gain an understanding of the way the related modules or
+ subsystems of the TSF are expected to behave.
+
+ With an understanding of the expected behaviour, the
+ evaluator examines the test plan to gain an understanding of
+ the testing approach. In most cases, the testing approach
+ will entail a TSFI being stimulated and its responses
+ observed. Externally-visible functionality can be tested
+ directly; however, in cases where functionality is not
+ visible external to the TOE (for example, testing the
+ residual information protection functionality), other means
+ will need to be employed.
+
+
+
+ In cases where it is impractical or inadequate to test
+ specific functionality (where it provides no
+ externally-visible TSFI), the test plan should identify the
+ alternate approach to verify expected behaviour. It is the
+ evaluator's responsibility to determine the suitability of
+ the alternate approach. However, the following should be
+ considered when assessing the suitability of alternate
+ approaches:
+
+
+ an analysis of the implementation representation to
+ determine that the required behaviour should be
+ exhibited by the TOE is an acceptable alternate
+ approach. This could mean a code inspection for a
+ software TOE or perhaps a chip mask inspection for a
+ hardware TOE.
+
+
+ it is acceptable to use evidence of developer
+ integration or module testing, even if the claimed
+ assurance requirements do not include availability of
+ lower level descriptions of the TOE modules (e.g. ) or implementation (). If evidence of developer
+ integration or module testing is used in verifying the
+ expected behaviour of a security functionality, care
+ should be given to confirm that the testing evidence
+ reflects the current implementation of the TOE. If the
+ subsystems or modules have been changed since testing
+ occurred, evidence that the changes were tracked and
+ addressed by analysis or further testing will usually be
+ required.
+
+
+
+ It should be emphasised that supplementing the testing
+ effort with alternate approaches should only be undertaken
+ when both the developer and evaluator determine that there
+ exists no other practical means to test the expected
+ behaviour.
+
+
+
+ Test pre-requisites are necessary to establish the required
+ initial conditions for the test. They may be expressed in
+ terms of parameters that must be set or in terms of test
+ ordering in cases where the completion of one test
+ establishes the necessary pre-requisites for another
+ test. The evaluator must determine that the pre-requisites
+ are complete and appropriate in that they will not bias the
+ observed test results towards the expected test
+ results.
+
+ The test steps and expected results specify the actions and
+ parameters to be applied to the TSFI as well as how the
+ expected results should be verified and what they are. The
+ evaluator must determine that the test steps and expected
+ results are consistent with the descriptions of the TSFI in
+ the functional specification. This means that each
+ characteristic of the TSFI behaviour explicitly described in
+ the functional specification should have tests and expected
+ results to verify that behaviour.
+
+ The overall aim of this testing activity is to determine
+ that each subsystem, module, and TSFI has been sufficiently
+ tested against the behavioural claims in the functional
+ specification, TOE design, and architecture description. At
+ the higher assurance levels, testing also includes bounds
+ testing and negative testing. The test procedures will
+ provide insight as to how the TSFIs, modules, and subsystems
+ have been exercised by the developer during testing. The
+ evaluator uses this information when developing additional
+ tests to independently test the TSF.
+
+
+
+
+
+ This family establishes that the TSF has been tested against
+ its functional specification. This is achieved through an
+ examination of developer evidence of correspondence.
+
+
+
+ Coverage deals with the completeness of the functional tests
+ performed by the developer on the TOE. It addresses the
+ extent to which the TSF is tested.
+
+
+
+ The components in this family are levelled on the basis of
+ specification.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to establish that some
+ of the TSFIs have been tested.
+
+
+
+ In this component the developer shows how tests in the
+ test documentation correspond to TSFIs in the functional
+ specification. This can be achieved by a statement of
+ correspondence, perhaps using a table.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+ The coverage analysis provided by the developer is
+ required to show the correspondence between the tests
+ provided as evaluation evidence and the functional
+ specification. However, the coverage analysis need not
+ demonstrate that all TSFI have been tested, or that all
+ externally-visible interfaces to the TOE have been
+ tested. Such shortcomings are considered by the evaluator
+ during the independent testing () sub-activity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage evidence.
+
+
+
+
+ The developer shall provide evidence of the test coverage.
+
+
+ The evidence of the test coverage shall show the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage evidence
+ to determine that the correspondence between the tests
+ identified in the test documentation and the TSFIs
+ described in the functional specification is
+ accurate.
+
+ Correspondence may take the form of a table or
+ matrix. The coverage evidence required for this
+ component will reveal the extent of coverage, rather
+ than to show complete coverage. In cases where coverage
+ is shown to be poor the evaluator should increase the
+ level of independent testing to compensate.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to confirm that all of
+ the TSFIs have been tested.
+
+
+
+ In this component the developer confirms that tests in the
+ test documentation correspond to all of the TSFIs in the
+ functional specification. This can be achieved by a
+ statement of correspondence, perhaps using a table, but
+ the developer also provides an analysis of the test
+ coverage.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested all of the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage analysis.
+
+
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the tests
+ in the test documentation and the interfaces in the
+ functional specification is accurate.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ interfaces presented in the test coverage analysis has
+ to be unambiguous.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the testing approach for each interface
+ demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that the test prerequisites, test steps and
+ expected result(s) adequately test each
+ interface.
+
+ Guidance on this work units, as it pertains to the
+ functional specification, can be found in:
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the
+ interfaces in the functional specification and the tests
+ in the test documentation is complete.
+
+ All TSFIs that are described in the functional
+ specification have to be present in the test coverage
+ analysis and mapped to tests in order for completeness
+ to be claimed, although exhaustive specification testing
+ of interfaces is not required. Incomplete coverage would
+ be evident if an interface was identified in the
+ functional specification and no test was mapped to
+ it.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to confirm that the
+ developer performed exhaustive tests of all interfaces in
+ the functional specification.
+
+ The objective of this component is to confirm that all
+ parameters of all of the TSFIs have been tested.
+
+
+
+ In this component the developer is required to show how
+ tests in the test documentation correspond to all of the
+ TSFIs in the functional specification. This can be
+ achieved by a statement of correspondence, perhaps using a
+ table, but in addition the developer is required to
+ demonstrate that the tests exercise all of the parameters
+ of all TSFIs. This additional requirement includes bounds
+ testing (i.e. verifying that errors are generated when
+ stated limits are exceeded) and negative testing
+ (e.g. when access is given to User A, verifying not only
+ that User A now has access, but also that User B did not
+ suddenly gain access). This kind of testing is not,
+ strictly speaking, exhaustive because not
+ every possible value of the parameters is expected to be
+ checked.
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been completely
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The components in this family deal with the level of detail
+ to which the TSF is tested by the developer. Testing of the
+ TSF is based upon increasing depth of information derived
+ from additional design representations and descriptions (TOE
+ design, implementation representation, and security
+ architecture description).
+
+ The objective is to counter the risk of missing an error in
+ the development of the TOE. Testing that exercises specific
+ internal interfaces can provide assurance not only that the
+ TSF exhibits the desired external security behaviour, but
+ also that this behaviour stems from correctly operating
+ internal functionality.
+
+
+
+ Depth deals with the level of detail to which the developer
+ tests the TSF. Testing is based upon increasing depth of
+ information derived from analysis of the TSF
+ representations.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing detail provided in the TSF representations, from
+ the TOE design to the implementation representation. This
+ levelling reflects the TSF representations presented in the
+ class.
+
+
+
+ The TOE design describes the internal components
+ (e.g. subsystems) and, perhaps, modules of the TSF, together
+ with a description of the interfaces among these components
+ and modules. Evidence of testing of this TOE design must
+ show that the internal interfaces have been exercised and
+ seen to behave as described. This may be achieved through
+ testing via the external interfaces of the TSF, or by
+ testing of the TOE component interfaces in isolation,
+ perhaps employing a test harness. In cases where some
+ aspects of an internal interface cannot be tested via the
+ external interfaces, there should either be justification
+ that these aspects need not be tested, or the internal
+ interface needs to be tested directly. In the latter case
+ the TOE design needs to be sufficiently detailed in order to
+ facilitate direct testing.
+
+ In cases where the description of the TSF's architectural
+ soundness (in ) cites
+ specific mechanisms, the tests performed by the developer
+ must show that the mechanisms have been exercised and seen
+ to behave as described.
+
+ At the highest component of this family, the testing is
+ performed not only against the TOE design, but also against
+ the implementation representation.
+
+
+
+
+
+
+
+ The subsystem descriptions of the TSF provide a high-level
+ description of the internal workings of the TSF. Testing
+ at the level of the TOE subsystems provides assurance that
+ the TSF subsystems behave and interact as described in the
+ TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSF subsystems against the
+ TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the descriptions of the
+ behaviour of TSF subsystems and of their interactions is
+ included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of
+ subsystems, this work unit addresses the interactions
+ among work units.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to
+ component interfaces in the TOE design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the SFR-enforcing
+ modules, of the TSF. Testing at this level of TOE
+ description provides assurance that the TSF subsystems and
+ SFR-enforcing modules behave and interact as described in
+ the TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSF subsystems against the
+ TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the SFR-enforcing modules in the TOE design have been
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of
+ subsystems, this work unit addresses the interactions
+ among work units.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of
+ SFR-enforcing modules are included within the test
+ documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms at the modular
+ level, this work unit also verifies the correspondence
+ between the tests and the descriptions of the behaviour
+ of such mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for each TSF module
+ interface demonstrates the expected behaviour of that
+ interface.
+
+ While work unit
+ addresses expected behaviour of subsystems, this work
+ unit addresses expected behaviour of the TSF module
+ interfaces that are covered by .
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to
+ component interfaces in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all interfaces of SFR-enforcing modules
+ are tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of SFR-enforcing modules that are provided in the TOE
+ design have to be tested. Incomplete depth of testing
+ would be evident if any interface of any SFR-enforcing
+ modules was identified in the TOE design and no tests
+ could be attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of an SFR-enforcing module in the TOE
+ design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSF subsystems against the
+ TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all modules in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are provided, the behaviour
+ of those subsystems may be performed directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are provided, the
+ interactions with other subsystems may be performed
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of TSF modules
+ are included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for each TSF module
+ interface demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to
+ component interfaces in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all interfaces of all modules are
+ tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of TSF modules that are provided in the TOE design have
+ to be tested. Incomplete depth of testing would be
+ evident if any interface of any TSF module was
+ identified in the TOE design and no tests could be
+ attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of a TSF module in the TOE design.
+
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description, and in accordance with the
+ implementation representation.
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all modules in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the TSF operates in accordance with its implementation
+ representation.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ Functional testing performed by the developer provides
+ assurance that the tests in the test documentation are
+ performed and documented correctly. The correspondence of
+ these tests to the design descriptions of the TSF is
+ achieved through the and
+ families.
+
+ This family contributes to providing assurance that the
+ likelihood of undiscovered flaws is relatively small.
+
+ The families , and are used in combination to define the evidence
+ of testing to be supplied by a developer. Independent
+ functional testing by the evaluator is specified by .
+
+
+
+ Functional testing establishes that the tests performed by
+ the developer are performed and documented correctly.
+
+
+
+ This family contains two components, the higher requiring
+ that ordering dependencies are analysed.
+
+
+
+ Procedures for performing tests are expected to provide
+ instructions for using test programs and test suites,
+ including the test environment, test conditions, test data
+ parameters and values. The test procedures should also show
+ how the test results are derived from the test
+ inputs.
+
+ Ordering dependencies are relevant when the successful
+ execution of a particular test depends upon the existence of
+ a particular state. For example, this might require that
+ test A be executed immediately before test B, since the
+ state resulting from the successful execution of test A is a
+ prerequisite for the successful execution of test B. Thus,
+ failure of test B could be related to a problem with the
+ ordering dependencies. In the above example, test B could
+ fail because test C (rather than test A) was executed
+ immediately before it, or the failure of test B could be
+ related to a failure of test A.
+
+
+
+
+
+ The objective is for the developer to demonstrate that the
+ tests in the test documentation are performed and
+ documented correctly.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented the tests
+ in the test documentation.
+
+
+
+ The extent to which the test documentation is required to
+ cover the TSF is dependent upon the coverage assurance
+ component.
+
+ For the developer tests provided, the evaluator determines
+ whether the tests are repeatable, and the extent to which
+ the developer's tests can be used for the evaluator's
+ independent testing effort. Any TSFI for which the
+ developer's test results indicate that it might not
+ perform as specified should be tested independently by the
+ evaluator to determine whether or not it does.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation.
+
+
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the test documentation
+ includes test plans, expected test results and actual
+ test results.
+
+ The evaluator checks that test plans, expected tests
+ results and actual test results are included in the test
+ documentation.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that it describes the scenarios for performing each
+ test.
+
+ The evaluator determines that the test plan provides
+ information about the test configuration being used:
+ both on the configuration of the TOE and on any test
+ equipment being used. This information should be
+ detailed enough to ensure that the test configuration is
+ reproducible.
+
+ The evaluator also determines that the test plan
+ provides information about how to execute the test: any
+ necessary automated set-up procedures (and whether they
+ require privilege to run), inputs to be applied, how
+ these inputs are applied, how output is obtained, any
+ automated clean-up procedures (and whether they require
+ privilege to run), etc. This information should be
+ detailed enough to ensure that the test is
+ reproducible.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the TOE test configuration is consistent with the
+ ST.
+
+ The TOE referred to in the developer's test plan should
+ have the same unique reference as established by the
+ sub-activities and
+ identified in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The evaluator verifies
+ that all test configurations identified in the developer
+ test documentation are consistent with the ST. For
+ example, the ST might define configuration options that
+ must be set, which could have an impact upon what
+ constitutes the TOE by including or excluding additional
+ portions. The evaluator verifies that all such
+ variations of the TOE are considered.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+ If this work unit is applied to a component TOE that
+ might be used/integrated in a composed TOE (see ), the following will apply. In
+ the instances that the component TOE under evaluation
+ depends on other components in the operational
+ environment to support their operation, the developer
+ may wish to consider using the other component(s) that
+ will be used in the composed TOE to fulfil the
+ requirements of the operational environment as one of
+ the test configurations. This will reduce the amount an
+ additional testing that will be required for the
+ composed TOE evaluation.
+
+
+
+
+ The evaluator shall examine the test plans to determine
+ that sufficient instructions are provided for any
+ ordering dependencies.
+
+ Some steps may have to be performed to establish initial
+ conditions. For example, user accounts need to be added
+ before they can be deleted. An example of ordering
+ dependencies on the results of other tests is the need
+ to perform actions in a test that will result in the
+ generation of audit records, before performing a test to
+ consider the searching and sorting of those audit
+ records. Another example of an ordering dependency
+ would be where one test case generates a file of data to
+ be used as input for another test case.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that all expected tests results are
+ included.
+
+ The expected test results are needed to determine
+ whether or not a test has been successfully
+ performed. Expected test results are sufficient if they
+ are unambiguous and consistent with expected behaviour
+ given the testing approach.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall check that the actual test results
+ in the test documentation are consistent with the
+ expected test results in the test documentation.
+
+ A comparison of the actual and expected test results
+ provided by the developer will reveal any
+ inconsistencies between the results. It may be that a
+ direct comparison of actual results cannot be made until
+ some data reduction or synthesis has been first
+ performed. In such cases, the developer's test
+ documentation should describe the process to reduce or
+ synthesise the actual data.
+
+ For example, the developer may need to test the contents
+ of a message buffer after a network connection has
+ occurred to determine the contents of the buffer. The
+ message buffer will contain a binary number. This binary
+ number would have to be converted to another form of
+ data representation in order to make the test more
+ meaningful. The conversion of this binary representation
+ of data into a higher-level representation will have to
+ be described by the developer in enough detail to allow
+ an evaluator to perform the conversion process
+ (i.e. synchronous or asynchronous transmission, number
+ of stop bits, parity, etc.).
+
+ It should be noted that the description of the process
+ used to reduce or synthesise the actual data is used by
+ the evaluator not to actually perform the necessary
+ modification but to assess whether this process is
+ correct. It is up to the developer to transform the
+ expected test results into a format that allows an easy
+ comparison with the actual test results.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall report the developer testing effort,
+ outlining the testing approach, configuration, depth and
+ results.
+
+ The developer testing information recorded in the ETR
+ allows the evaluator to convey the overall testing
+ approach and effort expended on the testing of the TOE
+ by the developer. The intent of providing this
+ information is to give a meaningful overview of the
+ developer testing effort. It is not intended that the
+ information regarding developer testing in the ETR be an
+ exact reproduction of specific test steps or results of
+ individual tests. The intention is to provide enough
+ detail to allow other evaluators and overseers to gain
+ some insight about the developer's testing approach,
+ amount of testing performed, TOE test configurations,
+ and the overall results of the developer testing.
+
+ Information that would typically be found in the ETR
+ subclause regarding the developer testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested,
+ including whether any privileged code was required
+ to set up the test or clean up afterwards;
+
+
+ testing approach. An account of the overall
+ developer testing strategy employed;
+
+
+ testing results. A description of the overall
+ developer testing results.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ developer testing effort.
+
+
+
+
+
+
+
+
+ The objectives are for the developer to demonstrate that
+ the tests in the test documentation are performed and
+ documented correctly, and to ensure that testing is
+ structured such as to avoid circular arguments about the
+ correctness of the interfaces being tested.
+
+
+
+ Although the test procedures may state pre-requisite
+ initial test conditions in terms of ordering of tests,
+ they may not provide a rationale for the ordering. An
+ analysis of test ordering is an important factor in
+ determining the adequacy of testing, as there is a
+ possibility of faults being concealed by the ordering of
+ tests.
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The test documentation shall include an analysis of the test
+ procedure ordering dependencies.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The objectives of this family are built upon the assurances
+ achieved in the , , and
+ families by verifying the developer testing and performing
+ additional tests by the evaluator.
+
+
+
+ Independent testing specifies the degree to which the
+ testing of the TSF must be performed by a party other than
+ the developer (e.g. a third party). This family adds value
+ by the introduction of tests that are not part of the
+ developer's tests.
+
+
+
+ Levelling is based upon the amount of developer test
+ documentation and test support and the amount of evaluator
+ testing.
+
+
+
+ This family deals with the degree to which there is
+ independent functional testing of the TSF. Independent
+ functional testing may take the form of repeating the
+ developer's functional tests (in whole or in part) or of
+ extending the scope or the depth of the developer's
+ tests. These activities are complementary, and an
+ appropriate mix must be planned for each TOE, which takes
+ into account the availability and coverage of test results,
+ and the functional complexity of the TSF.
+
+ Sampling of developer tests is intended to provide
+ confirmation that the developer has carried out his planned
+ test programme on the TSF, and has correctly recorded the
+ results. The size of sample selected will be influenced by
+ the detail and quality of the developer's functional test
+ results. The evaluator will also need to consider the scope
+ for devising additional tests, and the relative benefit that
+ may be gained from effort in these two areas. It is
+ recognised that repetition of all developer tests may be
+ feasible and desirable in some cases, but may be very
+ arduous and less productive in others. The highest component
+ in this family should therefore be used with
+ caution. Sampling will address the whole range of test
+ results available, including those supplied to meet the
+ requirements of both and
+ .
+
+ There is also a need to consider the different
+ configurations of the TOE that are included within the
+ evaluation. The evaluator will need to assess the
+ applicability of the results provided, and to plan his own
+ testing accordingly.
+
+ The suitability of the TOE for testing is based on the
+ access to the TOE, and the supporting documentation and
+ information required (including any test software or tools)
+ to run tests. The need for such support is addressed by the
+ dependencies to other assurance families.
+
+ Additionally, suitability of the TOE for testing may be
+ based on other considerations. For example, the version of
+ the TOE submitted by the developer may not be the final
+ version.
+
+ The term interfaces refers to interfaces
+ described in the functional specification and TOE design,
+ and parameters passed through invocations identified in the
+ implementation representation. The exact set of interfaces
+ to be used is selected through and the
+ components.
+
+ References to a subset of the interfaces are intended to
+ allow the evaluator to design an appropriate set of tests
+ which is consistent with the objectives of the evaluation
+ being conducted.
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents.
+
+
+
+ This component does not address the use of developer test
+ results. It is applicable where such results are not
+ available, and also in cases where the developer's testing
+ is accepted without validation. The evaluator is required
+ to devise and conduct tests with the objective of
+ confirming that the TOE operates in accordance with its
+ design representations, including but not limited to the
+ functional specification. The approach is to gain
+ confidence in correct operation through representative
+ testing, rather than to conduct every possible test. The
+ extent of testing to be planned for this purpose is a
+ methodology issue, and needs to be considered in the
+ context of a particular TOE and the balance of other
+ evaluation activities.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSFI, whether the
+ TOE behaves as specified in the functional specification
+ and guidance documentation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer should have the same
+ unique reference as established by the sub-activities and identified
+ in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state.
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall test a subset of the TSF interfaces to
+ confirm that the TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of the
+ interfaces. In other cases this may not be
+ cost-effective, and sampling is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of the interface. Complex interfaces may
+ require complex tests that impose onerous
+ requirements on the developer or evaluator, which
+ may not be conducive to cost-effective
+ evaluations. Conversely, they are a likely area to
+ find errors and are good candidates for the
+ subset. The evaluator will need to strike a balance
+ between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST and the functional specification, the
+ evaluator has to determine the most feasible way to test
+ the interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection, if the
+ implementation representation is available);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the behaviour of the
+ interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR
+ allows the evaluator to convey the overall testing
+ approach and effort expended on the testing activity
+ during the evaluation. The intent of providing this
+ information is to give a meaningful overview of the
+ testing effort. It is not intended that the information
+ regarding testing in the ETR be an exact reproduction of
+ specific test instructions or results of individual
+ tests. The intention is to provide enough detail to
+ allow other evaluators and overseers to gain some
+ insight about the testing approach chosen, amount of
+ testing performed, TOE test configurations, and the
+ overall results of the testing activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested;
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size;
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset;
+
+
+ interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset;
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ confirms that the developer performed some tests of some
+ interfaces in the functional specification.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ This component contains a requirement that the evaluator
+ has available test results from the developer to
+ supplement the programme of testing. The evaluator will
+ repeat a sample of the developer's tests to gain
+ confidence in the results obtained. Having established
+ such confidence the evaluator will build upon the
+ developer's testing by conducting additional tests that
+ exercise the TOE in a different manner. By using a
+ platform of validated developer test results the evaluator
+ is able to gain confidence that the TOE operates correctly
+ in a wider range of conditions than would be possible
+ purely using the developer's own efforts, given a fixed
+ level of resource. Having gained confidence that the
+ developer has tested the TOE, the evaluator will also have
+ more freedom, where appropriate, to concentrate testing in
+ areas where examination of documentation or specialist
+ knowledge has raised particular concerns.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSF, whether the TOE
+ behaves as specified in the design documentation, and to
+ gain confidence in the developer's test results by
+ performing a sample of the developer's tests.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design description;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the configuration management documentation;
+
+
+ the test documentation;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the developer
+ to functionally test the TSF
+
+ The set of resource used by the developer is documented
+ in the developer test plan, as considered in the family. The resource set may
+ include laboratory access and special test equipment,
+ among others. Resources that are not identical to those
+ used by the developer need to be equivalent in terms of
+ any impact they may have on test results.
+
+
+
+ The evaluator shall execute a sample of tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall conduct testing using a sample of
+ tests found in the developer test plan and
+ procedures.
+
+ The overall aim of this work unit is to perform a
+ sufficient number of the developer tests to confirm the
+ validity of the developer's test results. The evaluator
+ has to decide on the size of the sample, and the
+ developer tests that will compose the sample (see ).
+
+ All the developer tests can be traced back to specific
+ interfaces. Therefore, the factors to consider in the
+ selection of the tests to compose the sample are similar
+ to those listed for subset selection in work-unit . Additionally, the
+ evaluator may wish to employ a random sampling method to
+ select developer tests to include in the sample.
+
+
+
+ The evaluator shall check that all the actual test
+ results are consistent with the expected test
+ results.
+
+ Inconsistencies between the developer's expected test
+ results and actual test results will compel the
+ evaluator to resolve the discrepancies. Inconsistencies
+ encountered by the evaluator could be resolved by a
+ valid explanation and resolution of the inconsistencies
+ by the developer.
+
+ If a satisfactory explanation or resolution can not be
+ reached, the evaluator's confidence in the developer's
+ test results may be lessened and it may be necessary for
+ the evaluator to increase the sample size to the extent
+ that the subset identified in work unit is adequately tested:
+ deficiencies with the developer's tests need to result
+ in either corrective action to the developer's tests or
+ in the production of new tests by the evaluator.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces to
+ confirm that the TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The developer test evidence. The developer test
+ evidence consists of: the test documentation, the
+ available test coverage analysis, and the available
+ depth of testing analysis. The developer test
+ evidence will provide insight as to how the TSF has
+ been exercised by the developer during testing. The
+ evaluator applies this information when developing
+ new tests to independently test the
+ TOE. Specifically the evaluator should consider:
+
+
+ augmentation of developer testing for
+ interfaces. The evaluator may wish to perform
+ more of the same type of tests by varying
+ parameters to more rigorously test the
+ interface.
+
+
+ supplementation of developer testing strategy
+ for interfaces. The evaluator may wish to vary
+ the testing approach of a specific interface by
+ testing it using another test strategy.
+
+
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of them. In other
+ cases this may not be cost-effective, and sampling
+ is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Rigour of developer testing of the interfaces. Those
+ interfaces that the evaluator determines require
+ additional testing should be included in the test
+ subset.
+
+
+ Developer test results. If the results of developer
+ tests cause the evaluator to doubt that an interface
+ is not properly implemented, then the evaluator
+ should include such interfaces in the test subset.
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of interfaces. Interfaces that require
+ complex implementation may require complex tests
+ that impose onerous requirements on the developer or
+ evaluator, which may not be conducive to
+ cost-effective evaluations. Conversely, they are a
+ likely area to find errors and are good candidates
+ for the subset. The evaluator will need to strike a
+ balance between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST, the functional specification, and the
+ TOE design description, the evaluator has to determine
+ the most feasible way to test the
+ interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour of that interface.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR
+ allows the evaluator to convey the overall testing
+ approach and effort expended on the testing activity
+ during the evaluation. The intent of providing this
+ information is to give a meaningful overview of the
+ testing effort. It is not intended that the information
+ regarding testing in the ETR be an exact reproduction of
+ specific test instructions or results of individual
+ tests. The intention is to provide enough detail to
+ allow other evaluators and overseers to gain some
+ insight about the testing approach chosen, amount of
+ evaluator testing performed, amount of developer tests
+ performed, TOE test configurations, and the overall
+ results of the testing activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested.
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size.
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset.
+
+
+ Interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset.
+
+
+ developer tests performed. The amount of developer
+ tests performed and a brief description of the
+ criteria used to select the tests.
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate
+ that the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ includes repeating all of the developer tests.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ In this component the evaluator must repeat all of the
+ developer's tests as part of the programme of testing. As
+ in the previous component the evaluator will also conduct
+ tests that aim to exercise the TSF in a different manner
+ from that achieved by the developer. In cases where
+ developer testing has been exhaustive, there may remain
+ little scope for this.
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall execute all tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall test the TSF to confirm that the entire
+ TSF operates as specified.
+
+
+
+
+
+
+
+ The class addresses the
+ possibility of exploitable vulnerabilities introduced in the
+ development or the operation of the TOE.
+
+
+
+ Assurance class defines
+ requirements directed at the identification of exploitable
+ vulnerabilities. Specifically, it addresses those
+ vulnerabilities introduced in the development, operation,
+ misuse, or incorrect configuration of the TOE.
+
+
+
+ Generally, the vulnerability assessment activity covers
+ various vulnerabilities in the development and operation of
+ the TOE. Development vulnerabilities take advantage of some
+ property of the TOE which was introduced during its
+ development, e.g. defeating the TSF self protection through
+ tampering, direct attack or monitoring of the TSF, defeating
+ the TSF domain isolation through monitoring or direct attack
+ the TSF, or defeating non-bypassability through circumventing
+ (bypassing) the TSF. Operational vulnerabilities take
+ advantage of weaknesses in non-technical countermeasures to
+ violate the TOE SFRs, e.g. misuse or incorrect
+ configuration. Misuse investigates whether the TOE can be
+ configured or used in a manner that is insecure, but that an
+ administrator or user of the TOE would reasonably believe to
+ be secure.
+
+ Assessment of development vulnerabilities is covered by the
+ assurance family . Basically,
+ all development vulnerabilities can be considered in the
+ context of due to the fact,
+ that this family allows application of a wide range of
+ assessment methodologies being unspecific to the kind of an
+ attack scenario. These unspecific assessment methodologies
+ comprise, among other, also the specific methodologies for
+ those TSF where covert channels are to be considered (a
+ channel capacity estimation can be done using informal
+ engineering measurements, as well as actual test measurements)
+ or can be overcome by the use of sufficient resources in the
+ form of a direct attack (underlying technical concept of those
+ TSF is based on probabilistic or permutational mechanisms; a
+ qualification of their security behaviour and the effort
+ required to overcome them can be made using a quantitative or
+ statistical analysis).
+
+ If there are security objectives specified in the ST to either
+ to prevent one user of the TOE from observing activity
+ associated with another user of the TOE, or to ensure that
+ information flows cannot be used to achieve enforced illicit
+ data signals, covert channel analysis should be considered
+ during the conduct of the vulnerability analysis. This is
+ often reflected by the inclusion of and information flow policies (expressed through
+ multilevel access control policies in requirements in the ST.
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the exploitability of flaws or weaknesses in the TOE
+ in the operational environment. This determination is based
+ upon analysis of the evaluation evidence and a search of
+ publicly available material by the evaluator and is supported
+ by evaluator penetration testing.
+
+
+
+
+ Vulnerability analysis is an assessment to determine whether
+ potential vulnerabilities identified, during the evaluation
+ of the development and anticipated operation of the TOE or
+ by other methods (e.g. by flaw hypotheses or quantitative or
+ statistical analysis of the security behaviour of the
+ underlying security mechanisms), could allow attackers to
+ violate the SFRs.
+
+ Vulnerability analysis deals with the threats that an
+ attacker will be able to discover flaws that will allow
+ unauthorised access to data and functionality, allow the
+ ability to interfere with or alter the TSF, or interfere
+ with the authorised capabilities of other users.
+
+
+
+ Vulnerability analysis consists of the identification of
+ flaws potentially introduced in the different refinement
+ steps of the development (development vulnerabilities) or
+ through the application of the guidance in operation of the
+ TOE (operational vulnerabilities). It results in the
+ definition of penetration tests through the collection of
+ the necessary information concerning: (1) the completeness
+ of the TSF (does the TSF counter all the postulated
+ threats?), (2) the dependencies between all SFRs and (3)
+ whether any of the SFRs can be undermined through unexpected
+ behaviour of the TOE. These potential vulnerabilities are
+ assessed through penetration testing to determine whether
+ they could, in practise, be exploitable to compromise the
+ security of the TOE.
+
+ The characteristics of different levels of attack potential
+ are discussed in CEM .
+
+
+
+ Levelling is based on an increasing rigour of vulnerability
+ analysis by the evaluator and increased levels of attack
+ potential required by an attacker to identify and exploit
+ the potential vulnerabilities.
+
+
+
+
+
+
+
+ A vulnerability survey of information available in the
+ public domain is performed by the evaluator to ascertain
+ potential vulnerabilities that may be easily found by an
+ attacker.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has easily
+ identifiable exploitable vulnerabilities.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during the conduct of other parts of the
+ evaluation.
+
+ The use of the term guidance in this sub-activity refers
+ to the operational guidance and the preparative
+ guidance.
+
+ Potential vulnerabilities may be in information that is
+ publicly available, or not, and may require skill to
+ exploit, or not. These two aspects are related, but are
+ distinct. It should not be assumed that, simply because a
+ potential vulnerability is identifiable from information
+ that is publicly available, it can be easily
+ exploited.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the guidance documentation;
+
+
+ the TOE suitable for testing;
+
+
+ information publicly available to support the
+ identification of potential vulnerabilities.
+
+
+
+ Other input for this sub-activity is:
+
+
+ current information regarding potential
+ vulnerabilities (e.g. from an evaluation authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information, which
+ should be considered, e.g. mailing lists and security
+ forums on the world wide web that report known
+ vulnerabilities in specified technologies.
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks effectively operates to substantially
+ enhance the attack potential of a given attacker. The
+ accessibility of vulnerability information and
+ sophisticated attack tools on the Internet makes it more
+ likely that this information will be used in attempts to
+ identify potential vulnerabilities in the TOE and
+ exploit them. Modern search tools make such information
+ easily available to the evaluator, and the determination
+ of resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the information
+ publicly available. However, in this type of search, the
+ evaluator may not be able to describe the steps in
+ identifying potential vulnerabilities before the outset
+ of the examination, as the approach may evolve as a
+ result of findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as
+ necessary to determine the susceptibility of the TOE, in
+ its operational environment, to the potential
+ vulnerabilities identified during the search of the
+ sources of information publicly available. The evaluator
+ should have access to current information (e.g. from the
+ evaluation authority) regarding known potential
+ vulnerabilities that may not have been considered by the
+ evaluator, and may also have encountered potential
+ vulnerabilities as a result of performing other
+ evaluation activities.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses;
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing Basic
+ attack potential.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during other parts of the evaluation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the TOE using the guidance documentation,
+ functional specification, TOE design and security
+ architecture description to identify potential
+ vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a search of ST, guidance
+ documentation, functional specification, TOE design and
+ security architecture description evidence to identify
+ possible potential vulnerabilities in the TOE.
+
+ A search of the evidence should be completed whereby
+ specifications and documentation for the TOE are
+ analysed and then potential vulnerabilities in the TOE
+ are hypothesised, or speculated. The list of
+ hypothesised potential vulnerabilities is then
+ prioritised on the basis of the estimated probability
+ that a potential vulnerability exists and, assuming an
+ exploitable vulnerability does exist the attack
+ potential required to exploit it, and on the extent of
+ control or compromise it would provide. The prioritised
+ list of potential vulnerabilities is used to direct
+ penetration testing against the TOE.
+
+ The security architecture description provides the
+ developer vulnerability analysis, as it documents how
+ the TSF protects itself from interference from untrusted
+ subjects and prevents the bypass of security enforcement
+ functionality. Therefore, the evaluator should use this
+ description of the protection of the TSF as a basis for
+ the search for possible ways to undermine the
+ TSF.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as
+ necessary to determine the susceptibility of the TOE, in
+ its operational environment, to the potential
+ vulnerabilities identified during the search of the
+ sources of publicly available information and the
+ analysis of the TOE guidance and design evidence. The
+ evaluator should have access to current information
+ (e.g. from the evaluation authority) regarding known
+ potential vulnerabilities that may not have been
+ considered by the evaluator.
+
+ The evaluator is reminded that, as for considering the
+ security architecture description in the search for
+ vulnerabilities (as detailed in ), testing should be performed to confirm the
+ architectural properties. This is likely to require
+ negative tests attempting to disprove the properties of
+ the security architecture. In developing the strategy
+ for penetration testing, the evaluator will ensure that
+ each of the major characteristics of the security
+ architecture description are tested, either in
+ functional testing (as considered in ) or evaluator penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ Basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Enhanced-Basic, Moderate or
+ High attack potential do not result in a failure of this
+ evaluator action. Where analysis supports the
+ hypothesis, these need not be considered further as an
+ input to penetration testing. However, such
+ vulnerabilities are reported in the ETR as residual
+ vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic attack potential and
+ resulting in a violation of the security objectives
+ should be the highest priority potential vulnerabilities
+ comprising the list used to direct penetration testing
+ against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than an Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Enhanced-Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Enhanced-Basic attack potential.
+
+
+
+ During the conduct of evaluation activities the evaluator
+ may also identify areas of concern. These are specific
+ portions of the TOE evidence that the evaluator has some
+ reservation about, although the evidence meets the
+ requirements for the activity with which the evidence is
+ associated. For example, a particular interface
+ specification looks particularly complex, and therefore
+ may be prone to error either in the development of the TOE
+ or in the operation of the TOE. There is no potential
+ vulnerability apparent at this stage, further
+ investigation is required. This is beyond the bounds of
+ encountered, as further investigation is required.
+
+ The focused approach to the identification of potential
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. Further
+ guidance on focused vulnerability analysis can be found in
+ Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation subset selected;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the TOE using the guidance documentation,
+ functional specification, TOE design, security architecture
+ description and implementation representation to identify
+ potential vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a focused search of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ A flaw hypothesis methodology should be used whereby
+ specifications and development and guidance evidence are
+ analysed and then potential vulnerabilities in the TOE
+ are hypothesised, or speculated.
+
+ The evaluator should use the knowledge of the TOE design
+ and operation gained from the TOE deliverables to
+ conduct a flaw hypothesis to identify potential flaws in
+ the development of the TOE and potential errors in the
+ specified method of operation of the TOE.
+
+ The security architecture description provides the
+ developer vulnerability analysis, as it documents how
+ the TSF protects itself from interference from untrusted
+ subjects and prevents the bypass of security enforcement
+ functionality. Therefore, the evaluator should build
+ upon the understanding of the TSF protection gained from
+ the analysis of this evidence and then develop this in
+ the knowledge gained from other development ( evidence.
+
+ The following provide some examples of hypotheses that
+ may be created when examining the evidence:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ The approach taken is directed by areas of concern
+ identified during examination of the evidence during the
+ conduct of evaluation activities and ensuring a
+ representative sample of the development and guidance
+ evidence provided for the evaluation is searched.
+
+ For guidance on sampling see Annex . This guidance
+ should be considered when selecting the subset, giving
+ reasons for:
+
+
+ the approach used in selection;
+
+
+ qualification that the evidence to be examined
+ supports that approach.
+
+
+
+ The areas of concern may relate to the sufficiency of
+ specific protection features detailed in the security
+ architecture description.
+
+ The evidence to be considered during the vulnerability
+ analysis may be linked to the evidence the attacker is
+ assumed to be able to obtain. For example, the developer
+ may protect the TOE design and implementation
+ representations, so the only information assumed to be
+ available to an attacker is the functional specification
+ and guidance (available publicly available). So,
+ although the objectives for assurance in the TOE ensure
+ the TOE design and implementation representation
+ requirements are met, these design representations may
+ only be searched to further investigate areas of
+ concerns.
+
+ On the other hand, if the source is available publicly
+ available it would be reasonable to assume that the
+ attacker has access to the source and can use this in
+ attempts to attack the TOE. Therefore, the source should
+ be considered in the focused examination
+ approach.
+
+ The following indicates examples for the selection of
+ the subset of evidence to be considered:
+
+
+ For an evaluation where all levels of design
+ abstraction from functional specification to
+ implementation representation are provided,
+ examination of information in the functional
+ specification and the implementation representation
+ may be selected, as the functional specification
+ provides detail of interfaces available to an
+ attacker, and the implementation representation
+ incorporates the design decisions made at all other
+ design abstractions. Therefore, the TOE design
+ information will be considered as part of the
+ implementation representation.
+
+
+ Examination of a particular subset of information in
+ each of the design representations provided for the
+ evaluation.
+
+
+ Coverage of particular SFRs through each of the
+ design representations provided for the evaluation.
+
+
+ Examination of each of the design representations
+ provided for the evaluation, considering different
+ SFRs within each design representations.
+
+
+ Examination of aspects of the evidence provided for
+ the evaluation relating to current potential
+ vulnerability information the evaluator has received
+ (e.g. from a scheme).
+
+
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach; applying a system to the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered and the
+ hypothesis that is to be created.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be searched to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examine in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Enhanced-Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as
+ necessary to determine the susceptibility of the TOE, in
+ its operational environment, to the potential
+ vulnerabilities identified during the search of the
+ sources of publicly available information and the
+ analysis of the TOE guidance and design evidence. The
+ evaluator should have access to current information
+ (e.g. from the evaluation authority) regarding known
+ potential vulnerabilities that may not have been
+ considered by the evaluator.
+
+ The evaluator is reminded that, as for considering the
+ security architecture description in the search for
+ vulnerabilities (as detailed in ), testing should be performed to confirm the
+ architectural properties. If requirements from are included in the SARs, the
+ developer testing evidence will include testing
+ performed to confirm the correct implementation of any
+ specific mechanisms detailed in the security
+ architecture description. However, the developer testing
+ will not necessarily include testing of all aspects of
+ the architectural properties that protect the TSF, as
+ much of this testing will be negative testing in nature,
+ attempting to disprove the properties. In developing the
+ strategy for penetration testing, the evaluator will
+ ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ It will probably be practical to carry out penetration
+ test using a series of test cases, where each test case
+ will test for a specific potential vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Moderate or High attack
+ potential do not result in a failure of this evaluator
+ action. Where analysis supports the hypothesis, these
+ need not be considered further as an input to
+ penetration testing. However, such vulnerabilities are
+ reported in the ETR as residual vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic or Enhanced-Basic attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which an Enhanced-Basic attack potential is
+ required to effect an attack. However, as a result of
+ evaluation expertise, the evaluator may discover a
+ potential vulnerability that is exploitable only by an
+ attacker with greater than Enhanced-Basic attack
+ potential. Such vulnerabilities are to be reported in
+ the ETR as residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming an Enhanced-Basic attack
+ potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing an Enhanced-Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Moderate attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Moderate.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Moderate.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Moderate attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will describe the approach to be taken to
+ identify potential vulnerabilities in the publicly
+ available material, detailing the search to be
+ performed. This may be driven by factors such as areas
+ of concern identified by the evaluator, linked to the
+ evidence the attacker is assumed to be able to obtain.
+ However, it is recognised that in this type of search
+ the approach may further evolve as a result of findings
+ during the search. Therefore, the evaluator will also
+ report any actions taken in addition to those described
+ in the approach to further investigate issues thought to
+ lead to potential vulnerabilities, and will report the
+ evidence examined in completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct a methodical analysis of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ Guidance on methodical vulnerability analysis is
+ provided in Annex .
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach. A system is to be applied in the
+ examination. The evaluator is to describe the method to
+ be used in terms of the manner in which this information
+ is to be considered and the hypothesis that is to be
+ created.
+
+ A flaw hypothesis methodology should be used whereby the
+ ST, development (functional specification, TOE design
+ and implementation representation) and guidance evidence
+ are analysed and then vulnerabilities in the TOE are
+ hypothesised, or speculated.
+
+ The evaluator should use the knowledge of the TOE design
+ and operation gained from the TOE deliverables to
+ conduct a flaw hypothesis to identify potential flaws in
+ the development of the TOE and potential errors in the
+ specified method of operation of the TOE.
+
+ The security architecture description provides the
+ developer vulnerability analysis, as it documents how
+ the TSF protects itself from interference from untrusted
+ subjects and prevents the bypass of security enforcement
+ functionality. Therefore, the evaluator should build
+ upon the understanding of the TSF protection gained from
+ the analysis of this evidence and then develop this in
+ the knowledge gained from other development ( evidence.
+
+ The approach taken to the methodical search for
+ vulnerabilities is to consider any areas of concern
+ identified in the results of the evaluator's assessment
+ of the development and guidance evidence. However, the
+ evaluator should also consider each aspect of the
+ security architecture analysis to search for any ways in
+ which the protection of the TSF can be undermined. It
+ may be helpful to structure the methodical analysis on
+ the basis of the material presented in the security
+ architecture description, introducing concerns from
+ other evidence as
+ appropriate. The analysis can then be further developed
+ to ensure all other material from the evidence is considered.
+
+ The following provide some examples of hypotheses that
+ may be created when examining the evidence:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that 'all interface
+ specifications in the evidence provided will be searched
+ to hypothesise potential vulnerabilities' and go on to
+ explain the methods used in the hypothesis.
+
+ In addition, areas of concern the evaluator has
+ identified during examination of the evidence during the
+ conduct of evaluation activities. Areas of concern may
+ also be identified during the conduct of other work
+ units associated with this component, in particular
+ , and ) where the development
+ and conduct of penetration tests may identify further
+ areas of concerns for investigation, or potential
+ vulnerabilities.
+
+ However, examination of only a subset of the development
+ and guidance evidence or their contents is not permitted
+ in this level of rigour. The approach description should
+ provide a demonstration that the methodical approach
+ used is complete, providing confidence that the approach
+ used to search the deliverables has considered all of
+ the information provided in those deliverables.
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach; applying a system to the examination. The
+ evaluator is to describe the method to be used in terms
+ of how the evidence will be considered; the manner in
+ which this information is to be considered and the
+ hypothesis that is to be created. This approach should
+ be agreed with the evaluation authority, and the
+ evaluation authority should provide detail of any
+ additional approaches the evaluator should take to the
+ vulnerability analysis and identify any additional
+ information that should be considered by the
+ evaluator.
+
+ Although a system to identifying potential
+ vulnerabilities is predefined, the identification
+ process may still be iterative, where the identification
+ of one potential vulnerability may lead to identifying
+ another area of concern that requires further
+ investigation.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing Moderate attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as
+ necessary to determine the susceptibility of the TOE, in
+ its operational environment, to the potential
+ vulnerabilities identified during the search of the
+ sources of publicly available information and the
+ analysis of the TOE guidance and design evidence. The
+ evaluator should have access to current information
+ (e.g. from the evaluation authority) regarding known
+ potential vulnerabilities that may not have been
+ considered by the evaluator.
+
+ The evaluator is reminded that, as for considering the
+ security architecture description in the search for
+ vulnerabilities (as detailed in ), testing should be performed to confirm the
+ architectural properties. If requirements from are included in the SARs, the
+ developer testing evidence will include testing
+ performed to confirm the correct implementation of any
+ specific mechanisms detailed in the security
+ architecture description. However, the developer testing
+ will not necessarily include testing of all aspects of
+ the architectural properties that protect the TSF, as
+ much of this testing will be negative testing in nature,
+ attempting to disprove the properties. In developing the
+ strategy for penetration testing, the evaluator will
+ ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Moderate (or less) attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Moderate attack potential is required
+ to effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Moderate attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI;
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Moderate attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than a High attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than High.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of High.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing High
+ attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+ If the TOE SFRs include and
+ requirements such that
+ actions and data of one subject cannot be observed and
+ linked with another subject, the evaluator should consider
+ performing a covert channel analysis. This will build
+ upon the design evidence provided by the developer in
+ satisfaction of and requirements. The design evidence
+ will include details of how the TOE architecture prevents
+ observation by subjects of actions performed by other
+ subjects. the evaluator should seek guidance from the
+ evaluation authority on the conduct of such a covert
+ channel analysis.
+
+ The analysis of the guidance documentation is to include
+ consideration of whether it is possible to unknowingly
+ configure the TOE insecurely. Therefore, the analysis will
+ consider warning prompts provided by the TOE when
+ configuration options are selected by the user that may
+ render the TOE in an insecure state, not just in the
+ guidance but also in the use of the TOE. An example may be
+ when access control rules are amended from a remote
+ administration console, which will not take effect until
+ the TOE has been restarted. The evaluator will determine
+ whether the TOE issues a suitable warning when the changes
+ are made to ensure the user is aware that a restart must
+ be completed before the changes take effect.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing High attack potential.
+
+
+
+
+
+
+
+ EAL1 is applicable where some confidence in correct operation
+ is required, but the threats to security are not viewed as
+ serious. It will be of value where independent assurance is
+ required to support the contention that due care has been
+ exercised with respect to the protection of personal or
+ similar information.
+
+ EAL1 requires only a limited security target. It is sufficient
+ to simply state the SFRs that the TOE must meet, rather than
+ deriving them from threats, OSPs and assumptions through
+ security objectives.
+
+ EAL1 provides an evaluation of the TOE as made available to
+ the customer, including independent testing against a
+ specification, and an examination of the guidance
+ documentation provided. It is intended that an EAL1 evaluation
+ could be successfully conducted without assistance from the
+ developer of the TOE, and for minimal outlay.
+
+ An evaluation at this level should provide evidence that the
+ TOE functions in a manner consistent with its
+ documentation.
+
+
+
+ EAL1 provides a basic level of assurance by a limited security
+ target and an analysis of the SFRs in that ST using a
+ functional and interface specification and guidance
+ documentation, to understand the security behaviour.
+
+ The analysis is supported by a search for potential
+ vulnerabilities in the public domain and independent testing
+ (functional and penetration) of the TSF.
+
+ EAL1 also provides assurance through unique identification of
+ the TOE and of the relevant evaluation documents.
+
+ This EAL provides a meaningful increase in assurance over
+ unevaluated IT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL2 requires the co-operation of the developer in terms of
+ the delivery of design information and test results, but
+ should not demand more effort on the part of the developer
+ than is consistent with good commercial practise. As such it
+ should not require a substantially increased investment of
+ cost or time.
+
+ EAL2 is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record. Such a
+ situation may arise when securing legacy systems, or where
+ access to the developer may be limited.
+
+
+
+ EAL2 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation and a basic
+ description of the architecture of the TOE, to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, selective independent confirmation of the
+ developer test results, and a vulnerability analysis (based
+ upon the functional specification, TOE design, architectural
+ design and guidance evidence provided) demonstrating
+ resistance to penetration attackers with a basic attack
+ potential.
+
+ EAL2 also provides assurance through use of a configuration
+ management system and evidence of secure delivery
+ procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL1 by requiring developer testing, a vulnerability analysis
+ (in addition to the search of the public domain), and
+ independent testing based upon more detailed TOE
+ specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL3 permits a conscientious developer to gain maximum
+ assurance from positive security engineering at the design
+ stage without substantial alteration of existing sound
+ development practises.
+
+ EAL3 is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the TOE and
+ its development without substantial re-engineering.
+
+
+
+ EAL3 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation, and an
+ architectural description of the design of the TOE, to
+ understand the security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent
+ confirmation of the developer test results, and a
+ vulnerability analysis (based upon the functional
+ specification, TOE design, architectural design and guidance
+ evidence provided) demonstrating resistance to penetration
+ attackers with a basic attack potential.
+
+ EAL3 also provides assurance through the use of development
+ environment controls, TOE configuration management, and
+ evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL2 by requiring more complete testing coverage of the
+ security functionality and mechanisms and/or procedures that
+ provide some confidence that the TOE will not be tampered with
+ during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL4 permits a developer to gain maximum assurance from
+ positive security engineering based on good commercial
+ development practises which, though rigorous, do not require
+ substantial specialist knowledge, skills, and other
+ resources. EAL4 is the highest level at which it is likely to
+ be economically feasible to retrofit to an existing product
+ line.
+
+ EAL4 is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity TOEs
+ and are prepared to incur additional security-specific
+ engineering costs.
+
+
+
+ EAL4 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the basic modular design of the TOE, and a
+ subset of the implementation, to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent
+ confirmation of the developer test results, evidence of a
+ developer search for vulnerabilities, and a vulnerability
+ analysis (based upon the functional specification, TOE design,
+ implementation representation, architectural design and
+ guidance evidence provided) demonstrating resistance to
+ penetration attackers with an extended-basic attack
+ potential.
+
+ EAL4 also provides assurance through the use of development
+ environment controls and additional TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL3 by requiring more design description, a subset of the
+ implementation, and improved mechanisms and/or procedures that
+ provide confidence that the TOE will not be tampered with
+ during development or delivery.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL5 permits a developer to gain maximum assurance from
+ security engineering based upon rigorous commercial
+ development practises supported by moderate application of
+ specialist security engineering techniques. Such a TOE will
+ probably be designed and developed with the intent of
+ achieving EAL5 assurance. It is likely that the additional
+ costs attributable to the EAL5 requirements, relative to
+ rigorous development without the application of specialised
+ techniques, will not be large.
+
+ EAL5 is therefore applicable in those circumstances where
+ developers or users require a high level of independently
+ assured security in a planned development and require a
+ rigorous development approach without incurring unreasonable
+ costs attributable to specialist security engineering
+ techniques.
+
+
+
+ EAL5 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the design of the TOE, and the implementation,
+ to understand the security behaviour. A modular TSF design is
+ also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a moderate attack potential.
+
+ EAL5 also provides assurance through the use of a development
+ environment controls, and comprehensive TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL4 by requiring semiformal design descriptions, the entire
+ implementation, a more structured (and hence analysable)
+ architecture, and improved mechanisms and/or procedures that
+ provide confidence that the TOE will not be tampered with
+ during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL6 permits developers to gain high assurance from
+ application of security engineering techniques to a rigorous
+ development environment in order to produce a premium TOE for
+ protecting high value assets against significant risks.
+
+ EAL6 is therefore applicable to the development of security
+ TOEs for application in high risk situations where the value
+ of the protected assets justifies the additional costs.
+
+
+
+ EAL6 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and the implementation to understand the
+ security behaviour. Assurance is additionally gained through a
+ formal model of select TOE security policies and a semiformal
+ presentation of the functional specification and TOE design. A
+ modular and layered TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a high attack potential.
+
+ EAL6 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL5 by requiring more comprehensive analysis, a structured
+ representation of the implementation, more architectural
+ structure (e.g. layering), more comprehensive independent
+ vulnerability analysis, and improved configuration management
+ and development environment controls.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL7 is applicable to the development of security TOEs for
+ application in extremely high risk situations and/or where the
+ high value of the assets justifies the higher costs. Practical
+ application of EAL7 is currently limited to TOEs with tightly
+ focused security functionality that is amenable to extensive
+ formal analysis.
+
+
+
+ EAL7 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and a structured presentation of the
+ implementation to understand the security behaviour. Assurance
+ is additionally gained through a formal model of select TOE
+ security policies and a semiformal presentation of the
+ functional specification and TOE design. A modular, layered
+ and simple TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design and implementation representation,
+ complete independent confirmation of the developer test
+ results, and an independent vulnerability analysis
+ demonstrating resistance to penetration attackers with a high
+ attack potential.
+
+ EAL7 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL6 by requiring more comprehensive analysis using formal
+ representations and formal correspondence, and comprehensive
+ testing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-A is applicable when a composed TOE is integrated and
+ confidence in the correct security operation of the resulting
+ composite is required. This requires the cooperation of the
+ developer of the dependent component in terms of delivery of
+ design information and test results from the dependent
+ component certification, without requiring the involvement of
+ the base component developer.
+
+ CAP-A is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record.
+
+
+
+ CAP-A provides assurance by analysis of a security target for
+ the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation) and a
+ specification for the interfaces between the component TOEs in
+ the composed TOE to understand the security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information,
+ evidence of developer testing based on the reliance
+ information, development information and composition
+ rationale, and selective independent confirmation of the
+ developer test results. The analysis is also supported by a
+ vulnerability review of the composed TOE by the
+ evaluator.
+
+ CAP-A also provides assurance through unique identification of
+ the composed TOE (i.e. IT TOE and guidance
+ documentation).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-B permits a conscientious developer to gain maximum
+ assurance from understanding, at a subsystem level, the
+ affects of interactions between component TOEs integrated in
+ the composed TOE, whilst minimising the demand of involvement
+ of the base component developer.
+
+ CAP-B is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the composed
+ TOE and its development without substantial
+ re-engineering.
+
+
+
+ CAP-B provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF subsystems) contained in
+ the composed development information to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now also including TOE design), evidence of developer testing
+ based on the reliance information, development information and
+ composition rationale, and selective independent confirmation
+ of the developer test results. The analysis is also supported
+ by a vulnerability analysis of the composed TOE by the
+ evaluator demonstrating resistance to attackers with basic
+ attack potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-A by requiring more complete testing coverage of the
+ security functionality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-C permits a developer to gain maximum assurance from
+ positive analysis of the interactions between the components
+ of the composed TOE, which, though rigorous, do not require
+ full access to all evaluation evidence of the base
+ component.
+
+ CAP-C is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity
+ composed TOEs and are prepared to incur additional
+ security-specific engineering costs.
+
+
+
+ CAP-C provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF modules) contained in the
+ composed development information to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now including TOE design), evidence of developer testing
+ based on the reliance information, development information and
+ composition rationale, and selective independent confirmation
+ of the developer test results. The analysis is also supported
+ by a vulnerability analysis of the composed TOE by the
+ evaluator demonstrating resistance to attackers with
+ extended-basic attack potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-B by requiring more design description and demonstration
+ of resistance to a higher attack potential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/c5dec/assets/database/SecurityControls/cc3R2.xml b/c5dec/assets/database/SecurityControls/cc3R2.xml
new file mode 100644
index 0000000..7b53ce6
--- /dev/null
+++ b/c5dec/assets/database/SecurityControls/cc3R2.xml
@@ -0,0 +1,54639 @@
+
+
+
+ This Clause presents the general concepts used throughout
+ the CC, including the context in which the concepts are to be
+ used and the CC approach for applying the concepts. CC Part 2
+ and CC Part 3 expand on the use of these concepts and assume
+ that the approach described is used. This Clause assumes some
+ knowledge of IT security and does not propose to act as a
+ tutorial in this area.
+
+ The CC discusses security using a set of security concepts and
+ terminology. An understanding of these concepts and the
+ terminology is a prerequisite to the effective use of the
+ CC. However, the concepts themselves are quite general and are
+ not intended to restrict the class of IT security problems to
+ which the CC is applicable.
+
+
+ Security is concerned with the protection of assets. Assets
+ are entities that someone places value upon. Examples of
+ assets include:
+
+ contents of a file or a server;
+ the authenticity of votes cast in an election;
+ the availability of an electronic commerce
+ process;
+ the ability to use an expensive printer;
+ access to a classified facility.but
+ given that value is highly subjective, almost anything can be
+ an asset.
+
+ The environment(s) in which these assets are located is called
+ the operational environment. Examples of (aspects of)
+ operational environments are:
+
+ the computer room of a bank;
+
+ a computer network connected to the Internet;
+
+ a LAN;
+ a general office environment.
+
+ Many assets are in the form of information that is stored,
+ processed and transmitted by IT products to meet requirements
+ laid down by owners of the information. Information owners may
+ require that availability, dissemination and modification of
+ any such information is strictly controlled and that the
+ assets are protected from threats by countermeasures. Figure
+ illustrates these
+ high level concepts and relationships.
+
+
+ Safeguarding assets of interest is the responsibility of
+ owners who place value on those assets. Actual or presumed
+ threat agents may also place value on the assets and seek to
+ abuse assets in a manner contrary to the interests of the
+ owner. Examples of threat agents include hackers, malicious
+ users, non-malicious users (who sometimes make errors),
+ computer processes and accidents.
+ The owners of the assets will perceive
+ such threats as potential for impairment of the assets such
+ that the value of the assets to the owners would be
+ reduced. Security-specific impairment commonly includes, but
+ is not limited to: loss of asset confidentiality, loss of
+ asset integrity and loss of asset availability.
+ These threats therefore give rise to risks to the assets,
+ based on the likelihood of a threat being realised and the
+ impact on the assets when that threat is
+ realised. Subsequently countermeasures are imposed to reduce
+ the risks to assets. These countermeasures may consist of IT
+ countermeasures (such as firewalls and smart cards) and non-IT
+ countermeasures (such as guards and procedures).
+
+ Owners of assets may be (held) responsible for those assets
+ and therefore should be able to defend the decision to accept
+ the risks of exposing the assets to the threats.
+ Two important elements in defending this decision are
+ being able to demonstrate that:
+
+ the countermeasures are sufficient:
+ if the countermeasures do what they claim to do, the
+ threats to the assets are countered;
+ the countermeasures are correct: the
+ countermeasures do what they claim to do.
+
+
+ Many owners of assets lack the knowledge, expertise or
+ resources necessary to judge sufficiency and correctness of
+ the countermeasures, and they may not wish to rely solely on
+ the assertions of the developers of the countermeasures.
+ These consumers may therefore choose to increase their
+ confidence in the sufficiency and correctness of some or all
+ of their countermeasures by ordering an evaluation of these
+ countermeasures.
+
+
+ In an evaluation, sufficiency of the countermeasures is
+ analysed through a construct called the Security Target. In
+ this Subclause a simplified view on this construct is
+ provided: a more detailed and complete description may be
+ found in .
+
+ The Security Target begins with describing the assets and
+ the threats to those assets. The Security Target then
+ describes the countermeasures (in the form of Security
+ Objectives) and demonstrates that these countermeasures are
+ sufficient to counter these threats: if the countermeasures
+ do what they claim to do, the threats are countered.
+ The Security Target then divides these countermeasures
+ in two groups:
+
+ the security objectives for the TOE: these describe
+ the countermeasure(s) for which correctness will be
+ determined in the evaluation;
+ the security objectives for the Operational
+ Environment: these describe the countermeasures for
+ which correctness will not be determined in the
+ evaluation;
+ The reasons for this division are:
+
+ The CC is only suitable for assessing the
+ correctness of IT-countermeasures. Therefore the non-IT
+ countermeasures (e.g. human security guards, procedures)
+ are always in the Operational Environment.
+ Assessing correctness of countermeasures costs time
+ and money, possibly making it infeasible to assess the
+ correctness of all IT-countermeasures.
+ The correctness of some IT-countermeasures may
+ already have been assessed in another evaluation. It is
+ therefore not cost-effective to assess this correctness
+ again.
+ For the TOE (the IT-countermeasures whose correctness
+ will be assessed during the evaluation), the Security Target
+ requires a further detailing of the security objectives for
+ the TOE in Security Functional Requirements (SFRs). These
+ SFRs are formulated in a standardised language (described in
+ CC Part 2) to ensure exactness and facilitate
+ comparability.
+
+ In summary, the Security Target demonstrates that:
+
+ The SFRs meet the security objectives for the
+ TOE;
+ The security objectives for the TOE and the security
+ objectives for the operational environment counter the
+ threats;
+ And therefore, the SFRs and the security objectives
+ for the operational environment counter the
+ threats.
+ From this it follows that a correct TOE (meeting the
+ SFRs) in combination with a correct operational environment
+ (meeting the security objectives for the operational
+ environment) will counter the threats. In the next two
+ subclauses correctness of the TOE and correctness of the
+ operational environment are discussed separately.
+
+
+
+ A TOE may be incorrectly designed and implemented, and may
+ therefore contain errors that lead to vulnerabilities. By
+ exploiting these vulnerabilities, attackers may still damage
+ and/or abuse the assets.
+
+ These vulnerabilities may arise from accidental errors made
+ during development, poor design, intentional addition of
+ malicious code, poor testing etc.
+
+ To determine correctness of the TOE, various activities can
+ be performed such as:
+
+ testing the TOE;
+ examining various design representations of the
+ TOE;
+ examining the physical security of the development
+ environment of the TOE
+ The Security Target provides a structured description
+ of these activities to determine correctness in the form of
+ Security Assurance Requirements (SARs). These SARs are
+ formulated in a standardised language (described in CC Part
+ 3) to ensure exactness and facilitate comparability.
+
+ If the SARs are met, there exists assurance in the
+ correctness of the TOE and the TOE is therefore less likely
+ to contain vulnerabilities that can be exploited by
+ attackers. The amount of assurance that exists in the
+ correctness of the TOE is determined by the SARs themselves:
+ a few ``weak'' SARs will lead to a little assurance, a lot of
+ ``strong'' SARs will lead to a lot of assurance.
+
+
+
+ The operational environment may also be incorrectly designed
+ and implemented, and may therefore contain errors that lead
+ to vulnerabilities. By exploiting these vulnerabilities,
+ attackers may still damage and/or abuse the assets.
+ However, in the CC, no assurance is obtained regarding
+ the correctness of the operational environment. Or, in
+ other words, the operational environment is not evaluated
+ (see the next Subclause).
+ As far as the evaluation is concerned, the operational
+ environment is assumed to be a 100% correct instantiation of
+ the security objectives for the operational
+ environment.
+ This does not preclude a consumer of the TOE from using
+ other methods to determine the correctness of his
+ operational environment, such as:
+
+ If, for an OS TOE, the security objectives for the
+ operational environment state ``The operational
+ environment shall ensure that entities from an untrusted
+ network (e.g. the Internet) can only access the TOE by
+ ftp'', the consumer could select an evaluated firewall,
+ and configure it to only allow ftp access to the
+ TOE.
+ If the security objectives for the operational
+ environment state ``The operational environment shall
+ ensure that all administrative personnel will not behave
+ maliciously'', the consumer could adapt his contracts
+ with administrative personnel to include punitive
+ sanctions for malicious behaviour. but
+ this determination is not part of a
+ CC-evaluation.
+
+
+
+ The CC recognises two types of evaluation: an ST/TOE
+ evaluation, which is described below, and an evaluation of PPs, which are defined in CC Part 3. In
+ many places, the CC uses the term evaluation (without
+ qualifiers) to refer to an ST/TOE evaluation.
+
+ In the CC an ST/TOE evaluation proceeds in two steps:
+
+ An ST evaluation: where the sufficiency of the TOE and
+ the operational environment are determined;
+ A TOE evaluation: where the correctness of the TOE is
+ determined. As said earlier, the TOE evaluation does not
+ assess correctness of the operational environment.
+
+
+ The ST evaluation is carried out by applying the Security
+ Target evaluation criteria (which are defined in CC Part 3
+ Clause ) to the Security Target. The
+ precise method to apply the
+ criteria is determined by the evaluation methodology that is
+ used.
+
+ The TOE evaluation is more complex. The principal inputs to a
+ TOE evaluation are: the evaluation evidence, which includes
+ the TOE and ST, but will usually also include input from the
+ development environment, such as design documents or developer
+ test results.
+
+ The TOE evaluation consists of applying the SARs (from the
+ Security Target) to the evaluation evidence. The precise
+ method to apply a specific SAR is determined by the evaluation
+ methodology that is used.
+
+ How the results of applying the SARs are documented, and what
+ reports need to be generated and in what detail, is determined
+ by both the evaluation methodology that is used and the
+ evaluation scheme under which the evaluation is carried
+ out.
+
+ The result of the TOE evaluation process is either:
+ A statement that not all SARs have been met and that
+ therefore there is not the specified level of assurance that the TOE meets
+ the SFRs as stated in the ST; A statement that all SARs have been met, and that
+ therefore there is the specified level of assurance that the TOE meets the
+ SFRs as stated in the ST.
+
+ The TOE evaluation may be carried out after TOE development
+ has finished, or in parallel with TOE development.
+
+ The method of stating ST/TOE evaluation results is described
+ in Clause . These
+ results also identify the PP(s) and package(s) to which the
+ TOE claims conformance, and these constructs are described in
+ the next Clause.
+
+
+ CC functional and assurance components may be used exactly as
+ defined in the CC, or they may be tailored through the use of
+ permitted operations. When using operations, the PP/ST author
+ should be careful that the dependency needs of other
+ requirements that depend on this requirement are
+ satisfied. The permitted operations are selected from the
+ following set:
+
+ Iteration: allows a component to be used more than once
+ with varying operations;
+
+ Assignment: allows the specification of parameters;
+
+ Selection: allows the specification of one or more items
+ from a list; and
+
+ Refinement: allows the addition of details.
+
+ The assignment and selection operations are permitted only
+ where specifically indicated in a component. Iteration and
+ refinement are permitted for all components. The operations
+ are described in more detail below.
+ The CC Part 2 Annexes provide the guidance on the valid
+ completion of selections and assignments. This guidance provides
+ normative instructions on how to complete operations, and those
+ instructions shall be followed unless the PP/ST author justify
+ the deviation:
+
+ ``None'' is only available as a choice for the completion of
+ a selection if explicitly provided.
+
+ The lists provided for the completion of selections must
+ be non-empty. If a ``None'' option is chosen, no
+ additional selection options may be chosen. If ``None'' is
+ not given as an option in a selection, it is permissible
+ to combine the choices in a selection with ``and''s and
+ ``or''s, unless the selection explicitly states ``choose
+ one of''.
+ Selection operations may be combined by iteration where
+ needed. In this case, the applicability of the option
+ chosen for each iteration should not overlap the subject
+ of the other iterated selection, since they are intended
+ to be exclusive.
+ For the completion of assignments, the CC Part 2 Annexes
+ indicate when ``None'' would be a valid completion.
+
+ The iteration operation may be performed on every
+ component. The PP/ST author performs an iteration operation by
+ including multiple requirements based on the same
+ component. Each iteration of a component shall be different
+ from all other iterations of that component, which is realised
+ by completing assignments and selections in a different way,
+ or by applying refinements to it in a different way.
+ Different iterations should be uniquely identified to allow
+ clear rationales and tracings to and from these
+ requirements.
+ An assignment operation occurs where a given component
+ contains an element with a parameter that may be set by the
+ PP/ST author. The parameter may be an unrestricted variable,
+ or a rule that narrows the variable to a specific range of
+ values.
+ Whenever an element in a PP contains an assignment, a PP
+ author shall do one of four things:
+
+ leave the assignment uncompleted. The PP author could
+ include ``When the
+ defined number of unsuccessful authentication attempts has
+ been met or surpassed, the TSF shall [assignment:
+ list of actions].'' in the PP.
+
+ complete the assignment. As an example, the PP author
+ could include ``When
+ the defined number of unsuccessful authentication attempts
+ has been met or surpassed, the TSF shall prevent
+ that external entity from binding to any subject in the
+ future.'' in the PP.
+
+ narrow the assignment, to further limit the range of
+ values that is allowed. As an example, the PP author could
+ include ``The TSF
+ shall detect when [assignment: positive integer between 4
+ and 9] unsuccessful authentication attempts occur ...'' in
+ the PP.
+ transform the assignment to a selection, thereby narrowing
+ the assignment. As an example, the PP author could include
+ ``When the defined
+ number of unsuccessful authentication attempts has been
+ met or surpassed, the TSF shall [selection: prevent
+ that user from binding to any subject in the future,
+ notify the administrator].'' in the PP.
+
+ Whenever an element in an ST contains an assignment, an ST
+ author shall complete that assignment, as indicated in b)
+ above. Options a), c) and d) are not allowed for STs.
+ The values chosen in options b), c) and d) shall conform to
+ the indicated type required by the assignment.
+ When an assignment is to be completed with a set
+ (e.g. subjects), one may list a set of subjects, but also some
+ description of the set from which the elements of the set can
+ be derived such as:
+ all subjectsall subjects of type Xall subjects except subject a as long
+ as it is clear which subjects are meant.
+ The selection operation occurs where a given component
+ contains an element where a choice from several items has to
+ be made by the PP/ST author.
+ Whenever an element in a PP contains a selection, the PP
+ author may do one of three things:
+
+ leave the selection uncompleted.
+
+ complete the selection by choosing one or more items.
+
+ restrict the selection by removing some of the choices,
+ but leaving two or more.
+
+ Whenever an element in an ST contains a selection, an ST
+ author shall complete that selection, as indicated in b)
+ above. Options a) and c) are not allowed for STs.
+ The item or items chosen in b) and c) shall be taken from
+ the items provided in the selection.
+ The refinement operation can be performed on every
+ requirement. The PP/ST author performs a refinement by
+ altering that requirement. The first rule for a refinement is
+ that a TOE meeting the refined requirement also meets the
+ unrefined requirement in the context of the PP/ST (i.e. a
+ refined requirement must be ``stricter'' than the original
+ requirement). If a refinement does not meet this rule, the
+ resulting refined requirement is considered to be an extended
+ requirement and shall be treated as such.
+ The only exception to this rule is that a PP/ST author is
+ allowed to refine a SFR to apply to some but not all subjects,
+ objects, operations, security attributes and/or external
+ entities.
+ However, this exception does not apply to refining SFRs that
+ are taken from PPs that compliance is being claimed to; these
+ SFRs may not be refined to apply to fewer subjects, objects,
+ operations, security attributes and/or external entities than
+ the SFR in the PP.
+ The second rule for a refinement is that the refinement shall
+ be related to the original component. For example, refining an
+ audit component with an extra element on prevention of
+ electromagnetic radiation is not allowed.
+ A special case of refinement is an editorial refinement,
+ where a small change is made in a requirement,
+ i.e. rephrasing a sentence due to adherence to proper
+ English grammar, or to make it more understandable to the
+ reader. This change is not allowed to modify the meaning of
+ the requirement in any way.
+ Dependencies may exist between components. Dependencies arise
+ when a component is not self sufficient and relies upon the
+ presence of another component to provide security
+ functionality or assurance.
+ The functional components in CC Part 2 typically have
+ dependencies on other functional components and the assurance
+ components in CC Part 3 do also so for CC Part 3 components. CC
+ Part 2 depencies on CC Part 3 components may also be
+ defined. However, this does not preclude extended functional
+ components having dependencies on assurance components or vice
+ versa.
+ Component dependency descriptions are part of the CC component
+ definitions. In order to ensure completeness of the TOE security
+ requirements, dependencies should be satisfied when requirements
+ based on components with dependencies are incorporated into PPs
+ and STs. Dependencies should also be considered when
+ constructing packages.
+ In other words: if component A has a dependency on component B,
+ this means that whenever a PP/ST contains a security requirement
+ based on component A, the PP/ST shall also contain one of :
+
+ a security requirement based on component B, or
+
+ a security requirement based on a component that is
+ hierarchically higher than B, or
+
+ a justification why the PP/ST does not contain a security
+ requirement based on component B.
+
+ In cases a) and b), when a security requirement is included
+ because of a dependency, it may be necessary to complete
+ operations (assignment, iteration, refinement, selection) on
+ that security requirement in a particular manner to make sure
+ that it actually satisfies the dependency.
+ In case c), the justification that a security requirement is
+ not included should address either:
+
+ why the dependency is not necessary or useful, or
+
+ that the dependency has been addressed by the operational
+ environment of the TOE, in which case the justification
+ should describe how the security objectives for the
+ operational environment address this dependency, or
+
+ that the dependency has been addressed by the other SFRs
+ in some other manner (extended SFRs, combinations of SFRs
+ etc.)
+
+ In the CC it is mandatory to base requirements on components
+ from CC Part 2 or CC Part 3 with two exceptions:
+
+ there are security objectives for the TOE that can not be
+ translated to Part 2 SFRs, or there are third party requirements
+ (e.g., laws, standards) that can not be translated to Part 3
+ SARs (e.g. regarding evaluation of cryptography);
+
+ a security objective can be translated, but only with great
+ difficulty and/or complexity based on components in CC Part
+ 2 and/or CC Part 3.
+
+ In both cases the PP/ST author is required to define his own
+ components. These newly defined components are called
+ extended components. A precisely defined extended component
+ is needed to provide context and meaning to the extended
+ SFRs and SARs based on that component.
+ After the new components have been defined correctly, the
+ PP/ST author can then base one or more SFRs or SARs on these
+ newly defined extended components and use them in the same
+ way as the other SFRs and SARs. From this point on, there is
+ no further distinction between SARs and SFRs based on the CC
+ and SARs and SFRs based on extended components. Refer to CC
+ Part 3 and for further requirements on
+ extended components.
+
+
+
+ As described in CC Part 1 Protection Profiles and Security Targets
+ contain pre-defined security requirements, as well as providing PP and ST authors the ability to extend the component lists in some circumstances.
+
+
+
+
+
+ The CC has organised the components in CC Part 2 and CC Part 3
+ into hierarchical structures:
+
+ Classes, consisting of
+ Families, consisting of
+ Components, consisting of
+ Elements.
+
+ This organisation into a hierarchy of class - family -
+ component - element is provided to assist consumers,
+ developers and evaluators in locating specific
+ components.
+
+ The CC presents functional and assurance components in the
+ same general hierarchical style and uses the same organisation
+ and terminology for each.
+
+
+ An example of a class is the class that is focused at identification of users,
+ authentication of users and binding of users and subjects.
+
+
+
+ An example of a family is the
+ family which is part of the
+ class. This family concentrates on the authentication of users.
+
+
+
+ An example of a component is
+ which concentrates on unforgeable authentication.
+
+
+
+ An example of an element is
+ which concentrates on the
+ prevention of use of copied authentication data.
+
+
+
+
+
+
+
+
+
+
+
+
+ Examples of possible dependencies in extended components are:
+
+ if an extended component refers to auditing, dependencies
+ to components of the class may
+ have to be included;
+
+ if an extended component modifies or accesses data,
+ dependencies to components of the family may have to be included;
+
+ if an extended component uses a particular design
+ description a dependency to the appropriate family (e.g. Functional Specification) may
+ have to be included.
+
+
+
+
+
+
+
+
+
+
+ The goal of this Annex is to explain the Protection Profile
+ (PP) concept. This Annex does not define the criteria; this definition can be found in CC Part
+ 3.
+
+ As PPs and STs have a significant overlap, this Annex focuses
+ on the differences between PPs and STs. The material that is
+ identical between STs and PPs is described in .
+
+ This annex consists of four major parts:
+
+
+ What a PP must contain. This is
+ summarised in Subclause , and described in more detail
+ in Subclauses -. These subclauses describe the
+ mandatory contents of the PP, the interrelationships
+ between these contents, and provide examples.
+
+
+ How a PP should be used. This is
+ summarised in Subclause .
+
+
+ Low Assurance PPs. Low Assurance PPs are
+ PPs with reduced content. They are described in detail in
+ Subclause .
+
+
+ Claiming compliance with
+ standards. Subclause describes how a PP writer can claim that
+ the TOE is to meet a particular standard.
+
+
+
+
+
+ Figure portrays the
+ mandatory content for a PP that are given in CC Part 3. Figure may also be used as a structural
+ outline of the PP, though alternative structures are
+ allowed. For instance, if the security requirements rationale
+ is particularly bulky, it could be included in an appendix of
+ the PP instead of in the security requirements subclause. The
+ separate subclauses of a PP and the contents of those subclauses
+ are briefly summarised below and explained in much more detail
+ in Subclauses - . A PP contains:
+
+ a PP introduction containing a narrative
+ description of the TOE type;
+
+ a conformance claim, showing whether the
+ PP claims conformance to any PPs and/or packages, and if
+ so, to which PPs and/or packages;
+
+ a security problem definition, showing
+ threats, OSPs and assumptions that must be countered;
+ security objectives, showing how the
+ solution to the security problem is divided between
+ security objectives for the TOE and security objectives
+ for the operational environment of the TOE;
+ extended components definition, where new
+ components (i.e. not included in CC Part 2 or CC Part 3)
+ may be defined. These new components can then be used are
+ needed to define extended functional and extended
+ assurance requirements;
+ security requirements, where a
+ translation of the security objectives for the TOE into a
+ standardised language is provided. This standardised
+ language is in the form of SFRs. Additionally this subclause
+ defines the SARs;
+
+
+ There also exist low assurance PPs, which have reduced
+ contents, which are described in detail in Subclause . The remainder of this Annex
+ assumes that a PP with full contents is used.
+
+
+
+
+ A PP is typically a statement of need where a user
+ community, a regulatory entity, or a group of developers
+ define a common set of security needs. A PP gives consumers
+ a means of referring to this set, and facilitates future
+ evaluation against these needs.
+
+ A PP is therefore typically used as:
+
+
+ part of a requirement specification for a specific
+ consumer or group of consumers, who will only consider
+ buying a specific type of IT if it meets the PP;
+
+
+ part of a regulation from a specific regulatory entity,
+ who will only allow a specific type of IT to be used if
+ it meets the PP;
+
+
+ a baseline defined by a group of IT developers, who then
+ agree that all IT that they produce of this type will
+ meet this baseline.
+
+ though this does not preclude other uses.
+
+
+
+ Three roles (among many) that a PP should not fulfil are:
+
+
+ a detailed specification: A PP is
+ designed to be a security specification on a relatively
+ high level of abstraction. A PP should, in general, not
+ contain detailed protocol specifications, detailed
+ descriptions of algorithms and/or mechanisms, long
+ description of detailed operations etc.
+
+
+ a complete specification: A PP is
+ designed to be a security specification and not a
+ general specification. Unless security-relevant,
+ properties such as interoperability, physical size and
+ weight, required voltage etc. should not be part of a
+ PP. This means that in general a PP is a part of a
+ complete specification, but not a complete specification
+ itself.
+
+
+ a specification of a single product:
+ Unlike an ST, a PP is designed to describe a certain
+ type of IT, and not a single product. When only a single
+ product is described, it is better to use an ST for this
+ purpose.
+
+
+
+
+
+
+ A PP contains a clear PP reference that identifies that
+ particular PP. A typical PP reference consists of title,
+ version, authors and publication date. An example of a PP
+ reference is ``Atlantean Navy CablePhone Encryptor PP,
+ version 2b, Atlantean Navy Procurement Office, April 7,
+ 2003''.
+ apart.
+
+
+ A PP contains a clear PP reference that identifies that
+ particular PP. A typical PP reference consists of title,
+ version, authors and publication date. An example of a PP
+ reference is ``Atlantean Navy CablePhone Encryptor PP,
+ version 2b, Atlantean Navy Procurement Office, April 7,
+ 2003''. The reference must be unique so that it is possible
+ to tell different PPs and different versions of the same PP
+ apart.
+
+ The PP reference facilitates indexing and referencing the PP
+ and its inclusion in lists of PPs.
+
+
+
+ The TOE overview is aimed at potential consumers of a TOE
+ who are looking through lists of evaluated products to find
+ TOEs that may meet their security needs, and are supported
+ by their hardware, software and firmware.
+ The TOE overview is also aimed at developers who may use
+ the PP in designing TOEs or in adapting existing
+ products.
+ The typical length of a TOE overview is several
+ paragraphs.
+
+ To this end, the TOE overview briefly describes the usage of
+ the TOE and its major security features, identifies the TOE
+ type and identifies any major non-TOE
+ hardware/software/firmware available to the TOE.
+
+
+ The description of the usage and major security features
+ of the TOE is intended to give a very general idea of what
+ the TOE should be capable of, and what it can be used
+ for. This subclause should be written for (potential) TOE
+ consumers, describing TOE usage and major security
+ features in terms of business operations, using language
+ that TOE consumers understand.
+
+ An example of this is ``The Atlantean Navy CablePhone
+ Encryptor is an encryption device that should allow
+ confidential communication between ships across the
+ Atlantean Navy CablePhone system. To this end it should
+ allow at least 32 different users and support at least
+ 100Mb encryption speed. It should allow both bilateral
+ communication between ships and broadcast across the
+ entire network.''
+
+
+
+ The TOE overview identifies the general type of TOE, such
+ as: firewall, VPN-firewall, smart card, crypto-modem,
+ intranet, web server, database, web server and database,
+ LAN, LAN with web server and database, etc.
+
+
+
+ While some TOEs do not rely upon other IT, many TOEs
+ (notably software TOEs) rely on additional, non-TOE,
+ hardware, software and/or firmware. In the latter case,
+ the TOE overview is required to identify the non-TOE
+ hardware/software/firmware.
+ As a Protection Profile is not written for a specific
+ product, in many cases only a general idea can be given of
+ the available hardware/software/firmware. In some other
+ cases, e.g. a requirements specification for a specific
+ consumer where the platform is already known, (much) more
+ specific information may be provided.
+
+ Examples of hardware/software/firmware identifications
+ are:
+
+
+ None. (for a completely stand-alone TOE)
+
+ The Yaiza 3.0 Operating System running on a
+ general PC.
+
+ a CleverCard SB2067 integrated circuit;
+
+
+ a CleverCard SB2067 IC running v2.0 of the QuickOS
+ smart card operating system;
+
+
+ the December 2002 installation of the LAN of the
+ Director-General's Office of the Department of
+ Traffic.
+
+
+
+
+
+
+
+ This subclause of a PP describes how the PP conforms with other
+ PPs and with packages. It is identical to the conformance
+ claims subclause for an ST (see Subclause ), with one exception: the
+ conformance statement.
+
+ The conformance statement in the PP states how STs and/or
+ other PPs must conform to that PP. The PP author selects
+ whether ``strict'' or ``demonstrable'' conformance is
+ required. See for more details on
+ this.
+
+
+
+
+ This subclause is identical to the security problem definition
+ subclause of an ST as explained in Subclause .
+
+
+
+ This subclause is identical to the security objectives subclause
+ of an ST as explained in Subclause .
+
+
+
+ This subclause is identical to the extended components subclause
+ of an ST as explained in Subclause .
+
+
+
+ This subclause is identical to the security requirements subclause
+ of an ST as explained in Subclause . Note however that the rules for completing
+ operations in a PP are slightly different from the rules for
+ completing operations in an ST. This is explained in more
+ detail in Subclause .
+
+
+
+ A PP has no TOE summary specification.
+
+
+
+ A low assurance PP has the same relationship to a regular PP
+ (i.e., one with full contents), as a low assurance ST has to a
+ regular ST. This means that a low-assurance PP consists of
+
+ a PP introduction, consisting of a PP reference and a TOE
+ overview;
+
+ a conformance claim;
+
+ security objectives for the operational environment;
+
+ the SFRs and the SARs (including the extended components
+ definition) and the security requirements rationale (only if
+ the dependencies are not satisfied).
+
+
+ A low-assurance PP may only claim conformance to a low-assurance
+ PP (see ). A regular PP may claim
+ conformance with a low assurance PP.
+
+ The reduced content of a low assurance PP is shown in Figure
+ .
+
+
+
+
+ This subclause is identical to the subclause on standards for STs
+ as described in Subclause ,
+ with one exception: as a PP has no TOE summary specification,
+ the third option is not valid for PPs.
+
+ The PP author is reminded that referring to a standard in SFRs
+ may impose a significant burden on a developer developing a
+ TOE to meet that PP (depending on the size and complexity of
+ the standard and the assurance level required), and that it
+ may be more suitable to require alternative (non-CC related)
+ ways to assess conformance to that standard.
+
+
+
+
+
+ The goal of this annex is to explain the Security Target (ST)
+ concept. This annex does not define the criteria; this definition can be found in CC Part
+ 3.
+
+ This annex consists of four major parts:
+
+
+ What an ST must contain. This is
+ summarised in Subclause , and described in more detail
+ in Subclauses - . These subclauses describe the
+ mandatory contents of the ST, the interrelationships
+ between these contents, and provide examples.
+
+
+ How an ST should be used. This is
+ summarised in Subclause , and described in more detail in
+ Subclause . These
+ subclauses describe how an ST should be used, and some of
+ the questions that can be answered with an ST.
+
+
+ Low Assurance STs. Low Assurance STs are
+ STs with reduced content. They are described in detail in
+ Subclause .
+
+
+ Claiming compliance with
+ standards. Subclause describes how an ST writer can claim that
+ the TOE meets a particular standard.
+
+
+
+
+
+ Figure portrays the
+ mandatory contents of an ST that are given in CC Part 3. Figure
+ may also be used as a
+ structural outline of the ST, though alternative structures are
+ possible. For instance, if the security requirements rationale
+ is particularly bulky, it could be included in an appendix of
+ the ST instead of in the security requirements subclause. The
+ separate subclauses of an ST and the contents of those
+ subclauses are briefly summarised below and explained in much
+ more detail in Subclauses to
+ . An ST normally contains:
+
+ an ST introduction containing three
+ narrative descriptions of the TOE on different levels of
+ abstraction;
+
+ a conformance claim, showing whether the
+ ST claims conformance to any PPs and/or packages, and if
+ so, to which PPs and/or packages;
+
+ a security problem definition, showing
+ threats, OSPs and assumptions;
+ security objectives, showing how the
+ solution to the security problem is divided between
+ security objectives for the TOE and security objectives
+ for the operational environment of the TOE;
+ extended components definition, where new
+ components (i.e. not included in CC Part 2 or CC Part 3)
+ may be defined. These new components are needed to define
+ extended functional and extended assurance requirements;
+ security requirements, where a
+ translation of the security objectives for the TOE into a
+ standardised language is provided. This standardised
+ language is in the form of SFRs. Additionally this subclause
+ defines the SARs;
+
+ a TOE summary specification, showing how
+ the SFRs are implemented in the TOE.
+
+
+ There also exists low assurance STs which have reduced
+ contents; these are described in detail in Subclause . The remainder of this Annex
+ assumes that an ST with full contents is used.
+
+
+
+
+ A typical ST fulfils two roles:
+
+
+ Before and during the evaluation, the ST specifies
+ ``what is to be evaluated''. In this role, the ST serves
+ as a basis for agreement between the developer and the
+ evaluator on the exact security properties of the TOE
+ and the exact scope of the evaluation. Technical
+ correctness and completeness are major issues for this
+ role. Subclause
+ describes how the ST should be used in this role.
+
+
+ After the evaluation, the ST specifies ``what was
+ evaluated''. In this role, the ST serves as a basis for
+ agreement between the developer or re-seller of the TOE
+ and the potential consumer of the TOE. The ST describes
+ the exact security properties of the TOE in an abstract
+ manner, and the potential consumer can rely on this
+ description because the TOE has been evaluated to meet
+ the ST. Ease of use and understandability are major
+ issues for this role. Subclause describes how the ST should be used
+ in this role.
+
+
+
+
+
+ Two roles (among many) that an ST should not fulfil are:
+
+
+ a detailed specification: An ST is
+ designed to be a security specification on a relatively
+ high level of abstraction. An ST should, in general, not
+ contain detailed protocol specifications, detailed
+ descriptions of algorithms and/or mechanisms, long
+ description of detailed operations etc.
+
+
+ a complete specification: An ST is
+ designed to be a security specification and not a
+ general specification. Unless security-relevant,
+ properties such as interoperability, physical size and
+ weight, required voltage etc. should not be part of an
+ ST. This means that in general an ST may be a part of a
+ complete specification, but is not a complete
+ specification in itself.
+
+
+
+
+
+
+ The ST introduction describes the TOE in a narrative way on
+ three levels of abstraction:
+
+
+ the ST reference and the TOE reference, which provide
+ identification material for the ST and the TOE that the ST
+ refers to;
+
+
+ the TOE overview, which briefly describes the TOE;
+
+
+ the TOE description, which describes the TOE in more
+ detail.
+
+
+
+
+ An ST contains a clear ST reference that identifies that
+ particular ST. A typical ST reference consists of title,
+ version, authors and publication date. An example of an ST
+ reference is ``MauveRAM Database ST, version 1.3, MauveCorp
+ Specification Team, 11 October 2002''.
+
+ An ST also contains a TOE reference that identifies the TOE
+ that claims conformance to the ST. A typical TOE reference
+ consists of developer name, TOE name and TOE version
+ number. An example of a TOE reference is ``MauveCorp
+ MauveRAM Database v2.11''. As a single TOE may be evaluated
+ multiple times, for instance by different consumers of that
+ TOE, and therefore have multiple STs, this reference is not
+ necessarily unique.
+
+ If the TOE is constructed from one or more well-known products,
+ it is allowed to reflect this in the TOE reference,
+ by referring to the product name(s). However, this should not be
+ used to mislead consumers: situations where major parts or security
+ functionalities were not considered in the evaluation, yet the TOE
+ reference does not reflect this are not allowed.
+
+ The ST reference and the TOE reference facilitate indexing
+ and referencing the ST and TOE and their inclusion in
+ summaries of lists of evaluated TOEs/Products.
+
+
+
+ The TOE overview is aimed at potential consumers of a TOE
+ who are looking through lists of evaluated TOEs/Products to
+ find TOEs that may meet their security needs, and are
+ supported by their hardware, software and firmware. The
+ typical length of a TOE overview is several
+ paragraphs.
+
+ To this end, the TOE overview briefly describes the usage of
+ the TOE and its major security features, identifies the TOE
+ type and identifies any major non-TOE
+ hardware/software/firmware required by the TOE.
+
+
+ The description of the usage and major security features
+ of the TOE is intended to give a very general idea of what
+ the TOE is capable of in terms of security, and what it
+ can be used for in a security context. This subclause should
+ be written for (potential) TOE consumers, describing TOE
+ usage and major security features in terms of business
+ operations, using language that TOE consumers
+ understand.
+
+ An example of this is ``The MauveCorp MauveRAM Database
+ v2.11 is a multi-user database intended to be used in a
+ networked environment. It allows 1024 users to be active
+ simultaneously. It allows password/token and biometric
+ authentication, protects against accidental data
+ corruption, and can roll-back ten thousand
+ transactions. Its audit features are highly configurable,
+ so as to allow detailed audit to be performed for some
+ users and transactions, while protecting the privacy of
+ other users and transactions.''
+
+
+
+ The TOE overview identifies the general type of TOE, such
+ as: firewall, VPN-firewall, smart card, crypto-modem,
+ intranet, web server, database, web server and database,
+ LAN, LAN with web server and database, etc.
+ It may be the case that the TOE is not of a readily
+ available type, in which case ``none'' would be
+ acceptable.
+
+ In some cases, a TOE type can mislead consumers. Examples
+ include:
+
+
+ certain functionality can be expected of the TOE
+ because of its TOE type, but the TOE does not have
+ this functionality. Examples include:
+
+
+ an ATM-card type TOE, which does not support any
+ identification/authentication functionality;
+
+
+ a firewall type TOE, which does not support
+ protocols that are almost universally used;
+
+
+ a PKI-type TOE, which has no certificate
+ revocation functionality.
+
+
+
+
+ the TOE can be expected to operate in certain
+ operational environments because of its TOE type, but
+ it cannot do so. Examples include:
+
+
+ a PC-operating system type TOE, which is unable to
+ function securely unless the PC has no network
+ connection, floppy drive, and CD/DVD-player;
+
+
+ a firewall, which is unable to function securely
+ unless all users that can connect through that
+ firewall are benign.
+
+
+
+
+
+
+
+
+ While some TOEs do not rely upon other IT,
+ many TOEs (notably software TOEs) rely on additional, non-TOE, hardware, software and/or
+ firmware. In the latter case, the TOE overview is required to identify any non-TOE
+ hardware,software and/or firmware .
+ A complete and fully detailed identification of the additional hardware, software and/or firmware is not necessary,
+ but the identification should be complete and detailed enough for potential consumers to determine the major hardware,software and/or firmware needed to use the TOE.
+
+
+ Example hardware/software/firmware identifications are:
+
+
+ a standard PC with a 1GHz or higher processor and
+ 512MB or more RAM, running version 3.0 Update 6b, c,
+ or 7, or version 4.0 of the Yaiza operating system;
+
+
+ a standard PC with a 1GHz or higher processor and
+ 512MB or more RAM, running version 3.0 Update 6d of
+ the Yaiza operating system and the WonderMagic 1.0
+ Graphics card with the 1.0 WM Driver Set;
+
+
+ a standard PC with version 3.0 of the Yaiza OS (or
+ higher);
+
+
+ a CleverCard SB2067 integrated circuit;
+
+
+ a CleverCard SB2067 integrated circuit running v2.0 of
+ the QuickOS smart card operating system;
+
+
+ the December 2002 installation of the LAN of the
+ Director-General's Office of the Department of
+ Traffic.
+
+
+
+
+
+
+ A TOE description is a narrative description of the TOE,
+ likely to run to several pages. The TOE description should
+ provide evaluators and potential consumers with a general
+ understanding of the security capabilities of the TOE, in
+ more detail than was provided in the TOE overview. The TOE
+ description may also be used to describe the wider
+ application context into which the TOE will fit.
+
+ The TOE description discusses the physical scope of the TOE:
+ a list of all hardware, firmware, software and guidance
+ parts that constitute the TOE. This list should be described
+ at a level of detail that is sufficient to give the reader a
+ general understanding of those parts.
+
+ The TOE description should also discuss the logical scope of
+ the TOE: the logical security features offered by the TOE at
+ a level of detail that is sufficient to give the reader a
+ general understanding of those features. This description is
+ expected to be in more detail than the major security
+ features described in the TOE overview.
+
+ An important property of the physical and logical scopes is
+ that they describe the TOE in such a way that there remains
+ no doubt on whether a certain part or feature is in the TOE
+ or whether this part or feature is outside the TOE. This is
+ especially important when the TOE is intertwined with and
+ cannot be easily separated from non-TOE entities.
+
+ Examples where the TOE is intertwined with non-TOE entities
+ are:
+
+
+ the TOE is a cryptographic co-processor of a smart card
+ IC, instead of the entire IC;
+
+
+ the TOE is a smart card IC, except for the cryptographic
+ processor;
+
+
+ the TOE is the Network Address Translation part of the
+ MinuteGap Firewall v18.5.
+
+
+
+
+
+
+ This subclause of an ST describes how the ST conforms with:
+
+ the Common Criteria itself
+
+ Protection Profiles (if any)
+
+ Packages (if any)
+
+
+ The description of how the ST conforms to the CC consists of
+ two items: the version of the CC that is used and whether the
+ ST contains extended security requirements or not (see
+ Subclause ).
+ The description of conformance of the ST to Protection
+ Profiles means that the ST lists the Protection Profiles that
+ conformance is being claimed to. For a general explanation of
+ this, see Subclause . For a detailed description, see
+ .
+ The description of conformance of the ST to packages means
+ that the ST lists the packages that conformance is being
+ claimed to. For an explanation of this, see Subclause .
+
+
+
+
+ The security problem definition defines the security problem
+ that is to be addressed. The security problem definition is,
+ as far as the CC is concerned, axiomatic. That is, the
+ process of deriving the security problem definition falls
+ outside the scope of the CC.
+
+ However, it should be noted that the usefulness of the
+ results of an evaluation strongly depends on the ST, and the
+ usefulness of the ST strongly depends on the quality of the
+ security problem definition. It is therefore often
+ worthwhile to spend significant resources and use
+ well-defined processes and analyses to derive a good
+ security problem definition.
+
+ Note that according to CC part 3 it is not mandatory to have statements in all subclauses, an ST with threats does not need to have OSPs and vice versa. Any ST may omit assumptions.
+
+ Also note that where the TOE is physically distributed, it
+ may be better to discuss the relevant threats, OSPs and
+ assumptions separately for distinct domains of the TOE
+ operational environment.
+
+
+
+ This subclause of the security problem definition shows the
+ threats that are to be countered by the TOE, its operational
+ environment, or a combination of the two.
+
+ A threat consists of an adverse action performed by a threat agent on an asset.
+
+ Adverse actions influence one or more properties of an asset from which that asset derives its value.
+
+ Threat agents may be described as individual entities, but in some cases it may be better to describe them as types of entities, groups of entities etc.
+
+ Examples of threat agents are hackers, users, computer processes, TOE development personnel, and accidents. Threat agents may be further described by aspects such as expertise, resources, opportunity and motivation.
+
+ Adverse actions are actions performed by a threat agent on an asset. These actions influence one or more properties of an asset from which that asset derives its value.
+
+ Examples of threats are:
+
+
+ a hacker (with substantial expertise, standard
+ equipment, and being paid to do so) remotely copying
+ confidential files from a company network;
+
+
+ a worm seriously degrading the performance of a
+ wide-area network;
+
+
+ a system administrator violating user privacy;
+
+ Someone on the Internet listening in on confidential
+ electronic communication.
+
+
+
+ This subclause of the security problem definition shows the
+ OSPs that are to be enforced by the TOE, its operational
+ environment, or a combination of the two.
+
+ OSPs are security rules, procedures, or guidelines imposed
+ (or presumed to be imposed) now and/or in the future by an
+ actual or hypothetical organisation in the operational
+ environment. OSPs may be laid down by an organisation
+ controlling the operational environment of the TOE, or they
+ may be laid down by legislative or regulatory bodies. OSPs
+ can apply to the TOE and/or the operational environment of
+ the TOE.
+
+ Examples of OSPs are:
+
+
+ All products that are used by the Government must
+ conform to the National Standard for password generation
+ and encryption;
+
+
+ Only users with System Administrator privilege and
+ clearance of Department Secret shall be allowed to
+ manage the Department Fileserver.
+
+
+
+
+
+ This subclause of the security problem definition shows the
+ assumptions that are made on the operational environment in
+ order to be able to provide security functionality. If the
+ TOE is placed in an operational environment that does not
+ meet these assumptions, the TOE may not be able to provide
+ all of its security functionality anymore. Assumptions can
+ be on physical, personnel and connectivity of the
+ operational environment.
+
+ Examples of assumptions are:
+
+
+ Assumptions on physical aspects of the operational
+ environment:
+
+
+ It is assumed that the TOE will be placed in a room
+ that is designed to minimise electromagnetic
+ emanations;
+
+
+ It is assumed that the administrator consoles of the
+ TOE will be placed in a restricted access area.
+
+
+
+
+ Assumptions on personnel aspects of the operational
+ environment:
+
+
+ It is assumed that users of the TOE will be trained
+ sufficiently in order to operate the TOE;
+
+
+ It is assumed that users of the TOE are approved for
+ information that is classified as National Secret;
+
+
+ It is assumed that users of the TOE will not write
+ down their passwords.
+
+
+
+
+ Assumptions on connectivity aspects of the operational
+ environment:
+
+
+ It is assumed that a PC workstation with at least
+ 10GB of disk space is available to run the TOE on;
+
+
+ It is assumed that the TOE is the only non-OS
+ application running on this workstation;
+
+
+ It is assumed that the TOE will not be connected to
+ an untrusted network.
+
+
+
+
+
+ Note that during the evaluation these assumptions are
+ considered to be true: they are not tested in any way. For
+ these reasons, assumptions can only be made on the
+ operational environment. Assumptions can never be made on
+ the behaviour of the TOE because an evaluation consists of
+ evaluating assertions made about the TOE and not by assuming
+ that assertions on the TOE are true.
+
+
+
+
+ The security objectives are a concise and abstract statement
+ of the intended solution to the problem defined by the
+ security problem definition. The role of the security
+ objectives is threefold:
+
+
+ provide a high-level, natural language solution of the
+ problem;
+
+
+ divide this solution into two part wise solutions, that
+ reflect that different entities each have to address a
+ part of the problem;
+
+
+ demonstrate that these part wise solutions form a complete
+ solution to the problem.
+
+
+
+
+ The security objectives consist of a set of short and clear
+ statements without overly much detail that together form a
+ high-level solution to the security problem. The level of
+ abstraction of the security objectives aims at being clear
+ and understandable to knowledgeable potential consumers of
+ the TOE. The security objectives are in natural language.
+
+
+
+ In an ST the high-level security solution, as described by
+ the security objectives, is divided into two part wise
+ solutions. These part wise solutions are called the security
+ objectives for the TOE and the security objectives for the
+ operational environment. This reflects that these part wise
+ solutions are to be provided by two different entities: the
+ TOE, and the operational environment.
+
+
+ The TOE provides security functionality to solve a certain
+ part of the problem defined by the security problem
+ definition. This part wise solution is called the security
+ objectives for the TOE and consists of a set of objectives
+ that the TOE should achieve in order to solve its part of
+ the problem.
+
+ Examples of security objectives for the TOE are:
+
+
+ The TOE shall keep confidential the content of all
+ files transmitted between it and a Server;
+
+
+ The TOE shall identify and authenticate all users
+ before allowing them access to the Transmission
+ Service provided by the TOE;
+
+
+ The TOE shall restrict user access to data according
+ to the Data Access policy described in Annex 3 of the
+ ST.
+
+
+
+ If the TOE is physically distributed, it may be better to
+ subdivide the ST subclause containing the security
+ objectives for the TOE into several subsubclauses to reflect
+ this.
+
+
+
+ The operational environment of the TOE implements
+ technical and procedural measures to assist the TOE in
+ correctly providing its security functionality (which is
+ defined by the security objectives for the TOE). This
+ part wise solution is called the security objectives for
+ the operational environment and consists of a set of
+ statements describing the goals that the operational
+ environment should achieve.
+
+ Examples of security objectives for the operational
+ environment are:
+
+
+ The operational environment shall provide a
+ workstation with the OS Inux version 3.01b to execute
+ the TOE on;
+
+
+ The operational environment shall ensure that all
+ human TOE users receive appropriate training before
+ allowing them to work with the TOE;
+
+
+ The operational environment of the TOE shall restrict
+ physical access to the TOE to administrative personnel
+ and maintenance personnel accompanied by
+ administrative personnel;
+
+
+ The operational environment shall ensure the
+ confidentiality of the audit logs generated by the TOE
+ before sending them to the central Audit Server.
+
+
+
+ If the operational environment of the TOE consists of
+ multiple sites, each with different properties, it may be
+ better to subdivide the ST subclause containing the security
+ objectives for the operational environment into several
+ subsubclauses to reflect this.
+
+
+
+
+ The ST also contains a security objectives rationale
+ containing two subclauses:
+
+
+ a tracing that shows which security objectives address
+ which threats, OSPs and assumptions;
+
+
+ a set of justifications that shows that all threats,
+ OSPs, and assumptions are effectively addressed by the
+ security objectives.
+
+
+
+
+ The tracing shows how the security objectives trace back
+ to the threats, OSPs and assumptions as described in the
+ security problem definition.
+ No spurious objectives: Each security
+ objective traces to at least one threat, OSP or
+ assumption.
+ Complete with respect to the security problem
+ definition: Each threat, OSP and assumption
+ has at least one security objective tracing to it.
+ Correct tracing: Since assumptions
+ are always made by the TOE on the operational
+ environment, security objectives for the TOE do not
+ trace back to assumptions. The tracings allowed by CC Part 3 are
+ depicted in Figure .
+
+
+
+ Multiple security objectives may trace to the same threat,
+ indicating that the combination of those security
+ objectives counters that threat. A similar argument holds
+ for OSPs and assumptions.
+
+
+
+ The security objectives rationale also demonstrates that the tracing is effective:
+ All the given threats, OSPs and assumption are addressed (i.e. countered, enforced and upheld respectively) if all security objectives tracing to a particular threat, OSP or assumption are achieved.
+
+ This demonstration analyses the effect of achieving the
+ relevant security objectives on countering the threats,
+ enforcing the OSPs and upholding the assumptions and leads
+ to the conclusion that this is indeed the case.
+
+ In some cases, where parts of the security problem
+ definition very closely resemble some security objectives,
+ the demonstration can be very simple. An example is: a
+ threat ``T17: Threat agent X reads the Confidential
+ Information in transit between A and B'', a security
+ objective for the TOE: ``OT12: The TOE shall ensure that
+ all information transmitted between A and B is kept
+ confidential'', and a demonstration ``T17 is directly
+ countered by OT12''.
+
+
+
+ Countering a threat does not necessarily mean removing
+ that threat, it can also mean sufficiently diminishing
+ that threat or sufficiently mitigating that threat.
+
+ Examples of removing a threat are:
+
+
+ removing the ability to execute the adverse action
+ from the threat agent;
+
+
+ moving, changing or protecting the asset in such a way
+ that the adverse action is no longer applicable to it;
+
+
+ removing the threat agent (e.g. removing machines from
+ a network that frequently crash that network).
+
+
+
+ Examples of diminishing a threat are:
+
+
+ restricting the ability of a threat agent to perform
+ adverse actions;
+
+
+ restricting the opportunity to execute an adverse
+ action of a threat agent;
+
+
+ reducing the likelihood of an executed adverse action
+ being successful;
+
+
+ reducing the motivation to execute an adverse action
+ of a threat agent by deterrence;
+
+
+ requiring greater expertise or greater resources from
+ the threat agent.
+
+
+
+ Examples of mitigating the effects of a threat are:
+
+
+ making frequent back-ups of the asset;
+
+
+ obtaining spare copies of an asset;
+
+
+ insuring an asset;
+
+
+ ensuring that successful adverse actions are always
+ timely detected, so that appropriate action can be
+ taken.
+
+
+
+
+
+
+ Based on the security objectives and the security objectives
+ rationale, the following conclusion can be drawn: if all
+ security objectives are achieved then the security problem
+ as defined in is solved: all
+ threats are countered, all OSPs are enforced, and all
+ assumptions are upheld.
+
+
+
+
+ In many cases the security requirements (see the next
+ Subclause) in an ST are based on components in CC Part 2 or CC
+ Part 3. However, in some cases, there may be requirements in
+ an ST that are not based on components in CC Part 2 or CC Part
+ 3. In this case, new components (extended components) must be
+ defined, and this definition should be done in the Extended
+ Components Definition. For more information on this, see Annex
+
+ Note that this subclause is intended to contain only the
+ extended components and not the extended requirements
+ (requirements based on extended components). The extended
+ requirements should be included in the security requirements
+ (see the next Subclause) and are for all purposes the same as
+ requirements based on components in CC Part 2 or CC Part
+ 3.
+
+
+
+ The security requirements consists of two groups of
+ requirements:
+
+ the security functional requirements
+ (SFRs): a translation of the security
+ objectives for the TOE into a standardised
+ language;
+ the security assurance requirements
+ (SARs): a description of how assurance is to be
+ gained that the TOE meets the SFRs.
+
+ These two groups are discussed in the following two
+ subclauses:
+
+ The SFRs are a translation of the security objectives
+ for the TOE. They are usually at a more detailed level of
+ abstraction, but they have to be a complete translation (the
+ security objectives must be completely addressed). The CC
+ requires this translation into a standardised language for
+ several reasons:
+
+ to provide an exact description of what is to be
+ evaluated. As security objectives for the TOE are
+ usually formulated in natural language, translation into
+ a standardised language enforces a more exact
+ description of the functionality of the TOE.
+ to allow comparison between two STs. As different ST
+ authors may use different terminology in describing
+ their security objectives, the standardised language
+ enforces using the same terminology and concepts. This
+ allows easy comparison.
+
+ There is no translation required in the CC for the security
+ objectives for the operational environment, because the
+ operational environment is not evaluated and does therefore
+ not require a description aimed at its evaluation.
+ It may be the case that parts of the operational
+ environment are evaluated in another evaluation, but this is
+ out of scope for the current evaluation. For example: an OS
+ TOE may require a firewall to be present in its operational
+ environment. Another evaluation may subsequently evaluate
+ the firewall, but this evaluation has nothing to do with the
+ evaluation of the OS TOE.
+
+
+ The CC supports this translation in three ways:
+
+ by providing a predefined precise ``language''
+ designed to describe exactly what is to be
+ evaluated. This language is defined as a set of
+ components defined in CC Part 2. The use of this
+ language as a well-defined translation of the security
+ objectives for the TOE to SFRs is mandatory, though
+ some exceptions exist (see ).
+
+ by providing operations: mechanisms that allow the
+ ST writer to modify the SFRs to provide a more
+ accurate translation of the security objectives for
+ the TOE. The CC has four operations: assignment,
+ selection, iteration, and refinement. These are
+ described further in Subclause
+ .
+ by providing dependencies: a mechanism that
+ supports a more complete translation to SFRs. In the
+ CC Part 2 language, an SFR can have a dependency on
+ other SFRs. This signifies that if an ST uses that
+ SFR, it generally needs to use those other SFRs as
+ well. This makes it much harder for the ST writer to
+ overlook including necessary SFRs and thereby improves
+ the completeness of STs. Dependencies are described
+ further in Clause .
+
+
+
+
+ The ST also contains a security requirements rationale,
+ consisting of two subclauses about SFRs:
+
+ a tracing that shows which SFRs address which security
+ objectives for the TOE;
+
+ a set of justifications that shows that all security
+ objectives for the TOE are effectively addressed by
+ the SFRs.
+
+
+
+ The tracing shows how the SFRs trace back to the
+ security objectives for the TOE as follows:
+ No spurious SFRs: Each SFR traces
+ back to at least one security objective.
+ Complete with respect to the security
+ objectives for the TOE: Each security
+ objective for the TOE has at least one SFR tracing
+ to it.
+
+
+ Multiple SFRs may trace to the same security objective
+ for the TOE, indicating that the combination of those
+ security requirements meets that security objective for
+ the TOE.
+
+
+
+ The security requirements rationale
+ demonstrates that the tracing is effective: if all SFRs
+ tracing to a particular security objective for the TOE
+ are satisfied, that security objective for the TOE is
+ achieved.
+
+ This demonstration should analyse the effects of
+ satisfying the relevant SFRs on achieving the security
+ objective for the TOE and lead to the conclusion that
+ this is indeed the case.
+
+ In cases where SFRs very closely resemble security
+ objectives for the TOE, the demonstration can be very
+ simple.
+
+
+
+
+ The SARs are a description of how the TOE is to be
+ evaluated. This description uses a standardised language
+ for two reasons:
+
+ to provide an exact description of how the TOE is to
+ be evaluated. Using a standardised language assists in
+ creating an exact description and avoids ambiguity.
+ to allow comparison between two STs. As different
+ ST authors may use different terminology in describing
+ the evaluation, the standardised language enforces
+ using the same terminology and concepts. This allows
+ easy comparison.
+ This standardised language is defined as a set of
+ components defined in CC Part 3. The use of this language
+ is mandatory, though some exceptions exist (see Annex
+ ).The CC
+ enhances this languages in two ways:
+
+ by providing operations: mechanisms that allow the
+ ST writer to modify the SARs. The CC has
+ four operations: assignment, selection, iteration, and
+ refinement. These are described further in Subclause
+ .by providing dependencies: a mechanism that
+ supports a more complete translation to SARs. In the
+ CC Part 3 language, an SAR can have a dependency on
+ other SARs. This signifies that if an ST uses that
+ SAR, it generally needs to use those other SARs as
+ well. This makes it much harder for the ST writer to
+ overlook including necessary SARs and thereby improves
+ the completeness of STs. Dependencies are described
+ further in Annex .
+
+ The ST also contains a security requirements rationale that
+ explains why this particular set of SARs was deemed
+ appropriate. There are no specific requirements for this
+ explanation. The goal for this explanation is to allow the
+ readers of the ST to understand the reasons why this
+ particular set was chosen.
+ An example of an inconsistency is if the security problem
+ description mentions threats where the threat agent is very
+ capable, and a low (or no) is
+ included in the SARs.
+
+
+ In the security problem definition of the ST, the security
+ problem is defined as consisting of threats, OSPs and
+ assumptions. In the security objectives subclause of the ST,
+ the solution is provided in the form of two sub-solutions:
+
+
+ security objectives for the TOE;
+
+
+ security objectives for the operational environment.
+
+
+
+ Additionally, a security objectives rationale is provided
+ showing that if all security objectives are achieved, the
+ security problem is solved: all threats are countered, all
+ OSPs are enforced, and all assumptions are upheld.
+
+
+ In the security requirements subclause of the ST, the security
+ objectives for the TOE are translated to SFRs and a security
+ requirements rationale is provided showing that if all SFRs
+ are satisfied, all security objectives for the TOE are
+ achieved.
+ Additionally, a set of SARs is provided to show how the
+ TOE is evaluated, together with an explanation for selecting
+ these SARs.
+
+ All of the above can be combined into the statement: If all
+ SFRs and SARs are satisfied and all security objectives for
+ the operational environment are achieved, then there exists
+ assurance that the security problem as defined in is solved: all threats are
+ countered, all OSPs are enforced, and all assumptions are
+ upheld. This is illustrated in Figure .
+ The amount of assurance obtained is defined by the SARs,
+ and whether this amount of assurance is sufficient is
+ defined by the explanation for choosing these SARs.
+
+
+
+
+ The objective for the TOE summary specification is to provide
+ potential consumers of the TOE with a description of how the
+ TOE satisfies all the SFRs. The TOE summary specification
+ should provide the general technical mechanisms that the TOE
+ uses for this purpose. The level of detail of this description
+ should be enough to enable potential consumers to understand
+ the general form and implementation of the TOE.
+
+ For instance if the TOE is an Internet PC and the SFRs contain
+ to specify authentication,
+ the TOE summary specification should indicate how this
+ authentication is done: password, token, iris scanning
+ etc. More information, like applicable standards that the TOE
+ uses to meet SFRs, or more detailed descriptions may also be
+ provided.
+
+
+
+ After the evaluation, the ST specifies ``what was
+ evaluated''. In this role, the ST serves as a basis for
+ agreement between the developer or re-seller of the TOE and
+ the potential consumer of the TOE. The ST can therefore answer
+ the following questions (and more):
+
+
+ How can I find the ST/TOE that I need given the
+ multitude of existing STs/TOEs? This question
+ is addressed by the TOE overview, which gives a brief
+ (several paragraphs) summary of the TOE;
+
+
+ Does this TOE fit in with my existing
+ IT-infrastructure? This question is addressed
+ by the TOE overview, which identifies the major
+ hardware/firmware/software elements needed to run the
+ TOE;
+
+
+ Does this TOE fit in with my existing operational
+ environment? This question is addressed by the
+ security objectives for the operational environment,
+ which identifies all constraints the TOE places on the
+ operational environment in order to function;
+
+
+ What does the TOE do (interested reader)?
+ This question is addressed by the TOE overview, which
+ gives a brief (several paragraphs) summary of the TOE;
+
+
+ What does the TOE do (potential
+ consumer)? This question is addressed by the
+ TOE description, which gives a less brief (several
+ pages) summary of the TOE;
+
+
+ What does the TOE do (technical)? This
+ question is addressed by the TOE summary specification
+ which provides a high-level description of the mechanisms
+ the TOE uses;
+
+
+ What does the TOE do (expert)? This
+ question is addressed by the SFRs which provide an
+ abstract highly technical description, and the TOE summary
+ specification which provide additional detail;
+
+
+ Does the TOE address the problem as defined by my
+ government/organisation? If your
+ government/organisation has defined packages and/or PPs
+ to define this solution, then the answer can be found in
+ the Conformance Claims subclause of the ST, which lists
+ all packages and PPs that the ST conforms to.
+
+
+ Does the TOE address my security problem
+ (expert)? What are the threats countered by the
+ TOE? What organisational security policies does it
+ enforce? What assumptions does it make about the
+ operational environment? These questions are addressed
+ by the security problem definition;
+
+
+ How much trust can I place in the TOE?
+ This can be found in the SARs in the security
+ requirements subclause, which provide the assurance level
+ that was used to evaluate the TOE, and hence the trust
+ that the evaluation provides in the correctness of the
+ TOE.
+
+
+
+
+
+ Writing an ST is not a trivial task, and may, especially in
+ low assurance evaluations, be a major part of the total effort
+ expended by the developer and the evaluator in the whole of
+ the evaluation. For this reason, it is also possible to write
+ a low assurance ST.
+
+ The CC allows the use of a low assurance ST for an EAL 1
+ evaluation, but not for EAL 2 and up. A low-assurance ST may
+ only claim conformance to a low-assurance PP (see ). A
+ regular ST (i.e., one with full contents) may claim conformance
+ with a low assurance PP.
+
+ A low assurance ST has a significantly reduced content compared
+ to a regular ST:
+
+ there is no need to describe the security problem
+ definition;
+
+ there is no need to describe the security objectives for the
+ TOE. The security objectives for the operational environment
+ shall still be described;
+
+ there is no need to describe the security objectives
+ rationale as there is no security problem definition in the
+ ST;
+
+ the security requirements rationale only needs to justify
+ (any) dependencies not being satisfied as there are no
+ security objectives for the TOE in the ST.
+
+
+ All that remains are:
+
+
+ the references to TOE and ST
+
+
+ the conformance claim
+
+
+ the various narrative descriptions
+
+
+ the TOE overview
+
+
+ the TOE description
+
+
+ the TOE summary specification
+
+
+
+ the security objectives for the operational
+ environment
+
+ the SFRs and the SARs (including the extended components
+ definition) and the security requirements rationale (only if the dependencies are not satisfied).
+
+
+
+ The reduced content of a low assurance ST is shown in Figure
+ .
+
+
+
+ In some cases, an ST writer may wish to refer to an
+ external standard, such as a particular cryptographic standard
+ or protocol. The CC allows three ways of doing this:
+
+
+ As an organisational security policy (or part of it).
+
+ If, for example, there exists a government standard
+ defining how passwords have to be chosen, this may be
+ stated as an organisational security policy in an
+ ST. This may lead to an objective for the environment
+ (e. g. if users of the TOE need to choose passwords
+ accordingly), or it may lead to security objectives for
+ the TOE and then to appropriate SFRs (likely of the
+ class), if the TOE
+ generates passwords. In both cases the rationale of the
+ developer needs to make plausible that the security
+ objectives for the TOE and the SFRs are suitable to
+ fulfil the OSP. The evaluator will examine if this is
+ in fact plausible (and may decide to look into the
+ standard for this), if the OSP is implemented by SFRs,
+ as explained below.
+
+
+ As a technical standard (for example a cryptographic
+ standard) used in a refinement of an SFR.
+
+ In this case conformance to the standard is part of the
+ fulfilment of the SFR by the TOE and is treated as if
+ the full text of the standard is part of the
+ SFR. Conformance is subsequently determined like any
+ other conformance to SFRs: during and it is
+ analysed, by design analysis and tests, that the SFR is
+ completely and fully implemented in the TOE. If
+ reference to only a certain part of a standard is
+ desired, that part should be unambiguously stated in the
+ SFR refinement.
+
+
+ As a technical standard (for example a cryptographic
+ standard) mentioned in the TOE summary specification.
+
+ The TOE summary specification is only considered as an
+ explanation of how the SFRs are realised, and is not
+ strictly used as a strict implementation requirement
+ like the SFRs or the documents delivered for . So the evaluator may detect an
+ inconsistency if the TSS references a technical standard
+ and this is not reflected in
+ documentation, but there is no routine activity to test
+ fulfilment of the standard.
+
+
+
+
+
+
+ For the purposes of this document, the terms, definitions,
+ symbols and abbreviated terms given in CC Part 1 apply.
+
+
+
+ Security assurance components, as defined in this CC Part 3, are
+ the basis for the security assurance requirements expressed in a
+ Protection Profile (PP) or a Security Target (ST).
+
+ These requirements establish a standard way of expressing the
+ assurance requirements for TOEs. This CC Part 3 catalogues the
+ set of assurance components, families and classes. This CC Part
+ 3 also defines evaluation criteria for PPs and STs and presents
+ evaluation assurance levels that define the predefined CC scale
+ for rating assurance for TOEs, which is called the Evaluation
+ Assurance Levels (EALs).
+
+ The audience for this CC Part 3 includes consumers, developers,
+ and evaluators of secure IT products. CC Part 1 Clause provides additional information
+ on the target audience of the CC, and on the use of the CC by
+ the groups that comprise the target audience. These groups may
+ use this part of the CC as follows:
+
+
+ Consumers, who use this CC Part 3 when selecting components
+ to express assurance requirements to satisfy the security
+ objectives expressed in a PP or ST, determining required
+ levels of security assurance of the TOE.
+
+
+ Developers, who respond to actual or perceived consumer
+ security requirements in constructing a TOE, reference this
+ CC Part 3 when interpreting statements of assurance
+ requirements and determining assurance approaches of TOEs.
+
+
+ Evaluators, who use the assurance requirements defined in
+ this part of the CC as mandatory statement of evaluation
+ criteria when determining the assurance of TOEs and when
+ evaluating PPs and STs.
+
+
+
+
+
+
+ Clause describes the paradigm
+ used in the security assurance requirements of CC Part
+ 3.
+
+ Clause describes the
+ presentation structure of the assurance classes, families,
+ components, evaluation assurance levels along with their
+ relationships, and the structure of the composed assurance
+ packages. It also characterises the assurance classes and
+ families found in Clauses through
+ .
+
+ Clause provides detailed
+ definitions of the EALs.
+
+ Clause provides detailed
+ definitions of the CAPs.
+
+ Clauses through provide the detailed definitions of the CC Part 3
+ assurance classes.
+
+ provides further
+ explanations and examples of the concepts behind the
+ Development class.
+
+ provides an explanation of
+ the concepts behind composed TOE evaluations and the
+ Composition class.
+
+ provides
+ a summary of the dependencies between the assurance
+ components.
+
+ provides a cross
+ reference between PPs and the families and components of the
+ class.
+
+ provides a cross reference
+ between the EALs and the assurance components.
+
+ provides a cross reference
+ between the CAPs and the assurance components.
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CC-1
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 1: Introduction and general model.
+
+
+
+ CC-2
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 2: Functional security components.
+
+
+
+
+
+ This CC Part 3 defines the assurance requirements of the CC. It
+ includes the evaluation assurance levels (EALs) that define a
+ scale for measuring assurance for component TOEs, the composed
+ assurance packages (CAPs) that define a scale for measuring
+ assurance for composed TOEs, the individual assurance components
+ from which the assurance levels and packages are composed, and
+ the criteria for evaluation of PPs and STs.
+
+
+
+ The goal of this annex is to explain the concepts behind
+ composition evaluations and the
+ criteria. This annex does not define the criteria; this definition can be found in clause
+ .
+
+
+ The IT market is, on the whole, made up of vendors offering a
+ particular type of product/technology. Although there is some
+ overlap, where a PC hardware vendor may also offer application
+ software and/or operating systems or a chip manufacturer may
+ also develop a dedicated operating system for their own
+ chipset, it is often the case that an IT solution is
+ implemented by a variety of vendors.
+
+ There is sometimes a need for assurance in the combination
+ (composition) of components in addition to the assurance of
+ the individual components. Although there is cooperation
+ between these vendors, in the dissemination of certain
+ material required for the technical integration of the
+ components, the agreements rarely stretch to the extent of
+ providing detailed design information and development
+ process/procedure evidence. This lack of information from the
+ developer of a component on which another component relies
+ means that the dependent component developer does not have
+ access to the type of information necessary to perform an
+ evaluation of both the dependent and base components at EAL2
+ or above. Therefore, while an evaluation of the dependent
+ component can still be performed at any assurance level, to
+ compose components with assurance at EAL2 or above it is
+ necessary to reuse the evaluation evidence and results of
+ evaluations performed for the component developer.
+
+ It is intended that the criteria
+ are applicable in the situation where one IT entity is
+ dependent on another for the provision of security
+ services. The entity providing the services is termed the
+ ``base component'', and that receiving the services is termed
+ the ``dependent component''. This relationship may exist in a
+ number of contexts. For example, an application (dependent
+ component) may use services provided by an operating system
+ (base component). Alternatively, the relationship may be
+ peer-to-peer, in the sense of two linked applications, either
+ running in a common operating system environment, or on
+ separate hardware platforms. If there is a dominant peer
+ providing the services to the minor peer, the dominant peer is
+ considered to be the base component and the minor peer the
+ dependent component. If the peers provide services to each
+ other in a mutual manner, each peer will be considered to be
+ the base component for the services offered and dependent
+ component for the services required. This will require
+ iterations of the components
+ applying all requirements to each type of component
+ peer.
+
+ The criteria are also intended to be more broadly applicable,
+ stepwise (where a composed TOE comprised of a dependent
+ component and a base component itself becomes the base
+ component of another composed TOE), in more complex
+ relationships, but this may require further
+ interpretation.
+
+ It is still required for composed TOE evaluations that the
+ individual components are evaluated independently, as the
+ composition evaluation builds on the results of the individual
+ component evaluations. The evaluation of the dependent
+ component may still be in progress when the composed TOE
+ evaluation commences. However, the dependent component
+ evaluation must complete before the composed TOE evaluation
+ completes.
+
+ The composed evaluation activities may take place at the same
+ time as the dependent component evaluation. This is due to two
+ factors:
+
+
+ Economic/business drivers - the dependent component
+ developer will either be sponsoring the composition
+ evaluation activities or supporting these activities as
+ the evaluation deliverables from the dependent component
+ evaluation are required for composed evaluation
+ activities.
+
+ Technical drivers - the components consider whether the
+ requisite assurance is provided by the base component
+ (e.g. considering the changes to the base component since
+ completion of the component evaluation) with the
+ understanding that the dependent component has recently
+ undergone (is undergoing) component evaluation and all
+ evaluation deliverables associated with the evaluation are
+ available. Therefore, there are no activities during
+ composition requesting the dependent component evaluation
+ activities to be re-verified. Also, it is verified that
+ the base component forms (one of) the test configurations
+ for the testing of the dependent component during the
+ dependent component evaluation, leaving to consider the base component in this
+ configuration.
+
+ The evaluation evidence from the evaluation of the dependent
+ component is required input into the composed TOE evaluation
+ activities. The only evaluation material from the evaluation
+ of the base component that is required as input into the
+ composed TOE evaluation activities:
+
+
+ Residual vulnerabilities in the base component, as
+ reported during the base component evaluation. This is
+ required for the
+ activities.
+
+ No other evaluation evidence from the base component
+ activities should be required for the composed TOE evaluation,
+ as the evaluation results from the component evaluation of the
+ base component should be reused. Additional information about
+ the base component may be required if the composed TOE TSF
+ includes more of the base component than was considered to be
+ TSF during component evaluation of the base component.
+
+ The component evaluation of the base and dependent components
+ are assumed to be complete by the time final verdicts are
+ assigned for the components.
+
+ The components only consider
+ resistance against an attacker with an attack potential up to
+ Enhanced-Basic. This is due to the level of design information
+ that can be provided of how the base component provides the
+ services on which the dependent component relies through
+ application of the
+ activities. Therefore, the confidence arising from composed TOE
+ evaluations using CAPs is limited to a level similar to that
+ obtained from EAL4 component TOE evaluations. Although
+ assurance in the components that comprise the composed TOE may
+ be higher than EAL4.
+
+
+
+ An ST will be submitted by the developer for the evaluation of
+ the composed (base component + dependent component) TOE. This
+ ST will identify the assurance package to be applied to the
+ composed TOE, providing assurance in the composed entity by
+ drawing upon the assurance gained in the component
+ evaluations.
+
+ The purpose of considering the composition of components
+ within an ST is to validate the compatibility of the
+ components from the point of view of both the environment and
+ the requirements, and also to assess that the composed TOE ST
+ is consistent with the component STs and the security policies
+ expressed within them. This includes determining that the
+ component STs and the security policies expressed within them
+ are compatible.
+
+ The composed TOE ST may refer out to the content of the
+ component STs, or the ST author may chose to reiterate the
+ material of the component STs within the composed TOE ST
+ providing a rationale of how the component STs are represented
+ in the composed TOE ST.
+
+ During the conduct of the
+ evaluation activities for a composed TOE ST the evaluator
+ determines that the component STs are accurately represented
+ in the composed TOE ST. This is achieved through determining
+ that the composed TOE ST demonstrably conforms to the
+ component TOE STs. Also, the evaluator will need to determine
+ that the dependencies of the dependent component on the
+ operational environment are adequately fulfilled in the
+ composed TOE.
+
+ The composed TOE description will describe the composed
+ solution. The logical and physical scope and boundary of the
+ composed solution will be described, and the logical
+ boundary(ies) between the components will also be
+ identified. The description will identify the security
+ functionality to be provided by each component.
+
+ The statement of SFRs for the composed TOE will identify which
+ component is to satisfy an SFR. If an SFR is met by both
+ components, then the statement will identify which component
+ meets the different aspects of the SFR. Similarly the composed
+ TOE Summary Specification will identify which component
+ provides the security functionality described.
+
+ The package of requirements
+ applied to the composed TOE ST should be consistent with the
+ package of requirements used in
+ the component evaluations.
+
+ Reuse of evaluation results from the evaluation of component
+ STs can be made in the instances that the composed TOE ST
+ directly refers to the component STs. e.g. if the composed TOE
+ ST refers to a component ST for part of its statement of SFRs,
+ the evaluator can understand that the requirement for the
+ completion of all assignment and selection operations (as
+ stated in .*.3C has been
+ satisfied in the component evaluations.
+
+
+
+ The TSF of the base component is often defined without
+ knowledge of the dependencies of the possible applications
+ with which it may by composed. The TSF of this base component
+ is defined to include all parts of the base component that
+ have to be relied upon for enforcement of the base component
+ SFRs. This will include all parts of the base component
+ required to implement the base component SFRs.
+
+ The TSFI of this base component represents the interfaces
+ provided by the TSF to the external entities defined in the
+ statement of SFRs to invoke a service of the TSF. This
+ includes interfaces to the human user and also interfaces to
+ external IT entities. However, the TSFI only includes those
+ interfaces to the TSF, and therefore is not necessarily an
+ exhaustive interface specification of all possible interfaces
+ available between an external entity and the base
+ component. The base component may present interfaces to
+ services that were not considered security-relevant, either
+ because of the inherent purpose of the service (e.g., adjust
+ type font) or because associated CC SFRs are not being claimed
+ in the base component's ST (e.g. the login interface when no
+ SFRs are claimed).
+
+ The functional interfaces provided by the base component are
+ in addition to the security interfaces (TSFIs), and are not
+ required to be considered during the base component
+ evaluation. These often include interfaces that are used by a
+ dependent component to invoke a service provided by the base
+ component.
+
+ The base component may include some indirect interfaces
+ through which TSFIs may be called, e.g. APIs that can be used
+ to invoke a service of the TSF, which were not considered
+ during the evaluation of the base component.
+
+
+ The dependent component, which relies on the base component,
+ is similarly defined: interfaces to external entities defined
+ in the SFRs of the component ST are categorised as TSFI and
+ are examined in .
+
+ Any call out from the dependent TSF to the environment in
+ support of an SFR will indicate that the dependent TSF
+ requires some service from the environment in order to satisfy
+ the enforcement of the stated dependent component SFRs. Such a
+ service is outside the dependent component boundary and the
+ base component is unlikely to be defined in the dependent ST
+ as an external entity. Hence, the calls for services made out
+ by the dependent TSF to its underlying platform (the base
+ component) will not be analysed as part of the activities. These dependencies on
+ the base component are expressed in the dependent component ST
+ as security objectives for the environment.
+
+ This abstraction of the dependent component and the interfaces
+ is shown in Figure
+ below.
+
+
+ When considering the composition of the base component and the
+ dependent component, if the dependent component's TSF requires
+ services from the base component to support the implementation
+ of the SFR, the interface to the service will need to be
+ defined. If that service is provided by the base component's
+ TSF, then that interface should be a TSFI of the base
+ component and will therefore already be defined within the
+ functional specification of the base component.
+
+ If, however, the service called by the dependent component's
+ TSF is not provided by the TSF of the base component (i.e., it
+ is implemented in the non-TSF portion of the base component or
+ possibly even in the non-TOE portion of the base component
+ (not illustrated in Figure ), there is unlikely to be a TSFI of the base
+ component relating to the service, unless the service is
+ mediated by the TSF of the base component. The interfaces to
+ these services from the dependent component to the operational
+ environment are considered in the family .
+
+ The non-TSF portion of the base component is drawn into the
+ TSF of the composed TOE due to the dependencies the dependent
+ component has on the base component to support the SFRs of the
+ dependent component. Therefore, in such cases, the TSF of the
+ composed TOE would be larger than simply the sum of the
+ components' TSFs.
+
+
+ It may be the case that the base component TSFI is being
+ called in a manner that was unforeseen in the base component
+ evaluation. Hence there would be a requirement for further
+ testing of the base component TSFI.
+
+ The possible interfaces are further described in the following
+ diagram (Figure ) and
+ supporting text.
+
+
+
+
+ Arrows going into 'dependent component-a'
+ (A and B) = where the component expects the environment to
+ respond to a service request (responding to calls out from
+ dependent component to the environment);
+
+ Arrows coming out of 'base component-b'
+ (C and D) = interfaces of services provided by the base
+ component to the environment;
+
+ Broken lines between components = types of communication
+ between pairs of interfaces;
+
+ The other (grey) arrows = interfaces that are described by
+ the given criteria.
+
+ The following is a simplification, but explains the
+ considerations that need to be made.
+
+ There are components a ('dependent component-a') and b ('base
+ component-b'): the arrows coming out of TSF-a
+ are services provided by TSF-a and are therefore TSFIs(a);
+ likewise, the arrows coming out of TSF-b
+ (``C'') are TSFIs(b). These are each detailed in their
+ respective functional specs. component-a is such that it
+ requires services from its environment: those needed by the
+ TSF(a) are labelled ``A''; the other (not related to TSF-a)
+ services are labelled ``B''.
+
+ When component-a and component-b are combined, there are four
+ possible combinations of {services needed by component-a} and
+ {services provided by component-b}, shown as broken lines
+ (types of communication between pairs of interfaces). Any set
+ of these might exist for a particular composition:
+
+
+ TSF-a needs those services that are provided by TSF-b ("A" is connected to "C"):
+ this is straightforward: the details about "C" are in the FSP for component-b.
+ In this instance the interfaces should all be defined in the functional specifications for
+ the component-b.
+
+
+ Non-TSF-a needs those services that are provided by TSF-b
+ (``B'' is connected to ``C''): this is straightforward
+ (again, the details about ``C'' are in the FSP for
+ component-b), but unimportant: security-wise.
+
+ Non-TSF-a needs those services that are provided by
+ non-TSF-b (``B'' is connected to ``D''): we have no
+ details about D, but there are no security implications
+ about the use of these interfaces, so they do not need to
+ be considered in the evaluation, although they are likely
+ to be an integration issue for the developer.
+
+ TSF-a needs those services that are provided by non-TSF-b
+ (``A'' is connected to ``D''): this would arise when
+ component-a and component-b have different senses of what
+ a ``security service'' is. Perhaps component-b is making
+ no claims about I&A (has no
+ SFRs in its ST), but component-a needs authentication
+ provided by its environment. There are no details about
+ the ``D'' interfaces available (they are not TSFI (b), so
+ they are not in component-b's FSP).
+
+ Note: if the kind of interaction described in case d above
+ exists, then the TSF of the composed TOE would be TSF-a + TSF-b
+ + Non-TSF-b. Otherwise, the TSF of the composed TOE would be
+ TSF-a + TSF-b.
+
+ Interfaces types 2 and 4 of Figure are not directly relevant to the evaluation of
+ the composed TOE. Interfaces 1 and 3 will be considered during
+ the application of different families:
+
+
+ (for component-b) will
+ describe the C interfaces.
+
+ will describe the A
+ interfaces.
+
+ will describe the C
+ interfaces for connection type 1 and the D interfaces for
+ connection type 3.
+
+ A typical example where composition may be applied is a
+ database management system (DBMS) that relies upon its
+ underlying operating system (OS). During the evaluation of
+ the DBMS component, there will be an assessment made of the
+ security properties of that DBMS (to whatever degree of rigour
+ is dictated by the assurance components used in the
+ evaluation): its TSF boundary will be identified, its
+ functional specification will be assessed to determine whether
+ it describes the interfaces to the security services provided
+ by the TSF, perhaps additional information about the TSF (its
+ design, architecture, internal structure) will be provided,
+ the TSF will be tested, aspects of its life-cycle and its
+ guidance documentation will be assessed, etc.
+
+ However, the DBMS evaluation will not call for any evidence
+ concerning the dependency the DBMS has on the OS. The ST of
+ the DBMS will most likely state assumptions about the OS in
+ its Assumptions subclause and state security objectives for the
+ OS in its Environment subclause. The DBMS ST may even
+ instantiate those objectives for the environment in terms of
+ SFRs for the OS. However, there will be no specification for
+ the OS that mirrors the detail in the functional
+ specification, architecture description, or other evidence as for the DBMS. will fulfil that need.
+
+ describes the interfaces of
+ the dependent TOE that make the calls to the base component
+ for the provision of services. These are the interfaces to
+ which the base component is to respond. The interface
+ descriptions are provided from the dependent component's
+ viewpoint.
+
+ describes the interfaces
+ provided by the base component, which respond to the dependent
+ component service requests. These interfaces are mapped to the
+ relevant dependent component interfaces that are identified in
+ the reliance information. (The completeness of this mapping,
+ whether the base component interfaces described represent all
+ dependent component interfaces, is not verified here, but in
+ ). At the higher levels of
+ the subsystems providing the
+ interfaces are described.
+
+ Any interfaces required by the dependent component that have
+ not been described for the base component are reported in the
+ rationale for . The rationale
+ also reports whether the interfaces of the base component on
+ which the dependent component relies were considered within
+ the base component evaluation. For any interfaces that were
+ not considered in the base component evaluation, a rationale
+ is provided of the impact of using the interface on the base
+ component TSF.
+
+
+
+
+ This annex contains ancillary material to further explain and
+ provide additional examples for the topics brought up in
+ families of the class.
+
+
+ A security architecture is a set of properties that the TSF
+ exhibits; these properties include self-protection, domain
+ separation, and non-bypassability. Having these properties
+ provides a basis of confidence that the TSF is providing its
+ security services. This annex provides additional material on
+ these properties, as well as discussion on contents of a
+ security architecture description.
+
+ The remainder of this subclause first explains these properties,
+ then discusses the kinds of information that are needed to
+ describe how the TSF exhibits those properties.
+
+ Self-protection refers to the ability of
+ the TSF to protect itself from manipulation from external
+ entities that may result in changes to the TSF. Without these
+ properties, the TSF might be disabled from performing its
+ security services.
+
+ It is oftentimes the case that a TOE uses services or
+ resources supplied by other IT entities in order to perform
+ its functions (e.g. an application that relies upon its
+ underlying operating system). In these cases, the TSF does
+ not protect itself entirely on its own, because it depends
+ on the other IT entities to protect the services it
+ uses.
+ Domain separation is a property whereby the TSF
+ creates separate security domains for each
+ untrusted active entity to operate on its resources, and then
+ keeps those domains separated from one another so that no entity
+ can run in the domain of any other. For example, an operating
+ system TOE supplies a domain (address space, per-process
+ environment variables) for each process associated with
+ untrusted entities.
+
+ For some TOEs such domains do not exist because all of the
+ actions of the untrusted entities are brokered by the TSF. A
+ packet-filter firewall is an example of such a TOE, where
+ there are no untrusted entity domains; there are only data
+ structures maintained by the TSF. The existence of domains,
+ then, is dependant upon 1) the type of TOE and 2) the SFRs
+ levied on the TOE. In the cases where the TOE does provide
+ domains for untrusted entities, this family requires that
+ those domains are isolated from one another such that
+ untrusted entities in one domain are prevented from
+ tampering (affecting without brokering by the TSF) from
+ another untrusted entity's domain.
+
+ Non-bypassability is a property that the
+ security functionality of the TSF (as specified by the SFRs)
+ is always invoked and cannot be circumvented when
+ appropriate for that specific mechanism. For example, if
+ access control to files is specified as a capability of the
+ TSF via an SFR, there must be no interfaces through which
+ files can be accessed without invoking the TSF's access
+ control mechanism (an interface through which a raw disk
+ access takes place might be an example of such an
+ interface).
+
+ As is the case with self-protection, the very nature of some
+ TOEs might depend upon their environments to play a role in
+ non-bypassability of the TSF. For example, a security
+ application TOE requires that it be invoked by the
+ underlying operating system. Similarly, a firewall depends
+ upon the fact that there are no direct connections between
+ the internal and external networks and that all traffic
+ between them must go through the firewall.
+
+
+ The security architecture description explains how the
+ properties described above are exhibited by the TSF. It
+ describes how domains are defined and how the TSF keeps them
+ separate. It describes what prevents untrusted processes
+ from getting to the TSF and modifying it. It describes what
+ ensures that all resources under the TSF's control are
+ adequately protected and that all actions related to the
+ SFRs are mediated by the TSF. It explains any role the
+ environment plays in any of these (e.g. presuming it gets
+ correctly invoked by its underlying environment, how are its
+ security functions invoked?).
+
+ The security architecture description presents the TSF's
+ properties of self-protection, domain separation, and
+ non-bypassability in terms of the decomposition descriptions.
+ The level of this description is commensurate with the TSF
+ description required by the ,
+ and requirements that are being claimed. For example, if
+ is the only TSF description
+ available, it would be difficult to provide any meaningful
+ architectural design because none of the details of any internal
+ workings of the TSF would be available.
+
+ However, if the TOE design were also available, even at the most
+ basic level (), there would be
+ some information available concerning the subsystems that make
+ up the TSF, and there would be a description of how they work to
+ implement self-protection, domain separation, and
+ non-bypassability. For example, perhaps all user interaction
+ with the TOE is constrained through a process that acts on that
+ user's behalf, adopting all of the user's security attributes;
+ the architectural design would describe how such a process comes
+ into being, how the process's behaviour is constrained by the
+ TSF (so it cannot corrupt the TSF), how all actions of that
+ process are mediated by the TSF (thereby explaining why the TSF
+ cannot be bypassed), etc.
+
+ If the available TOE design is more detailed (e.g. at the
+ modular level), or the implementation representation is also
+ available, then the description of the architectural design
+ would be correspondingly more detailed, explaining how the
+ user's process communicate with the TSF processes, how different
+ requests are processed by the TSF, what parameters are passed,
+ what programmatic protections (buffer overflow prevention,
+ parameter bounds checking, time of check/time of use checking,
+ etc.) are in place. Similarly, a TOE whose ST claimed the component would go into
+ implementation-specific detail.
+
+ The explanations provided in the security architecture
+ description are expected to be of sufficient detail that one
+ would be able to test their accuracy. That is, simple
+ assertions (e.g. "The TSF keeps domains separate'') provide
+ no useful information to convince the reader that the TSF
+ does indeed create and separate domains.
+
+ In cases where the TOE exhibits domain separation entirely on
+ its own, there would be a straightforward description of how
+ this is attained. The security architecture description would
+ explain the different kinds of domains that are defined by the
+ TSF, how they are defined (i.e. what resources are allocated
+ to each domain), how no resources are left unprotected, and
+ how the domains are kept separated so that active entities in
+ one domain cannot tamper with resources in another
+ domain.
+ For cases where the TOE depends upon other IT entities to play
+ a role in domain separation, that sharing of roles must be made
+ clear. For example, a TOE that is solely application software
+ relies upon the underlying operating system to correctly
+ instantiate the domains that the TOE defines; if the TOE
+ defines separate processing space, memory space, etc, for each
+ domain, it depends upon the underlying operating system to
+ operate correctly and benignly (e.g. allow the process to
+ execute only in the execution space that is requested by the
+ TOE software).
+ For example, mechanisms that implement domain separation
+ (e.g., memory management, protected processing modes provided
+ by the hardware, etc.) would be identified and described. Or,
+ the TSF might implement software protection constructs or
+ coding conventions that contribute to implementing separation
+ of software domains, perhaps by delineating user address space
+ from system address space.
+ The vulnerability analysis and testing (see ) activities will likely include attempts to defeat
+ the described TSF domain separation through the use of
+ monitoring or direct attack the TSF.
+
+
+ In cases where the TOE exhibits self-protection entirely
+ on its own, there would be a straightforward description
+ of how this self-protection is attained. Mechanisms that
+ provide domain separation to define a TSF domain that is
+ protected from other (user) domains would be identified
+ and described.
+
+ For cases where the TOE depends upon other IT entities to
+ play a role in protecting itself, that sharing of roles
+ must be made clear. For example, a TOE that is solely
+ application software relies upon the underlying operating
+ system to operate correctly and benignly; the application
+ cannot protect itself against a malicious operating system
+ that subverts it (for example, by overwriting its
+ executable code or TSF data).
+
+ The security architecture description also covers how user input
+ is handled by the TSF in such a way that the TSF does not
+ subject itself to being corrupted by that user input. For
+ example, the TSF might implement the notion of privilege and
+ protect itself by using privileged-mode routines to handle user
+ data. The TSF might make use of processor-based separation
+ mechanisms (e.g. privilege levels or rings) to separate TSF
+ code and data from user code and data. The TSF might implement
+ software protection constructs or coding conventions that
+ contribute to implementing separation of software, perhaps by
+ delineating user address space from system address space.
+
+ For TOEs that start up in a low-function mode (for
+ example, a single-user mode accessible only to installers
+ or administrators) and then transition to the evaluated
+ secure configuration (a mode whereby untrusted users are
+ able to login and use the services and resources of the
+ TOE), the security architecture description also includes
+ an explanation of how the TSF is protected against this
+ initialisation code that does not run in the evaluated
+ configuration. For such TOEs, the security architecture
+ description would explain what prevents those services
+ that should be available only during initialisation
+ (e.g. direct access to resources) from being accessible in
+ the evaluated configuration. It would also explain what
+ prevents initialisation code from running while the TOE is
+ in the evaluated configuration.
+
+ There must also be an explanation of how the trusted
+ initialisation code will maintain the integrity of the TSF
+ (and of its initialisation process) such that the
+ initialisation process is able to detect any modification
+ that would result in the TSF being spoofed into believe it
+ was in an initial secure state.
+
+ The vulnerability analysis and testing (see ) activities will likely include
+ attempts to defeat the described TSF self protection
+ through the use of tampering, direct attack, or monitoring
+ of the TSF.
+
+
+ The property of non-bypassability is concerned with
+ interfaces that permit the bypass of the enforcement
+ mechanisms. In most cases this is a consequence of the
+ implementation, where if a programmer is writing an
+ interface that accesses or manipulates an object, it is
+ that programmer's responsibility to use interfaces that
+ are part of the SFR enforcement mechanism for the object
+ and not to try to circumvent those interfaces. For the
+ description pertaining to non-bypassability, then, there
+ are two broad areas that have to be covered.
+
+ The first consists of those interfaces to the SFR-enforcement.
+ The property for these interfaces is that they contain no
+ operations or modes that allow them to be used to bypass the
+ TSF. It is likely that the evidence for and can be used in
+ large part to make this determination. Because non-bypassability
+ is the concern, if only certain operations available through
+ these TSFIs are documented (because they are SFR-enforcing) and
+ others are not, the developer should consider whether additional
+ information (to that presented in
+ and ) is necessary to make a
+ determination that the
+ SFR-supporting and SFR-non-interfering
+ operations of the TSFI do not afford an
+ untrusted entity the ability to bypass the policy being
+ enforced. If such information is necessary, it is included
+ in the security architecture description.
+
+ The second area of non-bypassability is concerned with
+ those interfaces whose interactions are not associated
+ with SFR-enforcement. Depending on the and components
+ claimed, some information about these interfaces may or
+ may not exist in the functional specification and TOE
+ design documentation. The information presented for such
+ interfaces (or groups of interfaces) should be sufficient
+ so that a reader can make a determination (at the level of
+ detail commensurate with the rest of the evidence supplied
+ in the class) that the
+ enforcement mechanisms cannot be bypassed.
+
+ The property that the security functionality cannot be
+ bypassed applies to all security functionality
+ equally. That is, the design description should cover
+ objects that are protected under the SFRs (e.g. _* components) and functionality
+ (e.g., audit) that is provided by the TSF. The description
+ should also identify the interfaces that are associated
+ with security functionality; this might make use of the
+ information in the functional specification. This
+ description should also describe any design constructs,
+ such as object managers, and their method of use. For
+ instance, if routines are to use a standard macro to
+ produce an audit record, this convention is a part of the
+ design that contributes to the non-bypassability of the
+ audit mechanism. It is important to note that
+ non-bypassability in this context is not an
+ attempt to answer the question ``could a part of the TSF
+ implementation, if malicious, bypass the security
+ functionality'', but rather to document how the
+ implementation does not bypass the security
+ functionality.
+
+ The vulnerability analysis and testing (see ) activities will likely include
+ attempts to defeat the described non-bypassability by
+ circumventing the TSF.
+
+
+
+
+ The purpose in specifying the TSFIs is to provide the
+ necessary information to conduct testing; without knowing the
+ possible means interact with the TSF, one cannot adequately
+ test the behaviour of the TSF.
+
+ There are two parts to specifying the TSFIs: identifying them
+ and describing them. Because of the diversity of possible
+ TOEs, and of different TSFs therein, there is no standard set
+ of interfaces that constitute ``TSFIs''. This annex provides
+ guidance on the factors that determine which interfaces are
+ TSFIs.
+
+
+ In order to identify the interfaces to the TSF, the parts of the
+ TOE that make up the TSF must first be identified. This
+ identification is actually a part of the analysis, but is also performed implicitly
+ (through identification and description of the TSFI) by the
+ developer in cases where is not
+ included in the assurance package. In this analysis, a portion
+ of the TOE must be considered to be in the TSF if it contributes
+ to the satisfaction of an SFR in the ST (in whole or in
+ part). This includes, for example, everything in the TOE that
+ contributes to TSF run-time initialisation, such as software
+ that runs prior to the TSF being able to protect itself because
+ enforcement of the SFRs has not yet begun (e.g., while booting
+ up). Also included in the TSF are all parts of the TOE that
+ contribute to the architectural principles of TSF
+ self-protection, domain separation, and non-bypassability (see
+ ).
+
+ Once the TSF has been defined, the TSFI are identified. The
+ TSFI consist of all means for users to invoke a service from
+ the TSF (by supplying data that is processed by the TSF) and
+ the corresponding responses to those service
+ invocations. These service invocations and responses are the
+ means of crossing the TSF boundary. While many of these are
+ readily apparent, others might not be as obvious. The
+ question that should be asked when determining the TSFIs is:
+ ``How can a potential attacker interact with the TSF in an
+ attempt to subvert the SFRs?'' The following discussions
+ illustrate the application of the TSFI definition in
+ different contexts.
+
+
+ In TOEs such as smart cards, where the adversary has not
+ only logical access to the TOE, but also complete physical
+ access to the TOE, the TSF boundary is the physical
+ boundary. Therefore, the exposed electrical interfaces
+ are considered TSFI because their manipulation could
+ affect the behaviour of the TSF. As such, all these
+ interfaces (electrical contacts) need to be described:
+ various voltages that might be applied, etc.
+
+
+
+ The TSFIs of a TOE that performs protocol processing would
+ be those protocol layers to which a potential attacker has
+ direct access. This need not be the entire protocol stack,
+ but it might be.
+
+ For example, if the TOE were some sort of a network
+ appliance that allowed potential attackers to affect every
+ level of the protocol stack (i.e. to send arbitrary
+ signals, arbitrary voltages, arbitrary packets, arbitrary
+ datagrams, etc.), then the TSF boundary exists at each
+ layer of the stack. Therefore, the functional
+ specification would have to address every protocol at
+ every layer of the stack.
+
+ If, however, the TOE were a firewall that protects an
+ internal network from the Internet, a potential attacker
+ would have no means of directly manipulating the voltages
+ that enter the TOE; any extreme voltages would simply not
+ be passed though the Internet. That is, the attacker would
+ have access only to those protocols at the Internet layer
+ or above. The TSF boundary exists at each layer of the
+ stack. Therefore, the functional specification would have
+ to address only those protocols at or above the Internet
+ layer: it would describe each of the different
+ communication layers at which the firewall is exposed in
+ terms of what constitutes well-formed input for what might
+ appear on the line, and the result of both well-formed and
+ malformed inputs. For example, the description of the
+ Internet protocol layer would describe what constitutes a
+ well-formed IP packet and what happens when both
+ correctly-formed and malformed packets are
+ received. Likewise, the description of the TCP layer would
+ describe a successful TCP connection and what happens both
+ when successful connections are established and when
+ connections cannot be established or are inadvertently
+ dropped. Presuming the firewall's purpose is to filter
+ application-level commands (like FTP or telnet), the
+ description of the application layer would describe the
+ application-level commands that are recognised and
+ filtered by the firewall, as well as the results of
+ encountering unknown commands.
+
+ The descriptions of these layers would likely reference
+ published communication standards (telnet, FTP, TCP, etc.)
+ that are used, noting which user-defined options are
+ chosen.
+
+
+
+
+
+
+ ``Wrappers'' translate complex series of interactions into
+ simplified common services, such as when Operating Systems
+ create APIs for use by applications (as shown in Figure
+ ). Whether the TSFIs
+ would be the system calls or the APIs depends upon what is
+ available to the application: if the application can use
+ the system calls directly, then the system calls are the
+ TSFIs. If, however, there were something that prohibits
+ their direct use and requires all communication through
+ the APIs, then the APIs would be the TSFIs.
+
+ A Graphical User interface is similar: it translates
+ between machine-understandable commands and user-friendly
+ graphics. Similarly, the TSFIs would be the commands if
+ users have access to them, or the graphics (pull-down
+ menus, check-boxes, text fields) if the users are
+ constrained to using them.
+
+ It is worth noting that, in both of these examples, if the
+ user is prohibited from using the more primitive
+ interfaces (i.e. the system calls or the commands), the
+ description of this restriction and of its enforcement
+ would be included in the Security Architecture Description
+ (see ). Also, the wrapper would be
+ part of the TSF.
+
+
+
+ For a given TOE, not all of the interfaces may be
+ accessible. That is, the security
+ objectives for the operational environment (in the
+ Security Target) may prevent access to these interfaces or
+ limit access in such a way that they are practically
+ inaccessible. Such interfaces would not be considered
+ TSFIs. Some examples:
+
+ If the security objectives for the operational
+ environment for the stand-alone firewall state that
+ ``the firewall will be operational in a server room
+ environment to which only trusted and trained
+ personnel will have access, and which will be equipped
+ with an interruptible power supply (against power
+ failure)'', physical and power interfaces will not be
+ accessible, since trusted and trained personnel will
+ not attempt to dismantle the firewall and/or disable
+ its power supply. If the security
+ objectives for the operational environment for the
+ software firewall (application) state that ``the OS
+ and the hardware will provide a security domain for
+ the application free from tampering by other
+ programs'', the interfaces through which the firewall
+ can be accessed by other applications on the OS
+ (e.g. deleting or modifying the firewall executable,
+ direct reading or writing to the memory space of the
+ firewall) will not be accessible, since the
+ OS/hardware part of the operational environment makes
+ this interface inaccessible.If the
+ security objectives for the operational environment
+ for the software firewall additionally state that the
+ OS and hardware will faithfully execute the commands
+ of the TOE, and will not tamper with the TOE in any
+ manner, interfaces through which the firewall obtains
+ primitive functionality from the OS and hardware
+ (executing machine code instructions, OS APIs, such as
+ creating, reading, writing or deleting files,
+ graphical APIs etc.) will not be accessible, since the
+ OS/hardware are the only entities that can access that
+ interface, and they are completely
+ trusted. For all of these examples,
+ these inaccessible interfaces would not be
+ TSFIs.
+
+
+
+ Figure
+ illustrates a complex TOE: a database management system that
+ relies on hardware and software that is outside the TOE
+ boundary (referred to as the IT environment
+ in the rest of this discussion). To simplify this example,
+ the TOE is identical to the TSF. The
+ shaded boxes represent the TSF, while the unshaded boxes
+ represent IT entities in the environment. The TSF comprises
+ the database engine and management GUIs (represented by the
+ box labelled DB) and a kernel module that
+ runs as part of the OS that performs some security function
+ (represented by the box labelled PLG). The
+ TSF kernel module has entry points defined by the OS
+ specification that the OS will call to invoke some function
+ (this could be a device driver, or an authentication module,
+ etc.). The key is that this pluggable kernel module is
+ providing security services specified by functional
+ requirements in the ST.
+
+
+
+
+ The IT environment consists of the operating system itself
+ (represented by the box labelled OS), as
+ well as an external server (labelled SRV).
+ This external server, like the OS, provides a service that
+ the TSF depends on, and thus needs to be in the IT
+ environment. Interfaces in the figure are labelled
+ Ax for TSFI, and Bx for
+ other interfaces that would be documented in . Each of these groups of interfaces is now
+ discussed.
+
+ Interface group A1 represents the most obvious set of TSFI.
+ These are interfaces used by users to directly access the
+ database and its security functionality and
+ resources.
+
+ Interface group A2 represent the TSFI that the OS invokes to
+ obtain the functionality provided by the pluggable module.
+ These are contrasted with interface group B3, which
+ represent calls that the pluggable module makes to obtain
+ services from the IT environment.
+
+ Interface group A3 represent TSFI that pass through the IT
+ environment. In this case, the DBMS communicates over the
+ network using a proprietary application-level
+ protocol. While the IT environment is responsible for
+ providing various supporting protocols (e.g., Ethernet, IP,
+ TCP), the application layer protocol that is used to obtain
+ services from the DBMS is a TSFI and must be documented as
+ such. The dotted line indicates return values/services from
+ the TSF over the network connection.
+
+ The interfaces labelled Bx represent
+ interfaces to functionality in the IT Environment. These
+ interfaces are not TSFI and need only be discussed and
+ analysed when the TOE is being used in a composite
+ evaluation as part of the activities associated with the
+ class.
+
+
+
+ The Example firewall is used between an internal network and
+ an external network. It verifies the source address of data
+ received (to ensure that external data is not attempting to
+ masquerade as originating from the internal data); if it
+ detects any such attempts, it saves the offending attempt to
+ the audit log. The administrator connects to the firewall by
+ establishing a telnet connection to the firewall from the
+ internal network. Administrator actions consist of
+ authenticating, changing passwords, reviewing the audit log,
+ and setting or changing the addresses of the internal and
+ external networks.
+
+ The Example firewall presents the following interfaces to
+ the internal network:
+
+ IP datagrams
+ Administrator Commands and the
+ following interfaces to the external network:
+
+ IP datagrams
+ Interfaces Descriptions: IP
+ Datagrams
+ The datagrams are in the format specified by RFC 791.
+
+ Purpose - to transmit blocks of data (``datagrams'')
+ from source hosts to destination hosts identified by
+ fixed length addresses; also provides for fragmentation
+ and reassembly of long datagrams, if necessary, for
+ transmission through small-packet networks.
+ Method of Use - they arrive from the lower-level
+ (e.g. data link) protocol.
+ Parameters - the following fields of the IP datagram
+ header: source address, destination address,
+ don't-fragment flag.
+ Parameter description - [As defined by RFC 791,
+ subclause 3.1 (``Internet Header Format'')]
+ Actions - Transmits datagrams that are not
+ masquerading; fragments large datagrams if necessary;
+ reassembles fragments into datagrams.
+ Error messages - (none). No reliability guaranteed
+ (reliability to be provided by upper-level protocols)
+ Undeliverable datagrams (e.g. must be fragmented for
+ transmission, but don't-fragment flag is set)
+ dropped.
+ Interfaces Descriptions: Administrator
+ Commands
+ The administrator commands provide a means for the
+ administrator to interact with the firewall. These commands
+ and responses ride atop a telnet (RFC 854) connection
+ established from any host on the internal network. Available
+ commands are:
+
+ Passwd
+
+ Purpose - sets administrator password
+ Method of Use - Passwd
+ <password>
+ Parameters - password
+ Parameter description - value of new
+ password
+ Actions - changes password to new value
+ supplied. There are no restrictions.
+ Error messages - none.
+
+ Readaudit
+
+ Purpose - presents the audit log to the
+ administrator
+ Method of Use - Readaudit
+ Parameters - none
+ Parameter description - none
+ Actions - provides the text of the audit
+ log
+ Error messages - none.
+
+ Setintaddr
+
+ Purpose - sets the address of the internal
+ address.
+ Method of Use - Setintaddr
+ <address>
+ Parameters - address
+ Parameter description - first three fields of an
+ IP address (as defined in RFC 791). For example:
+ 123.123.123.
+ Actions - changes the internal value of the
+ variable defining the internal network, the value of
+ which is used to judge attempted masquerades.
+ Error messages - ``address in use'': indicates
+ the identified internal network is the same as the
+ external network.
+
+ Setextaddr
+
+ Purpose - sets the address of the external address
+ Method of Use - Setextaddr
+ <address>
+ Parameters - address
+ Parameter description - first three fields of an
+ IP address (as defined in RFC 791). For example:
+ 123.123.123.
+ Actions - changes the internal value of the
+ variable defining the external network.
+ Error messages - ``address in use'': indicates
+ the identified external network is the same as the
+ internal network.
+
+
+
+
+
+
+ The wide variety of TOEs makes it impossible to codify
+ anything more specific than ``well-structured'' or ``minimum
+ complexity''. Judgements on structure and complexity are
+ expected to be derived from the specific technologies used in
+ the TOE. For example, software is likely to be considered
+ well-structured if it exhibits the characteristics cited in
+ the software engineering disciplines.
+
+ This annex provides supplementary material on assessing the
+ structure and complexity of procedure-based software portions
+ of the TSF. This material is based on information readily
+ available in software engineering literature. For other kinds
+ of internals (e.g. hardware, non-procedural software such as
+ object-oriented code, etc.), corresponding literature on good
+ practises should be consulted.
+
+
+ The structure of procedural software is traditionally
+ assessed according to its
+ modularity. Software written with a modular
+ design aids in achieving understandability by clarifying
+ what dependencies a module has on other modules
+ (coupling) and by including in a module
+ only tasks that are strongly related to each other
+ (cohesion). The use of modular design
+ reduces the interdependence between elements of the TSF and
+ thus reduces the risk that a change or error in one module
+ will have effects throughout the TOE. Its use enhances
+ clarity of design and provides for increased assurance that
+ unexpected effects do not occur. Additional desirable
+ properties of modular decomposition are a reduction in the
+ amount of redundant or unneeded code.
+
+ Minimising the amount of functionality in the TSF allows the
+ evaluator as well as the developer to focus only on that
+ functionality which is necessary for SFR enforcement,
+ contributing further to understandability and further
+ lowering the likelihood of design or implementation
+ errors.
+
+ The incorporation of modular decomposition, layering and
+ minimisation into the design and implementation process must
+ be accompanied by sound software engineering
+ considerations. A practical, useful software system will
+ usually entail some undesirable coupling among modules, some
+ modules that include loosely-related functions, and some
+ subtlety or complexity in a module's design. These
+ deviations from the ideals of modular decomposition are
+ often deemed necessary to achieve some goal or constraint,
+ be it related to performance, compatibility, future planned
+ functionality, or some other factors, and may be acceptable,
+ based on the developer's justification for them. In applying
+ the requirements of this class, due consideration must be
+ given to sound software engineering principles; however, the
+ overall objective of achieving understandability must be
+ achieved.
+
+
+ Cohesion is the manner and degree to which the tasks
+ performed by a single software module are related to one
+ another; types of cohesion include coincidental,
+ communicational, functional, logical, sequential, and
+ temporal. These types of cohesion are characterised below,
+ listed in the order of decreasing desirability.
+
+ functional cohesion - a module
+ with functional cohesion performs activities related
+ to a single purpose. A functionally cohesive module
+ transforms a single type of input into a single type
+ of output, such as a stack manager or a queue
+ manager.
+ sequential cohesion - a module
+ with sequential cohesion contains functions each of
+ whose output is input for the following function in
+ the module. An example of a sequentially cohesive
+ module is one that contains the functions to write
+ audit records and to maintain a running count of the
+ accumulated number of audit violations of a specified
+ type.
+ communicational cohesion - a
+ module with communicational cohesion contains
+ functions that produce output for, or use output from,
+ other functions within the module. An example of a
+ communicationally cohesive module is an access check
+ module that includes mandatory, discretionary, and
+ capability checks.
+ temporal cohesion - a module
+ with temporal cohesion contains functions that need to
+ be executed at about the same time. Examples of
+ temporally cohesive modules include initialisation,
+ recovery, and shutdown modules.
+ logical (or
+ procedural) cohesion - a module with
+ logical cohesion performs similar activities on
+ different data structures. A module exhibits logical
+ cohesion if its functions perform related, but
+ different, operations on different inputs.
+ coincidental cohesion - a
+ module with coincidental cohesion performs unrelated,
+ or loosely related, activities.
+
+
+
+ Coupling is the manner and degree of interdependence
+ between software modules; types of coupling include call,
+ common and content coupling. These types of coupling are
+ characterised below, listed in the order of decreasing
+ desirability:
+
+ call: two modules are call coupled if they
+ communicate strictly through the use of their
+ documented function calls; examples of call coupling
+ are data, stamp, and control, which are defined below.
+
+ data: two modules are data
+ coupled if they communicate strictly through the
+ use of call parameters that represent single data
+ items.
+ stamp: two modules are stamp
+ coupled if they communicate through the use of
+ call parameters that comprise multiple fields or
+ that have meaningful internal structures.
+ control: two modules are
+ control coupled if one passes information that is
+ intended to influence the internal logic of the
+ other.
+
+ common: two modules are common
+ coupled if they share a common data area or a common
+ system resource. Global variables indicate that
+ modules using those global variables are common
+ coupled. Common coupling through global variables is
+ generally allowed, but only to a limited degree. For
+ example, variables that are placed into a global area,
+ but are used by only a single module, are
+ inappropriately placed, and should be removed. Other
+ factors that need to be considered in assessing the
+ suitability of global variables are:
+
+ The number of modules that modify a global
+ variable: In general, only a single module should
+ be allocated the responsibility for controlling
+ the contents of a global variable, but there may
+ be situations in which a second module may share
+ that responsibility; in such a case, sufficient
+ justification must be provided. It is unacceptable
+ for this responsibility to be shared by more than
+ two modules. (In making this assessment, care
+ should be given to determining the module actually
+ responsible for the contents of the variable; for
+ example, if a single routine is used to modify the
+ variable, but that routine simply performs the
+ modification requested by its caller, it is the
+ calling module that is responsible, and there may
+ be more than one such module). Further, as part
+ of the complexity determination, if two modules
+ are responsible for the contents of a global
+ variable, there should be clear indications of how
+ the modifications are coordinated between
+ them.
+ The number of modules that reference a global
+ variable: Although there is generally no limit on
+ the number of modules that reference a global
+ variable, cases in which many modules make such a
+ reference should be examined for validity and
+ necessity.
+
+ content: two modules are content
+ coupled if one can make direct reference to the
+ internals of the other (e.g. modifying code of, or
+ referencing labels internal to, the other module).
+ The result is that some or all of the content of one
+ module are effectively included in the other. Content
+ coupling can be thought of as using unadvertised
+ module interfaces; this is in contrast to call
+ coupling, which uses only advertised module
+ interfaces.
+
+
+
+
+ Complexity is the measure of the decision points and logical
+ paths of execution that code takes. Software engineering
+ literature cites complexity as a negative characteristic of
+ software because it impedes understanding of the logic and
+ flow of the code. Another impediment to the understanding of
+ code is the presence of code that is unnecessary, in that it
+ is unused or redundant.
+
+ The use of layering to separate levels of abstraction and
+ minimise circular dependencies further enables a better
+ understanding of the TSF, providing more assurance that the
+ TOE security functional requirements are accurately and
+ completely instantiated in the implementation.
+
+ Reducing complexity also includes reducing or eliminating
+ mutual dependencies, which pertains both to modules in a
+ single layer and to those in separate layers. Modules that
+ are mutually dependent may rely on one another to formulate
+ a single result, which could result in a deadlock condition,
+ or worse yet, a race condition (e.g., time of check vs. time
+ of use concern), where the ultimate conclusion could be
+ indeterminate and subject to the computing environment at
+ the given instant in time.
+
+ Design complexity minimisation is a key characteristic of a
+ reference validation mechanism, the purpose of which is to
+ arrive at a TSF that is easily understood so that it can be
+ completely analysed. (There are other important
+ characteristics of a reference validation mechanism, such as
+ TSF self-protection and non-bypassability; these other
+ characteristics are covered by requirements in the family.)
+
+
+
+
+ This Subclause provides additional guidance on the TDS family,
+ and its use of the terms ``subsystem'' and ``module''. This is
+ followed by a discussion of how, as more-detailed becomes
+ available, the requirement for the less-detailed is
+ reduced.
+
+ Figure
+ shows that, depending on the complexity of the TSF, the
+ design may be described in terms of subsystems
+ and modules (where subsystems are at a
+ higher level of abstraction than modules); or it may just be
+ described in terms of one level of abstraction (e.g.,
+ subsystems at lower assurance levels,
+ modules at higher levels). In cases where a
+ lower level of abstraction (modules) is presented,
+ requirements levied on higher-level abstractions
+ (subsystems) are essentially met by default. This concept is
+ further elaborated in the discussion on subsystems and
+ modules below.
+
+
+ The developer is expected to describe the design of the TOE
+ in terms of subsystems. The term
+ ``subsystem'' was chosen to be specifically vague so that it
+ could refer to units appropriate to the TOE (e.g.,
+ subsystems, modules). subsystems can even be uneven in
+ scope, as long as the requirements for description of
+ subsystems are met.
+
+ The first use of subsystems is to distinguish the TSF boundary;
+ that is, the portions of the TOE that comprise the TSF. In
+ general, a subsystem is part of the TSF if it has the capability
+ (whether by design or implementation) to affect the correct
+ operation of any of the SFRs. For example, for software that
+ depends on different hardware execution modes to provide domain
+ separation (see ) where
+ SFR-enforcing code is executed in one domain, then all
+ subsystems that execute in that domain would be considered part
+ of the TSF. Likewise, if a server outside that domain
+ implemented an SFR (e.g. enforced an access control policy over
+ objects it managed), then it too would be considered part of the
+ TSF.
+
+ The second use of subsystems is to provide a structure for
+ describing the TSF at a level of description that, while
+ describing how the TSF works, does not necessarily contain
+ low-level implementation detail found in module descriptions
+ (discussed later). subsystems are described at either a high
+ level (lacking an abundance of implementation detail) or a
+ detailed level (providing more insight into the
+ implementation). The level of description provided for a
+ subsystem is determined by the degree to which that
+ subsystem is responsible for implementing an SFR.
+
+ An SFR-enforcing subsystem is a subsystem
+ that provides mechanisms for enforcing an element of any SFR,
+ or directly supports a subsystem that is responsible
+ for enforcing an SFR. If a subsystem provides (implements)
+ an SFR-enforcing TSFI, then the subsystem is
+ SFR-enforcing.
+
+ Subsystems can also be identified as
+ SFR-supporting and
+ SFR-non-interfering. An SFR-supporting
+ subsystem is one that is depended on by an SFR-enforcing
+ subsystem in order to implement an SFR, but does not play as
+ direct a role as an SFR-enforcing subsystem. An
+ SFR-non-interfering subsystem is one that is not depended
+ upon, in either a supporting or enforcing role, to implement
+ an SFR.
+
+
+
+ A module is generally a relatively small architectural unit
+ that can be characterised in terms of the properties
+ discussed in . When both
+ (or above) requirements
+ and requirements are
+ present in a PP or ST, a ``module'' in terms of the requirements refers to the same
+ entity as a ``module'' for the requirements. Unlike subsystems, modules
+ describe the implementation in a level of detail that can
+ serve as a guide to reviewing the implementation
+ representation.
+
+ It is important to note that, depending on the TOE, modules
+ and subsystems may refer to the same abstraction. For and (which do not require description at the
+ module level) the subsystem description provides the lowest
+ level detail available about the TSF. For (which require module
+ descriptions) these descriptions provide the lowest level of
+ detail, while the subsystem descriptions (if they exist as
+ separate entities) merely serve to put to the module
+ descriptions in context. That is, it is not necessary to
+ provide detailed subsystem descriptions if module
+ descriptions exist. In TOEs that are sufficiently simple, a
+ separate ``subsystem description'' is not necessary; the
+ requirements can be met through documentation provided by
+ modules. For complex TOEs, the purpose of the subsystem
+ description (with respect to the TSF) is to provide the
+ reader context so they can focus their analysis
+ appropriately. This difference is illustrated in Figure
+ .
+
+ An SFR-enforcing module is a module that directly implements
+ a security functional requirement (SFR) in the ST. Such
+ modules will typically implement an SFR-enforcing TSFI, but
+ some functionality expressed in an SFR (for example, audit
+ and object re-use functionality) may not be directly tied to
+ a single TSFI. As was the case with subsystems,
+ SFR-supporting modules are those modules that are depended
+ upon by an SFR-enforcing module, but are not responsible for
+ directly implementing an SFR. SFR-non-interfering modules
+ are those modules that do not deal, directly or indirectly,
+ with the enforcement of SFRs.
+
+ It is important to note that the determination of what
+ ``directly implements'' means is somewhat subjective. In the
+ narrowest sense of the term, it could be interpreted to mean
+ the one or two lines of code that actually perform a
+ comparison, zeroing operation, etc. that implements a
+ requirement. A broader interpretation might be that it
+ includes the module that is invoked in response to a
+ SFR-enforcing TSFI, and all modules that may be invoked in
+ turn by that module (and so on until the completion of the
+ call). Neither of these interpretations is particularly
+ satisfying, since the narrowness of the first interpretation
+ may lead to important modules being incorrectly categorised
+ as SFR supporting, while the second leads to modules that
+ are actually not SFR-enforcing being classified as
+ such.
+
+ A description of a module should be such that one could
+ create an implementation of the module from the description,
+ and the resulting implementation would be 1) identical to
+ the actual TSF implementation in terms of the interfaces
+ presented and used by the module, and 2) algorithmically
+ identical to the TSF module. For instance, RFC 793 provides
+ a high-level description of the TCP protocol. It is
+ necessarily implementation independent. While it provides a
+ wealth of detail, it is
+
+ not a suitable design description
+ because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC,
+ and implementation choices (for example, the use of global
+ data vs. local data in various parts of the implementation)
+ may have an impact on the analysis that is performed. The
+ design description of the TCP module would list the
+ interfaces presented by the implementation (rather than just
+ those defined in RFC 793), as well as an algorithm
+ description of the processing associated with the modules
+ implementing TCP (assuming they were part of the
+ TSF).
+
+ In the design, modules are described in detail in terms of
+ the function they provide (the purpose); the interfaces they
+ present; the return values from such interfaces; the
+ interfaces (presented by other modules) they use;
+ and a description of how they provide their
+ functionality (one possible way to describe the functionality is
+ an algorithmic desription).
+
+ The purpose of a module should be described indicating what
+ function the module is providing. It should be sufficient so
+ that the reader could get a general idea of what the
+ module's function is in the architecture.
+
+ The interfaces presented by a module are those interfaces
+ used by other modules to invoke the functionality
+ provided. Interfaces include both explicit
+ interfaces (e.g., a calling sequence invoked by other
+ modules) as well as implicit interfaces
+ (e.g., global data manipulated by the module). Interfaces
+ are described in terms of how they are invoked, and any
+ values that are returned. This description would include a
+ list of parameters, and descriptions of these parameters. If
+ a parameter were expected to take on a set of values (e.g.,
+ a ``flag'' parameter), the complete set of values the
+ parameter could take on that would have an effect on module
+ processing would be specified. Likewise, parameters
+ representing data structures are described such that each
+ field of the data structure is identified and
+ described. Global data should be described as to whether it
+ is read or written (or both) by the module.
+
+ Note that different programming languages may have
+ additional ``interfaces'' that would be non-obvious; an
+ example would be operator/function overloading in C++. This
+ ``implicit interface'' in the class description would also
+ be described as part of the module design. Note that
+ although a module could present only one interface, it is
+ more common that a module presents a small set of related
+ interfaces.
+
+ By contrast, interfaces used by a module must be identified
+ such that it can be determined which module is being invoked
+ by the module being described. It must also be clear from
+ the design description the algorithmic reason the invoking
+ module is being called. For example, if Module A is being
+ described, and it uses Module B's bubble sort routine, an
+ inadequate algorithmic description would be ``Module A
+ invokes the double_bubble() interface in
+ Module B to perform a bubble sort''. An adequate algorithmic
+ description would be ``Module A invokes the
+ double_bubble routine with the list of
+ access control entries; double_bubble()
+ will return the entries sorted first on the username, then
+ on the access_allowed field according the following
+ rules...'' The detailed description of a module in the
+ design must provide enough detail so that it is clear what
+ effects Module A is expecting from the bubble sort
+ interface. Note that one method of presenting these called
+ interfaces is via a call tree, and then the algorithmic
+ description can be included in the algorithmic description
+ of the called module.
+
+ As discussed previously, the algorithmic description of the
+ module should describe in an algorithmic fashion the
+ implementation of the module. This can be done in
+ pseudo-code, through flow charts, or (at ) informal text. It discusses
+ how the module inputs and called functions are used to
+ accomplish the module's function. It notes changes to global
+ data, system state, and return values produced by the
+ module. It is at the level of detail that an implementation
+ could be derived that would be very similar to the actual
+ implementation of the TOE.
+
+ It should be noted that source code does not meet the module
+ documentation requirements. Although the module design
+ describes the implementation, it is not the
+ implementation. The comments surrounding the source code
+ might be sufficient documentation if they provide an
+ explanation of the intent of the source code. In-line
+ comments that merely state what each line of code is doing
+ are useless because they provide no explanation of what the
+ module is meant to accomplish.
+
+ In the elements below, the labels (SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering) discussed for
+ subsystems and modules are used to describe the amount and
+ type of information that needs to be made available by the
+ developer. The elements have been structured so that there
+ is no expectation that the developer provide
+ only the information specified. That is, if
+ the developer's documentation of the TSF provides the
+ information in the requirements below, there is no
+ expectation that the developer update their documentation
+ and label subsystems and modules as SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering. The primary purpose
+ of this labelling is to allow developers with less mature
+ development methodologies (and associated artifacts, such as
+ detailed interface and design documentation) to provide the
+ necessary evidence without undue cost.
+
+
+
+ Because there is subjectivity in determining what is
+ SFR-enforcing vs. SFR-supporting (and in some cases, even
+ determining what is SFR-non-interfering) the following
+ paradigm has been adopted in this family. In early
+ components of the family, the developer makes a
+ determination about the classification of the subsystems
+ into SFR-enforcing, etc., supplying the appropriate
+ information, and there is little additional evidence for the
+ evaluator to examine to support this claim. As the level of
+ desired assurance increases, while the developer still makes
+ a classification determination, the evaluator obtains more
+ and more evidence that is used to confirm the developer's
+ classification.
+
+ In order to focus the evaluator's analysis on the SFR-related
+ portions of the TOE, especially at lower levels of assurance,
+ the components of the family are levelled such that initially
+ detailed information is required only for SFR-enforcing
+ architectural entities. As the level of assurance increases,
+ more information is required for SFR-supporting and (eventually)
+ SFR-non-interfering entities. It should be noted that even when
+ complete information is required, it is not required that all of
+ this information be analysed in the same level of detail. The
+ focus should be in all cases on whether the
+ necessary information has been provided and
+ analysed.
+
+ Table summarises the
+ information required at each of the family components for the
+ architectural entities to be described.
+
+
+
+
+
+ TSF subsystem
+ TSF Module
+
+
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+
+
+
+
+
+ (informal
+ presentation)
+
+ structure, summary of SFR-Enf. behaviour, interactions
+
+ designation support
+ designation support means that
+ only documentation sufficient to support the
+ classification of the subsystem / module is
+ needed.
+
+ designation support
+
+
+
+
+
+
+ (informal
+ presentation)
+
+ structure, detailed description of SFR-Enf. behaviour,
+ summary of other behaviour, interactions
+
+
+ structure, summary of other behaviour, interactions
+
+ designation support, interactions
+
+
+
+
+
+
+
+ (informal
+ presentation)description,
+ interactionsdescription, interactions
+ description, interactions
+
+ purpose, SFR interfacesSFR interfaces means that the module description contains,
+ for each SFR-related interface, the returned values and the called interfaces
+ to other modules.
+ interaction, purpose
+ interaction, purpose
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, SFR interfaces
+
+
+ purpose, SFR interfaces
+
+ interaction, purpose
+
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, all interfacesAll interfaces means that the module description contains,
+ for each interface, the returned values and the called interfaces to other
+ modules.
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+
+
+ (semiformal
+ presentation; additional formal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+
+
+ Description Detail Levelling
+
+
+
+
+
+ Formal methods provide a mathematical representation of the
+ TSF and its behaviour and are required by the , , and
+ components. There are two aspects of formal methods: the
+ specification language that is used for
+ formal expression, and the theorem prover
+ that mathematically proves the completeness and correctness of
+ the formal specification.
+
+ A formal specification is expressed within a formal system
+ based upon well-established mathematical concepts. These
+ mathematical concepts are used to define well-defined
+ semantics, syntax and rules of inference. A formal system is
+ an abstract system of identities and relations that can be
+ described by specifying a formal alphabet, a formal language
+ over that alphabet which is based on a formal syntax, and a
+ set of formal rules of inference for constructing derivations
+ of sentences in the formal language.
+
+ The evaluator should examine the identified formal systems to
+ make sure that:
+
+ The semantics, syntax and inference rules of the
+ formal system are defined or a definition is
+ referenced.
+ Each formal system is accompanied by explanatory text
+ that provides defined semantics so that:
+
+ the explanatory text provides defined meanings of
+ terms, abbreviations and acronyms that are used in a
+ context other than that accepted by normal
+ usage,
+ the use of a formal system and semiformal notation
+ use is accompanied by supporting explanatory text in
+ informal style appropriate for unambiguous
+ meaning,
+ the formal system is able to express rules and
+ characteristics of applicable SFPs,
+ security functionality and interfaces (providing
+ details of effects, exceptions and error messages) of
+ TSF, their subsystems or modules to be specified for
+ the assurance family for which the notations are
+ used.
+ the notation provides rules to determine the
+ meaning of syntactical valid constructs.
+
+ Each formal system uses a formal syntax that provides
+ rules to unambiguously recognise constructs.
+ Each formal system provides proof rules which
+
+ support logical reasoning of well-established
+ mathematical concepts,
+ help to prevent derivation of
+ contradictions
+
+ If the developer uses a formal system which is already accepted
+ by the evaluation authority the evaluator can rely on the level
+ of formality and strength of the system and focus on the
+ instantiation of the formal system to the TOE specifications and
+ correspondence proofs.
+
+ The formal style supports mathematical proofs of the security
+ properties based on the security features, the consistency of
+ refinements and the correspondence of the representations.
+ Formal tool support seems adequate whenever manual derivations
+ would otherwise become long winded and
+ incomprehensible. Formal tools are also apt to reduce the
+ error probability inherent in manual derivations.
+
+ Examples of formal systems:
+
+ The Z specification language is highly
+ expressive, and supports many different methods or styles
+ of formal specification. The use of Z has been
+ predominantly for model-oriented specification, using
+ schemas to formally specify
+ operations. See for more
+ information.
+ ACL2 is an open-source formal system
+ comprising a LISP-based specification language and a
+ theorem prover. See for
+ further information.
+ Isabelle is a popular generic theorem
+ proving environment that allows mathematical formulae to
+ be expressed in a formal language and provides tools for
+ proving those formulae within a logical calculus (see
+ e.g. for
+ additional information)
+ The B method is a formal system based
+ on the propositional calculus, the first order predicate
+ calculus with inference rules and set theory (see
+ e.g. for further
+ information).
+
+
+
+
+ The dependencies documented in the components of Clauses and - are the direct dependencies between the
+ assurance components.
+
+ The following dependency tables for assurance components show
+ their direct, indirect and optional dependencies. Each of the
+ components that is a dependency of some assurance component is
+ allocated a column. Each assurance component is allocated a
+ row. The value in the table cell indicate whether the column
+ label component is directly required (indicated by a cross
+ ``X'') or indirectly required (indicated by a dash ``-''), by
+ the row label component. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+ The purpose of this Clause is to document the philosophy that
+ underpins the CC approach to assurance. An understanding of this
+ Clause will permit the reader to understand the rationale behind
+ the CC Part 3 assurance requirements.
+
+
+ The CC philosophy is that the threats to security and
+ organisational security policy commitments should be clearly
+ articulated and the proposed security measures be demonstrably
+ sufficient for their intended purpose.
+
+ Furthermore, measures should be adopted that reduce the
+ likelihood of vulnerabilities, the ability to exercise
+ (i.e. intentionally exploit or unintentionally trigger) a
+ vulnerability, and the extent of the damage that could occur
+ from a vulnerability being exercised. Additionally, measures
+ should be adopted that facilitate the subsequent
+ identification of vulnerabilities and the elimination,
+ mitigation, and/or notification that a vulnerability has been
+ exploited or triggered.
+
+
+
+ The CC philosophy is to provide assurance based upon an
+ evaluation (active investigation) of the IT product that is to
+ be trusted. Evaluation has been the traditional means of
+ providing assurance and is the basis for prior evaluation
+ criteria documents. In aligning the existing approaches, the
+ CC adopts the same philosophy. The CC proposes measuring the
+ validity of the documentation and of the resulting IT product
+ by expert evaluators with increasing emphasis on scope, depth,
+ and rigour.
+
+ The CC does not exclude, nor does it comment upon, the
+ relative merits of other means of gaining assurance. Research
+ continues with respect to alternative ways of gaining
+ assurance. As mature alternative approaches emerge from these
+ research activities, they will be considered for inclusion in
+ the CC, which is so structured as to allow their future
+ introduction.
+
+
+ It is assumed that there are threat agents that will
+ actively seek to exploit opportunities to violate security
+ policies both for illicit gains and for well-intentioned,
+ but nonetheless insecure actions. Threat agents may also
+ accidentally trigger security vulnerabilities, causing harm
+ to the organisation. Due to the need to process sensitive
+ information and the lack of availability of sufficiently
+ trusted products, there is significant risk due to failures
+ of IT. It is, therefore, likely that IT security breaches
+ could lead to significant loss.
+
+ IT security breaches arise through the intentional
+ exploitation or the unintentional triggering of
+ vulnerabilities in the application of IT within business
+ concerns.
+
+ Steps should be taken to prevent vulnerabilities arising in
+ IT products. To the extent feasible, vulnerabilities should
+ be:
+
+
+ eliminated -- that is, active steps should be taken to
+ expose, and remove or neutralise, all exercisable
+ vulnerabilities;
+
+
+ minimised -- that is, active steps should be taken to
+ reduce, to an acceptable residual level, the potential
+ impact of any exercise of a vulnerability;
+
+
+ monitored -- that is, active steps should be taken to
+ ensure that any attempt to exercise a residual
+ vulnerability will be detected so that steps can be
+ taken to limit the damage.
+
+
+
+
+
+ Vulnerabilities can arise through failures in:
+
+
+ requirements -- that is, an IT product may possess all
+ the functions and features required of it and still
+ contain vulnerabilities that render it unsuitable or
+ ineffective with respect to security;
+
+
+ development -- that is, an IT product does not meet its
+ specifications and/or vulnerabilities have been
+ introduced as a result of poor development standards or
+ incorrect design choices;
+
+
+ operation -- that is, an IT product has been constructed
+ correctly to a correct specification but vulnerabilities
+ have been introduced as a result of inadequate controls
+ upon the operation.
+
+
+
+
+
+ Assurance is grounds for confidence that an IT product meets
+ its security objectives. Assurance can be derived from
+ reference to sources such as unsubstantiated assertions,
+ prior relevant experience, or specific experience. However,
+ the CC provides assurance through active
+ investigation. Active investigation is an evaluation of the
+ IT product in order to determine its security
+ properties.
+
+
+
+ Evaluation has been the traditional means of gaining
+ assurance, and is the basis of the CC approach. Evaluation
+ techniques can include, but are not limited to:
+
+
+ analysis and checking of process(es) and procedure(s);
+
+
+ checking that process(es) and procedure(s) are being
+ applied;
+
+
+ analysis of the correspondence between TOE design
+ representations;
+
+
+ analysis of the TOE design representation against the
+ requirements;
+
+
+ verification of proofs;
+
+
+ analysis of guidance documents;
+
+
+ analysis of functional tests developed and the results
+ provided;
+
+
+ independent functional testing;
+
+
+ analysis for vulnerabilities (including flaw
+ hypothesis);
+
+
+ penetration testing.
+
+
+
+
+
+
+ The CC philosophy asserts that greater assurance results from
+ the application of greater evaluation effort, and that the
+ goal is to apply the minimum effort required to provide the
+ necessary level of assurance. The increasing level of effort
+ is based upon:
+
+
+ scope -- that is, the effort is greater because a larger
+ portion of the IT product is included;
+
+
+ depth -- that is, the effort is greater because it is
+ deployed to a finer level of design and implementation
+ detail;
+
+
+ rigour -- that is, the effort is greater because it is
+ applied in a more structured, formal manner.
+
+
+
+
+
+
+ This annex provides an explanation of the criteria and examples of their application. This
+ annex does not define the criteria;
+ this definition can be found in CC Part 3 Section .
+
+ This annex consists of 2 major parts:
+
+
+ Guidance for completing an independent vulnerability
+ analysis. This is summarised in section , and described in more
+ detail in section
+ . These sections describe how an evaluator should approach
+ the construction of an independent Vulnerability Analysis.
+
+
+ How to characterise and use assumed Attack Potential of an
+ attacker. This is described in sections to . These sections provide an example of describe
+ how an attack potential can be characterised and should be
+ used, and provide examples.
+
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the existence and exploitability of flaws or
+ weaknesses in the TOE in the operational environment. This
+ determination is based upon analysis performed by the
+ evaluator, and is supported by evaluator testing.
+
+ At the lowest levels of the
+ evaluator simply performs a search of publicly available
+ information to identify any known weaknesses in the TOE, while
+ at the higher levels the evaluator performs a structured
+ analysis of the TOE evaluation evidence.
+
+ There are three main factors in performing a vulnerability
+ analysis, namely:
+
+ the identification of potential vulnerabilities;
+
+ assessment to determine whether the identified potential
+ vulnerabilities could allow an attacker with the relevant
+ attack potential to violate the SFRs.
+
+ penetration testing to determine whether the identified
+ potential vulnerabilities are exploitable in the operational
+ environment of the TOE.
+
+
+ The identification of vulnerabilities can be further
+ decomposed into the evidence to be searched and how hard to
+ search that evidence to identify potential vulnerabilities. In
+ a similar manner, the penetration testing can be further
+ decomposed into analysis of the potential vulnerability to
+ identify attack methods and the demonstration of the attack
+ methods.
+
+ These main factors are iterative in nature, i.e. penetration
+ testing of potential vulnerabilities may lead to the
+ identification of further potential vulnerabilities. Hence,
+ these are performed as a single vulnerability analysis
+ activity.
+
+
+
+ The evaluator vulnerability analysis is to determine that the
+ TOE is resistant to penetration attacks performed by an
+ attacker possessing a Basic (for and ),
+ Enhanced-Basic (for ),
+ Moderate (for ) or High (for
+ ) attack potential. The
+ evaluator first assesses the exploitability of all identified
+ potential vulnerabilities. This is accomplished by conducting
+ penetration testing. The evaluator should assume the role of
+ an attacker with a Basic (for
+ and ), Enhanced-Basic (for
+ ), Moderate (for ) or High (for ) attack potential when attempting to penetrate the
+ TOE.
+
+ The evaluator considers potential vulnerabilities encountered
+ by the evaluator during the conduct of other evaluation
+ activities. The evaluator penetration testing determining TOE
+ resistance to these potential vulnerabilities should be
+ performed assuming the role of an attacker with a Basic (for
+ and ), Enhanced-Basic (for ), Moderate (for )
+ or High (for ) attack
+ potential.
+
+ However, vulnerability analysis should not be performed as an
+ isolated activity. It is closely linked with and . The evaluator
+ performs these other evaluation activities with a focus on
+ identifying potential vulnerabilities or ``areas of
+ concern''. Therefore, evaluator familiarity with the generic
+ vulnerability guidance (provided in Section ) is required.
+
+
+ The following five categories provide discussion of generic
+ vulnerabilities.
+
+
+ Bypassing includes any means by which an attacker could
+ avoid security enforcement, by:
+
+
+ exploiting the capabilities of interfaces to the TOE,
+ or of utilities which can interact with the TOE;
+
+
+ inheriting privileges or other capabilities that
+ should otherwise be denied;
+
+
+ (where confidentiality is a concern) reading sensitive
+ data stored or copied to inadequately protected areas.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on exploiting the capabilities of
+ interfaces or utilities generally take advantage of
+ the absence of the required security enforcement on
+ those interfaces. For example, gaining access to
+ functionality that is implemented at a lower level
+ than that at which access control is
+ enforced. Relevant items include:
+
+
+ changing the predefined sequence of invocation of
+ TSFI;
+
+
+ invoking an additional TSFI;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using implementation detail introduced in less
+ abstract representations;
+
+
+ using the delay between time of access check and
+ time of use.
+
+
+
+
+ Changing the predefined sequence of invocation of
+ components should be considered where there is an
+ expected order in which interfaces to the TOE
+ (e.g. user commands) are called to invoke a TSFI
+ (e.g. opening a file for access and then reading data
+ from it). If a TSFI is invoked through one of the TOE
+ interfaces (e.g. an access control check), the
+ evaluator should consider whether it is possible to
+ bypass the control by performing the call at a later
+ point in the sequence or by missing it out altogether.
+
+
+ Executing an additional component (in the predefined
+ sequence) is a similar form of attack to the one
+ described above, but involves the calling of some
+ other TOE interface at some point in the sequence. It
+ can also involve attacks based on interception of
+ sensitive data passed over a network by use of network
+ traffic analysers (the additional component here being
+ the network traffic analyser).
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes using an unrelated TOE
+ interface to bypass the TSF by using it to achieve a
+ purpose that it was not designed or intended to
+ achieve. Covert channels are an example of this type
+ of attack (see for further discussion of covert
+ channels). The use of undocumented interfaces, which
+ may be insecure, also falls into this category. Such
+ interfaces may include undocumented support and help
+ facilities.
+
+
+ Using implementation detail introduced in lower
+ representations may allow an attacker to take
+ advantage of additional functions, resources or
+ attributes that are introduced to the TOE as a
+ consequence of the refinement process. Additional
+ functionality may include test harness code contained
+ in software modules and back-doors introduced during
+ the implementation process.
+
+
+ Using the delay between time of check and time of use
+ includes scenarios where an access control check is
+ made and access granted, and an attacker is
+ subsequently able to create conditions in which, had
+ they applied at the time the access check was made,
+ would have caused the check to fail. An example would
+ be a user creating a background process to read and
+ send highly sensitive data to the user's terminal, and
+ then logging out and logging back in again at a lower
+ sensitivity level. If the background process is not
+ terminated when the user logs off, the MAC checks
+ would have been effectively bypassed.
+
+
+ Attacks based on inheriting privileges are generally
+ based on illicitly acquiring the privileges or
+ capabilities of some privileged component, usually by
+ exiting from it in an uncontrolled or unexpected
+ manner. Relevant items include:
+
+
+ executing data not intended to be executable, or
+ making it executable;
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Executing data not intended to be executable, or
+ making it executable includes attacks involving
+ viruses (e.g. putting executable code or commands in a
+ file which are automatically executed when the file is
+ edited or accessed, thus inheriting any privileges the
+ owner of the file has).
+
+
+ Generating unexpected input for a component can have
+ unexpected effects which an attacker could take
+ advantage of. For example, if the TSF could be
+ bypassed if a user gains access to the underlying
+ operating system, it may be possible to gain such
+ access following the login sequence by exploring the
+ effect of hitting various control or escape sequences
+ whilst a password is being authenticated.
+
+
+ Invalidating assumptions and properties on which lower
+ level components rely includes attacks based on
+ breaking out of the constraints of an application to
+ gain access to an underlying operating system in order
+ to bypass the TSF of an application. In this case the
+ assumption being invalidated is that it is not
+ possible for a user of the application to gain such
+ access. A similar attack can be envisaged against an
+ application on an underlying database management
+ system: again the TSF could be bypassed if an attacker
+ can break out of the constraints of the application.
+
+
+ Attacks based on reading sensitive data stored in
+ inadequately protected areas (applicable where
+ confidentiality is a concern) include the following
+ issues which should be considered as possible means of
+ gaining access to sensitive data:
+
+
+ disk scavenging;
+
+
+ access to unprotected memory;
+
+
+ exploiting access to shared writable files or
+ other shared resources (e.g. swap files);
+
+
+ Activating error recovery to determine what access
+ users can obtain. For example, after a crash an
+ automatic file recovery system may employ a lost
+ and found directory for headerless files, which
+ are on disk without labels. If the TOE implements
+ mandatory access controls, it is important to
+ investigate at what security level this directory
+ is kept (e.g. at system high), and who has access
+ to this directory.
+
+
+
+
+
+ There are a number of different methods through which an
+ evaluator may identify a back-door, including two main
+ techniques. Firstly, by the evaluator inadvertently
+ identifying during testing an interface that can be
+ misused. Secondly, through testing each external
+ interface of the TSF in a debugging mode to identify any
+ modules that are not called as a part of testing the
+ documented interfaces and then inspecting the code that is
+ not called to consider whether it is a back-door.
+
+ For a software TOE where and or
+ higher components are included in the assurance package,
+ the evaluator may consider during their analysis of the
+ tools the libraries and packages that are linked by the
+ compiler at compilation stage to determine that back-doors
+ are not introduced at this stage.
+
+
+
+ Tampering includes any attack based on an attacker
+ attempting to influence the behaviour of the TSF
+ (i.e. corruption or de-activation), for example by:
+
+
+ accessing data on whose confidentiality or integrity
+ the TSF relies;
+
+
+ forcing the TOE to cope with unusual or unexpected
+ circumstances;
+
+
+ disabling or delaying security enforcement;
+
+
+ physical modification the TOE.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on accessing data, whose confidentiality
+ or integrity are protected, include:
+
+
+ reading, writing or modifying internal data
+ directly or indirectly;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using interfaces between components that are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Reading, writing or modifying internal data directly
+ or indirectly includes the following types of attack
+ which should be considered:
+
+
+ reading ``secrets'' stored internally, such as
+ user passwords;
+
+
+ spoofing internal data that security enforcing
+ mechanisms rely upon;
+
+
+ modifying environment variables (e.g. logical
+ names), or data in configuration files or
+ temporary files.
+
+
+
+ It may be possible to deceive a trusted process into
+ modifying a protected file that it wouldn't normally
+ access.
+
+
+ The evaluator should also consider the following
+ ``dangerous features'':
+
+
+ source code resident on the TOE along with a
+ compiler (for instance, it may be possible to
+ modify the login source code);
+
+
+ an interactive debugger and patch facility (for
+ instance, it may be possible to modify the
+ executable image);
+
+
+ the possibility of making changes at device
+ controller level, where file protection does not
+ exist;
+
+
+ diagnostic code which exists in the source code
+ and that may be optionally included;
+
+
+ developer's tools left in the TOE.
+
+
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes (for example), where the
+ TOE is an application built upon an operating system,
+ users exploiting knowledge of a word processor package
+ or other editor to modify their own command file
+ (e.g. to acquire greater privileges).
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction includes
+ attacks exploiting shared access to resources, where
+ modification of a resource by one component can
+ influence the behaviour of another (trusted)
+ component, e.g. at source code level, through the use
+ of global data or indirect mechanisms such as shared
+ memory or semaphores.
+
+
+ Attacks based on forcing the TOE to cope with unusual
+ or unexpected circumstances should always be
+ considered. Relevant items include:
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Generating unexpected input for a component includes
+ investigating the behaviour of the TOE when:
+
+
+ command input buffers overflow (possibly
+ ``crashing the stack'' or overwriting other
+ storage, which an attacker may be able to take
+ advantage of, or forcing a crash dump that may
+ contain sensitive information such as clear-text
+ passwords);
+
+
+ invalid commands or parameters are entered
+ (including supplying a read-only parameter to an
+ interface which expects to return data via that
+ parameter and supplying improperly formatted input
+ that should fail parsing such as SQL-injection,
+ format strings);
+
+
+ an end-of-file marker (e.g. CTRL-Z or CTRL-D) or
+ null character is inserted in an audit trail.
+
+
+
+
+ Invalidating assumptions and properties on which
+ lower-level components rely includes attacks taking
+ advantage of errors in the source code where the code
+ assumes (explicitly or implicitly) that security
+ relevant data is in a particular format or has a
+ particular range of values. In these cases the
+ evaluator should determine whether they can invalidate
+ such assumptions by causing the data to be in a
+ different format or to have different values, and if
+ so whether this could confer advantage to an attacker.
+
+
+ The correct behaviour of the TSF may be dependent on
+ assumptions that are invalidated under extreme
+ circumstances where resource limits are reached or
+ parameters reach their maximum value. The evaluator
+ should consider (where practical) the behaviour of the
+ TOE when these limits are reached, for example:
+
+
+ changing dates (e.g. examining how the TOE behaves
+ when a critical date threshold is passed);
+
+
+ filling disks;
+
+
+ exceeding the maximum number of users;
+
+
+ filling the audit log;
+
+
+ saturating security alarm queues at a console;
+
+
+ overloading various parts of a multi-user TOE
+ which relies heavily upon communications
+ components;
+
+
+ swamping a network, or individual hosts, with
+ traffic;
+
+
+ filling buffers or fields.
+
+
+
+
+ Attacks based on disabling or delaying security
+ enforcement include the following items:
+
+
+ using interrupts or scheduling functions to
+ disrupt sequencing;
+
+
+ disrupting concurrence;
+
+
+ using interfaces between components which are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Using interrupts or scheduling functions to disrupt
+ sequencing includes investigating the behaviour of the
+ TOE when:
+
+
+ a command is interrupted (with CTRL-C, CTRL-Y,
+ etc.);
+
+
+ a second interrupt is issued before the first is
+ acknowledged.
+
+
+
+
+ The effects of terminating security critical processes
+ (e.g. an audit daemon) should be explored. Similarly,
+ it may be possible to delay the logging of audit
+ records or the issuing or receipt of alarms such that
+ it is of no use to an administrator (since the attack
+ may already have succeeded).
+
+
+ Disrupting concurrence includes investigating the
+ behaviour of the TOE when two or more subjects attempt
+ simultaneous access. It may be that the TOE can cope
+ with the interlocking required when two subjects
+ attempt simultaneous access, but that the behaviour
+ becomes less well defined in the presence of further
+ subjects. For example, a critical security process
+ could be put into a resource-wait state if two other
+ processes are accessing a resource which it requires.
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction may provide a
+ means of delaying a time-critical trusted process.
+
+
+ Physical attacks can be categorised into physical
+ probing, physical manipulation, physical modification,
+ and substitution.
+
+
+ Physical probing by penetrating the TOE targeting
+ internals of the TOE, e.g. reading at internal
+ communication interfaces, lines or memories.
+
+
+ Physical manipulation can be with the TOE
+ internals aiming at internal modifications of the
+ TOE (e.g. by using optical fault induction as an
+ interaction process), at the external interfaces
+ of the TOE (e.g. by power or clock glitches) and
+ at the TOE environment (e.g. by modifying
+ temperature).
+
+
+ Physical modification of TOE internal security
+ enforcing attributes to inherit privileges or
+ other capabilities that should be denied in
+ regular operation. Such modifications can be
+ caused, e.g., by optical fault induction. Attacks
+ based on physical modification may also yield a
+ modification of the TSF itself, e.g. by causing
+ faults at TOE internal program data transfers
+ before execution. Note, that such kind of
+ bypassing by modifying the TSF itself can
+ jeopardise every TSF unless there are other
+ measures (possibly environmental measures) that
+ prevent an attacker from gaining physical access
+ to the TOE.
+
+
+ Physical substitution to replace the TOE with
+ another IT entity, during delivery or operation of
+ the TOE. Substitution during delivery of the TOE
+ from the development environment to the user
+ should be prevented through application of secure
+ delivery procedures (such as those considered
+ under ). Substitution of the TOE during
+ operation may be considered through a combination
+ of user guidance and the operational environment,
+ such that the user is able to be confident that
+ they are interacting with the TOE.
+
+
+
+
+
+
+
+ Direct attack includes the identification of any
+ penetration tests necessary to test the strength of
+ permutational or probabilistic mechanism and other
+ mechanisms to ensure they withstand direct attack.
+
+ For example, it may be a flawed assumption that a
+ particular implementation of a pseudo-random number
+ generator will possess the required entropy necessary to
+ seed the security mechanism.
+
+ Where a probabilistic or permutational mechanism relies on
+ selection of security attribute value (e.g. selection of
+ password length) or entry of data by a human user
+ (e.g. choice of password), the assumptions made should
+ reflect the worst case.
+
+ Probabilistic or permutational mechanisms should be
+ identified during examination of evaluation evidence
+ required as input to this sub-activity (security target,
+ functional specification, TOE design and implementation
+ representation subset) and any other TOE (e.g. guidance)
+ documentation may identify additional probabilistic or
+ permutational mechanisms.
+
+ Where the design evidence or guidance includes assertions
+ or assumptions (e.g. about how many authentication
+ attempts are possible per minute), the evaluator should
+ independently confirm that these are correct. This may be
+ achieved through testing or through independent
+ analysis.
+
+ Direct attacks reliant upon a weakness in a cryptographic
+ algorithm should not be considered under , as this is outside the scope
+ of the CC. Correctness of the implementation of the
+ cryptographic algorithm is considered during the and
+ activities.
+
+
+
+ Information is an abstract view on relation between the
+ properties of entities, i.e. a signal contains information
+ for a system, if the TOE is able to react to this
+ signal. The TOE resources processes and stores information
+ represented by user data. Therefore:
+
+
+ information may flow with the user data between
+ subjects by internal TOE transfer or export from the TOE;
+
+
+ information may be generated and passed to other user
+ data;
+
+
+ information may be gained through monitoring the
+ operations on data representing the information.
+
+
+
+ The information represented by user data may be
+ characterised by security attributes like ``classification
+ level'' having values, for example unclassified,
+ confidential, secret, top secret, to control operations to
+ the data. This information and therefore the security
+ attributes may be changed by operations e.g. may describe decrease of the
+ level by ``sanitarisation'' or increase of level by
+ combination of data. This is one aspects of an information
+ flow analysis focused on controlled operations of
+ controlled subjects on controlled objects.
+
+ The other aspect is the analysis of illicit
+ information flow. This aspect is more
+ general than the direct access to objects containing user
+ data addressed by the
+ family. An unenforced
+ signalling channel carrying information under control of
+ the information flow control policy can also be caused by
+ monitoring of the processing of any object containing or
+ related to this information (e.g. side channels). An
+ enforced signalling channels
+ may be identified in terms of the subjects manipulating
+ resources and the subject or user that observe such
+ manipulation. Classically, covert channels have been
+ identified as timing or storage channels, according to the
+ resource being modified or modulated. As for other
+ monitoring attacks, the use of the TOE is in accordance
+ with the SFRs.
+
+ Covert channels are normally applicable in the case when
+ the TOE has unobservability AND multi-level separation
+ policy requirements. Covert channels may be routinely
+ spotted during vulnerability analysis and design
+ activities, and should therefore be tested. However,
+ generally such monitoring attacks are only identified
+ through specialised analysis techniques commonly referred
+ to as ``covert channel analysis''. These techniques have
+ been the subject of much research and there are many
+ papers published on this subject. Guidance for the
+ conduct of covert channel analysis should be sought from
+ the evaluation authority.
+
+ Unenforced information flow monitoring
+ attacks include passive analysis techniques aiming at
+ disclosure of sensitive internal data of the TOE by
+ operating the TOE in the way that corresponds to the
+ guidance documents.
+
+ Side Channel Analysis includes crypt analytical techniques
+ based on physical leakage of the TOE. Physical leakage can
+ occur by timing information, power consumption or power
+ emanation during computation of a TSF. Timing information
+ can be collected also by a remote-attacker (having network
+ access to the TOE), power based information channels
+ requires that the attacker is in the near-by environment
+ of the TOE.
+
+ Eavesdropping techniques include interception of all forms
+ of energy, e.g., electromagnetic or optical emanation of
+ computer displays, not necessarily in the near-field of
+ the TOE.
+
+ Monitoring also includes exploits of protocol flaws, e.g.,
+ an attack on SSL implementation.
+
+
+
+ Misuse may arise from:
+
+
+ incomplete guidance documentation;
+
+
+ unreasonable guidance;
+
+
+ unintended misconfiguration of the TOE;
+
+
+ forced exception behaviour of the TOE.
+
+
+
+ If the guidance documentation is incomplete the user may
+ not know how to operate the TOE in accordance with the
+ SFRs. The evaluator should apply familiarity with the TOE
+ gained from performing other evaluation activities to
+ determine that the guidance is complete. In particular,
+ the evaluator should consider the functional
+ specification. The TSF described in this document should
+ be described in the guidance as required to permit secure
+ administration and use through the TSFI available to human
+ users. In addition, the different modes of operation
+ should be considered to ensure that guidance is provided
+ for all modes of operation.
+
+ The evaluator may, as an aid, prepare an informal mapping
+ between the guidance and these documents. Any omissions in
+ this mapping may indicate incompleteness.
+
+ The guidance is considered to be unreasonable if it makes
+ demands on the TOE's usage or operational environment that
+ are inconsistent with the ST or unduly onerous to maintain
+ security.
+
+ A TOE may use a variety of ways to assist the consumer in
+ effectively using that TOE in accordance with the SFRs and
+ prevent unintentional misconfiguration. A TOE may employ
+ functionality (features) to alert the consumer when the
+ TOE is in a state that is inconsistent with the SFRs,
+ whilst other TOEs may be delivered with enhanced guidance
+ containing suggestions, hints, procedures, etc. on using
+ the existing security features most effectively; for
+ instance, guidance on using the audit feature as an aid
+ for detecting when the SFRs are being compromised; namely
+ insecure.
+
+ The evaluator considers the TOE's functionality, its
+ purpose and security objectives for the operational
+ environment to arrive at a conclusion of whether or not
+ there is reasonable expectation that use of the guidance
+ would permit transition into an insecure state to be
+ detected in a timely manner.
+
+ The potential for the TOE to enter into insecure states
+ may be determined using the evaluation deliverables, such
+ as the ST, the functional specification and any other
+ design representations provided as evidence for components
+ included in the assurance package for the TOE (e.g. the
+ TOE/TSF design specification if a component from is included).
+
+ Instances of forced exception behaviour of the TSF could
+ include, but are not limited to, the following:
+
+
+ behaviour of the TOE when start-up, close-down or error
+ recovery is activated;
+
+
+ behaviour of the TOE under extreme circumstances
+ (sometimes termed overload or asymptotic behaviour),
+ particularly where this could lead to the
+ de-activation or disabling of parts of the TSF;
+
+
+ any potential for unintentional misconfiguration or
+ insecure use arising from attacks noted in the section
+ on tampering above.
+
+
+
+
+
+
+ Potential vulnerabilities may be identified by the evaluator
+ during different activities. They may become apparent during
+ an evaluation activity or they may be identified as a result
+ of analysis of evidence to search for
+ vulnerabilities.
+
+
+ The encountered identification of vulnerabilities is where
+ potential vulnerabilities are identified by the evaluator
+ during the conduct of evaluation activities, i.e. the
+ evidence are not being analysed with the express aim of
+ identifying potential vulnerabilities.
+
+ The encountered method of identification is dependent on the
+ evaluator's experience and knowledge; which is monitored and
+ controlled by the evaluation authority. It is not reproducible
+ in approach, but will be documented to ensure repeatability of
+ the conclusions from the reported potential
+ vulnerabilities.
+
+ There are no formal analysis criteria required for this
+ method. Potential vulnerabilities are identified from the
+ evidence provided as a result of knowledge and
+ experience. However, this method of identification is not
+ constrained to any particular subset of evidence.
+
+ Evaluator is assumed to have knowledge of the TOE-type
+ technology and known security flaws as documented in the
+ public domain. The level of knowledge assumed is that
+ which can be gained from a security e-mail list relevant
+ to the TOE type, the regular bulletins (bug, vulnerability
+ and security flaw lists) published by those organisations
+ researching security issues in products and technologies
+ in widespread use. This knowledge is not expected to
+ extend to specific conference proceedings or detailed
+ theses produced by university research for or . However, to ensure the knowledge applied is
+ up to date, the evaluator may need to perform a search of
+ public domain material.
+
+ For to the search of publicly
+ available information is expected to include conference
+ proceeding and theses produced during research activities
+ by universities and other relevant organisations.
+
+ Examples of how these may arise (how the evaluator may
+ encounter potential vulnerabilities):
+
+
+ while the evaluator is examining some evidence, it
+ sparks a memory of a potential vulnerability
+ identified in a similar product type, that the
+ evaluator believes to also be present in the TOE under
+ evaluation;
+
+
+ while examining some evidence, the evaluator spots a
+ flaw in the specification of an interface, that
+ reflects a potential vulnerability.
+
+
+ This may include becoming aware of a potential
+ vulnerability in a TOE through reading about generic
+ vulnerabilities in a particular product type in an IT
+ security publication or on a security e-mail list to which
+ the evaluator is subscribed.
+
+ Attack methods can be developed directly from these
+ potential vulnerabilities. Therefore, the encountered
+ potential vulnerabilities are collated at the time of
+ producing penetration tests based on the evaluator's
+ vulnerability analysis. There is no explicit action for
+ the evaluator to encounter potential
+ vulnerabilities. Therefore, the evaluator is directed
+ through an implicit action specified in and .*.4E.
+
+ Current information regarding public domain
+ vulnerabilities and attacks may be provided to the
+ evaluator by, for example, an evaluation authority. This
+ information is to be taken into account by the evaluator
+ when collating encountered vulnerabilities and attack
+ methods when developing penetration tests.
+
+
+
+ The following types of analysis are presented in terms of
+ the evaluator actions.
+
+
+ The unstructured analysis to be performed by the
+ evaluator (for )
+ permits the evaluator to consider the generic
+ vulnerabilities (as discussed in ). The evaluator will also apply their
+ experience and knowledge of flaws in similar technology
+ types.
+
+
+
+ During the conduct of evaluation activities the
+ evaluator may also identify areas of concern. These are
+ specific portions of the TOE evidence that the evaluator
+ has some reservation about, although the evidence meets
+ the requirements for the activity with which the
+ evidence is associated. For example, a particular
+ interface specification looks particularly complex, and
+ therefore may be prone to error either in the
+ development of the TOE or in the operation of the
+ TOE. There is no potential vulnerability apparent at
+ this stage, further investigation is required. This is
+ beyond the bounds of encountered, as further
+ investigation is required.
+
+ Difference between potential vulnerability and area of
+ concern:
+
+
+ Potential vulnerability - The evaluator knows a
+ method of attack that can be used to exploit the
+ weakness or the evaluator knows of vulnerability
+ information that is relevant to the TOE.
+
+
+ Area of concern - The evaluator may be able to
+ discount concern as a potential vulnerability based
+ on information provided elsewhere. While reading
+ interface specification, the evaluator identifies
+ that due to the extreme (unnecessary) complexity of
+ an interface a potential vulnerability may lay
+ within that area, although it is not apparent
+ through this initial examination.
+
+
+ The focused approach to the identification of
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. This
+ approach to the identification of potential
+ vulnerabilities can be used during the independent
+ vulnerability analysis required by .
+
+ This analysis can be achieved through different
+ approaches, that will lead to commensurate levels of
+ confidence. None of the approaches have a rigid format
+ for the examination of evidence to be performed.
+
+ The approach taken is directed by the results of the
+ evaluator's assessment of the evidence to determine it
+ meets the requirements of the /
+ sub-activities. Therefore, the investigation of the
+ evidence for the existence of potential vulnerabilities
+ may be directed by any of the following:
+
+
+ areas of concern identified during examination of
+ the evidence during the conduct of evaluation
+ activities;
+
+
+ reliance on particular functionality to provide
+ separation, identified during the analysis of the
+ architectural design (as in ), requiring further analysis to
+ determine it cannot be bypassed;
+
+
+ representative examination of the evidence to
+ hypothesise potential vulnerabilities in the
+ TOE.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, the evaluator may not be able to
+ describe the steps in identifying potential
+ vulnerabilities before the outset of the
+ examination. The approach will evolve as a result of the
+ outcome of evaluation activities.
+
+ The areas of concern may arise from examination of any
+ of the evidence provided to satisfy the SARs specified
+ for the TOE evaluation. The information publicly
+ accessible is also considered.
+
+ The activities performed by the evaluator can be
+ repeated and the same conclusions, in terms of the level
+ of assurance in the TOE, can be reached although the
+ steps taken to achieve those conclusions may vary. As
+ the evaluator is documenting the form the analysis took,
+ the actual steps taken to achieve those conclusions are
+ also reproducible.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the
+ focused identification method). The method is specified
+ in terms of the information that will be considered and
+ how/why it will be considered. This approach to the
+ identification of potential vulnerabilities can be used
+ during the independent vulnerability analysis required
+ by and .
+
+ This analysis of the evidence is deliberate and
+ pre-planned in approach, considering all evidence
+ identified as an input into the analysis.
+
+ All evidence provided to satisfy the () assurance requirements specified in the
+ assurance package are used as input to the potential
+ vulnerability identification activity.
+
+ The ``methodical'' descriptor for this analysis has been
+ used in an attempt to capture the characterisation that
+ this identification of potential vulnerabilities is to
+ take an ordered and planned approach. A ``method'' or
+ ``system'' is to be applied in the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered; and the
+ hypothesis that is to be generated.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a security mechanism, such as domain
+ separation, hypothesising internal buffer overflows
+ leading to degradation of separation;
+
+
+ analysis to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine the SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the analysis that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be analysed to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ This identification method will provide a plan of attack
+ of the TOE, that would be performed by an evaluator
+ completing penetration testing of potential
+ vulnerabilities in the TOE. The rationale for the method
+ of identification would provide the evidence for the
+ coverage and depth of exploitation determination that
+ would be performed on the TOE.
+
+
+
+
+
+
+
+ Attack potential is used by a PP/ST author during the
+ development of the PP/ST, in consideration of the threat
+ environment and the selection of assurance components. This
+ may simply be a determination that the attack potential
+ possessed by the assumed attackers of the TOE is generically
+ characterised as Basic, Enhanced-Basic, Moderate or
+ High. Alternatively, the PP/ST may wish to specify
+ particular levels of individual factors assumed to be
+ possessed by attackers. (e.g. the attackers are assumed to
+ be experts in the TOE technology type, with access to
+ specialised equipment.)
+
+ The PP/ST author considers the threat profile developed during a
+ risk assessment (outside the scope of the CC, but used as an
+ input into the development of the PP/ST in terms of the Security
+ Problem Definition or in the case of low assurance STs, the
+ requirements statement). Consideration of this threat profile in
+ terms of one of the approaches discussed in the following
+ sections will permit the specification of the attack potential
+ the TOE is to resist.
+
+
+
+ Attack potential is especially considered by the evaluator
+ in two distinct ways during the ST evaluation and the
+ vulnerability assessment activities.
+
+ Attack potential is used by an evaluator during the conduct
+ of the vulnerability analysis sub-activity to determine
+ whether or not the TOE is resistant to attacks assuming a
+ specific attack potential of an attacker. If the evaluator
+ determines that a potential vulnerability is exploitable in
+ the TOE, they have to confirm that it is exploitable
+ considering all aspects of the intended environment,
+ including the attack potential assumed by an
+ attacker.
+
+ Therefore, using the information provided in the threat
+ statement of the Security Target, the evaluator determines
+ the minimum attack potential required by an attacker to
+ effect an attack, and arrives at some conclusion about the
+ TOE's resistance to attacks. Table demonstrates the relationship between this
+ analysis and attack potential.
+
+
+
+
+ Vulnerability Component
+ TOE resistant to attacker with
+ attack potential of:
+ Residual vulnerabilities only
+ exploitable by attacker with attack potential
+ of:
+
+
+
+
+ VAN.5
+ High
+ Beyond High
+
+
+ VAN.4
+ Moderate
+ High
+
+
+ VAN.3
+ Enhanced-Basic
+ Moderate
+
+
+ VAN.2
+ Basic
+ Enhanced-Basic
+
+
+ VAN.1
+ Basic
+ Enhanced-Basic
+
+
+
+ Vulnerability testing and attack potential
+
+
+ The ``beyond high'' entry in the residual vulnerabilities
+ column of the above table represents those potential
+ vulnerabilities that would require an attacker to have an
+ attack potential greater than that of ``high'' in order to
+ exploit the potential vulnerability. A vulnerability
+ classified as residual in this instance reflects the fact
+ that a known weakness exists in the TOE, but in the current
+ operational environment, with the assumed attack potential,
+ the weakness cannot be exploited.
+
+ At any level of attack potential a potential vulnerability
+ may be deemed ``infeasible'' due to a countermeasure in the
+ operational environment that prevents the vulnerability from
+ being exploited.
+
+ A vulnerability analysis applies to all TSFI, including ones
+ that access probabilistic or permutational mechanisms. No
+ assumptions are made regarding the correctness of the design
+ and implementation of the TSFI; nor are constraints placed
+ on the attack method or the attacker's interaction with the
+ TOE - if an attack is possible, then it is to be considered
+ during the vulnerability analysis. As shown in Table , successful evaluation
+ against a vulnerability assurance component reflects that
+ the TSF is designed and implemented to protect against the
+ required level of threat.
+
+ It is not necessary for an evaluator to perform an attack
+ potential calculation for each potential vulnerability. In
+ some cases it is apparent when developing the attack method
+ whether or not the attack potential required to develop and
+ run the attack method is commensurate with that assumed of
+ the attacker in the operational environment. For any
+ vulnerabilities for which an exploitation is determined, the
+ evaluator performs an attack potential calculation to
+ determine that the exploitation is appropriate to the level
+ of attack potential assumed for the attacker.
+
+ The approach described below is to be applied whenever it is
+ necessary to calculate attack potential, unless the evaluation
+ authority provides mandatory guidance that an alternative
+ approach is to be applied. The values given in Tables and
+ below are not mathematically proven. Therefore, the values given
+ in these example tables may need to be adjusted according to the
+ technology type and specific environments. The evaluator should
+ seek guidance from the evaluation authority.
+
+
+
+
+
+ Attack potential is a function of expertise, resources and
+ motivation. There are multiple methods of representing and
+ quantifying these factors. Also, there may be other factors
+ that are applicable for particular TOE types.
+
+
+ Motivation is an attack potential factor that can be used
+ to describe several aspects related to the attacker and
+ the assets the attacker desires. Firstly, motivation can
+ imply the likelihood of an attack - one can infer from a
+ threat described as highly motivated that an attack is
+ imminent, or that no attack is anticipated from an
+ un-motivated threat. However, except for the two extreme
+ levels of motivation, it is difficult to derive a
+ probability of an attack occurring from motivation.
+
+ Secondly, motivation can imply the value of the asset,
+ monetarily or otherwise, to either the attacker or the
+ asset holder. An asset of very high value is more likely
+ to motivate an attack compared to an asset of little
+ value. However, other than in a very general way, it is
+ difficult to relate asset value to motivation because the
+ value of an asset is subjective - it depends largely upon
+ the value an asset holder places on it.
+
+ Thirdly, motivation can imply the expertise and resources
+ with which an attacker is willing to effect an attack. One
+ can infer that a highly motivated attacker is likely to
+ acquire sufficient expertise and resources to defeat the
+ measures protecting an asset. Conversely, one can infer
+ that an attacker with significant expertise and resources
+ is not willing to effect an attack using them if the
+ attacker's motivation is low.
+
+ During the course of preparing for and conducting an
+ evaluation, all three aspects of motivation are at some
+ point considered. The first aspect, likelihood of attack,
+ is what may inspire a developer to pursue an
+ evaluation. If the developer believes that the attackers
+ are sufficiently motivated to mount an attack, then an
+ evaluation can provide assurance of the ability of the TOE
+ to thwart the attacker's efforts. Where the operational
+ environment is well defined, for example in a system
+ evaluation, the level of motivation for an attack may be
+ known, and will influence the selection of
+ countermeasures.
+
+ Considering the second aspect, an asset holder may believe
+ that the value of the assets (however measured) is
+ sufficient to motivate attack against them. Once an
+ evaluation is deemed necessary, the attacker's motivation
+ is considered to determine the methods of attack that may
+ be attempted, as well as the expertise and resources used
+ in those attacks. Once examined, the developer is able to
+ choose the appropriate assurance level, in particular the
+ requirement components,
+ commensurate with the attack potential for the
+ threats. During the course of the evaluation, and in
+ particular as a result of completing the vulnerability
+ assessment activity, the evaluator determines whether or
+ not the TOE, operating in its operational environment, is
+ sufficient to thwart attackers with the identified
+ expertise and resources.
+
+ It may be possible for a PP author to quantify the
+ motivation of an attacker, as the PP author has greater
+ knowledge of the operational environment in which the TOE
+ (conforming to the requirements of the PP) is to be
+ placed. Therefore, the motivation could form an explicit
+ part of the expression of the attack potential in the PP,
+ along with the necessary methods and measures to quantify
+ the motivation.
+
+
+
+
+ This section examines the factors that determine attack
+ potential, and provides some guidelines to help remove some
+ of the subjectivity from this aspect of the evaluation
+ process.
+
+
+ The determination of the attack potential for an attack
+ corresponds to the identification of the effort required to
+ create the attack, and to demonstrate that it can be
+ successfully applied to the TOE (including setting up or
+ building any necessary test equipment), thereby exploiting the
+ vulnerability in the TOE. The demonstration that the attack can
+ be successfully applied needs to consider any difficulties in
+ expanding a result shown in the laboratory to create a useful
+ attack. For example, where an experiment reveals some bits or
+ bytes of a confidential data item (such as a key), it is
+ necessary to consider how the remainder of the data item would
+ be obtained (in this example some bits might be measured
+ directly by further experiments, while others might be found by
+ a different technique such as exhaustive search). It may not be
+ necessary to carry out all of the experiments to identify the
+ full attack, provided it is clear that the attack actually
+ proves that access has been gained to a TOE asset, and that the
+ complete attack could realistically be carried out in
+ exploitation according to the
+ component targeted. In some cases the only way to prove that an
+ attack can realistically be carried out in exploitation
+ according to the component
+ targeted is to perform completely the attack and
+ then rate it based upon the resources actually required.
+ One of the outputs from the identification of a potential
+ vulnerability is assumed to be a script that gives a
+ step-by-step description of how to carry out the attack that can
+ be used in the exploitation of the vulnerability on another
+ instance of the TOE.
+
+ In many cases, the evaluators will estimate the parameters
+ for exploitation, rather than carry out the full
+ exploitation. The estimates and their rationale will be
+ documented in the ETR.
+
+
+
+ The following factors should be considered during analysis
+ of the attack potential required to exploit a
+ vulnerability:
+
+
+ Time taken to identify and exploit (
+ Elapsed Time);
+
+
+ Specialist technical expertise required (
+ Specialist Expertise);
+
+
+ Knowledge of the TOE design and operation (
+ Knowledge of the TOE);
+
+
+
+ Window of opportunity;
+
+
+
+ IT hardware/software or other
+ equipment required for
+ exploitation.
+
+
+
+ In many cases these factors are not independent, but may be
+ substituted for each other in varying degrees. For example,
+ expertise or hardware/software may be a substitute for time. A
+ discussion of these factors follows. (The levels of each factor
+ are discussed in increasing order of magnitude.) When it is the
+ case, the less ``expensive'' combination is considered in the
+ exploitation phase.
+ Elapsed time is the total amount
+ of time taken by an attacker to identify that a particular
+ potential vulnerability may exist in the TOE, to develop an
+ attack method and to sustain effort required to mount the attack
+ against the TOE. When considering this factor, the worst case
+ scenario is used to estimate the amount of time required. The
+ identified amount of time is as follows:
+ less than one day;between one day and one week;between one week and two weeks;between two weeks and one month;each additional month up to 6 months leads to an
+ increased value;more than 6 months.
+
+ Specialist expertise refers
+ to the level of generic knowledge of the underlying
+ principles, product type or attack methods (e.g. Internet
+ protocols, Unix operating systems, buffer overflows). The
+ identified levels are as follows:
+
+
+ Laymen are unknowledgeable compared to experts or
+ proficient persons, with no particular expertise;
+
+
+ Proficient persons are knowledgeable in that they are
+ familiar with the security behaviour of the product or
+ system type;
+
+
+ Experts are familiar with the underlying algorithms,
+ protocols, hardware, structures, security behaviour,
+ principles and concepts of security employed,
+ techniques and tools for the definition of new
+ attacks, cryptography, classical attacks for the
+ product type, attack methods, etc. implemented in the
+ product or system type.
+
+
+ The level ``Multiple Expert'' is introduced to allow for
+ a situation, where different fields of expertise are
+ required at an Expert level for distinct steps of an
+ attack.
+
+ It may occur that several types of expertise are
+ required. By default, the higher of the different
+ expertises factors is chosen. In very specific cases, the
+ ``multiple expert'' level could be used but it should be
+ noted that the expertise must concern fields that are
+ strictly different like for example HW manipulation and
+ cryptography.
+
+
+ Knowledge of the TOE refers to
+ specific expertise in relation to the TOE. This is
+ distinct from generic expertise, but not unrelated to
+ it. Identified levels are as follows:
+
+
+ Public information concerning the TOE (e.g. as gained
+ from the Internet);
+
+
+ Restricted information concerning the TOE
+ (e.g. knowledge that is controlled within the
+ developer organisation and shared with other
+ organisations under a non-disclosure agreement)
+
+
+ Sensitive information about the TOE (e.g. knowledge
+ that is shared between discreet teams within the
+ developer organisation, access to which is constrained
+ only to members of the specified teams);
+
+
+ Critical information about the TOE (e.g. knowledge
+ that is known by only a few individuals, access to
+ which is very tightly controlled on a strict need to
+ know basis and individual undertaking).
+
+
+
+ The knowledge of the TOE may graduate according to design
+ abstraction, although this can only be done on a TOE by
+ TOE basis. Some TOE designs may be public source (or
+ heavily based on public source) and therefore even the
+ design representation would be classified as public or at
+ most restricted, while the implementation representation
+ for other TOEs is very closely controlled as it would give
+ an attacker information that would aid an attack and is
+ therefore considered to be sensitive or even
+ critical.
+
+ It may occur that several types of knowledge are
+ required. In such cases, the higher of the different
+ knowledge factors is chosen.
+
+
+ Window of opportunity
+
+ (Opportunity) is also an important consideration, and has
+ a relationship to the Elapsed Time
+ factor. Identification or exploitation of a
+ vulnerability may require considerable amounts of access
+ to a TOE that may increase the likelihood of
+ detection. Some attack methods may require considerable
+ effort off-line, and only brief access to the TOE to
+ exploit. Access may also need to be continuous, or over a
+ number of sessions.
+
+ For some TOEs the Window of
+ opportunity may equate to the number of
+ samples of the TOE that the attacker can obtain. This is
+ particularly relevant where attempts to penetrate the
+ TOE and undermine the SFRs may result in the destruction
+ of the TOE preventing use of that TOE sample for further
+ testing, e.g. hardware devices. Often in these cases
+ distribution of the TOE is controlled and so the
+ attacker must apply effort to obtain further samples of
+ the TOE.
+
+ For the purposes of this discussion:
+
+
+ unnecessary/unlimited access means that the attack
+ doesn't need any kind of opportunity to be realised
+ because there is no risk of being detected during
+ access to the TOE and it is no problem to access the
+ number of TOE samples for the attack;
+
+ easy means that access is required for less than a day
+ and that the number of TOE samples required to perform
+ the attack is less than ten;
+
+ moderate means that access is required for less than a
+ month and that the number of TOE samples required to
+ perform the attack is less than one hundred;
+
+ difficult means that access is required for at least a
+ month or that the number of TOE samples required to
+ perform the attack is at least one hundred;
+
+ none means that the opportunity window is not
+ sufficient to perform the attack (the length for which
+ the asset to be exploited is available or is sensitive
+ is less than the opportunity length needed to perform
+ the attack - for example, if the asset key is changed
+ each week and the attack needs two weeks); another
+ case is, that a sufficient number of TOE samples
+ needed to perform the attack is not accessible to the
+ attacker - for example if the TOE is a hardware and
+ the probability to destroy the TOE during the attack
+ instead of being successful is very high and the
+ attacker has only access to one sample of the
+ TOE.
+
+ Consideration of this factor may result in determining
+ that it is not possible to complete the exploit, due to
+ requirements for time availability that are greater than
+ the opportunity time.
+
+
+ IT hardware/software or other equipment
+ refers to the equipment required to identify
+ or exploit a vulnerability.
+
+
+ Standard equipment is readily available to the
+ attacker, either for the identification of a
+ vulnerability or for an attack. This equipment may be
+ a part of the TOE itself (e.g. a debugger in an
+ operating system), or can be readily obtained
+ (e.g. Internet downloads, protocol analyser or simple
+ attack scripts).
+
+
+ Specialised equipment is not readily available to the attacker,
+ but could be acquired without undue effort. This could include
+ purchase of moderate amounts of equipment (e.g. power analysis
+ tools, use of hundreds of PCs linked across the Internet would
+ fall into this category), or development of more extensive
+ attack scripts or programs. If clearly different test benches
+ consisting of specialised equipment are required for distinct
+ steps of an attack this would be rated as bespoke.
+
+
+ Bespoke equipment is not readily available to the
+ public as it may need to be specially produced
+ (e.g. very sophisticated software), or because the
+ equipment is so specialised that its distribution is
+ controlled, possibly even restricted. Alternatively,
+ the equipment may be very expensive.
+
+ The level ``Multiple Bespoke'' is introduced to allow
+ for a situation, where different types of bespoke
+ equipment are required for distinct steps of an
+ attack.
+
+ Specialist expertise and Knowledge of the
+ TOE are concerned with the information
+ required for persons to be able to attack a TOE. There
+ is an implicit relationship between an attacker's
+ expertise (where the attacker may be one or more persons
+ with complementary areas of knowledge) and the ability
+ to effectively make use of equipment in an attack. The
+ weaker the attacker's expertise, the lower the potential
+ to use equipment (IT hardware/software or other
+ equipment). Likewise, the greater the expertise, the
+ greater the potential for equipment to be used in the
+ attack. Although implicit, this relationship between
+ expertise and the use of equipment does not always
+ apply, for instance, when environmental measures prevent
+ an expert attacker's use of equipment, or when, through
+ the efforts of others, attack tools requiring little
+ expertise to be effectively used are created and freely
+ distributed (e.g. via the Internet).
+
+
+
+ Table identifies the
+ factors discussed in the previous section and associates
+ numeric values with the total value of each factor.
+
+ Where a factor falls close to the boundary of a range the
+ evaluator should consider use of an intermediate value to those
+ in the table. For example, if twenty samples are required to
+ perform the attack then a value between one and four may be
+ selected for that factor, or if the design is based on a
+ publicly available design but the developer has made some
+ alterations then a value between zero and three should be
+ selected according to the evaluator's view of the impact of
+ those design changes. The table is intended as a guide.
+
+ The ``**'' specification in the table in considering
+ Window of Opportunity is not
+ to be seen as a natural progression from the timescales
+ specified in the preceding ranges associated with this
+ factor. This specification identifies that for a
+ particular reason the potential vulnerability cannot be
+ exploited in the TOE in its intended operational
+ environment. For example, access to the TOE may be
+ detected after a certain amount of time in a TOE with a
+ known environment (i.e. in the case of a system) where
+ regular patrols are completed, and the attacker could not
+ gain access to the TOE for the required two weeks
+ undetected. However, this would not be applicable to a TOE
+ connected to the network where remote access is possible,
+ or where the physical environment of the TOE is
+ unknown.
+
+
+
+
+
+ Factor
+
+
+ Value
+
+
+
+
+
+
+ Elapsed Time
+
+
+
+
+
+ <= one day
+
+ 0
+
+
+
+ <= one week
+
+ 1
+
+
+
+ <= two weeks
+
+ 2
+
+
+
+ <= one month
+
+ 4
+
+
+
+ <= two months
+
+ 7
+
+
+
+ <= three months
+
+ 10
+
+
+
+ <= four months
+
+ 13
+
+
+
+ <= five months
+
+ 15
+
+
+
+ <= six months
+
+ 17
+
+
+
+ > six months
+
+ 19
+
+
+
+ Expertise
+
+
+
+
+
+ Layman
+
+ 0
+
+
+
+ Proficient
+
+
+ 3*When several proficient persons are
+ required to complete the attack path, the
+ resulting level of expertise still remains
+ ``proficient'' (which leads to a 3
+ rating).
+
+
+
+ Expert
+
+ 6
+
+
+
+ Multiple experts
+
+ 8
+
+
+
+ Knowledge of TOE
+
+
+
+
+
+ Public
+
+ 0
+
+
+
+ Restricted
+
+ 3
+
+
+
+ Sensitive
+
+ 7
+
+
+
+ Critical
+
+ 11
+
+
+
+ Window of Opportunity
+
+
+
+
+
+ Unnecessary / unlimited access
+
+ 0
+
+
+
+ Easy
+
+ 1
+
+
+
+ Moderate
+
+ 4
+
+
+
+ Difficult
+
+ 10
+
+
+
+ None
+
+
+ **Indicates that the attack path is not
+ exploitable due to other measures in the
+ intended operational environment of the
+ TOE.
+
+
+
+
+ Equipment
+
+
+
+
+
+ Standard
+
+ 0
+
+
+
+ Specialised
+
+ 4If clearly different test benches
+ consisting of specialised equipment are required
+ for distinct steps of an attack, this should be
+ rated as bespoke.
+
+
+
+ Bespoke
+
+ 7
+
+
+
+ Multiple bespoke
+
+ 9
+
+
+
+
+ Calculation of attack potential
+
+
+ To determine the resistance of the TOE to the potential
+ vulnerabilities identified the following steps should be
+ applied:
+
+
+ Define the possible attack scenarios {AS1, AS2, ...,
+ ASn} for the TOE in the operational
+ environment.
+
+ For each attack scenario, perform a theoretical
+ analysis and calculate the relevant attack potential
+ using Table .
+
+ For each attack scenario, if necessary, perform
+ penetration tests in order to confirm or to disprove
+ the theoretical analysis.
+
+ Divide all attack scenarios {AS1, AS2, ..., ASn} into
+ two groups:
+
+
+ the attack scenarios having been successful
+ (i.e. those that have been used to successfully
+ undermine the SFRs), and
+
+ the attack scenarios that have been demonstrated
+ to be unsuccessful.
+
+
+
+ For each successful attack scenario, apply Table and determine, whether
+ there is a contradiction between the resistance of the
+ TOE and the chosen
+ assurance component, see the last column of Table .
+
+ Should one contradiction be found, the vulnerability
+ assessment will fail, e.g. the author of the ST chose
+ the component and an
+ attack scenario with an attack potential of 21 points
+ (high) has broken the security of the TOE. In this
+ case the TOE is resistant to attacker with attack
+ potential 'Moderate', this contradicts to , hence, the vulnerability
+ assessment fails.
+
+ The ``Values'' column of Table indicates the range of attack potential values
+ (calculated using Table ) of an
+ attack scenario that results in the SFRs being
+ undermined.
+
+
+ An approach such as this cannot take account of every
+ circumstance or factor, but should give a better
+ indication of the level of resistance to attack required
+ to achieve the standard ratings. Other factors, such as
+ the reliance on unlikely chance occurrences are not
+ included in the basic model, but can be used by an
+ evaluator as justification for a rating other than those
+ that the basic model might indicate.
+
+ It should be noted that whereas a number of
+ vulnerabilities rated individually may indicate high
+ resistance to attack, collectively the combination of
+ vulnerabilities may indicate that overall a lower rating
+ is applicable. The presence of one vulnerability may make
+ another easier to exploit.
+
+ If a PP/ST author wants to use the attack potential table for
+ the determination of the level of attack the TOE should
+ withstand (selection of Vulnerability analysis () component), he should proceed as
+ follows: For all different attack scenarios (i.e. for all
+ different types of attacker and/or different types of attack the
+ author has in mind) which must note violate the SFRs, several
+ passes through Table should be
+ made to determine the different values of attack potential
+ assumed for each such unsuccessful attack scenario. The PP/ST
+ author then chooses the highest value of them in order to
+ determine the level of the TOE resistance to be claimed from
+ Table : the TOE resistance must
+ be at least equal to this highest value determined. For
+ example, the highest value of attack potentials of all attack
+ scenarios, which must not undermine the TOE security policy,
+ determined in such a way is Moderate; hence, the TOE resistance
+ shall be at least Moderate (i.e. Moderate or High); therefore,
+ the PP/ST author can choose either (for Moderate) or
+ (for High) as the appropriate assurance component.
+
+
+
+
+
+
+
+ Mechanisms subject to direct attack are often vital for system
+ security and developers often strengthen these mechanisms. As
+ an example, a TOE might use a simple pass number
+ authentication mechanism that can be overcome by an attacker
+ who has the opportunity to repeatedly guess another user's
+ pass number. The system can strengthen this mechanism by
+ restricting pass numbers and their use in various ways. During
+ the course of the evaluation an analysis of this direct attack
+ could proceed as follows:
+
+ Information gleaned from the ST and design evidence reveals
+ that identification and authentication provides the basis upon
+ which to control access to network resources from widely
+ distributed terminals. Physical access to the terminals is not
+ controlled by any effective means. The duration of access to a
+ terminal is not controlled by any effective means. Authorised
+ users of the system choose their own pass numbers when
+ initially authorised to use the system, and thereafter upon
+ user request. The system places the following restrictions on
+ the pass numbers selected by the user:
+
+
+ the pass number must be at least four and no greater than
+ six digits long;
+
+
+ consecutive numerical sequences are disallowed (such as
+ 7,6,5,4,3);
+
+
+ repeating digits is disallowed (each digit must be
+ unique).
+
+
+
+ Guidance provided to the users at the time of pass number
+ selection is that pass numbers should be as random as possible
+ and should not be affiliated with the user in some way - a
+ date of birth, for instance.
+
+ The pass number space is calculated as follows:
+
+
+ Patterns of human usage are important considerations that
+ can influence the approach to searching a password
+ space. Assuming the worst case scenario and the user
+ chooses a number comprising only four digits, the number
+ of pass number permutations assuming that each digit must
+ be unique is:
+
+
+ The number of possible increasing sequences is seven, as
+ is the number of decreasing sequences. The pass number
+ space after disallowing sequences is:
+
+
+
+ Based on further information gleaned from the design evidence,
+ the pass number mechanism is designed with a terminal locking
+ feature. Upon the sixth failed authentication attempt the
+ terminal is locked for one hour. The failed authentication
+ count is reset after five minutes so that an attacker can at
+ best attempt five pass number entries every five minutes, or
+ 60 pass number entries every hour.
+
+ On average, an attacker would have to enter 2513 pass numbers,
+ over 2513 minutes, before entering the correct pass number. The
+ average successful attack would, as a result, occur in slightly
+ less than:
+
+ Using the approach to calculate the attack potential, described
+ in the previous section, identifies that it is possible that a
+ layman can defeat the mechanism within days (given easy access
+ to the TOE), with the use of standard equipment, and with no
+ knowledge of the TOE, giving a value of 1. Given the resulting
+ sum, 1, the attack potential required to effect a successful
+ attack is not rated, as it falls below that considered to be
+ Basic.
+
+
+
+
+ Table describes the
+ relationship between the composition assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Composed Assurance Packages (CAPs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance for
+ composed TOEs.
+
+ It is important to note that there are only a small number of
+ families and components from CC Part 3 included in the
+ CAPs. This is due to their nature of building upon evaluation
+ results of previously evaluated entities (base components and
+ dependent components), and is not to say that these do not
+ provide meaningful and desirable assurances.
+
+
+ CAPs are to be applied to composed TOEs, which are comprised
+ of components that have been (are going through) component TOE
+ evaluation (see ). The
+ individual components will have been certified to an EAL or
+ another assurance package specified in the ST. It is expected
+ that a basic level of assurance in a composed TOE will be
+ gained through application of EAL1, which can be achieved with
+ information about the components that is generally available
+ in the public domain. (EAL1 can be applied as specified
+ within to both component and composed TOEs.) CAPs provide an
+ alternative approach to obtaining higher levels of assurance
+ for a composed TOE than application of the EALs above
+ EAL1.
+
+ While a dependent component can be evaluated using a
+ previously evaluated and certified base component to satisfy
+ the IT platform requirements in the environment, this does not
+ provide any formal assurance of the interactions between the
+ components or the possible introduction of vulnerabilities
+ resulting from the composition. Composed assurance packages
+ consider these interactions and, at higher levels of
+ assurance, ensure that the interface between the components
+ has itself been the subject of testing. A vulnerability
+ analysis of the composed TOE is also performed to consider the
+ possible introduction of vulnerabilities as a result of
+ composing the components.
+
+ Table represents a summary
+ of the CAPs. The columns represent a hierarchically ordered
+ set of CAPs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, three hierarchically
+ ordered composed assurance packages are defined in the CC for
+ the rating of a composed TOE's assurance. They are
+ hierarchically ordered inasmuch as each CAP represents more
+ assurance than all lower CAPs. The increase in assurance from
+ CAP to CAP is accomplished by substitution of a hierarchically
+ higher assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements). These increases result in
+ greater analysis of the composition to identify the impact on
+ the evaluation results gained for the individual component
+ TOEs.
+
+ These CAPs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each CAP includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ The CAPs only consider resistance against an attacker with an
+ attack potential up to Enhanced-Basic. This is due to the level
+ of design information that can be provided through the , limiting some of the factors
+ associated with attack potential (knowledge of the composed TOE)
+ and subsequently affecting the rigour of vulnerability analysis
+ that can be performed by the evaluator. Therefore, the level of
+ assurance in the composed TOE is limited, although the assurance
+ in the individual components within the composed TOE may be much
+ higher.
+
+
+
+
+ The following Subclauses provide definitions of the CAPs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ Unlike the CC, where each element maintains the last digit of
+ its identifying symbol for all components within the family,
+ the CEM may introduce new work units when a CC evaluator
+ action element changes from sub-activity to sub-activity; as a
+ result, the last digit of the work unit's identifying symbol
+ may change although the work unit remains unchanged.
+
+ Any methodology-specific evaluation work required that is not
+ derived directly from CC requirements is termed
+ task or sub-task.
+
+
+
+ All work unit and sub-task verbs are preceded by the auxiliary
+ verb shall and by presenting both the verb
+ and the shall in
+
+ bold italic type face. The
+ auxiliary verb shall is used only when the
+ provided text is mandatory and therefore only within the work
+ units and sub-tasks. The work units and sub-tasks contain
+ mandatory activities that the evaluator must perform in order
+ to assign verdicts.
+
+ Guidance text accompanying work units and sub-tasks gives
+ further explanation on how to apply the CC words in an
+ evaluation. The verb usage is in accordance with ISO
+ definitions for these verbs. The auxiliary verb
+ should is used when the described method is
+ strongly preferred. All other auxiliary verbs, including
+ may, are used where the described method(s)
+ is allowed but is neither recommended nor strongly preferred;
+ it is merely explanation.
+
+ The verbs check, examine,
+ report and record are used
+ with a precise meaning within this part of the CEM and the
+ Clause should be
+ referenced for their definitions.
+
+
+
+ Material that has applicability to more than one sub-activity
+ is collected in one place. Guidance whose applicability is
+ widespread (across activities and EALs) has been collected
+ into . Guidance that
+ pertains to multiple sub-activities within a single activity
+ has been provided in the introduction to that activity. If
+ guidance pertains to only a single sub-activity, it is
+ presented within that sub-activity.
+
+
+
+ There are direct relationships between the CC structure
+ (i.e. class, family, component and element) and the structure
+ of the CEM. Figure illustrates the correspondence
+ between the CC constructs of class, family and evaluator
+ action elements and CEM activities, sub-activities and
+ actions. However, several CEM work units may result from the
+ requirements noted in CC developer action and content and
+ presentation elements.
+
+
+
+
+ For the purposes of this document, the following terms and
+ definitions apply.
+
+ Terms which are presented in bold-faced type are themselves
+ defined in this Subclause.
+
+
+ action
+
+
+ evaluator action element of the CC Part 3. These actions are
+ either explicitly stated as evaluator actions or implicitly
+ derived from developer actions (implied evaluator actions)
+ within the CC Part 3 assurance components.
+
+
+
+
+ activity
+
+
+ the application of an assurance class of the CC Part 3.
+
+
+
+
+ check
+
+ to generate a verdict by a simple
+ comparison. Evaluator expertise is not required. The statement
+ that uses this verb describes what is mapped.
+
+
+
+ evaluation deliverable
+
+
+ any resource required from the sponsor or developer by the
+ evaluator or evaluation authority to perform one or more evaluation or
+ evaluation oversight activities.
+
+
+
+ evaluation evidence
+
+ a tangible evaluation
+ deliverable.
+
+
+
+ evaluation technical report
+
+
+ a report that documents the overall verdict and its
+ justification, produced by the evaluator and submitted to an
+ evaluation authority.
+
+
+
+ examine
+
+ to generate a verdict by analysis using
+ evaluator expertise. The statement that uses this verb
+ identifies what is analysed and the properties for which it is
+ analysed.
+
+
+
+ interpretation
+
+ a clarification or amplification of a CC, CEM or
+ scheme requirement.
+
+
+
+ methodology
+
+ the system of principles, procedures and processes
+ applied to IT security evaluations.
+
+
+
+ observation report
+
+ a report written by the evaluator requesting a
+ clarification or identifying a problem during the
+ evaluation.
+
+
+
+ overall verdict
+
+ a pass or fail statement issued by an
+ evaluator with respect to the result of an
+ evaluation.
+
+
+
+ oversight verdict
+
+
+ a statement issued by an evaluation authority confirming or rejecting an
+ overall verdict based on the results of
+ evaluation oversight activities.
+
+
+
+ record
+
+ to retain a written description of procedures, events,
+ observations, insights and results in sufficient detail to
+ enable the work performed during the evaluation to be
+ reconstructed at a later time.
+
+
+
+ report
+
+ to include evaluation results and supporting material
+ in the Evaluation Technical Report or an
+ Observation Report.
+
+
+
+ scheme
+
+ set of rules, established by an evaluation authority,
+ defining the evaluation environment, including criteria and
+ methodology required to conduct IT security
+ evaluations.
+
+
+
+ sub-activity
+
+
+ the application of an assurance component of the CC Part
+ 3. Assurance families are not explicitly addressed in the CEM
+ because evaluations are conducted on a single assurance
+ component from an assurance family.
+
+
+
+
+ tracing
+
+ a simple directional relation between two sets of
+ entities, which shows which entities in the first set
+ correspond to which entities in the second.
+
+
+
+ verdict
+
+ a pass, fail or inconclusive
+ statement issued by an evaluator with respect to a CC
+ evaluator action element, assurance component, or class. Also
+ see overall verdict.
+
+
+
+ work unit
+
+
+ the most granular level of evaluation work. Each CEM action
+ comprises one or more work units, which are grouped within the
+ CEM action by CC content and presentation of evidence or
+ developer action element. The work units are presented in the
+ CEM in the same order as the CC elements from which they are
+ derived. Work units are identified in the left margin by a
+ symbol such as . In
+ this symbol, the string indicates the CC component (i.e. the CEM
+ sub-activity), and the final digit (2)
+ indicates that this is the second work unit in the sub-activity.
+
+
+
+
+
+ The target audience for the Common Methodology for Information
+ Technology Security Evaluation (CEM) is primarily evaluators
+ applying the CC and certifiers confirming evaluator actions;
+ evaluation sponsors, developers, PP/ST authors and other parties
+ interested in IT security may be a secondary audience.
+
+ The CEM recognises that not all questions concerning IT security
+ evaluation will be answered herein and that further
+ interpretations will be needed. Individual schemes will
+ determine how to handle such interpretations, although these may
+ be subject to mutual recognition agreements. A list of
+ methodology-related activities that may be handled by individual
+ schemes can be found in .
+
+
+
+
+ Clause defines the
+ conventions used in the CEM.
+
+ Clause
+ describes general evaluation tasks with no verdicts associated
+ with them as they do not map to CC evaluator action
+ elements.
+
+ Clause addresses the work
+ necessary for reaching an evaluation result on a PP.
+
+ Clauses to define the evaluation activities, organised by
+ Assurance Classes.
+
+ covers the basic
+ evaluation techniques used to provide technical evidence of
+ evaluation results.
+
+ provides an explanation
+ of the Vulnerability Analysis criteria and examples of their
+ application
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CC
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+
+
+
+
+ The Common Methodology for Information Technology Security
+ Evaluation (CEM) is a companion document to the Common Criteria
+ for Information Technology Security Evaluation (CC). The CEM
+ defines the minimum actions to be performed by an evaluator in
+ order to conduct a CC evaluation, using the criteria and
+ evaluation evidence defined in the CC.
+ The CEM does not define evaluator actions for certain high
+ assurance CC components, where there is as yet no generally
+ agreed guidance.
+
+
+
+ CEM
+
+ Common Methodology for Information Technology Security
+ Evaluation
+
+
+
+ ETR
+
+ Evaluation Technical Report
+
+
+
+ OR
+
+ Observation Report
+
+
+
+
+ For the purpose of this document, the following terms and
+ definitions apply.
+ This Clause contains only
+ those terms which are used in a specialised way throughout the
+ CC. Some combinations of common terms used in the CC, while
+ not meriting inclusion in this Clause , are explained for clarity in the context where
+ they are used.
+ adverse actions
+
+ actions performed by a threat agent on an asset.
+
+
+ assets
+
+
+ entities that the owner of the TOE presumably places value
+ upon.
+
+
+
+ assignment
+
+
+ the specification of an identified parameter in a component
+ (of the CC) or requirement.
+
+
+
+ assurance
+
+
+ grounds for confidence that a TOE meets the SFRs.
+
+
+
+ attack potential
+
+
+ a measure of the effort to be expended in attacking a TOE,
+ expressed in terms of an attacker's expertise, resources and
+ motivation.
+
+
+
+ augmentation
+
+
+ the addition of one or more requirement(s) to a package.
+
+
+ authentication data
+
+ information used to verify the claimed identity of a user.
+
+
+ authorised user
+
+ a user who may, in accordance with the SFRs, perform an
+ operation.
+
+
+ can
+
+ within normative text, ``can'' indicates ``statements of
+ possibility and capability, whether material, physical or
+ causal'' (ISO/IEC Directives, Part 2).
+
+
+ class
+
+
+ a grouping of CC families that share a common focus.
+
+
+
+ coherent
+
+
+ an entity is logically ordered and has a discernible
+ meaning. For documentation, this addresses both the actual
+ text and the structure of the document, in terms of whether it
+ is understandable by its target audience.
+
+
+
+ complete
+
+
+ all necessary parts of an entity have been provided. In terms
+ of documentation, this means that all relevant information is
+ covered in the documentation, at such a level of detail that
+ no further explanation is required at that level of
+ abstraction.
+
+
+
+ component
+
+
+ the smallest selectable set of elements on which requirements
+ may be based.
+
+
+
+ component TOE
+
+
+ an evaluated TOE that is part of another TOE.
+
+
+
+ composed assurance package (CAP)
+
+
+ an assurance package, consisting of requirements drawn from CC
+ Part 3 (predominately from the
+ class), representing a point on the CC predefined composition
+ assurance scale.
+
+
+
+ confirm
+
+
+ this term is used to indicate that something needs to be
+ reviewed in detail, and that an independent determination of
+ sufficiency needs to be made. The level of rigour required
+ depends on the nature of the subject matter. This term is only
+ applied to evaluator actions.
+
+
+ conformance
+ in reference to protection profiles, CC defines two types of conformance:
+ strict conformance: there exists a
+ very strict relation between the PP and the ST. This
+ relation can be roughly defined as ``the ST shall contain
+ all statements that are in the PP, but may contain
+ more''. Strict conformance is expected to be used for
+ stringent requirements that are to be adhered to in a
+ single manner;
+ demonstrable conformance: there is
+ no subset-superset type relation between the PP and the
+ ST. The PP and the ST may contain entirely different
+ statements that discuss different entities, use
+ different concepts etc. Demonstrable conformance is
+ also suitable for a TOE type where several similar PPs
+ already exist (or likely to exist in the future), thus
+ allowing the ST author to claim conformance to all these
+ PPs simultaneously, thereby saving work.
+
+ connectivity
+
+ the property of the TOE which allows interaction with IT
+ entities external to the TOE. This includes exchange of data by
+ wire or by wireless means, over any distance in any environment
+ or configuration.
+
+
+
+ consistent
+
+
+ this term describes a relationship between two or more
+ entities, indicating that there are no apparent contradictions
+ between these entities.
+
+
+
+ counter (verb)
+
+
+ this term is typically used when the impact of a particular
+ threat is mitigated but not necessarily eradicated.
+
+
+
+ demonstrate
+
+
+ this term refers to an analysis leading to a conclusion, which
+ is less rigorous than a ``proof''.
+
+
+
+ dependency
+
+
+ a relationship between components such that if a requirement
+ based on the depending component is included in a PP, ST or
+ package, a requirement based on the component that is depended
+ upon must normally also be included in the PP, ST or package.
+
+
+
+ describe
+
+
+ this term requires that specific details of an entity be
+ provided.
+
+
+
+ determine
+
+
+ this term requires an independent analysis to be made, with
+ the objective of reaching a particular conclusion. The usage
+ of this term differs from ``confirm'' or ``verify'', since
+ these other terms imply that an analysis has already been
+ performed which needs to be reviewed, whereas the usage of
+ ``determine'' implies a truly independent analysis, usually in
+ the absence of any previous analysis having been performed.
+
+
+
+ development environment
+
+
+ the environment in which the TOE is developed.
+
+
+
+ element
+
+
+ an indivisible statement of security need.
+
+
+
+ ensure
+
+
+ this term, used by itself, implies a strong causal
+ relationship between an action and its consequences. When this
+ term is preceded by the word ``helps'' it indicates that the
+ consequence is not fully certain, on the basis of that action
+ alone.
+
+
+
+ evaluation
+
+
+ assessment of a PP, an ST or a TOE, against defined criteria.
+
+
+
+ evaluation assurance level (EAL)
+
+
+ an assurance package, consisting of assurance requirements
+ drawn from CC Part 3, representing a point on the CC
+ predefined assurance scale.
+
+
+
+ evaluation authority
+
+
+ a body that implements the CC for a specific community by
+ means of an evaluation scheme and thereby sets the standards
+ and monitors the quality of evaluations conducted by bodies
+ within that community.
+
+
+
+ evaluation scheme
+
+
+ the administrative and regulatory framework under which the CC
+ is applied by an evaluation authority within a specific
+ community.
+
+
+
+ exhaustive
+
+
+ this term is used in the CC with respect to conducting an
+ analysis or other activity. It is related to ``systematic''
+ but is considerably stronger, in that it indicates not only
+ that a methodical approach has been taken to perform the
+ analysis or activity according to an unambiguous plan, but
+ that the plan that was followed is sufficient to ensure that
+ all possible avenues have been exercised.
+
+
+
+ explain
+
+
+ this term differs from both ``describe'' and
+ ``demonstrate''. It is intended to answer the question
+ ``Why?'' without actually attempting to argue that the course
+ of action that was taken was necessarily optimal.
+
+
+ extension
+
+ the addition to an ST or PP of functional requirements not
+ contained in Part 2 and/or assurance requirements not
+ contained in Part 3 of the CC.
+
+
+
+ external entity
+
+
+ any entity (human or IT) outside the TOE that interacts
+ (or may interact) with the TOE.
+
+
+
+ family
+
+
+ a grouping of components that share a similar goal but may
+ differ in emphasis or rigour.
+
+
+
+ formal
+
+
+ expressed in a restricted syntax language with defined
+ semantics based on well-established mathematical concepts.
+
+
+
+ guidance documentation
+
+
+ documentation that describes the delivery, preparation,
+ operation, management and/or use of the TOE.
+
+
+ identity
+
+ a representation (e.g. a string) uniquely identifying an
+ authorised user, which can either be the full or abbreviated
+ name of that user or a pseudonym.
+
+
+
+ informal
+
+
+ expressed in natural language.
+
+
+ informative
+
+ informative text ``provides additional information intended to
+ assist the understanding or use of the document.'' (ISO/IEC Directives, Part 2).
+
+ inter-TSF transfers
+
+ communicating data between the TOE and the security
+ functionality of other trusted IT products.
+
+
+ internal communication channel
+
+ a communication channel between separated parts of the TOE.
+
+
+ internal TOE transfer
+
+ communicating data between separated parts of the TOE.
+
+
+
+ internally consistent
+
+
+ this term means that there are no apparent contradictions
+ between any aspects of an entity. In terms of documentation,
+ this means that there can be no statements within the
+ documentation that can be taken to contradict each other.
+
+
+
+ iteration
+
+
+ the use of the same component to express two or more distinct
+ requirements.
+
+
+
+ justification
+
+
+ this term refers to an analysis leading to a conclusion, but
+ is more rigorous than a demonstration. This term requires
+ significant rigour in terms of very carefully and thoroughly
+ explaining every step of a logical argument.
+
+
+ may
+
+ within normative text, ``may'' indicates ``a course of action
+ permissible within the limits of the document'' (ISO/IEC Directives, Part 2).
+
+ normative
+
+ normative text ``describes the scope of the document, and sets
+ out provisions.'' (ISO/IEC Directives, Part 2). Within normative text, the verbs ``shall'',
+ ``should'', ``may'', and ``can'' have the ISO standard meanings
+ described in this glossary and the verb ``must'' is not
+ used. Unless explicitly labelled ``informative'', all CC text is
+ normative.
+
+
+ object
+
+
+ a passive entity in the TOE, that contains or receives
+ information, and upon which subjects perform operations.
+
+
+
+ operation (on a component of the CC)
+
+
+ modifying or repeating that component. Allowed operations on
+ components are assignment, iteration, refinement and
+ selection.
+
+
+
+ operation (on an object)
+
+
+ a specific type of action performed by a subject on an object.
+
+
+
+ operational environment
+
+
+ the environment in which the TOE is operated.
+
+
+
+ organisational security policy (OSP)
+
+
+ a set of security rules, procedures, or guidelines imposed (or
+ presumed to be imposed) now and/or in the future by an actual
+ or hypothetical organisation in the operational environment.
+
+
+
+ package
+
+
+ a named set of either functional or assurance requirements
+ (e.g. EAL 3).
+
+
+
+ PP evaluation
+
+
+ assessment of a PP against defined criteria.
+
+
+
+ Protection Profile (PP)
+
+
+ an implementation-independent statement of security needs for
+ a TOE type.
+
+
+
+ prove
+
+
+ this term refers to a formal analysis in its mathematical
+ sense. It is completely rigorous in all ways. Typically,
+ ``prove'' is used when there is a desire to show
+ correspondence between two TSF representations at a high level
+ of rigour.
+
+
+
+ refinement
+
+
+ the addition of details to a component.
+
+
+ role
+
+ a predefined set of rules establishing the allowed
+ interactions between a user and the TOE.
+
+
+ secret
+
+ information that must be known only to authorised users
+ and/or the TSF in order to enforce a specific SFP.
+
+
+ secure state
+
+ a state in which the TSF data are consistent and the TSF
+ continues correct enforcement of the SFRs.
+
+
+
+ security attribute
+
+
+ a property of subjects, users (including external IT products),
+ objects, information, sessions and/or resources that is used in
+ defining the SFRs and whose values are used in enforcing the
+ SFRs.
+
+
+ security function policy (SFP)
+
+ a set of rules describing specific security behaviour enforced
+ by the TSF and expressible as a set of SFRs.
+
+
+
+ security objective
+
+
+ a statement of intent to counter identified threats and/or
+ satisfy identified organisation security policies and/or
+ assumptions.
+
+ security problem
+ with reference to the TOE and its operational environment the combination of threats countered by the TOE, OSPs enforced by the TOE and assumptions that are upheld.
+ security requirement
+ the translation of the security objectives for the TOE into a standardised language.
+
+
+ Security Target (ST)
+
+
+ an implementation-dependent statement of security needs for a
+ specific identified TOE.
+
+
+
+ selection
+
+
+ the specification of one or more items from a list in a
+ component.
+
+
+
+ semiformal
+
+
+ expressed in a restricted syntax language with defined
+ semantics.
+
+
+ shall
+
+ within normative text, ``shall'' indicates ``requirements
+ strictly to be followed in order to conform to the document
+ and from which no deviation is permitted.'' (ISO/IEC Directives, Part 2).
+
+ should
+
+ within normative text, ``should'' indicates ``that among
+ several possibilities one is recommended as particularly
+ suitable, without mentioning or excluding others, or that a
+ certain course of action is preferred but not necessarily
+ required.'' (ISO/IEC Directives, Part 2). The CC
+ interprets 'not necessarily required' to mean that the choice
+ of another possibility requires a justification of why the
+ preferred option was not chosen.
+
+
+ specify
+
+
+ this term is used in the same context as ``describe'', but is
+ intended to be more rigorous and precise. It is very similar
+ to ``define''.
+
+
+
+ ST evaluation
+
+
+ assessment of an ST against defined criteria.
+
+
+
+ subject
+
+
+ an active entity in the TOE that performs operations on
+ objects.
+
+
+ target of evaluation (TOE)
+
+ a set of software, firmware and/or hardware possibly
+ accompanied by guidance.
+
+ threat agent
+
+ threat agents are entities that can adversely act on assets.
+
+
+ TOE evaluation
+
+
+ assessment of a TOE against defined criteria.
+
+
+ TOE resource
+
+ anything useable or consumable in the TOE.
+
+
+
+ TOE Security Functionality (TSF)
+
+
+ a set consisting of all hardware, software, and firmware of
+ the TOE that must be relied upon for the correct enforcement
+ of the SFRs.
+
+
+
+ trace (verb)
+
+
+ this term is used to indicate that an informal correspondence
+ is required between two entities with only a minimal level of
+ rigour.
+
+ transfers outside of the TOE
+ the TSF mediated communication of data to entities not under control
+ of the TSF.
+
+ trusted channel
+
+ a means by which a TSF and another trusted IT product can
+ communicate with necessary confidence.
+
+
+ trusted IT product
+
+ an IT product other than the TOE which has its security
+ functional requirements administratively coordinated with
+ the TOE and which is assumed to enforce its security functional
+ requirements correctly (e. g. by being separately evaluated).
+
+
+ trusted path
+
+ a means by which a user and a TSF can communicate with
+ necessary confidence.
+
+
+ TSF data
+
+ data for the operation of the TOE upon which the enforcement of
+ the SFRs relies.
+
+
+
+ TSF interface (TSFI)
+
+
+ a means by which external entities (or subjects in the TOE but
+ outside of the TSF) supply data to the TSF, receive data from
+ the TSF and invoke services from the TSF.
+
+ user
+ see external entity.
+
+ user data
+
+ data for the user, that does not affect the operation of the
+ TSF.
+
+
+
+ verify
+
+
+ this term is similar in context to ``confirm'', but has more
+ rigorous connotations. This term when used in the context of
+ evaluator actions indicates that an independent effort is
+ required of the evaluator.
+
+
+
+ The following terms are used in the requirements for software
+ internal structuring. Some of these are derived from the
+ Institute of Electrical and Electronics Engineers
+ Glossary of software engineering terminology, IEEE Std
+ 610.12-1990.
+
+
+ administrator
+
+
+ an entity that has complete trust with respect to all
+ policies implemented by the TSF.
+
+
+
+ call tree
+
+ a diagram that identifies the modules in a system and shows
+ which modules call one another. All the modules named in a
+ call tree that originates with (i.e., is rooted by) a
+ specific module are the modules that directly or indirectly
+ implement the functions of the originating module.
+
+
+
+ cohesion (also called module strength)
+ the manner and degree to which the tasks performed by a single software module are related to one another.
+
+
+
+
+ complexity
+
+ this is a measure of how difficult software is to
+ understand, and thus to analyse, test, and
+ maintain. Reducing complexity is the ultimate goal for using
+ modular decomposition, layering and
+ minimisation. Controlling coupling and cohesion contributes
+ significantly to this goal.
+
+ A good deal of effort in the software engineering field
+ has been expended in attempting to develop metrics to
+ measure the complexity of source code. Most of these
+ metrics use easily computed properties of the source code,
+ such as the number of operators and operands, the
+ complexity of the control flow graph (cyclomatic
+ complexity), the number of lines of source code, the ratio
+ of comments to executable code, and similar
+ measures. Coding standards have been found to be a useful
+ tool in generating code that is more readily
+ understood.
+
+ This family calls for a
+ complexity analysis in all components. It
+ is expected that the developer will provide support for
+ the claims that there has been a sufficient reduction in
+ complexity. This support could include the developer's
+ programming standards, and an indication that all modules
+ meet the standard (or that there are some exceptions that
+ are justified by software engineering arguments). It could
+ include the results of tools used to measure some of the
+ properties of the source code. Or it could include other
+ support that the developer finds appropriate.
+
+
+
+ coupling
+ the manner and degree of interdependence between software modules.
+
+
+ domain separation
+
+ the security architecture property whereby the TSF defines
+ separate security domains for each user and for the TSF and
+ ensures that no user process can affect the contents of a
+ security domain of another user or of the TSF.
+
+
+
+
+ interaction
+
+ a general communication-based relationship between entities.
+
+
+
+ interface
+
+ a means of interaction with a component or module.
+
+
+
+ layering
+
+ the design of software such that separate groups of modules
+ (the layers) are hierarchically organised
+ to have separate responsibilities such that one layer
+ depends only on layers below it in the hierarchy for
+ services, and provides its services only to the layers above
+ it. Strict layering adds the constraint that each layer
+ receives services only from the layer immediately beneath
+ it, and provides services only to the layer immediately
+ above it.
+
+
+
+
+ modular decomposition
+
+ the process of breaking a system into components to
+ facilitate design and development.
+
+
+
+ non-bypassability (of the TSF)
+
+ the security architecture property whereby all SFR-related
+ actions are mediated by the TSF.
+
+
+
+ security domain
+
+ the collection of resources to which an active entity has
+ access.
+
+
+
+
+ software engineering
+
+ the application of a systematic, disciplined, quantifiable
+ approach to the development, operation, and maintenance of
+ software; that is, the application of engineering to
+ software. As with engineering practises in general, some
+ amount of judgement must be used in applying engineering
+ principles. Many factors affect choices, not just the
+ application of measures of modular decomposition, layering,
+ and minimisation. For example, a developer may design a
+ system with future applications in mind that will not be
+ implemented initially. The developer may choose to include
+ some logic to handle these future applications without fully
+ implementing them; further, the developer may include some
+ calls to as-yet unimplemented modules, leaving call
+ stubs. The developer's justification for such deviations
+ from well-structured programs will have to be assessed using
+ judgement, as well as the application of good software
+ engineering discipline.
+
+
+
+
+ TSF self-protection
+
+ the security architecture property whereby the TSF cannot be
+ corrupted by non-TSF code or entities.
+
+
+
+
+
+
+ installation
+
+
+ the procedures that the user has to perform normally only once
+ after receipt and acceptance of the TOE to progress it to the
+ secure configuration as described in the ST including the
+ embedding of the TOE in its operational environment. If
+ similar processes have to be performed by the developer they
+ are denoted as ``generation'' throughout . If the TOE requires an initial start-up that does
+ not need to be repeated regularly, this process would be
+ classified as installation here.
+
+
+
+
+ operation
+
+
+ the usage phase of the TOE. This includes ``normal usage'',
+ administration and maintenance of the TOE.
+
+
+
+
+ operation (of the TOE)
+
+
+ usage of the TOE after delivery and preparation.
+
+
+
+
+ preparation
+
+
+ the product life-cycle phase comprising the customer's
+ acceptance of the delivered TOE and its installation which
+ may include such things as booting, initialisation,
+ start-up, progressing the TOE to a state ready for
+ operation.
+
+
+
+
+
+ acceptance criteria
+
+
+ the criteria to be applied when performing the acceptance
+ procedures (e.g. successful document review, or successful
+ testing in the case of software, firmware or hardware).
+
+
+
+
+ acceptance procedures
+
+
+ the procedures followed in order to accept newly created or
+ modified configuration items as part of the TOE, or to move
+ them to the next step of the life-cycle. These procedures
+ identify the roles or individuals responsible for the
+ acceptance and the criteria to be applied to decide on the
+ acceptance.
+
+ There are several types of acceptance situations some of
+ which may overlap:
+
+
+ acceptance of an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers into
+ the TOE (``integration'');
+
+
+ progression of configuration items to the next
+ life-cycle phase at each stage of the construction of
+ the TOE (e.g. module, subsystem, quality control of
+ the finished TOE);
+
+
+ subsequent to transports of configuration items (for
+ example parts of the TOE or preliminary products)
+ between different development sites;
+
+
+ subsequent to the delivery of the TOE to the consumer.
+
+
+
+
+
+
+ CM documentation (documentation of the CM system)
+
+
+ overall term for the following:
+
+
+ CM output
+
+
+ CM list (configuration list)
+
+
+ CM system records
+
+
+
+
+ CM plan
+
+
+ CM usage documentation
+
+
+
+
+
+
+ CM evidence
+
+
+ everything that may be used to establish confidence in the
+ correct operation of the CM system, e.g., CM output,
+ rationales provided by the developer, observations,
+ experiments or interviews made by the evaluator during a
+ site visit.
+
+
+
+
+ CM item (configuration item)
+
+
+ object managed by the CM system during the TOE
+ development. These may be either parts of the TOE or objects
+ related to the development of the TOE like evaluation
+ documents or development tools. CM items may be stored in
+ the CM system directly (for example files) or by reference
+ (for example hardware parts) together with their version.
+
+
+
+
+ CM list (configuration list)
+
+
+ a CM output document listing all configuration items for a
+ specific product together with the exact version of each CM
+ item relevant for a specific version of the complete
+ product. This list allows distinguishing the items belonging
+ to the evaluated version of the product from other versions
+ of these items belonging to other versions of the
+ product. The final CM list is a specific document for a
+ specific version of a specific product. (Of course the list
+ can be an electronic document inside of a CM tool. In that
+ case it can be seen as a specific view into the system or a
+ part of the system rather than an output of the
+ system. However, for the practical use in an evaluation the
+ configuration list will probably be delivered as a part of
+ the evaluation documentation.) The configuration list
+ defines the items that are under the CM requirements of
+ .
+
+
+
+ CM output
+
+ the CM related results produced or enforced by the CM
+ system. These CM related results could occur as documents
+ (for example filled paper forms, CM system records, logging
+ data, hard-copies and electronic output data) as well as
+ actions (for example manual measures to fulfil CM
+ instructions). Examples of such CM outputs are configuration
+ lists, CM plans and/or behaviours during the product
+ life-cycle.
+
+
+
+ CM plan
+
+
+ part of the CM documentation describing how the CM system is
+ used for the TOE. The objective of issuing a CM plan is that
+ staff members can see clearly what they have to do. From the
+ point of view of the overall CM system this can be seen as
+ an output document (because it may be produced as part of
+ the application of the CM system). From the point of view of
+ the concrete project it is a usage document because members
+ of the project team use it in order to understand the steps
+ that they have to perform during the project. The CM plan
+ defines the usage of the system for the specific product;
+ the same system may be used to a different extent for other
+ products. That means the CM plan defines and describes the
+ output of the CM system of a company which is used during
+ the TOE development.
+
+
+
+
+ CM system
+
+
+ overall term for the set of procedures and tools (including
+ their documentation) used by a developer to develop and
+ maintain configurations of his products during their
+ life-cycles. CM systems may have varying degrees of rigour
+ and function. At higher levels, CM systems may be automated,
+ with flaw remediation, change controls, and other tracking
+ mechanisms.
+
+
+
+
+ CM system records
+
+
+ those CM output documents which are produced during the
+ operation of the CM system documenting important
+ activities. Examples of CM system records are CM item change
+ control forms or CM item access approval forms.
+
+
+
+
+ CM tools
+
+
+ tools realising or supporting a CM system, for example tools
+ for the version management of the parts of the TOE. They may
+ require manual operation or may be automated.
+
+
+
+
+ CM usage documentation
+
+
+ that part of the CM system, which describes, how the CM
+ system is defined and applied by using for example
+ handbooks, regulations and/or documentation of tools and
+ procedures.
+
+
+
+
+ delivery
+
+
+ the product life-cycle phase which is concerned with the
+ transmission of the finished TOE from the production
+ environment into the hands of the customer. This may include
+ packaging and storage at the development site, but does not
+ include transportations of the unfinished TOE or parts of
+ the TOE between different developers or different
+ development sites.
+
+
+
+
+ developer
+
+
+ the organisation responsible for the development of the TOE.
+
+
+
+
+ development
+
+
+ the product life-cycle phase which is concerned with
+ generating the implementation representation of the
+ TOE. Throughout the requirements,
+ development and related terms (developer, develop) are meant
+ in the more general sense to comprise development
+ and production.
+
+
+
+
+ development tools
+
+
+ tools (including test software, if applicable) supporting
+ the development and production of the TOE. E.g., for a
+ software TOE, development tools are usually programming
+ languages, compilers, linkers and generating tools.
+
+
+
+
+ implementation representation
+
+
+ the least abstract representation of the TSF, specifically
+ the one that is used to create the TSF itself without
+ further design refinement. Source code that is then compiled
+ or a hardware drawing that is used to build the actual
+ hardware are examples of parts of an implementation
+ representation.
+
+
+
+
+ life-cycle
+
+
+ the sequence of stages of existence of an object (for
+ example a product or a system) in time.
+
+
+
+
+ life-cycle definition
+
+
+ the definition of the life-cycle model.
+
+
+
+
+ life-cycle model
+
+
+ description of the stages and their relations to each other
+ that are used in the management of the life-cycle of a
+ certain object, how the sequence of stages looks like and
+ which high level characteristics the stages have.
+
+
+
+
+ measurable life-cycle model
+
+
+ a life-cycle model using some quantitative valuation
+ (arithmetic parameters and/or metrics) of the managed
+ product in order to measure development properties of the
+ product. Typical metrics are source code complexity metrics,
+ defect density (errors per size of code) or mean time to
+ failure.
+
+
+
+
+ production
+
+
+ the production life-cycle phase follows the development
+ phase and consists of transforming the implementation
+ representation into the implementation of the TOE, i.e. into
+ a state acceptable for delivery to the customer. This phase
+ may comprise manufacturing, integration, generation,
+ internal transports, storage, and labelling of the TOE.
+
+
+
+
+
+
+ covert channel
+
+
+ an enforced, illicit signalling channel that allows a user to
+ surreptitiously contravene the multi-level separation policy
+ and unobservability requirements of the TOE (this is a special
+ case of monitoring attacks).
+
+
+
+
+ encountered potential vulnerabilities
+
+
+ potential weakness in the TOE identified by the evaluator
+ while performing evaluation activities that could be used to
+ violate the SFRs.
+
+
+
+
+ exploitable vulnerability
+
+
+ a weakness in the TOE that can be used to violate the SFRs
+ in the operational environment for the TOE.
+
+
+
+
+ monitoring attacks
+
+
+ a generic category of attack methods that includes passive
+ analysis techniques aiming at disclosure of sensitive internal
+ data of the TOE by operating the TOE in the way that
+ corresponds to the guidance documents.
+
+
+
+
+ potential vulnerability
+
+
+ a weakness the existence of which is suspected (by virtue of
+ a postulated attack path), but not confirmed, to violate the
+ SFRs.
+
+
+
+
+ residual vulnerability
+
+
+ a weakness that cannot be exploited in the operational
+ environment for the TOE, but that could be used to violate
+ the SFRs by an attacker with greater attack potential than
+ is anticipated in the operational environment for the TOE.
+
+
+
+
+ vulnerability
+
+
+ a weakness in the TOE that can be used to violate the SFRs
+ in some environment.
+
+
+
+
+
+ base component
+
+
+ the entity in a composed TOE, which has itself been the
+ subject of an evaluation, providing services and resources
+ to a dependent component.
+
+
+
+
+ compatible (components)
+
+
+ one component providing the services required by the other
+ component, through the corresponding interfaces of each
+ component, in consistent operational environments.
+
+
+
+
+ composed TOE
+
+
+ comprised solely of two or more components that have been
+ successfully evaluated.
+
+
+
+
+ dependent component
+
+
+ an entity in a composed TOE, which is itself the subject of
+ an evaluation, relying on the provision on services by a
+ base component.
+
+
+
+
+ functional interface
+
+
+ the (external) interfaces that provide a user with access to
+ functionality of the TOE that is not directly involved in
+ enforcing security functional requirements. In a composed
+ TOE these are the interfaces provided by the base component
+ that are required by the dependent component to support the
+ operation of the composed TOE.
+
+
+
+
+
+ Table describes the
+ relationship between the evaluation assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Evaluation Assurance Levels (EALs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance. The
+ CC approach identifies the separate concepts of assurance in a
+ TOE at the end of the evaluation, and of maintenance of that
+ assurance during the operational use of the TOE.
+
+ It is important to note that not all families and components
+ from CC Part 3 are included in the EALs. This is not to say that
+ these do not provide meaningful and desirable
+ assurances. Instead, it is expected that these families and
+ components will be considered for augmentation of an EAL in
+ those PPs and STs for which they provide utility.
+
+
+ Table represents a summary
+ of the EALs. The columns represent a hierarchically ordered
+ set of EALs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, seven hierarchically
+ ordered evaluation assurance levels are defined in the CC for
+ the rating of a TOE's assurance. They are hierarchically
+ ordered inasmuch as each EAL represents more assurance than
+ all lower EALs. The increase in assurance from EAL to EAL is
+ accomplished by substitution of a hierarchically higher
+ assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements).
+
+ These EALs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each EAL includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ While the EALs are defined in the CC, it is possible to
+ represent other combinations of assurance. Specifically, the
+ notion of ``augmentation'' allows the addition of assurance
+ components (from assurance families not already included in
+ the EAL) or the substitution of assurance components (with
+ another hierarchically higher assurance component in the same
+ assurance family) to an EAL. Of the assurance constructs
+ defined in the CC, only EALs may be augmented. The notion of
+ an ``EAL minus a constituent assurance component'' is not
+ recognised by the standard as a valid claim. Augmentation
+ carries with it the obligation on the part of the claimant to
+ justify the utility and added value of the added assurance
+ component to the EAL. An EAL may also be augmented with
+ extended assurance requirements.
+
+
+
+
+ The following Subclauses provide definitions of the EALs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ The objective of this clause is to cover general guidance
+ used to provide technical evidence of evaluation results. The
+ use of such general guidance helps in achieving objectivity,
+ repeatability and reproducibility of the work performed by the
+ evaluator.
+
+
+
+ This Subclause provides general guidance on sampling. Specific
+ and detailed information is given in those work units under
+ the specific evaluator action elements where sampling has to
+ be performed.
+
+ Sampling is a defined procedure of an evaluator whereby some
+ subset of a required set of evaluation evidence is examined
+ and assumed to be representative for the entire set. It allows
+ the evaluator to gain enough confidence in the correctness of
+ particular evaluation evidence without analysing the whole
+ evidence. The reason for sampling is to conserve resources
+ while maintaining an adequate level of assurance. Sampling of
+ the evidence can provide two possible outcomes:
+
+
+ The subset reveals no errors, allowing the evaluator to
+ have some confidence that the entire set is correct.
+
+
+ The subset reveals errors and therefore the validity of
+ the entire set is called into question. Even the
+ resolution of all errors that were found may be
+ insufficient to provide the evaluator the necessary
+ confidence and as a result the evaluator may have to
+ increase the size of the subset, or stop using sampling
+ for this particular evidence.
+
+
+
+ Sampling is a technique which can be used to reach a reliable
+ conclusion if a set of evidence is relatively homogeneous in
+ nature, e.g. if the evidence has been produced during a well
+ defined process.
+
+ Sampling in the cases identified in the CC, and in cases
+ specifically covered in CEM work items, is recognised as a
+ cost-effective approach to performing evaluator
+ actions. Sampling in other areas is permitted only in
+ exceptional cases, where performance of a particular activity
+ in its entirety would require effort disproportionate to the
+ other evaluation activities, and where this would not add
+ correspondingly to assurance. In such cases a rationale for
+ the use of sampling in that area will need to be made. Neither
+ the fact that the TOE is large and complex, nor that it has
+ many security functional requirements, is sufficient
+ justification, since evaluations of large, complex TOEs can be
+ expected to require more effort. Rather it is intended that
+ this exception be limited to cases such as that where the TOE
+ development approach yields large quantities of material for a
+ particular CC requirement that would normally all need to be
+ checked or examined, and where such an action would not be
+ expected to raise assurance correspondingly.
+
+ Sampling needs to be justified taking into account the
+ possible impact on the security objectives and threats of the
+ TOE. The impact depends on what might be missed as a result of
+ sampling. Consideration also needs to be given to the nature
+ of the evidence to be sampled, and the requirement not to
+ diminish or ignore any security functions.
+
+ It should be recognised that sampling of evidence directly
+ related to the implementation of the TOE (e.g. developer test
+ results) requires a different approach to sampling, then
+ sampling related to the determination of whether a process is
+ being followed. In many cases the evaluator is required to
+ determine that a process is being followed, and a sampling
+ strategy is recommended. The approach for sampling a
+ developer's test results will differ. This is because the
+ former case is concerned with ensuring that a process is in
+ place, and the latter deals with determining correct
+ implementation of the TOE. Typically, larger sample sizes
+ should be analysed in cases related to the correct
+ implementation of the TOE than would be necessary to ensure
+ that a process is in place.
+
+ In certain cases it may be appropriate for the evaluator to
+ give greater emphasis to the repetition of developer
+ testing. For example if the independent tests left for the
+ evaluator to perform would be only superficially different
+ from those included in an extensive developer test set
+ (possibly because the developer has performed more testing
+ than necessary to satisfy the
+ and criteria) then it would
+ be appropriate for the evaluator to give greater focus to the
+ repetition of developer tests. Note that this does not
+ necessarily imply a requirement for a high percentage sample
+ for repetition of developer tests; indeed, given an extensive
+ developer test set, the evaluator may be able to justify a low
+ percentage sample.
+
+ Where the developer has used an automated test suite to
+ perform functional testing, it will usually be easier for the
+ evaluator to re-run the entire test suite rather than repeat
+ only a sample of developer tests. However the evaluator does
+ have an obligation to check that the automatic testing does
+ not give misrepresentative results. The implication is thus
+ that this check must be performed for a sample of the
+ automatic test suite, with the principles for selecting some
+ tests in preference to others and ensuring a sufficient sample
+ size applying equally in this case.
+
+ The following principles should be followed whenever sampling
+ is performed:
+
+
+ Sampling should not be random, rather it should be chosen
+ such that it is representative of all of the evidence. The
+ sample size and composition must always be justified.
+
+
+ When sampling relates to the correct implementation of the
+ TOE, the sample should be representative of all aspects
+ relevant to the areas that are sampled. In particular, the
+ selection should cover a variety of components,
+ interfaces, developer and operational sites (if more than
+ one is involved) and hardware platform types (if more than
+ one is involved). The sample size should be commensurate
+ with the cost effectiveness of the evaluation and will
+ depend on a number of TOE dependent factors (e.g. the size
+ and complexity of the TOE, the amount of documentation).
+
+
+ Also, when sampling relates to specifically gaining
+ evidence that the developer testing is repeatable and
+ reproducible the sample used must be sufficient to
+ represent all distinct aspects of developer testing, such
+ as different test regimes. The sample used must be
+ sufficient to detect any systematic problem in the
+ developer's functional testing process. The evaluator
+ contribution resulting from the combination of repeating
+ developer tests and performing independent tests must be
+ sufficient to address the major points of concern for the
+ TOE.
+
+
+ Where sampling relates to gaining evidence that a process
+ (e.g. visitor control or design review) the evaluator
+ should sample sufficient information to gain reasonable
+ confidence that the procedure is being followed.
+
+
+ The sponsor and developer should not be informed in
+ advance of the exact composition of the sample, subject to
+ ensuring timely delivery of the sample and supporting
+ deliverable, e.g. test harnesses and equipment to the
+ evaluator in accordance with the evaluation schedule.
+
+
+ The choice of the sample should be free from bias to the
+ degree possible (one should not always choose the first or
+ last item). Ideally the sample selection should be done by
+ someone other than the evaluator.
+
+
+
+ Errors found in the sample can be categorised as being either
+ systematic or sporadic. If the error is systematic, the
+ problem should be corrected and a complete new sample
+ taken. If properly explained, sporadic errors might be solved
+ without the need for a new sample, although the explanation
+ should be confirmed. The evaluator should use judgement in
+ determining whether to increase the sample size or use a
+ different sample.
+
+
+
+ In general it is possible to perform the required evaluation
+ activities, sub-activities, and actions in any order or in
+ parallel. However, there are different kinds of dependencies
+ which have to be considered by the evaluator. This Subclause
+ provides general guidance on dependencies between different
+ activities, sub-activities, and actions.
+
+
+ For some cases the different assurance classes may recommend
+ or even require a sequence for the related activities. A
+ specific instance is the ST activity. The ST evaluation
+ activity is started prior to any TOE evaluation activities
+ since the ST provides the basis and context to perform
+ them. However, a final verdict on the ST evaluation may not
+ be possible until the TOE evaluation is complete, since
+ changes to the ST may result from activity findings during
+ the TOE evaluation.
+
+
+
+ Dependencies identified between components in CC Part 3 have
+ to be considered by the evaluator. Most dependencies are
+ one way, e.g. claims a
+ dependency on and . There are also instances of
+ mutual dependencies, where both components depend on each
+ other. An example of this is and .
+
+ A sub-activity can be assigned a pass verdict normally only
+ if all those sub-activities are successfully completed on
+ which it has a one-way dependency. For example, a pass
+ verdict on can normally
+ only be assigned if the sub-activities related to and are assigned a pass verdict too. In the case
+ of mutual dependency the ordering of these components is
+ down to the evaluator deciding which sub-activity to perform
+ first. Note this indicates that pass verdicts can normally
+ only be assigned once both sub-activities have been
+ successful.
+
+ So when determining whether a sub-activity will impact
+ another sub-activity, the evaluator should consider whether
+ this activity depends on potential evaluation results from
+ any dependent sub-activities. Indeed, it may be the case
+ that a dependent sub-activity will impact this sub-activity,
+ requiring previously completed evaluator actions to be
+ performed again.
+
+ A significant dependency effect occurs in the case of
+ evaluator-detected flaws. If a flaw is identified as a
+ result of conducting one sub-activity, the assignment of a
+ pass verdict to a dependent sub-activity may not be possible
+ until all flaws related to the sub-activity upon which it
+ depends are resolved.
+
+
+
+ It may be the case, that results which are generated by the
+ evaluator during one action are used for performing another
+ action. For example, actions for completeness and
+ consistency cannot be completed until the checks for content
+ and presentation have been completed. This means for example
+ that the evaluator is recommended to evaluate the PP/ST
+ rationale after evaluating the constituent parts of the
+ PP/ST.
+
+
+
+
+
+ The assurance class includes
+ requirements for
+
+
+ the application of configuration management, ensuring
+ that the integrity of the TOE is preserved;
+
+
+ measures, procedures, and standards concerned with
+ secure delivery of the TOE, ensuring that the security
+ protection offered by the TOE is not compromised during
+ the transfer to the user,
+
+
+ security measures, used to protect the development
+ environment.
+
+
+
+ A development site visit is a useful means whereby the
+ evaluator determines whether procedures are being followed
+ in a manner consistent with that described in the
+ documentation.
+
+ Reasons for visiting sites include:
+
+
+ to observe the use of the CM system as described in the
+ CM plan;
+
+
+ to observe the practical application of delivery
+ procedures as described in the delivery documentation;
+
+
+ to observe the application of security measures during
+ development and maintenance of the TOE as described in
+ the development security documentation.
+
+
+
+ Specific and detailed information is given in work units for
+ those activities where site visits are performed:
+
+
+ .n with n>=3
+ (especially work unit = = );
+
+
+ (especially work unit
+ );
+
+
+ (especially work unit
+ = ).
+
+
+
+
+
+ During an evaluation it is often necessary that the
+ evaluator will meet the developer more than once and it is a
+ question of good planning to combine the site visit with
+ another meeting to reduce costs. For example one might
+ combine the site visits for configuration management, for
+ the developer's security and for delivery. It may also be
+ necessary to perform more than one site visit to the same
+ site to allow the checking of all development phases. It
+ should be considered that development could occur at
+ multiple facilities within a single building, multiple
+ buildings at the same site, or at multiple sites.
+
+ The first site visit should be scheduled early during the
+ evaluation. In the case of an evaluation which starts during
+ the development phase of the TOE, this will allow corrective
+ actions to be taken, if necessary. In the case of an
+ evaluation which starts after the development of the TOE, an
+ early site visit could allow corrective measures to be put
+ in place if serious deficiencies in the applied procedures
+ emerge. This avoids unnecessary evaluation effort.
+
+ Interviews are also a useful means of determining whether the
+ written procedures reflect what is done. In conducting such
+ interviews, the evaluator aims to gain a deeper understanding of
+ the analysed procedures at the development site, how they are
+ used in practise and whether they are being applied as described
+ in the provided evaluation evidence. Such interviews complement
+ but do not replace the examination of evaluation
+ evidence.
+
+ As a first step preparing the site visits the evaluators
+ should perform the evaluator work units concerning the
+ assurance class excluding the
+ aspects describing the results of the site visit. Based on
+ the information provided by the relevant developer
+ documentation and the remaining open questions which were
+ not answered by the documentation the evaluators compile a
+ check list of the questions which are to be resolved by the
+ site visits.
+
+ The first version of the evaluation report concerning the
+ class and the check list serves
+ as input for the consultation with the evaluation authority
+ concerning the site visits.
+
+ The check list serve as a guide line for the site visits,
+ which questions are to be answered by inspection of the
+ relevant measures, their application and results, and by
+ interviews. Where appropriate, sampling is used for gaining
+ the required level of confidence (see Subclause ).
+
+ The results of the site visits are recorded and serve as
+ input for the final version of the evaluation report
+ concerning the assurance class .
+
+ Other approaches to gain confidence should be considered
+ that provide an equivalent level of assurance (e.g. to
+ analyse evaluation evidence). Any decision not to make a
+ visit should be determined in consultation with the
+ evaluation authority. Appropriate security criteria and a
+ methodology should be based on other standards of the
+ Information Security Management Systems area.
+
+
+
+ In the following some keywords are provided, which topics
+ should be checked during an audit.
+
+ Basic
+
+
+ Items of the configuration list, including TOE, source
+ code, run time libraries, design documentation,
+ development tools ().
+
+
+ Tracking of design documentation, source code, user
+ guidance to different versions of the TOE.
+
+
+ Integration of the configuration system in the design
+ and development process, test planning, test analysis
+ and quality management procedures.
+
+
+
+ Test analysis
+
+
+ Tracking of test plans and results to specific
+ configurations and versions of the TOE.
+
+
+
+ Access control to development systems
+
+
+ Policies for access control and logging.
+
+
+ Policies for project specific assignment and changing
+ of access rights.
+
+
+
+ Clearance
+
+
+ Policies for clearance of the TOE and user guidance to
+ the customer.
+
+
+ Policies for testing and approving of components and
+ the TOE before deployment.
+
+
+
+
+
+ Infrastructure
+
+
+ Security measures for physical access control to the
+ development site and rationale for the effectiveness
+ of these measures.
+
+
+
+ Organisational measures
+
+
+ Organisational structure of the company in respect of
+ the security of the development environment.
+
+
+ Organisational separation between development,
+ production, testing and quality assurance.
+
+
+
+ Personal measures
+
+
+ Measures for education of the personnel in respect of
+ development security.
+
+
+ Measures and legal agreements of non disclosure of
+ internal information.
+
+
+
+ Access control
+
+
+ Assignment of secured objects (for instance TOE,
+ source code, run time libraries, design documentation,
+ development tools, user guidance) and security
+ policies.
+
+
+ Policies and responsibilities concerning the access
+ control and the handling of authentication
+ information.
+
+
+ Policies for logging of any kind access to the
+ development site and protection of the logging data.
+
+
+
+ Input, processing and output of data
+
+
+ Security measures for protection of output and output
+ devices (printer, plotter and displays).
+
+
+ Securing of local networks and communication
+ connections.
+
+
+
+ Storage, transfer and destruction of documents and data
+ media.
+
+
+ Policies for handling of documents and data media.
+
+
+ Policies and responsibilities for destruction of
+ sorted out documents and logging of these events.
+
+
+
+ Data protection
+
+
+ Policies and responsibilities for data and information
+ protection (e.g. for performing backups).
+
+
+
+ Contingency plan
+
+
+ Practises in case of emergency and responsibilities.
+
+
+ Documentation of the contingency measures concerning
+ access control.
+
+
+ Information of the personnel about applicable
+ practises in extreme cases. protection (e.g. for
+ performing backups).
+
+
+
+
+
+
+ The examples of checklists for site visits consist in tables
+ for the preparation of an audit and for the presentation of
+ the results of an audit.
+
+ The checklist structure given in the following is
+ preliminary. Dependent on the concrete contents of the new
+ guideline, changes might become necessary.
+ The checklist is divided into three subclauses according
+ to the subjects indicated in the introduction (Subclause ).
+
+
+ Configuration management system.
+
+
+ Delivery procedures.
+
+
+ Security measures during development.
+
+
+ These subclauses correspond to the actual CC class , especially the families .n with n>=3, and .
+ The subclauses are subdivided further into rows
+ corresponding to the relevant work units of the CEM.
+
+ The columns of the checklist contain in turn
+
+
+ a consecutive number,
+
+
+ the referenced work unit,
+
+
+ the references to the corresponding developer
+ documentation,
+
+
+ the explicit reproduction of the developer measures,
+
+
+ special remarks and questions to be clarified on the
+ visit (beyond the standard evaluator task to verify the
+ application of the indicated measures),
+
+
+ the result of the examinations during the visit.
+
+
+ If it is decided to have separate checklists for
+ preparation and reporting of the audit, the result column is
+ omitted in the preparation list and the remarks and
+ questions column is omitted in the reporting list. The
+ remaining columns should be identical in both lists.
+
+
+ Example of a checklist at EAL 4 (extract)
+
+
+
+
+
+ A. Examination of the CM system ( and )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ A.1
+
+
+ ,
+
+
+
+ ``Configuration Management System'', ch. ...
+
+
+ The system automatically managing the source code
+ files is capable of administering user profiles and
+ graded access rights, and of checking identification
+ and authentication of users.
+
+
+ Does reading or updating of a source code file
+ require a user authentication?
+
+
+ If a user has not the right to access a confidential
+ document, it is not even displayed to him in the
+ file list.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ B. Examination of the Delivery Procedures ()
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ B.1
+
+
+ ,
+
+
+
+ ``Delivery of the TOE'', ch. ...
+
+
+ The software is transmitted PGP-signed and encrypted
+ to the customer.
+
+
+ ---
+
+
+ The evaluators have checked the process and found it
+ as described, additionally a checksum is
+ transmitted.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ C. Examination of the organisational and
+ infrastructural developer security
+ (,
+ ,
+ )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ C.1
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Premises)
+
+
+ The premises are protected by security fencing.
+
+
+ Is the fencing sufficiently strong and high to
+ prevent an easy intrusion into the premises?
+
+
+ The evaluators considered the fencing to be
+ sufficiently strong and high.
+
+
+
+
+ C.2
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Building)
+
+
+ The building has the following access possibilities:
+ The main entrance which is surveyed by the reception
+ and is closed if the reception is not manned. And an
+ access in the goods reception which is secured by
+ two roller shutters.
+
+
+ Is the listing of the access possibilities complete?
+
+
+ Beyond the indicated access possibilities, there is
+ an emergency exit that cannot be opened from the
+ outside. The roller shutters mentioned before can be
+ operated only from inside.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+
+ This CEM describes the minimum technical work that evaluations
+ conducted under oversight (scheme) bodies must
+ perform. However, it also recognises (both explicitly and
+ implicitly) that there are activities or methods upon which
+ mutual recognition of evaluation results do not rely. For the
+ purposes of thoroughness and clarity, and to better delineate
+ where the CEM ends and an individual scheme's methodology
+ begins, the following matters are left up to the discretion of
+ the schemes. Schemes may choose to provide the following,
+ although they may choose to leave some unspecified. (Every
+ effort has been made to ensure this list is complete;
+ evaluators encountering a subject neither listed here nor
+ addressed in the CEM should consult with their evaluation
+ schemes to determine under whose auspices the subject
+ falls.)
+
+ The matters that schemes may choose to specify include:
+
+
+ what is required in ensuring that an evaluation was done
+ sufficiently - every scheme has a means of verifying the
+ technical competence, understanding of work and the work
+ of its evaluators, whether by requiring the evaluators to
+ present their findings to the oversight body, by requiring
+ the oversight body to redo the evaluator's work, or by
+ some other means that assures the scheme that all
+ evaluation bodies are adequate and comparable;
+
+
+ process for disposing of evaluation evidence upon
+ completion of an evaluation;
+
+
+ any requirements for confidentiality (on the part of the
+ evaluator and the non-disclosure of information obtained
+ during evaluation);
+
+
+ the course of action to be taken if a problem is
+ encountered during the evaluation (whether the evaluation
+ continues once the problem is remedied, or the evaluation
+ ends immediately and the remedied product must be
+ re-submitted for evaluation);
+
+
+ any specific (natural) language in which documentation
+ must be provided;
+
+
+ any recorded evidence that must be submitted in the ETR -
+ this CEM specifies the minimum to be reported in an ETR;
+ however, individual schemes may require additional
+ information to be included;
+
+
+ any additional reports (other than the ETR) required from
+ the evaluators -for example, testing reports;
+
+
+ any specific ORs that may be required by the scheme,
+ including the structure, recipients, etc. of any such ORs;
+
+
+ any specific content structure of any written report as a
+ result from an ST evaluation - a scheme may have a
+ specific format for all of its reports detailing results
+ of an evaluation, be it the evaluation of a TOE or of an
+ ST;
+
+
+ any additional PP/ST identification information required;
+
+
+ any activities to determine the suitability of
+ explicitly-stated requirements in an ST;
+
+
+ any requirements for provision of evaluator evidence to
+ support re-evaluation and re-use of evidence;
+
+
+ any specific handling of scheme identifiers, logos,
+ trademarks, etc.;
+
+
+ any specific guidance in dealing with cryptography;
+
+
+ handling and application of scheme, national and
+ international interpretations;
+
+
+ a list or characterisations of suitable alternative
+ approaches to testing where testing is infeasible;
+
+
+ the mechanism by which an evaluation authority can determine what
+ steps an evaluator took while testing;
+
+
+ preferred test approach (if any): at internal interface or
+ at external interface;
+
+
+ a list or characterisation of acceptable means of
+ conducting the evaluator's vulnerability analysis
+ (e.g. flaw hypothesis methodology);
+
+
+ information regarding any vulnerabilities and weaknesses
+ to be considered.
+
+
+
+
+
+
+
+ This Clause presents the expected results from PP and ST/TOE
+ evaluations.
+
+ PP evaluations lead to catalogues of evaluated PPs.
+
+ An ST evaluation leads to intermediate results that
+ are used in the frame of a TOE evaluation.
+
+
+ ST/TOE evaluations lead to catalogues of evaluated
+ TOEs. In many cases these catalogues will refer to the IT
+ products that the TOEs are derived from rather than the
+ specific TOE. Therefore, the existence of an IT product in
+ a catalogue should not be construed as meaning that the
+ whole IT product has been evaluated; instead the actual
+ extent of the ST/TOE evaluation is defined by the ST.
+
+
+
+ STs may be based on packages, evaluated PPs or
+ non-evaluated PPs - however this is not mandatory, as STs do
+ not have to be based on anything at all.
+
+ Evaluation should lead to objective and repeatable results
+ that can be cited as evidence, even if there is no absolute
+ objective scale for representing the results of a security
+ evaluation. The existence of a set of evaluation criteria is a
+ necessary pre-condition for evaluation to lead to a meaningful
+ result and provides a technical basis for mutual recognition
+ of evaluation results between evaluation authorities.
+
+ An evaluation result represents the findings of a specific
+ type of investigation of the security properties of a
+ TOE. Such a result does not automatically guarantee fitness
+ for use in any particular application environment. The
+ decision to accept a TOE for use in a specific application
+ environment is based on consideration of many security issues
+ including the evaluation findings.
+
+
+
+ The CC contains the evaluation criteria that permit an
+ evaluator to state whether a PP is complete, consistent, and
+ technically sound and hence suitable for use in developing an
+ ST.
+
+ The results of the evaluation shall also include a ``Conformance Claim''
+ (see Subclause ).
+
+
+
+ The CC contains the evaluation criteria that enable an
+ evaluator to determine whether sufficient assurance exists
+ that the TOE satisfies the SFRs in the ST. Evaluation of the
+ TOE shall therefore result in a pass/fail statement for the
+ ST. If both the ST and the TOE evaluation have resulted in a
+ pass statement, the underlying product is eligible for
+ inclusion in a registry. The results of evaluation shall also
+ include a ``Conformance Claim'' as defined in the next
+ Subclause.
+ It may be the case that the evaluation results are
+ subsequently used in a certification process, but this
+ certification process is outside the scope of the CC.
+
+
+
+ The conformance claim indicates the source of the collection
+ of requirements that is met by a PP or ST that passes its
+ evaluation. This conformance claim contains a CC conformance
+ claim that:
+
+
+ describes the version of the CC to which the PP or ST
+ claims conformance.
+
+
+ describes the conformance to CC Part 2 (security
+ functional requirements) as either:
+
+
+ CC Part 2 conformant - A PP or ST is CC
+ Part 2 conformant if all SFRs in that PP or ST are
+ based only upon functional components in CC Part 2, or
+
+
+ CC Part 2 extended - A PP or ST is CC
+ Part 2 extended if at least one SFR in that PP or ST
+ is not based upon functional components in CC Part 2.
+
+
+
+
+ describes the conformance to CC Part 3 (security assurance
+ requirements) as either:
+
+
+ CC Part 3 conformant - A PP or ST is CC
+ Part 3 conformant if all SARs in that PP or ST are
+ based only upon assurance components in CC Part 3, or
+
+
+ CC Part 3 extended - A PP or ST is CC
+ Part 3 extended if at least one SAR in that PP or ST
+ is not based upon assurance components in CC Part 3.
+
+
+
+
+
+ Additionally, the conformance claim may include a statement
+ made with respect to packages, in which case it consists of
+ one of the following:
+
+
+ Package name Conformant - A PP or ST is
+ conformant to a pre-defined package (e.g. EAL) if:
+
+ the SFRs of that PP or ST are identical to the
+ SFRs in the package, or
+ the SARs of that PP or ST are identical to the
+ SARs in the package.
+
+
+
+ Package name Augmented - A PP or ST is an
+ augmentation of a predefined package if:
+
+ the SFRs of that PP or ST contain all SFRs in the
+ package, but have at least one additional SFR or one
+ SFR that is hierarchically higher than an SFR in the
+ package.
+ the SARs of that PP or ST contain all SARs in the
+ package, but have at least one additional SAR or one
+ SAR that is hierarchically higher than an SAR in the
+ package.
+
+
+
+ Note that when a TOE is successfully evaluated to a given
+ ST, any conformance claims of the ST also hold for the TOE. A
+ TOE can therefore also be e.g. CC Part 2 conformant.
+
+ Finally, the conformance claim may also include two statements
+ with respect to Protection Profiles:
+
+
+ PP Conformant - A PP or TOE meets
+ specific PP(s), which are listed as part of the
+ conformance result.
+
+ Conformance Statement (Only for PPs) - This
+ statement describes the manner in which PPs or STs must conform
+ to this PP: strict or demonstrable. For more information on this
+ Conformance Statement, see .
+
+
+
+
+
+ Once an ST and a TOE have been evaluated, asset owners can
+ have the assurance (as defined in the ST) that the TOE,
+ together with the operational environment, counters the
+ threats. The evaluation results may be used by the asset owner
+ in deciding whether to accept the risk of exposing the assets
+ to the threats.
+
+ However, the asset owner should carefully check whether:
+
+ the Security Problem Definition in the ST matches the
+ security problem of the asset owner;
+
+ the Operational Environment of the asset owner conforms
+ (or can be made to conform) to the security objectives for
+ the Operational Environment described in the ST.
+
+
+ If either of these is not the case, the TOE may not be
+ suitable for the purposes of the asset owner.
+
+ Additionally, once an evaluated TOE is in operation, it is
+ possible that previously unknown errors or vulnerabilities in
+ the TOE may surface. In that case, the developer may correct
+ the TOE (to repair the vulnerabilities) or change the ST to exclude the vulnerabilities from the scope of the evaluation. In either case, the old evaluation results may no longer be valid.
+ If it is deemed necessary that confidence is regained,
+ re-evaluation is needed. The CC may be used for this
+ re-evaluation, but detailed procedures for re-evaluation are
+ outside the scope of this document.
+
+
+
+
+ The following annexes through provide the application notes for the functional
+ classes defined in the main body of this part of the CC.
+
+
+ For the purposes of this document, the terms, definitions,
+ symbols and abbreviated terms given in CC Part 1 apply.
+
+
+ Security functional components, as defined in this CC Part 2, are
+ the basis for the security functional requirements expressed in a
+ Protection Profile (PP) or a Security Target (ST). These
+ requirements describe the desired security behaviour expected of a
+ Target of Evaluation (TOE) and are intended to meet the security
+ objectives as stated in a PP or an ST. These requirements describe
+ security properties that users can detect by direct interaction
+ (i.e. inputs, outputs) with the IT or by the IT response to
+ stimulus.
+
+ Security functional components express security requirements
+ intended to counter threats in the assumed operating environment
+ of the TOE and/or cover any identified organisational security
+ policies and assumptions.
+
+ The audience for this CC Part 2 includes consumers, developers,
+ and evaluators of secure IT products. CC Part 1
+ Chapter provides additional
+ information on the target audience of the CC, and on the use of
+ the CC by the groups that comprise the target audience. These
+ groups may use this part of the CC as follows:
+
+
+ Consumers, who use this CC Part 2 when selecting components to
+ express functional requirements to satisfy the security
+ objectives expressed in a PP or ST. CC Part 1 Section provides more detailed
+ information on the relationship between security objectives
+ and security requirements.
+
+
+ Developers, who respond to actual or perceived consumer
+ security requirements in constructing a TOE, may find a
+ standardised method to understand those requirements in this
+ part of the CC. They can also use the contents of this part of
+ the CC as a basis for further defining the TOE security
+ functionality and mechanisms that comply with those
+ requirements.
+
+
+ Evaluators, who use the functional requirements defined in
+ this part of the CC in verifying that the TOE functional
+ requirements expressed in the PP or ST satisfy the IT security
+ objectives and that all dependencies are accounted for and
+ shown to be satisfied. Evaluators also should use this part of
+ the CC to assist in determining whether a given TOE satisfies
+ stated requirements.
+
+
+
+
+
+ The CC and the associated security functional requirements
+ described herein are not meant to be a definitive answer to all
+ the problems of IT security. Rather, the CC offers a set of well
+ understood security functional requirements that can be used to
+ create trusted products reflecting the needs of the market. These
+ security functional requirements are presented as the current
+ state of the art in requirements specification and
+ evaluation.
+
+ This part of the CC does not presume to include all possible
+ security functional requirements but rather contains those that
+ are known and agreed to be of value by the CC Part 2 authors at
+ the time of release.
+
+ Since the understanding and needs of consumers may change, the
+ functional requirements in this part of the CC will need to be
+ maintained. It is envisioned that some PP/ST authors may have
+ security needs not (yet) covered by the functional requirement
+ components in CC Part 2. In those cases the PP/ST author may
+ choose to consider using functional requirements not taken from
+ the CC (referred to as extensibility), as explained in annexes
+ and
+ of
+ CC Part 1.
+
+
+
+ Clause
+ describes the paradigm used in the security functional
+ requirements of CC Part 2.
+
+ Clause
+ introduces the catalogue of CC Part 2 functional components
+ while clauses through describe the functional classes.
+
+ provides explanatory information for potential
+ users of the functional components including a complete cross
+ reference table of the functional component dependencies.
+
+ through provide the explanatory information for the
+ functional classes. This material must be seen as normative
+ instructions on how to apply relevant operations and select
+ appropriate audit or documentation information; the use of the
+ auxiliary verb should means that the instruction is strongly
+ preferred, but others may be justifiable. Where different
+ options are given, the choice is left to the PP/ST
+ author.
+
+ Those who author PPs or STs should refer to clause 2 of CC Part
+ 1 for relevant structures, rules, and guidance:
+
+
+ CC Part 1, clause
+ defines the terms used in the CC.
+
+
+ CC Part 1, annex defines the
+ structure for STs.
+
+
+ CC Part 1, annex defines the
+ structure for PPs.
+
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest edition
+ of the referenced document (including any amendments) applies.CC
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 1: Introduction and general model.
+
+
+ This part of the CC defines the required structure and content
+ of security functional components for the purpose of security
+ evaluation. It includes a catalogue of functional components
+ that will meet the common security functionality requirements
+ of many IT products.
+
+
+ This chapter describes the paradigm used in the security
+ functional requirements of this part of the CC. Key concepts
+ discussed are highlighted in bold/italics. This section is not
+ intended to replace or supersede any of the terms found in CC Part
+ 1, chapter .
+
+ This part of the CC is a catalogue of security functional
+ components that can be specified for a Target of
+ Evaluation (TOE). A TOE is a set of software, firmware
+ and/or hardware possibly accompanied by user and administrator
+ guidance documentation. A TOE may contain resources such as
+ electronic storage media (e.g. main memory, disk space),
+ peripheral devices (e.g. printers), and computing capacity (e.g.
+ CPU time) that can be used for processing and storing
+ information and is the subject of an evaluation.
+
+ TOE evaluation is concerned primarily with ensuring that a defined
+ set of security functional requirements (SFRs) is
+ enforced over the TOE resources. The SFRs define the rules by
+ which the TOE governs access to and use of its resources, and thus
+ information and services controlled by the TOE.
+
+ The SFRs may define multiple Security Function Policies
+ (SFPs) to represent the rules that the TOE must enforce. Each such SFP
+ must specify its scope of control, by defining the subjects,
+ objects, resources or information, and operations to which it applies. All
+ SFPs are implemented by the TSF (see below), whose mechanisms enforce the
+ rules defined in the SFRs and provide necessary capabilities.
+
+ Those portions of a TOE that must be relied on for the correct
+ enforcement of the SFRs are collectively referred to as the
+ TOE Security Functionality (TSF). The TSF consists of
+ all hardware, software, and firmware of a TOE that is either
+ directly or indirectly relied upon for security enforcement.
+
+ The TOE may be a monolithic product containing hardware, firmware,
+ and software.
+
+ Alternatively a TOE may be a distributed product that consists
+ internally of multiple separated parts. Each of these parts of the
+ TOE provides a particular service for the TOE, and is connected to
+ the other parts of the TOE through an internal communication
+ channel. This channel can be as small as a processor bus,
+ or may encompass a network internal to the TOE.
+
+ When the TOE consists of multiple parts, each part of the TOE may
+ have its own part of the TSF which exchanges user and TSF data
+ over internal communication channels with other parts of the
+ TSF. This interaction is called internal TOE
+ transfer. In this case the separate parts of the TSF
+ abstractly form the composite TSF, which enforces the SFRs.
+
+ TOE interfaces may be localised to the particular TOE, or they may
+ allow interaction with other IT products over external
+ communication channels. These external interactions with
+ other IT products may take two forms:
+
+
+ The SFRs of the other ``trusted IT product'' and the SFRs of
+ the TOE have been administratively coordinated and the other
+ trusted IT product is assumed to enforce its SFRs correctly
+ (e. g. by being separately evaluated). Exchanges of
+ information in this situation are called inter-TSF
+ transfers, as they are between the TSFs of distinct
+ trusted products.
+
+
+ The other IT product may not be trusted, it may be called an
+ ``untrusted IT product''. Therefore its SFRs are either
+ unknown or their implementation is not viewed as
+ trustworthy. TSF mediated exchanges of information in this
+ situation are called transfers outside of the
+ TOE, as there is no TSF (or its policy characteristics
+ are unknown) on the other IT product.
+
+
+ The set of interfaces, whether interactive (man-machine
+ interface) or programmatic (application programming interface),
+ through which resources are accessed that are mediated by the TSF,
+ or information is obtained from the TSF, is referred to as the
+ TSF Interface (TSFI). The TSFI defines the boundaries
+ of the TOE functionality that provide for the enforcement of the
+ SFRs.
+
+ Users are outside of the TOE. However, in order to request that
+ services be performed by the TOE that are subject to rules
+ defined in the SFRs, users interact with the TOE through the
+ TSFIs. There are two types of users of interest to CC Part 2:
+ human users and external IT
+ entities. Human users may further be differentiated as
+ local human users, meaning they interact directly
+ with the TOE via TOE devices (e.g. workstations), or
+ remote human users, meaning they interact
+ indirectly with the TOE through another IT product.
+
+ A period of interaction between users and the TSF is referred to
+ as a user session. Establishment of user sessions can
+ be controlled based on a variety of considerations, for example:
+ user authentication, time of day, method of accessing the TOE, and
+ number of allowed concurrent sessions (per user or in total).
+
+ This part of the CC uses the term authorised to
+ signify a user who possesses the rights and/or privileges
+ necessary to perform an operation. The term authorised
+ user, therefore, indicates that it is allowable for a user
+ to perform a specific operation or a set of operations as defined
+ by the SFRs.
+
+ To express requirements that call for the separation of
+ administrator duties, the relevant security functional
+ components (from family )
+ explicitly state that administrative roles are
+ required. A role is a pre-defined set of rules establishing the
+ allowed interactions between a user operating in that role and
+ the TOE. A TOE may support the definition of any number of
+ roles. For example, roles related to the secure operation of a
+ TOE may include ``Audit Administrator'' and ``User Accounts
+ Administrator''.
+
+ TOEs contain resources that may be used for the
+ processing and storing of information. The primary goal of the TSF
+ is the complete and correct enforcement of the SFRs over the
+ resources and information that the TOE controls.
+
+ TOE resources can be structured and utilised in many different
+ ways. However, CC Part 2 makes a specific distinction that allows
+ for the specification of desired security properties. All entities
+ that can be created from resources can be characterised in one of
+ two ways. The entities may be active, meaning that they are the
+ cause of actions that occur internal to the TOE and cause
+ operations to be performed on information. Alternatively, the
+ entities may be passive, meaning that they are either the
+ container from which information originates or to which
+ information is stored.
+
+ Active entities in the TOE that perform operations on objects are
+ referred to as subjects. Several types of subjects
+ may exist within a TOE:
+
+
+ those acting on behalf of an authorised user (e.g. UNIX
+ processes);
+
+
+ those acting as a specific functional process that may in turn
+ act on behalf of multiple users (e.g. functions as might be
+ found in client/server architectures); or
+
+
+ those acting as part of the TOE itself (e.g. processes not
+ acting on behalf of a user).
+
+
+
+ CC Part 2 addresses the enforcement of the SFRs over types of
+ subjects as those listed above.
+
+ Passive entities in the TOE that contain or receive information
+ and upon which subjects perform operations are called
+ objects. In the case where a subject (an active
+ entity) is the target of an operation (e.g. interprocess
+ communication), a subject may also be acted on as an object.
+
+ Objects can contain information. This concept is
+ required to specify information flow control policies as addressed
+ in the FDP class.
+
+ Users, subjects, information, objects, sessions and resources
+ controlled by rules in the SFRs may possess certain
+ attributes that contain information that is used by
+ the TOE for its correct operation. Some attributes, such as file
+ names, may be intended to be informational or may be used to
+ identify individual resources while others, such as access control
+ information, may exist specifically for the enforcement of the
+ SFRs. These latter attributes are generally referred to as
+ ``security attributes''. The word attribute will be
+ used as a shorthand in some places of this part of the CC for the
+ word ``security attribute''. However, no matter what the intended
+ purpose of the attribute information, it may be necessary to have
+ controls on attributes as dictated by the SFRs.
+
+ Data in a TOE is categorised as either user data or TSF
+ data. Figure depicts this
+ relationship. User Data is information stored in TOE
+ resources that can be operated upon by users in accordance with
+ the SFRs and upon which the TSF places no special meaning. For
+ example, the content of an electronic mail message is user
+ data. TSF Data is information used by the TSF in making decisions
+ as required by the SFRs. TSF Data may be influenced
+ by users if allowed by the SFRs. Security attributes,
+ authentication data, TSF internal status variables used by the
+ rules defined in the SFRs or used for the protection of the TSF
+ and access control list entries are examples of TSF data.
+
+ There are several SFPs that apply to data protection such as
+ access control SFPs and information flow
+ control SFPs. The mechanisms that implement access control
+ SFPs base their policy decisions on attributes of the users,
+ resources, subjects, objects, sessions, TSF status data and
+ operations within the scope of control. These attributes are used
+ in the set of rules that govern operations that subjects may
+ perform on objects.
+
+ The mechanisms that implement information flow control SFPs base
+ their policy decisions on the attributes of the subjects and
+ information within the scope of control and the set of rules that
+ govern the operations by subjects on information. The attributes
+ of the information, which may be associated with the attributes of
+ the container or may be derived from the data in the container,
+ stay with the information as it is processed by the TSF.
+
+
+ Two specific types of TSF data addressed by CC Part 2 can be, but
+ are not necessarily, the same. These are authentication
+ data and secrets.
+
+ Authentication data is used to verify the claimed identity of a
+ user requesting services from a TOE. The most common form of
+ authentication data is the password, which depends on being kept
+ secret in order to be an effective security mechanism. However,
+ not all forms of authentication data need to be kept
+ secret. Biometric authentication devices (e.g. fingerprint
+ readers, retinal scanners) do not rely on the fact that the data
+ is kept secret, but rather that the data is something that only
+ one user possesses and that cannot be forged.
+
+ The term secrets, as used in CC Part 2, while applicable to
+ authentication data, is intended to also be applicable to other
+ types of data that must be kept secret in order to enforce a
+ specific SFP. For example, a trusted channel mechanism that
+ relies on cryptography to preserve the confidentiality of
+ information being transmitted via the channel can only be as
+ strong as the method used to keep the cryptographic keys secret
+ from unauthorised disclosure.
+
+ Therefore, some, but not all, authentication data needs to be kept
+ secret and some, but not all, secrets are used as authentication
+ data. Figure shows this relationship
+ between secrets and authentication data. In the Figure the types
+ of data typically encountered in the authentication data and the
+ secrets sections are indicated.
+
+
+
+
+
+ This clause provides an overview of the evaluation process
+ and defines the tasks an evaluator is intended to perform when
+ conducting an evaluation.
+
+ Each evaluation, whether of a PP or TOE (including ST),
+ follows the same process, and has four evaluator tasks in
+ common: the input task, the output task, the evaluation
+ sub-activities, and the demonstration of the technical
+ competence to the evaluation authority task.
+
+ The input task and the output tasks, which are related to
+ management of evaluation evidence and to report generation,
+ are entirely described in this clause. Each task has
+ associated sub-tasks that apply to, and are normative for all
+ CC evaluations (evaluation of a PP or a TOE).
+
+ The evaluation sub-activities are only introduced in this
+ clause, and fully described in the following clauses.
+
+ In contrast to the evaluation sub-activities, input and output
+ tasks have no verdicts associated with them as they do not map
+ to CC evaluator action elements; they are performed in order
+ to ensure conformance with the universal principles and to
+ comply with the CEM.
+
+ The demonstration of the technical competence to the
+ evaluation authority task may be fulfilled by the evaluation
+ authority analysis of the output tasks results, or may include
+ the demonstration by the evaluators of their understanding of
+ the inputs for the evaluation sub-activities. This task has no
+ associated evaluator verdict, but has an evaluator authority
+ verdict. The detailed criteria to pass this task are left to
+ the discretion of the evaluation authority, as noted in Annex
+ .
+
+
+
+
+ This subclause presents the general model of the methodology
+ and identifies:
+
+
+ roles and responsibilities of the parties involved in
+ the evaluation process;
+
+
+ the general evaluation model.
+
+
+
+
+
+ The general model defines the following roles: sponsor,
+ developer, evaluator and evaluation authority.
+
+ The sponsor is responsible for requesting and supporting an
+ evaluation. This means that the sponsor establishes the
+ different agreements for the evaluation (e.g. commissioning
+ the evaluation). Moreover, the sponsor is responsible for
+ ensuring that the evaluator is provided with the evaluation
+ evidence.
+
+ The developer produces the TOE and is responsible for
+ providing the evidence required for the evaluation
+ (e.g. training, design information), on behalf of the
+ sponsor.
+
+ The evaluator performs the evaluation tasks required in the
+ context of an evaluation: the evaluator receives the
+ evaluation evidence from the developer on behalf of the
+ sponsor or directly from the sponsor, performs the
+ evaluation sub-activities and provides the results of the
+ evaluation assessment to the evaluation authority.
+
+ The evaluation authority establishes and maintains the
+ scheme, monitors the evaluation conducted by the evaluator,
+ and issues certification/validation reports as well as
+ certificates based on the evaluation results provided by the
+ evaluator.
+
+
+
+ To prevent undue influence from improperly affecting an
+ evaluation, some separation of roles is required. This
+ implies that the roles described above are fulfilled by
+ different entities, except that the roles of developer and
+ sponsor may be satisfied by a single entity.
+
+ Moreover, some evaluations (e.g. EAL1 evaluation) may not
+ require the developer to be involved in the project. In this
+ case, it is the sponsor who provides the TOE to the
+ evaluator and who generates the evaluation evidence.
+
+
+
+ The evaluation process consists of the evaluator performing
+ the evaluation input task, the evaluation output task and
+ the evaluation sub-activities. Figure provides an overview of
+ the relationship between these tasks and
+ sub-activities.
+
+
+ The evaluation process may be preceded by a preparation
+ phase where initial contact is made between the sponsor and
+ the evaluator. The work that is performed and the
+ involvement of the different roles during this phase may
+ vary. It is typically during this step that the evaluator
+ performs a feasibility analysis to assess the likelihood of
+ a successful evaluation.
+
+
+
+ The evaluator assigns verdicts to the requirements of the CC
+ and not to those of the CEM. The most granular CC structure
+ to which a verdict is assigned is the evaluator action
+ element (explicit or implied). A verdict is assigned to an
+ applicable CC evaluator action element as a result of
+ performing the corresponding CEM action and its constituent
+ work units. Finally, an evaluation result is assigned, as
+ described in CC Part 1, Clause .
+
+
+ The CEM recognises three mutually exclusive verdict states:
+
+
+ Conditions for a pass verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST or TOE under evaluation are met. The
+ conditions for passing the element are defined as:
+
+
+ the constituent work units of the related CEM
+ action, and;
+
+
+ all evaluation evidence required for performing
+ these work units is coherent, that is it can be
+ fully and completely understood by the evaluator,
+ and
+
+
+ all evaluation evidence required for performing
+ these work units does not have any obvious internal
+ inconsistencies or inconsistencies with other
+ evaluation evidence. Note that obvious means here
+ that the evaluator discovers this inconsistency
+ while performing the work units: the evaluator
+ should not undertake a full consistency analysis
+ across the entire evaluation evidence every time a
+ work unit is performed.
+
+
+
+
+ Conditions for a fail verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST, or TOE under evaluation are not met, or
+ that the evidence is incoherent, or an obvious
+ inconsistency in the evaluation evidence has been found;
+
+
+ All verdicts are initially inconclusive
+ and remain so until either a pass or
+ fail verdict is assigned.
+
+
+
+ The overall verdict is pass if and only if
+ all the constituent verdicts are also
+ pass. In the example illustrated in Figure
+ , if the verdict for one
+ evaluator action element is fail then the
+ verdicts for the corresponding assurance component,
+ assurance class, and overall verdict are also
+ fail.
+
+
+
+
+
+ The objective of this task is to ensure that the evaluator
+ has available the correct version of the evaluation evidence
+ necessary for the evaluation and that it is adequately
+ protected. Otherwise, the technical accuracy of the
+ evaluation cannot be assured, nor can it be assured that the
+ evaluation is being conducted in a way to provide repeatable
+ and reproducible results.
+
+
+
+ The responsibility to provide all the required evaluation
+ evidence lies with the sponsor. However, most of the
+ evaluation evidence is likely to be produced and supplied by
+ the developer, on behalf of the sponsor.
+
+ Since the assurance requirements apply to the entire TOE,
+ all evaluation evidence pertaining to all parts of the TOE
+ is to be made available to the evaluator. The scope and
+ required content of such evaluation evidence is independent
+ of the level of control that the developer has over each of
+ the parts of the TOE. For example, if design is required,
+ then the requirements will
+ apply to all subsystems that are part of the TSF. In
+ addition, assurance requirements that call for procedures to
+ be in place (for example,
+ and ) will also apply to the
+ entire TOE (including any part produced by another
+ developer).
+
+ It is recommended that the evaluator, in conjunction with
+ the sponsor, produce an index to required evaluation
+ evidence. This index may be a set of references to the
+ documentation. This index should contain enough information
+ (e.g. a brief summary of each document, or at least an
+ explicit title, indication of the subclauses of interest) to
+ help the evaluator to find easily the required
+ evidence.
+
+ It is the information contained in the evaluation evidence
+ that is required, not any particular document
+ structure. Evaluation evidence for a sub-activity may be
+ provided by separate documents, or a single document may
+ satisfy several of the input requirements of a
+ sub-activity.
+
+ The evaluator requires stable and formally-issued versions
+ of evaluation evidence. However, draft evaluation evidence
+ may be provided during an evaluation, for example, to help
+ an evaluator make an early, informal assessment, but is not
+ used as the basis for verdicts. It may be helpful for the
+ evaluator to see draft versions of particular appropriate
+ evaluation evidence, such as:
+
+
+ test documentation, to allow the evaluator to make an
+ early assessment of tests and test procedures;
+
+
+ design documents, to provide the evaluator with
+ background for understanding the TOE design;
+
+
+ source code or hardware drawings, to allow the evaluator
+ to assess the application of the developer's standards.
+
+
+
+ Draft evaluation evidence is more likely to be encountered
+ where the evaluation of a TOE is performed concurrently with
+ its development. However, it may also be encountered during
+ the evaluation of an already-developed TOE where the
+ developer has had to perform additional work to address a
+ problem identified by the evaluator (e.g. to correct an
+ error in design or implementation) or to provide evaluation
+ evidence of security that is not provided in the existing
+ documentation (e.g. in the case of a TOE not originally
+ developed to meet the requirements of the CC).
+
+
+
+
+ The evaluator shall perform configuration control of the
+ evaluation evidence.
+
+ The CC implies that the evaluator is able to identify and
+ locate each item of evaluation evidence after it has been
+ received and is able to determine whether a specific
+ version of a document is in the evaluator's
+ possession.
+
+ The evaluator shall protect the evaluation evidence from
+ alteration or loss while it is in the evaluator's
+ possession.
+
+
+
+ Schemes may wish to control the disposal of evaluation
+ evidence at the conclusion of an evaluation. The disposal
+ of the evaluation evidence should be achieved by one or
+ more of:
+
+
+ returning the evaluation evidence;
+
+
+ archiving the evaluation evidence;
+
+
+ destroying the evaluation evidence.
+
+
+
+
+
+ An evaluator may have access to sponsor and developer
+ commercially-sensitive information (e.g. TOE design
+ information, specialist tools), and may have access to
+ nationally-sensitive information during the course of an
+ evaluation. Schemes may wish to impose requirements for
+ the evaluator to maintain the confidentiality of the
+ evaluation evidence. The sponsor and evaluator may
+ mutually agree to additional requirements as long as these
+ are consistent with the scheme.
+
+ Confidentiality requirements affect many aspects of
+ evaluation work, including the receipt, handling, storage
+ and disposal of evaluation evidence.
+
+
+
+
+
+ The evaluation sub-activities vary depending whether it is a
+ PP or a TOE evaluation. Moreover, in the case of a TOE
+ evaluation, the sub-activities depend upon the selected
+ assurance requirements.
+
+
+
+
+ The objective of this Subclause is to describe the Observation
+ Report (OR) and the Evaluation Technical Report
+ (ETR). Schemes may require additional evaluator reports such
+ as reports on individual units of work, or may require
+ additional information to be contained in the OR and the
+ ETR. The CEM does not preclude the addition of information
+ into these reports as the CEM specifies only the minimum
+ information content.
+
+ Consistent reporting of evaluation results facilitates the
+ achievement of the universal principle of repeatability and
+ reproducibility of results. The consistency covers the type and
+ the amount of information reported in the ETR and OR. ETR and OR
+ consistency among different evaluations is the responsibility of
+ the evaluation authority.
+
+ The evaluator performs the two following sub-tasks in order
+ to achieve the CEM requirements for the information content
+ of reports:
+
+
+ write OR sub-task (if needed in the context of the
+ evaluation);
+
+
+ write ETR sub-task.
+
+
+
+
+
+ The evaluator delivers the ETR to the evaluation authority,
+ as well as any ORs as they become available. Requirements
+ for controls on handling the ETR and ORs are established by
+ the scheme which may include delivery to the sponsor or
+ developer. The ETR and ORs may include sensitive or
+ proprietary information and may need to be sanitised before
+ they are given to the sponsor.
+
+
+
+ In this version of the CEM, the requirements for the
+ provision of evaluator evidence to support re-evaluation and
+ re-use have not been explicitly stated. Where information
+ for re-evaluation or re-use is required by the sponsor, the
+ scheme under which the evaluation is being performed should
+ be consulted.
+
+
+
+ ORs provide the evaluator with a mechanism to request a
+ clarification (e.g. from the evaluation authority on the application of a
+ requirement) or to identify a problem with an aspect of the
+ evaluation.
+
+ In the case of a fail verdict, the evaluator shall provide
+ an OR to reflect the evaluation result. Otherwise, the
+ evaluator may use ORs as one way of expressing clarification
+ needs.
+
+ For each OR, the evaluator shall report the following:
+
+
+ the identifier of the PP or TOE evaluated;
+
+
+ the evaluation task/sub-activity during which the
+ observation was generated;
+
+
+ the observation;
+
+
+ the assessment of its severity (e.g. implies a fail
+ verdict, holds up progress on the evaluation, requires a
+ resolution prior to evaluation being completed);
+
+
+ the identification of the organisation responsible for
+ resolving the issue;
+
+
+ the recommended timetable for resolution;
+
+
+ the assessment of the impact on the evaluation of
+ failure to resolve the observation.
+
+
+
+ The intended audience of an OR and procedures for handling the
+ report depend on the nature of the report's content and on the
+ scheme. Schemes may distinguish different types of ORs or define
+ additional types, with associated differences in required
+ information and distribution (e.g. evaluation ORs to evaluation authorities
+ and sponsors).
+
+
+
+
+ The evaluator shall provide an ETR to present technical
+ justification of the verdicts.
+
+ The CEM defines the ETR's minimum content requirement;
+ however, schemes may specify additional content and
+ specific presentational and structural requirements. For
+ instance, schemes may require that certain introductory
+ material (e.g. disclaimers and copyright Clauses) be
+ reported in the ETR.
+
+ The reader of the ETR is assumed to be familiar with
+ general concepts of information security, the CC, the CEM,
+ evaluation approaches and IT.
+
+ The ETR supports the evaluation authority to confirm that
+ the evaluation was done to the required standard, but it
+ is anticipated that the documented results may not provide
+ all of the necessary information, so additional
+ information specifically requested by the scheme may be
+ necessary. This aspect is outside the scope of the
+ CEM.
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a PP evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report PP configuration control
+ identifiers.
+
+ PP configuration control identifiers (e.g. name, date and
+ version number) are required to identify what is being evaluated
+ in order for the evaluation authority to verify that the verdicts have been
+ assigned correctly by the evaluator.
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the PP developer is required to identify
+ the party responsible for producing the PP.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator references the evaluation criteria,
+ methodology and interpretations used to evaluate the
+ PP.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the handling of evaluation
+ results and assumptions made during the evaluation that
+ have an impact on the evaluation results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ The evaluator shall report a verdict and a supporting
+ rationale for each assurance component that constitutes
+ an activity, as a result of
+ performing the corresponding CEM action and its
+ constituent work units.
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, in particular the overall verdict as defined
+ in CC Part 1 Clause , and determined by application
+ of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be useful for
+ the evaluation authority. These recommendations may include shortcomings of
+ the PP discovered during the evaluation or mention of features
+ which are particularly useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a TOE evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report ST and TOE configuration
+ control identifiers.
+
+ ST and TOE configuration control identifiers identify
+ what is being evaluated in order for the evaluation authority to
+ verify that the verdicts have been assigned correctly by
+ the evaluator.
+
+ If the ST claims that the TOE conforms to the
+ requirements of one or more PPs, the ETR shall report
+ the reference of the corresponding PPs.
+
+ The PPs reference contains information that uniquely
+ identifies the PPs (e.g. title, date, and version
+ number).
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the TOE developer is required to
+ identify the party responsible for producing the
+ TOE.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report a high level description of
+ the TOE and its major components based on the evaluation
+ evidence described in the CC assurance family entitled
+ , where
+ applicable.
+
+ The intent of this Subclause is to characterise the degree
+ of architectural separation of the major components. If
+ there is no requirement
+ in the ST, this is not applicable and is considered to
+ be satisfied.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator may reference the evaluation criteria,
+ methodology and interpretations used to evaluate the TOE
+ or the devices used to perform the tests.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the distribution of
+ evaluation results and assumptions made during the
+ evaluation that have an impact on the evaluation
+ results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ For each activity on which the TOE is evaluated, the
+ evaluator shall report:
+
+
+ the title of the activity considered;
+
+
+ a verdict and a supporting rationale for each
+ assurance component that constitutes this activity,
+ as a result of performing the corresponding CEM
+ action and its constituent work units.
+
+
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+ The evaluator shall report all information specifically
+ required by a work unit.
+
+ For the and activities, work units that identify
+ information to be reported in the ETR have been
+ defined.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, which will relate to whether the TOE has
+ satisfied its associated ST, in particular the overall
+ verdict as defined in CC Part 1 Clause , and determined by
+ application of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be useful for
+ the evaluation authority. These recommendations may include shortcomings of
+ the IT product discovered during the evaluation or mention of
+ features which are particularly useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+
+
+
+ The CC permits comparability between the results of independent
+ security evaluations. The CC does so by providing a common set
+ of requirements for the security functionality of IT products
+ and for assurance measures applied to these IT products during a
+ security evaluation. These IT products may be implemented in
+ hardware, firmware or software.
+
+ The evaluation process establishes a level of confidence that
+ the security functionality of these IT products and the
+ assurance measures applied to these IT products meet these
+ requirements. The evaluation results may help consumers to
+ determine whether these IT products fulfil their security
+ needs.
+
+ The CC is useful as a guide for the development, evaluation
+ and/or procurement of IT products with security
+ functionality.
+
+ The CC addresses protection of assets from unauthorised
+ disclosure, modification, or loss of use. The categories of
+ protection relating to these three types of failure of security
+ are commonly called confidentiality, integrity, and
+ availability, respectively. The CC may also be applicable to
+ aspects of IT security outside of these three. The CC is
+ applicable to risks arising from human activities (malicious or
+ otherwise) and to risks arising from non-human activities. Apart
+ from IT security, the CC may be applied in other areas of IT,
+ but makes no claim of applicability in these areas.
+
+
+
+ Table describes the
+ relationship between PPs and the families and components of the
+ class.
+
+
+
+ This Clause introduces the main concepts of the CC. It
+ identifies the concept ``TOE'', the target audience of the CC,
+ and the approach taken to present the material in the remainder
+ of the CC.
+
+
+ CC is flexible in what to evaluate and is therefore not tied to the boundaries of IT products as commonly understood. Therefore in the context of evaluation, CC uses the term “TOE" (Target of Evaluation).
+ A TOE is defined as a set of software, firmware and/or
+ hardware possibly accompanied by guidance.
+ While there are cases where a TOE consists of an IT
+ product, this need not be the case. The TOE may be an IT
+ product, a part of an IT product, a set of IT products, a
+ unique technology that may never be made into a product, or a
+ combination of these.
+
+ As far as the CC is concerned, the precise relation between
+ the TOE and any IT products is only important in one aspect:
+ the evaluation of a TOE containing only part of an IT product
+ should not be misrepresented as the evaluation of the entire
+ IT product.
+ Examples of TOEs include:
+
+
+ A software application;
+
+
+ An operating system;
+
+
+ A software application in combination with an operating
+ system;
+
+
+ A software application in combination with an operating
+ system and a workstation;
+
+
+ An operating system in combination with a workstation;
+
+
+ A smart card integrated circuit;
+
+
+ The cryptographic co-processor of a smart card integrated
+ circuit;
+
+
+ A Local Area Network including all terminals, servers,
+ network equipment and software;
+
+
+ A database application excluding the remote client
+ software normally associated with that database
+ application.
+
+
+
+
+ In the CC, a TOE can occur in several representations, such
+ as (for a software TOE):
+
+ a list of files in a configuration management
+ system;
+ a single master copy, that has just been
+ compiled;
+ a box containing a CD-ROM and a manual, ready to be
+ shipped to a customer;
+ an installed and operational version.
+
+ All of these are considered to be a TOE: and wherever the
+ term ``TOE'' is used in the remainder of the CC, the context
+ determines the representation that is meant.
+
+
+ In general, IT products can be configured in many ways:
+ installed in different ways, with different options enabled
+ or disabled. As, during a CC evaluation, it will be
+ determined whether a TOE meets certain requirements, this
+ flexibility in configuration may lead to problems, as all
+ possible configurations of the TOE must meet the
+ requirements. For these reasons, it is often the case that
+ the guidance part of the TOE strongly constrains the
+ possible configurations of the TOE. That is: the guidance of
+ the TOE may be different from the general guidance of the IT
+ product.
+ An example is an operating system IT product. This
+ product can be configured in many ways (e.g. types of users,
+ number of users, types of external connections
+ allowed/disallowed, options enabled/disabled etc.).
+ If the same IT product is to be a TOE, and is evaluated
+ against a reasonable set of requirements, the configuration
+ should be much more tightly controlled, as many options
+ (e.g. allow all types of external connections or the system
+ administrator does not need to be authenticated) will lead
+ to a TOE not meeting the requirements.
+ For this reason, there would normally be a difference
+ between the guidance of the IT product (allowing many
+ configurations) and the guidance of the TOE (allowing only
+ one or only configurations that do not differ in
+ security-relevant ways).
+ Note that if the guidance of the TOE still allows more
+ than one configuration, these configurations are
+ collectively called ``the TOE'' and each such configuration
+ must meet the requirements levied on the TOE.
+
+
+
+
+ There are three groups with a general interest in evaluation
+ of the security properties of TOEs: consumers, developers and
+ evaluators. The criteria presented in this document have been
+ structured to support the needs of all three groups. They are
+ all considered to be the principal users of the CC. The three
+ groups can benefit from the criteria as explained in the
+ following paragraphs.
+
+
+ The CC is written to ensure that evaluation fulfils the
+ needs of the consumers as this is the fundamental purpose
+ and justification for the evaluation process.
+
+ Consumers can use the results of evaluations to help decide
+ whether a TOE fulfils their security needs. These security
+ needs are typically identified as a result of both risk
+ analysis and policy direction. Consumers can also use the
+ evaluation results to compare different TOEs.
+
+ The CC gives consumers, especially in consumer groups and
+ communities of interest, an implementation-independent
+ structure, termed the Protection Profile (PP), in which to
+ express their security requirements in an unambiguous
+ manner.
+
+
+
+ The CC is intended to support developers in preparing for
+ and assisting in the evaluation of their TOEs and in
+ identifying security requirements to be satisfied by those
+ TOEs. These requirements are contained in an
+ implementation-dependent construct termed the Security
+ Target (ST). This ST may be based on one or more PPs to show
+ that the ST conforms to the security requirements from
+ consumers as laid down in those PPs.
+
+ The CC can then be used to determine the responsibilities
+ and actions to provide evidence that is necessary to support
+ the evaluation of the TOE against these requirements. It
+ also defines the content and presentation of that
+ evidence.
+
+
+
+ The CC contains criteria to be used by evaluators when
+ forming judgements about the conformance of TOEs to their
+ security requirements. The CC describes the set of general
+ actions the evaluator is to carry out. Note that the CC does
+ not specify procedures to be followed in carrying out those
+ actions. More information on these procedures may be found
+ in Subclause .
+
+
+
+ While the CC is oriented towards specification and
+ evaluation of the IT security properties of TOEs, it may
+ also be useful as reference material to all parties with an
+ interest in or responsibility for IT security. Some of the
+ additional interest groups that can benefit from information
+ contained in the CC are:
+
+
+ system custodians and system security officers
+ responsible for determining and meeting organisational
+ IT security policies and requirements;
+
+
+ auditors, both internal and external, responsible for
+ assessing the adequacy of the security of an IT solution
+ (which may consist of or contain a TOE);
+
+
+ security architects and designers responsible for the
+ specification of security properties of IT products;
+
+
+ accreditors responsible for accepting an IT solution for
+ use within a particular environment;
+
+
+ sponsors of evaluation responsible for requesting and
+ supporting an evaluation; and
+
+
+ evaluation authorities responsible for the management
+ and oversight of IT security evaluation programmes.
+
+
+
+
+
+ The CC is presented as a set of distinct but related parts
+ as identified below. Terms used in the description of the
+ parts are explained in Clause .
+
+
+
+ Part 1, Introduction and general model
+
+ is the introduction to the CC. It defines the general
+ concepts and principles of IT security evaluation and
+ presents a general model of evaluation.
+
+
+
+ Part 2, Security functional components
+
+ establishes a set of functional components that serve as
+ standard templates upon which to base functional
+ requirements for TOEs. CC Part 2 catalogues the set of
+ functional components and organises them in families and
+ classes.
+
+
+
+ Part 3, Security assurance components
+
+ establishes a set of assurance components that serve as
+ standard templates upon which to base assurance
+ requirements for TOEs. CC Part 3 catalogues the set of
+ assurance components and organises them into families
+ and classes. CC Part 3 also defines evaluation criteria
+ for PPs and STs and presents seven pre-defined assurance
+ packages which are called the Evaluation Assurance
+ Levels (EALs).
+
+
+
+ In support of the three parts of the CC listed above, other
+ documents have been published, most notably the CEM []. It is anticipated that other
+ documents will be published, including technical rationale
+ material and guidance documents.
+
+ The following table presents, for the three key target
+ audience groupings, how the parts of the CC will be of
+ interest.
+
+
+
+
+
+
+ Consumers
+
+
+ Developers
+
+
+ Evaluators
+
+
+
+
+
+
+ Part 1
+
+
+ Use for background information and reference
+ purposes. Guidance structure for PPs.
+
+
+ Use for background information and reference
+ purposes. Development of security specifications
+ for TOEs.
+
+
+ Use for background information and reference
+ purposes. Guidance structure for PPs and STs.
+
+
+
+
+ Part 2
+
+
+ Use for guidance and reference when formulating
+ statements of requirements for a TOE.
+
+
+ Use for reference when interpreting statements of
+ functional requirements and formulating functional
+ specifications for TOEs.
+
+
+ Use for reference when interpreting statements of
+ functional requirements.
+
+
+
+
+ Part 3
+
+
+ Use for guidance when determining required levels of
+ assurance.
+
+
+ Use for reference when interpreting statements of
+ assurance requirements and determining assurance
+ approaches of TOEs.
+
+
+ Use for reference when interpreting statements of
+ assurance requirements.
+
+
+
+
+
+ Road map to the Common Criteria
+
+
+
+
+
+ In order to achieve greater comparability between evaluation
+ results, evaluations should be performed within the framework
+ of an authoritative evaluation scheme that sets the standards,
+ monitors the quality of the evaluations and administers the
+ regulations to which the evaluation facilities and evaluators
+ must conform.
+
+ The CC does not state requirements for the regulatory
+ framework. However, consistency between the regulatory
+ frameworks of different evaluation authorities will be
+ necessary to achieve the goal of mutual recognition of the
+ results of such evaluations.
+
+ An example of a regulatory framework is the CCRA (Arrangement
+ on the Recognition of the CC Certificates in the field of IT
+ Security). This arrangement has been executed among a number
+ of evaluation authorities in different countries and provides
+ the conditions for mutual recognition of CC certificates
+ between these evaluation authorities.
+
+ A second way of achieving greater comparability between
+ evaluation results is using a common methodology to achieve
+ these results. For the CC, this methodology has been described
+ in the CEM.
+
+ Use of a common evaluation methodology contributes to the
+ repeatability and objectivity of the results but is not by
+ itself sufficient. Many of the evaluation criteria require the
+ application of expert judgement and background knowledge for
+ which consistency is more difficult to achieve. In order to
+ enhance the consistency of the evaluation findings, the final
+ evaluation results may be submitted to a certification
+ process.
+
+ The certification process is the independent inspection of the
+ results of the evaluation leading to the production of the
+ final certificate or approval, which is normally publicly
+ available. The certification process is a means of gaining
+ greater consistency in the application of IT security
+ criteria.
+
+ The evaluation schemes and certification processes are the
+ responsibility of the evaluation authorities that run such
+ schemes and processes and are outside the scope of the
+ CC.
+
+
+
+
+ A PP is intended to be used as a ``template" for an ST.
+ That is: the PP describes a set of user needs, while an ST
+ that conforms to that PP describes a TOE that satisfies those
+ needs.
+ Note that it is also possible for a PP to be used as a
+ template for another PP. This case is completely similar to
+ that of an ST vs. a PP. For clarity this Annex describes only
+ the ST/PP case, but it holds also for the PP case.
+
+ The allowed type of conformance is determined by the PP. That is, the PP states (in the PP conformance statement, see Subclause B.5) what the allowed types of conformance for the ST are. An ST is only allowed to conform to a PP in a demonstrable manner, if the PP explicitly allows this, whereas an ST can always conform with strict conformance to any PP. This distinction between strict and demonstrable conformance is applicable to each PP to which an ST may claim conformance on an individual basis. This may mean that the ST conforms strictly to some PPs and demonstrably to other PPs.
+
+
+ Restating this in other words, an ST is only allowed to conform
+ to a PP in a demonstrable manner, if the PP explicitly allows
+ this.
+
+
+
+
+
+ Strict conformance is oriented to the PP-author who requires
+ evidence that the requirements in the PP are met, that the ST
+ is an instantiation of the PP, though the ST could be broader
+ than the PP. In essence, the ST specifies that the TOE does at
+ least the same as in the PP, while the operational environment
+ does at most the same as in the PP.
+
+
+
+
+
+ Demonstrable conformance is orientated to the PP-author who
+ requires evidence that the ST is a suitable solution to the
+ generic security problem described in the PP. Where there is a
+ clear subset-superset type relation between PP and ST in the
+ case of strict conformance, the relation is less clear-cut in
+ the case of demonstrable conformance. The general statement is
+ that the ST must be equivalent or more restrictive than the
+ PP.
+
+
+
+
+
+
+ To allow consumer groups and communities of interest to
+ express their security needs, and to facilitate writing STs,
+ the CC provides two special constructs: packages and
+ Protection Profiles (PPs). In the following two Subclauses
+ these constructs are described in more detail, followed by a
+ Subclause on how these constructs can be used.
+
+
+
+ A package is a named set of security requirements. A package
+ is either
+
+ a functional package, containing only SFRs, or
+ an assurance package, containing only SARs.
+ Mixed packages containing both SFRs and SARs are not
+ allowed.
+ A package can be defined by any party and is intended to
+ be re-usable. To this goal it should contain requirements that
+ are useful and effective in combination. Packages can be used
+ in the construction of larger packages, PPs and STs. At
+ present there are no criteria for the evaluation of packages,
+ therefore any set of SFRs or SARs can be a package.
+ Examples of assurance packages are the evaluation
+ assurance levels (EALs) that are defined in CC Part 3. At the
+ time of writing there are no functional packages for this
+ version of the CC.
+
+
+
+ Whereas an ST always describes a specific TOE (e.g. the
+ MinuteGap v18.5 Firewall), a PP is intended to describe a TOE
+ type (e.g. firewalls). The same PP may therefore be used as a
+ template for many different STs to be used in different
+ evaluations. A detailed description of PPs is given in .
+
+ In general an ST describes requirements for a TOE and is
+ written by the developer of that TOE, while a PP describes the
+ general requirements for a TOE type, and is therefore
+ typically written by:
+
+ A user community seeking to come to a consensus on
+ the requirements for a given TOE type;
+ A developer of a TOE, or a group of developers of
+ similar TOEs wishing to establish a minimum baseline for
+ that type of TOE;
+ A government or large corporation specifying its
+ requirements as part of its acquisition process.
+
+
+ The PP determines the allowed type of conformance of the ST to
+ the PP. That is, the PP states (in the PP conformance statement,
+ see Subclause ) what the allowed
+ types of conformance for the ST are:
+
+ if the PP states that strict conformance is required, the ST
+ shall conform to the PP in a strict manner;
+ if the PP states that demonstrable conformance is required,
+ the ST shall conform to the PP in a strict or demonstrable
+ manner.
+ Restating this in other words, an ST is only allowed to
+ conform in a PP in a demonstrable manner, if the PP explicitly
+ allows this.
+ If an ST claims conformance to multiple PPs, it shall
+ conform (as described above) to each PP in the manner ordained
+ by that PP. This may mean that the ST conforms strictly to
+ some PPs and demonstrably to other PPs.
+ Note that either the ST conforms to the PP in question or
+ it does not. The CC does not recognise ``partial" conformance.
+ It is therefore the responsibility of the PP author to ensure
+ the PP is not overly onerous, prohibiting PP/ST authors in
+ claiming conformance to the PP.
+ An ST is equivalent or more restrictive than a PP if:
+
+ all TOEs that meet the PP also meet ST, and
+ all operational environments that meet the ST also
+ meet the PP.
+ or, informally, the ST shall levy the same or more,
+ restrictions on the TOE and the same or less restrictions on
+ the operational environment of the TOE.
+ This general statement can be made more specific for various
+ subclauses of the ST:Security problem definition: The conformance
+ rationale in the ST shall demonstrate that the security
+ problem definition in the ST is equivalent (or more
+ restrictive) than the security problem definition in the
+ PP. This means that:
+
+ all TOEs that would meet the security problem
+ definition in the ST also meet the security problem
+ definition in the PP;
+ all operational environments that would meet the
+ security problem definition in the PP would also meet
+ the security problem definition in the ST.Security objectives: The conformance
+ rationale in the ST shall demonstrate that the security
+ objectives in the ST is equivalent (or more restrictive)
+ than the security objectives in the PP. This means that:
+
+ all TOEs that would meet the security objectives
+ for the TOE in the ST also meet the security
+ objectives for the TOE in the PP;
+ all operational environments that would meet the
+ security objectives for the operational environment in
+ the PP would also meet the security objectives for the
+ operational environment in the ST.
+ If strict conformance for protection profiles is specified then
+ the following requirements apply:
+ Security problem definition: The ST shall
+ contain the security problem definition of the PP, may
+ specify additional threats and OSPs, but may not specify
+ additional assumptions.Security objectives: The ST:
+
+ shall contain all security objectives for the TOE
+ of the PP but may specify additional security
+ objectives for the TOE;
+ shall contain all security objectives for the
+ operational environment (with one exception in the next
+ bullet) but may not specify additional security
+ objectives for the operational environment;
+ may specify that certain objectives for the operational
+ environment in the PP are security objectives for the
+ TOE in the ST. This is called
+ re-assigning a security
+ objective.Security requirements: The ST shall
+ contain all SFRs and SARs in the PP, but may claim
+ additional or hierarchically stronger SFRs and SARs. The
+ completion of operations in the ST must be consistent with
+ that in the PP; either the same completion will be used in
+ the ST as that in the PP or one that makes the requirement
+ more restrictive (the rules of refinement apply).
+
+ If demonstrable conformance for protection profiles is
+ specified then the following requirements apply:
+
+ the ST shall contain a rationale on why the ST is considered
+ to be ``equivalent or more restrictive'' than the PP (see
+ Subclause subclause-link).
+ Demonstrable conformance allows a PP author to describe a
+ common security problem to be solved and provide generic
+ guidelines to the requirements necessary for its resolution,
+ in the knowledge that there is likely to be more than one
+ way of specifying a resolution.
+ PPs can be evaluated (by applying the criteria to them as listed in CC Part 3). The goal
+ of such an evaluation is to demonstrate that the PP is
+ complete, consistent, and technically sound and suitable for
+ use as a template on which to build another PP or an
+ ST.
+ Basing a PP/ST on an evaluated PP has two advantages:
+
+ There is much less risk that there are errors,
+ ambiguities or gaps in the PP. If any problems with a PP
+ (that would have been caught by evaluating that PP) are
+ found during the writing or evaluation of the new ST,
+ significant time may elapse before the PP is
+ corrected.
+ Evaluation of the new PP/ST may often re-use
+ evaluation results of the evaluated PP, resulting in less
+ effort for evaluating the new PP/ST.
+
+
+
+ If an ST claims to be conformant to one or more packages
+ and/or Protection Profiles, the evaluation of that ST will
+ (among other properties of that ST) demonstrate that the ST
+ actually conforms to these packages and/or PPs that they claim
+ conformance to. Details of this determination of conformance
+ can be found in .
+
+ This allows the following process:
+
+ An organisation seeking to acquire a particular type
+ of IT security product develops their security needs into
+ a PP, then has this evaluated and publishes it;
+
+
+ A developer takes this PP, writes an ST that claims
+ conformance to the PP and has this ST evaluated;
+
+
+ The developer then builds a TOE (or uses an existing one)
+ and has this evaluated against the ST.
+
+
+
+ The result is that the developer can prove that his TOE is
+ conformant to the security needs of the organisation: the
+ organisation can therefore acquire that TOE. A similar line of
+ reasoning applies to packages.
+
+
+
+ The CC also allows PPs to conform to other PPs, allowing
+ chains of PPs to be constructed, each based on the previous
+ one(s).
+
+ For instance, one could take a PP for an Integrated Circuit
+ and a PP for a Smart Card OS, and use these to construct a
+ Smart Card PP (IC and OS) that claims conformance to the other
+ two. One could then write a PP on Smart Cards for Public
+ Transport based on the Smart Card PP and a PP on Applet
+ Loading. Finally, a developer could then construct an ST based
+ on this Smart Cards for Public Transport PP.
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CEM
+
+ Common Methodology for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+
+
+ ISO/IEC
+
+ ISO/IEC Directives - Part 2: Rules for the structure and
+ drafting of International Standards.
+
+
+
+
+
+ This multi-part standard, the Common Criteria (CC), is meant to
+ be used as the basis for evaluation of security properties of IT
+ products. By establishing such a common criteria base, the
+ results of an IT security evaluation may be meaningful to a
+ wider audience.
+
+ Certain topics, because they involve specialised techniques or
+ because they are somewhat peripheral to IT security, are
+ considered to be outside the scope of the CC. Some of these are
+ identified below.
+
+
+ The CC does not contain security evaluation criteria
+ pertaining to administrative security measures not related
+ directly to the IT security functionality. However, it is
+ recognised that significant security can often be achieved
+ through or supported by administrative measures such as
+ organisational, personnel, physical, and procedural
+ controls.
+
+
+ The evaluation of some technical physical aspects of IT
+ security such as electromagnetic emanation control is not
+ specifically covered, although many of the concepts
+ addressed will be applicable to that area.
+
+
+ The CC does not address the evaluation methodology under
+ which the criteria should be applied. This methodology is
+ described in the CEM.
+
+
+ The CC does not address the administrative and legal
+ framework under which the criteria may be applied by
+ evaluation authorities. However, it is expected that the CC
+ will be used for evaluation purposes in the context of such
+ a framework.
+
+
+ The procedures for use of evaluation results in
+ accreditation are outside the scope of the CC. Accreditation
+ is the administrative process whereby authority is granted
+ for the operation of an IT product (or collection thereof)
+ in its full operational environment including all of its
+ non-IT parts. The results of the evaluation process are an
+ input to the accreditation process. However, as other
+ techniques are more appropriate for the assessments of
+ non-IT related properties and their relationship to the IT
+ security parts, accreditors should make separate provisions
+ for those aspects.
+
+ The subject of criteria for the assessment of the
+ inherent qualities of cryptographic algorithms is not
+ covered in the CC. Should independent assessment of
+ mathematical properties of cryptography be required, the
+ evaluation scheme under which the CC is applied must make
+ provision for such assessments.
+
+
+ The CC is intentionally flexible, enabling a range of
+ evaluation methods to be applied to a range of security
+ properties of a range of IT products. Therefore care should be
+ exercised to ensure that this flexibility is not misused. For
+ example, the CC should not be used to apply unsuitable
+ evaluation methods, to irrelevant security properties, of
+ inappropriate IT products, resulting in meaningless evaluation
+ results.
+ Consequently, the fact that an IT product has been evaluated
+ has meaning only in the context of the security properties that
+ were evaluated and the evaluation methods that were used.
+ Evaluation authorities should carefully check the products,
+ properties and methods to determine that an evaluation will
+ provide meaningful results. Additionally, purchasers of
+ evaluated products should carefully consider this context to
+ determine whether the evaluated product is useful and applicable
+ to their specific situation and needs.
+
+
+
+
+ The following Subclauses describe the constructs used in
+ representing the assurance classes, families, and
+ components.
+
+ Figure
+ illustrates the SARs defined in this CC Part 3. Note that the
+ most abstract collection of SARs is referred to as a
+ class. Each class contains assurance families, which then
+ contain assurance components, which in turn contain assurance
+ elements. Classes and families are used to provide a taxonomy
+ for classifying SARs, while components are used to specify
+ SARs in a PP/ST.
+
+
+ Figure
+ illustrates the assurance class structure.
+
+
+ Each assurance class is assigned a unique name. The name
+ indicates the topics covered by the assurance
+ class.
+
+ A unique short form of the assurance class name is also
+ provided. This is the primary means for referencing the
+ assurance class. The convention adopted is an ``A''
+ followed by two letters related to the class name.
+
+
+
+ Each assurance class has an introductory Subclause that
+ describes the composition of the class and contains
+ supportive text covering the intent of the class.
+
+
+
+ Each assurance class contains at least one assurance
+ family. The structure of the assurance families is
+ described in the following Subclause.
+
+
+
+
+
+ Figure
+ illustrates the assurance family structure.
+
+
+ Every assurance family is assigned a unique name. The name
+ provides descriptive information about the topics covered
+ by the assurance family. Each assurance family is placed
+ within the assurance class that contains other families
+ with the same intent.
+
+ A unique short form of the assurance family name is also
+ provided. This is the primary means used to reference the
+ assurance family. The convention adopted is that the short
+ form of the class name is used, followed by an underscore,
+ and then three letters related to the family name.
+
+
+
+ The objectives Subclause of the assurance family presents
+ the intent of the assurance family.
+
+ This Subclause describes the objectives, particularly
+ those related to the CC assurance paradigm, that the
+ family is intended to address. The description for the
+ assurance family is kept at a general level. Any specific
+ details required for objectives are incorporated in the
+ particular assurance component.
+
+
+
+ Each assurance family contains one or more assurance
+ components. This Subclause of the assurance family
+ describes the components available and explains the
+ distinctions between them. Its main purpose is to
+ differentiate between the assurance components once it has
+ been determined that the assurance family is a necessary
+ or useful part of the SARs for a PP/ST.
+
+ Assurance families containing more than one component are
+ levelled and rationale is provided as to how the
+ components are levelled. This rationale is in terms of
+ scope, depth, and/or rigour.
+
+
+
+ The application notes Subclause of the assurance family,
+ if present, contains additional information for the
+ assurance family. This information should be of particular
+ interest to users of the assurance family (e.g. PP and ST
+ authors, designers of TOEs, evaluators). The presentation
+ is informal and covers, for example, warnings about
+ limitations of use and areas where specific attention may
+ be required.
+
+
+
+ Each assurance family has at least one assurance
+ component. The structure of the assurance components is
+ provided in the following Subclause.
+
+
+
+
+ Figure illustrates the
+ assurance component structure.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding convention. Those parts of the
+ requirements that are new, enhanced or modified beyond the
+ requirements of the previous component within a hierarchy
+ are bolded.
+
+
+ The component identification Subclause provides
+ descriptive information necessary to identify, categorise,
+ register, and reference a component.
+
+ Every assurance component is assigned a unique name. The
+ name provides descriptive information about the topics
+ covered by the assurance component. Each assurance
+ component is placed within the assurance family that
+ shares its security objective.
+
+ A unique short form of the assurance component name is
+ also provided. This is the primary means used to reference
+ the assurance component. The convention used is that the
+ short form of the family name is used, followed by a
+ period, and then a numeric character. The numeric
+ characters for the components within each family are
+ assigned sequentially, starting from 1.
+
+
+
+ The objectives Subclause of the assurance component, if
+ present, contains specific objectives for the particular
+ assurance component. For those assurance components that
+ have this Subclause, it presents the specific intent of
+ the component and a more detailed explanation of the
+ objectives.
+
+
+
+ The application notes Subclause of an assurance component,
+ if present, contains additional information to facilitate
+ the use of the component.
+
+
+
+ Dependencies among assurance components arise when a
+ component is not self-sufficient, and relies upon the
+ presence of another component.
+
+ Each assurance component provides a complete list of
+ dependencies to other assurance components. Some
+ components may list ``No dependencies'', to indicate that
+ no dependencies have been identified. The components
+ depended upon may have dependencies on other
+ components.
+
+ The dependency list identifies the minimum set of
+ assurance components which are relied upon. Components
+ which are hierarchical to a component in the dependency
+ list may also be used to satisfy the dependency.
+
+ In specific situations the indicated dependencies might
+ not be applicable. The PP/ST author, by providing
+ rationale for why a given dependency is not applicable,
+ may elect not to satisfy that dependency.
+
+
+
+ A set of assurance elements is provided for each assurance
+ component. An assurance element is a security requirement
+ which, if further divided, would not yield a meaningful
+ evaluation result. It is the smallest security requirement
+ recognised in the CC.
+
+ Each assurance element is identified as belonging to one
+ of the three sets of assurance elements:
+
+
+ Developer action elements: the activities that shall
+ be performed by the developer. This set of actions is
+ further qualified by evidential material referenced in
+ the following set of elements. Requirements for
+ developer actions are identified by appending the
+ letter ``D'' to the element number.
+
+
+ Content and presentation of evidence elements: the
+ evidence required, what the evidence shall
+ demonstrate, and what information the evidence shall
+ convey. Requirements for content and presentation of
+ evidence are identified by appending the letter ``C''
+ to the element number.
+
+
+ Evaluator action elements: the activities that shall
+ be performed by the evaluator. This set of actions
+ explicitly includes confirmation that the requirements
+ prescribed in the content and presentation of evidence
+ elements have been met. It also includes explicit
+ actions and analysis that shall be performed in
+ addition to that already performed by the
+ developer. Implicit evaluator actions are also to be
+ performed as a result of developer action elements
+ which are not covered by content and presentation of
+ evidence requirements. Requirements for evaluator
+ actions are identified by appending the letter ``E''
+ to the element number.
+
+
+
+ The developer actions and content and presentation of
+ evidence define the assurance requirements that are used
+ to represent a developer's responsibilities in
+ demonstrating assurance in the TOE meeting the SFRs of a
+ PP or ST.
+
+ The evaluator actions define the evaluator's
+ responsibilities in the two aspects of evaluation. The
+ first aspect is validation of the PP/ST, in accordance
+ with the classes and in Clauses and . The second
+ aspect is verification of the TOE's conformance with its
+ SFRs and SARs. By demonstrating that the PP/ST is valid
+ and that the requirements are met by the TOE, the
+ evaluator can provide a basis for confidence that the TOE
+ in its operational environment solves the defined security
+ problem.
+
+ The developer action elements, content and presentation of
+ evidence elements, and explicit evaluator action elements,
+ identify the evaluator effort that shall be expended in
+ verifying the security claims made in the ST of the
+ TOE.
+
+
+
+
+ Each element represents a requirement to be met. These
+ statements of requirements are intended to be clear,
+ concise, and unambiguous. Therefore, there are no compound
+ sentences: each separable requirement is stated as an
+ individual element.
+
+
+
+ This CC Part 3 contains classes of families and components
+ that are grouped on the basis of related assurance. At the
+ start of each class is a diagram that indicates the families
+ in the class and the components in each family.
+
+
+ In Figure ,
+ above, the class as shown contains a single family. The
+ family contains three components that are linearly
+ hierarchical (i.e. component 2 requires more than component
+ 1, in terms of specific actions, specific evidence, or
+ rigour of the actions or evidence). The assurance families
+ in this CC Part 3 are all linearly hierarchical, although
+ linearity is not a mandatory criterion for assurance
+ families that may be added in the future.
+
+
+
+
+ Figure illustrates
+ the EALs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in an EAL by reference to the actual
+ components defined in the CC.
+
+
+
+ Each EAL is assigned a unique name. The name provides
+ descriptive information about the intent of the EAL.
+
+ A unique short form of the EAL name is also provided. This
+ is the primary means used to reference the EAL.
+
+
+
+ The objectives Subclause of the EAL presents the intent of
+ the EAL.
+
+
+ The application notes Subclause of the EAL, if present,
+ contains information of particular interest to users of the
+ EAL (e.g. PP and ST authors, designers of TOEs targeting
+ this EAL, evaluators). The presentation is informal and
+ covers, for example, warnings about limitations of use and
+ areas where specific attention may be required.
+ A set of assurance components have been chosen for each
+ EAL.
+ A higher level of assurance than that provided by a given
+ EAL can be achieved by:
+
+ including additional assurance components from other
+ assurance families; or
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ assurance levels defined in the CC. While assurance
+ components further decompose into assurance elements,
+ assurance elements cannot be individually referenced by
+ assurance levels. Note that the arrow in the figure
+ represents a reference from an EAL to an assurance component
+ within the class where it is defined.
+
+
+
+
+
+ The structure of the CAPs is similar to that of the EALs. The
+ main difference between these two types of package is the type
+ of TOE they apply to; the EALs applying to component TOEs and
+ the CAPs applying to composed TOEs.
+
+ Figure illustrates
+ the CAPs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in a CAP by reference to the actual
+ components defined in the CC.
+
+
+
+ Each CAP is assigned a unique name. The name provides
+ descriptive information about the intent of the CAP.
+
+ A unique short form of the CAP name is also provided. This
+ is the primary means used to reference the CAP.
+
+
+
+ The objectives Subclause of the CAP presents the intent of
+ the CAP.
+
+
+ The application notes Subclause of the CAP, if present,
+ contains information of particular interest to users of the
+ CAP (e.g. PP and ST authors, integrators of composed TOEs
+ targeting this CAP, evaluators). The presentation is
+ informal and covers, for example, warnings about limitations
+ of use and areas where specific attention may be
+ required.
+ A set of assurance components have been chosen for each
+ CAP.
+ Some dependencies identify the activities performed during
+ the evaluation of the dependent component on which the
+ composed TOE activity relies. Where it is not explicitly
+ identified that the dependency is on a dependent component
+ activity, the dependency is to another evaluation activity
+ of the composed TOE.
+ A higher level of assurance than that provided by a given
+ CAP can be achieved by:
+
+ including additional assurance components from other
+ assurance families; or
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+ The components included in the CAP
+ assurance packages should not be used as augmentations for
+ component TOE evaluations, as this would provide no
+ meaningful assurance for the component.
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ composed assurance packages defined in the CC. While
+ assurance components further decompose into assurance
+ elements, assurance elements cannot be individually
+ referenced by assurance packages. Note that the arrow in the
+ figure represents a reference from a CAP to an assurance
+ component within the class where it is defined.
+
+
+
+
+
+
+
+
+ This clause defines the content and presentation of the
+ functional requirements of the CC, and provides guidance on
+ the organisation of the requirements for new components to be
+ included in an ST. The functional requirements are expressed
+ in classes, families, and components.
+
+
+
+ Figure illustrates the
+ functional class structure in diagrammatic form. Each
+ functional class includes a class name, class introduction,
+ and one or more functional families.
+
+
+
+
+
+ The class name subclause provides information necessary to
+ identify and categorise a functional class. Every
+ functional class has a unique name. The categorical
+ information consists of a short name of three
+ characters. The short name of the class is used in the
+ specification of the short names of the families of that
+ class.
+
+
+
+ The class introduction expresses the common intent or
+ approach of those families to satisfy security
+ objectives. The definition of functional classes does not
+ reflect any formal taxonomy in the specification of the
+ requirements.
+
+ The class introduction provides a figure describing the
+ families in this class and the hierarchy of the components
+ in each family, as explained in subclause .
+
+
+
+
+
+ Figure
+ illustrates the functional family structure in diagrammatic
+ form.
+
+
+
+
+
+ The family name subclause provides categorical and
+ descriptive information necessary to identify and
+ categorise a functional family. Every functional family
+ has a unique name. The categorical information consists of
+ a short name of seven characters, with the first three
+ identical to the short name of the class followed by an
+ underscore and the short name of the family as follows
+ XXX_YYY. The unique short form of the family name provides
+ the principal reference name for the components.
+
+
+
+ The family behaviour is the narrative description of the
+ functional family stating its security objective and a
+ general description of the functional requirements. These
+ are described in greater detail below:
+
+
+ The security objectives of the family
+ address a security problem that may be solved with the
+ help of a TOE that incorporates a component of this
+ family;
+
+
+ The description of the functional
+ requirements summarises all the requirements
+ that are included in the component(s). The description
+ is aimed at authors of PPs, STs and functional
+ packages who wish to assess whether the family is
+ relevant to their specific requirements.
+
+
+
+
+
+ Functional families contain one or more components, any
+ one of which can be selected for inclusion in PPs, STs and
+ functional packages. The goal of this section is to
+ provide information to users in selecting an appropriate
+ functional component once the family has been identified
+ as being a necessary or useful part of their security
+ requirements.
+
+ This section of the functional family description
+ describes the components available, and their
+ rationale. The exact details of the components are
+ contained within each component.
+
+ The relationships between components within a functional
+ family may or may not be hierarchical. A component is
+ hierarchical to another if it offers more security.
+
+ As explained in the descriptions of the
+ families provide a graphical overview of the hierarchy of
+ the components in a family.
+
+
+
+
+ The management clauses contain information for
+ the PP/ST authors to consider as management activities for a
+ given component. The clauses reference components of the
+ management class (FMT), and provide guidance regarding potential
+ management activities that may be applied via operations to
+ those components.
+
+ A PP/ST author may select the indicated management components or
+ may include other management requirements not listed to detail
+ management activities. As such the information should be
+ considered informative.
+
+
+
+
+ The audit requirements contain auditable
+ events for the PP/ST authors to select, if requirements
+ from the class , are included in the
+ PP/ST. These requirements include security relevant events
+ in terms of the various levels of detail supported by the
+ components of the family. For example,
+ an audit note might include actions that are in terms of:
+ Minimal - successful use of the security mechanism; Basic
+ - any use of the security mechanism as well as relevant
+ information regarding the security attributes involved;
+ Detailed - any configuration changes made to the
+ mechanism, including the actual configuration values
+ before and after the change.
+
+ It should be observed that the categorisation of auditable
+ events is hierarchical. For example, when Basic Audit
+ Generation is desired, all auditable events identified as
+ being both Minimal and Basic should be included in the
+ PP/ST through the use of the appropriate assignment
+ operation, except when the higher level event simply
+ provides more detail than the lower level event. When
+ Detailed Audit Generation is desired, all identified
+ auditable events (Minimal, Basic and Detailed) should be
+ included in the PP/ST.
+
+ In the class the rules governing the audit
+ are explained in more detail.
+
+
+
+
+
+ Figure illustrates the
+ functional component structure.
+
+
+
+
+
+ The component identification subclause provides
+ descriptive information necessary to identify, categorise,
+ register and cross-reference a component. The following is
+ provided as part of every functional component:
+
+ A unique name. The name reflects the
+ purpose of the component.
+
+ A short name. A unique short form of the
+ functional component name. This short name serves as the
+ principal reference name for the categorisation,
+ registration and cross-referencing of the component. This
+ short name reflects the class and family to which the
+ component belongs and the component number within the
+ family.
+
+ A hierarchical-to list. A list of other
+ components that this component is hierarchical to and for
+ which this component can be used to satisfy dependencies
+ to the listed components.
+
+
+
+
+ A set of elements is provided for each component. Each
+ element is individually defined and is self-contained.
+
+ A functional element is a security functional requirement
+ that if further divided would not yield a meaningful
+ evaluation result. It is the smallest security functional
+ requirement identified and recognised in the CC.
+
+ When building packages, PPs and/or STs, it is not
+ permitted to select only one or more elements from a
+ component. The complete set of elements of a component
+ must be selected for inclusion in a PP, ST or package.
+
+ A unique short form of the functional element name is
+ provided. For example the requirement name FDP_IFF.4.2
+ reads as follows: F - functional requirement, DP - class
+ ``User data protection'', _IFF -
+ family ``Information flow control
+ functions'', .4 - 4th component named
+ ``Partial elimination of illicit information
+ flows'', .2 - 2nd element of the component.
+
+
+
+
+ Dependencies among functional components arise when a
+ component is not self sufficient and relies upon the
+ functionality of, or interaction with, another component
+ for its own proper functioning.
+
+ Each functional component provides a complete list of
+ dependencies to other functional and assurance
+ components. Some components may list ``No
+ dependencies''. The components depended upon may in
+ turn have dependencies on other components. The list
+ provided in the components will be the direct
+ dependencies. That is only references to the functional
+ requirements that are required for this requirement to
+ perform its job properly. The indirect dependencies, that
+ is the dependencies that result from the depended upon
+ components can be found in
+ of this part of the CC. It is noted that in some cases the
+ dependency is optional in that a number of functional
+ requirements are provided, where each one of them would be
+ sufficient to satisfy the dependency (see for example
+ ).
+
+ The dependency list identifies the minimum functional or
+ assurance components needed to satisfy the security
+ requirements associated with an identified
+ component. Components that are hierarchical to the
+ identified component may also be used to satisfy the
+ dependency.
+
+ The dependencies indicated in CC Part 2 are
+ normative. They must be satisfied within a PP/ST. In
+ specific situations the indicated dependencies might not
+ be applicable. The PP/ST author, by providing the
+ rationale why it is not applicable, may leave the depended
+ upon component out of the package, PP or ST.
+
+
+
+
+
+
+
+
+ The grouping of the components in this part of the CC does not
+ reflect any formal taxonomy.
+
+ This part of the CC contains classes of families and
+ components, which are rough groupings on the basis of related
+ function or purpose, presented in alphabetic order. At the
+ start of each class is an informative diagram that indicates
+ the taxonomy of each class, indicating the families in each
+ class and the components in each family. The diagram is a
+ useful indicator of the hierarchical relationship that may
+ exist between components.
+
+ In the description of the functional components, a section
+ identifies the dependencies between the component and any
+ other components.
+
+ In each class a figure describing the family hierarchy similar
+ to Figure , is provided. In Figure
+ the first family, Family 1,
+ contains three hierarchical components, where component 2 and
+ component 3 can both be used to satisfy dependencies on
+ component 1. Component 3 is hierarchical to component 2 and
+ can also be used to satisfy dependencies on component 2.
+
+
+
+
+ In Family 2 there are three components not all of which are
+ hierarchical. Components 1 and 2 are hierarchical to no other
+ components. Component 3 is hierarchical to component 2, and
+ can be used to satisfy dependencies on component 2, but not to
+ satisfy dependencies on component 1.
+
+ In Family 3, components 2, 3, and 4 are hierarchical to
+ component 1. Components 2 and 3 are both hierarchical to
+ component 1, but non-comparable. Component 4 is hierarchical
+ to both component 2 and component 3.
+
+ These diagrams are meant to complement the text of the
+ families and make identification of the relationships
+ easier. They do not replace the ``Hierarchical
+ to:'' note in each component that is the mandatory
+ claim of hierarchy for each component.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding
+ convention. This bolding convention calls for the bolding of
+ all new requirements. For hierarchical components,
+ requirements are bolded when they are
+ enhanced or modified beyond the requirements of the previous
+ component. In addition, any new or enhanced permitted
+ operations beyond the previous component are also
+ highlighted using bold type.
+
+
+
+
+
+ This annex contains additional guidance for the families and
+ components defined in the elements of this CC Part 2, which
+ may be required by users, developers or evaluators to use the
+ components. To facilitate finding the appropriate information,
+ the presentation of the classes, families and components in
+ this annex is similar to the presentation within the elements.
+
+
+
+ This clause defines the content and presentation of the notes
+ related to functional requirements of the CC.
+
+
+
+ Figure below
+ illustrates the functional class structure in this annex.
+
+
+
+
+
+ This is the unique name of the class defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The class introduction in this annex provides information
+ about the use of the families and components of the
+ class. This information is completed with the informative
+ diagram that describes the organisation of each class with
+ the families in each class and the hierarchical
+ relationship between components in each family.
+
+
+
+
+
+ Figure illustrates
+ the functional family structure for application notes in
+ diagrammatic form.
+
+
+
+
+
+ This is the unique name of the family defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The user notes contain additional information that is of
+ interest to potential users of the family, that is PP, ST
+ and functional package authors, and developers of TOEs
+ incorporating the functional components. The presentation
+ is informative, and might cover warnings about limitations
+ of use and areas where specific attention might be
+ required when using the components.
+
+
+
+
+ The evaluator notes contain any information that is of
+ interest to developers and evaluators of TOEs that claim
+ compliance with a component of the family. The
+ presentation is informative and can cover a variety of
+ areas where specific attention might be needed when
+ evaluating the TOE. This can include clarifications of
+ meaning and specification of the way to interpret
+ requirements, as well as caveats and warnings of specific
+ interest to evaluators.
+
+ These User Notes and Evaluator Notes sections are not
+ mandatory and appear only if appropriate.
+
+
+
+
+
+ Figure illustrates
+ the functional component structure for the application
+ notes.
+
+
+
+
+
+ This is the unique name of the component defined within
+ the normative elements of this part of the CC.
+
+
+
+
+ Any specific information related to the component can be
+ found in this section.
+
+
+ The rationale contains the specifics
+ of the rationale that refine the general statements on
+ rationale for the specific level, and should only be
+ used if level specific amplification is required.
+
+
+ The application notes contain
+ additional refinement in terms of narrative
+ qualification as it pertains to a specific
+ component. This refinement can pertain to user notes,
+ and/or evaluator notes as described in Subclause . This refinement can be
+ used to explain the nature of the dependencies
+ (e.g. shared information, or shared operation).
+
+
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+ This portion of each component contains advice relating to
+ the permitted operations of the component.
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+
+ The following dependency tables for functional components
+ show their direct, indirect and optional dependencies. Each
+ of the components that is a dependency of some functional
+ component is allocated a column. Each functional component is
+ allocated a row. The value in the table cell indicate whether
+ the column label component is directly required (indicated by
+ a cross ``X''), indirectly required (indicated by a
+ dash ``-''), or optionally required (indicated by a
+ ``o'') by the row label component. An example of a
+ component with optional dependencies is , which requires either
+ or to be present. So if is present, is not
+ necessary and vice versa. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+ The following abbreviations are used in one or more parts of the
+ CC:
+
+ API
+
+ Application Programming Interface
+
+
+
+ CAP
+
+ Composed Assurance Package
+
+
+
+ CC
+
+ Common Criteria
+
+
+
+ CCRAArrangement on the
+ Recognition of Common Criteria Certificates in the field of IT
+ Security
+
+
+
+ DAC
+
+ Discretionary Access Control
+
+
+
+ EAL
+
+ Evaluation Assurance Level
+
+
+
+ GHz
+
+ Gigahertz
+
+
+
+ GUI
+
+ Graphical User Interface
+
+
+
+ IC
+
+ Integrated Circuit
+
+
+
+ IOCTL
+
+ Input Output Control
+
+
+
+ IP
+
+ Internet Protocol
+
+
+
+ IT
+
+ Information Technology
+
+
+
+ MB
+
+ Mega Byte
+
+
+
+ OS
+
+ Operating System
+
+
+
+ OSP
+
+ Organisational Security Policy
+
+
+
+ PC
+
+ Personal Computer
+
+
+
+ PCI
+
+ Peripheral Component Interconnect
+
+
+
+ PKI
+
+ Public Key Infrastructure
+
+
+
+ PP
+
+ Protection Profile
+
+
+
+ RAM
+
+ Random Access Memory
+
+
+
+ RPC
+
+ Remote Procedure Call
+
+
+
+ SAR
+
+ Security Assurance Requirement
+
+
+
+ SFR
+
+ Security Functional Requirement
+
+
+
+ SFP
+
+ Security Function Policy
+
+
+
+ ST
+
+ Security Target
+
+
+
+ TCP
+
+ Transmission Control Protocol
+
+
+
+ TOE
+
+ Target of Evaluation
+
+
+
+ TSF
+
+ TOE Security Functionality
+
+
+
+ TSFI
+
+ TSF Interface
+
+
+
+ VPN
+
+ Virtual Private Network
+
+
+
+
+
+
+ Security auditing involves recognising, recording, storing,
+ and analysing information related to security relevant
+ activities (i.e. activities controlled by the TSF). The
+ resulting audit records can be examined to determine which
+ security relevant activities took place and whom (which user)
+ is responsible for them.
+
+
+
+ CC audit families allow PP/ST authors the ability to define
+ requirements for monitoring user activities and, in some
+ cases, detecting real, possible, or imminent violations of
+ the enforcement of the SFRs. The TOE's security audit functions are
+ defined to help monitor security-relevant events, and act as a
+ deterrent against security violations. The requirements of the
+ audit families refer to functions that include audit data
+ protection, record format, and event selection, as well as
+ analysis tools, violation alarms, and real-time analysis. The
+ audit trail should be presented in human-readable format
+ either directly (e.g. storing the audit trail in
+ human-readable format) or indirectly (e.g. using audit
+ reduction tools), or both.
+
+ While developing the security audit requirements, the PP/ST
+ author should take note of the inter-relationships among the
+ audit families and components. The potential exists to specify
+ a set of audit requirements that comply with the
+ family/component dependencies lists, while at the same time
+ resulting in a deficient audit function (e.g. an audit
+ function that requires all security relevant events to be
+ audited but without the selectivity to control them on any
+ reasonable basis such as individual user or object).
+
+
+ The implementation of audit requirements for networks and
+ other large systems may differ significantly from those
+ needed for stand-alone systems. Larger, more complex and
+ active systems require more thought concerning which audit
+ data to collect and how this should be managed, due to
+ lowered feasibility of interpreting (or even storing) what
+ gets collected. The traditional notion of a time-ordered list
+ or ``trail'' of audited events may not
+ be applicable in a global asynchronous network with
+ arbitrarily many events occurring at once.
+
+ Also, different hosts and servers on a distributed TOE may
+ have differing naming policies and values. Symbolic names
+ presentation for audit review may require a net-wide
+ convention to avoid redundancies and ``name
+ clashes.''
+
+ A multi-object audit repository, portions of which are
+ accessible by a potentially wide variety of authorised
+ users, may be required if audit repositories are to serve a
+ useful function in distributed systems.
+
+ Finally, misuse of authority by authorised users should be
+ addressed by systematically avoiding local storage of audit
+ data pertaining to administrator actions.
+
+
+
+
+
+
+ This family defines the response to be taken in case of
+ detected events indicative of a potential security
+ violation.
+
+
+
+ The Security audit automatic response family describes
+ requirements for the handling of audit events. The
+ requirement could include requirements for alarms or TSF
+ action (automatic response). For example, the TSF could
+ include the generation of real time alarms, termination of
+ the offending process, disabling of a service, or
+ disconnection or invalidation of a user account.
+
+ An audit event is defined to be an ``potential
+ security violation'' if so indicated by the
+ components.
+
+
+
+
+
+
+
+
+ An action should be taken for follow up action in the
+ event of an alarm. This action can be to inform the
+ authorised user, to present the authorised user with a set
+ of possible containment actions, or to take corrective
+ actions. The timing of the actions should be carefully
+ considered by the PP/ST author.
+
+
+
+ At , the TSF shall take actions in
+ case a potential security violation is detected.
+
+
+ the management (addition, removal, or modification) of
+ actions.
+
+
+ Actions taken due to potential security violations.
+
+
+ The TSF shall take
+
+
+ list of actions
+
+
+
+ the PP/ST author should specify the actions to be taken
+ in case of a potential security violation. An example of
+ such a list is: ``inform the authorised user, disable
+ the subject that created the potential security
+ violation.'' It can also specify that the action to be
+ taken can be specified by an authorised user.
+
+
+ upon detection of a potential security violation.
+
+
+
+
+
+
+
+ This family defines requirements for recording the
+ occurrence of security relevant events that take place under
+ TSF control. This family identifies the level of auditing,
+ enumerates the types of events that shall be auditable by
+ the TSF, and identifies the minimum set of audit-related
+ information that should be provided within various audit
+ record types.
+
+
+
+ The Security audit data generation family includes
+ requirements to specify the audit events that should be
+ generated by the TSF for security-relevant events.
+
+ This family is presented in a manner that avoids a dependency
+ on all components requiring audit support. Each component has
+ an audit section developed in which the events to be audited
+ for that functional area are listed. When the PP/ST author
+ assembles the PP/ST, the items in the audit area are used to
+ complete the variable in this component. Thus, the
+ specification of what could be audited for a functional area
+ is localised in that functional area.
+
+ The list of auditable events is entirely dependent on the
+ other functional families within the PP/ST. Each family
+ definition should therefore include a list of its
+ family-specific auditable events. Each auditable event in the
+ list of auditable events specified in the functional family
+ should correspond to one of the levels of audit event
+ generation specified in this family (i.e. minimal, basic,
+ detailed). This provides the PP/ST author with information
+ necessary to ensure that all appropriate auditable events are
+ specified in the PP/ST. The following example shows how
+ auditable events are to be specified in appropriate functional
+ families:
+
+ ``The following actions should be auditable if is included in the PP/ST:
+
+
+ Minimal: Successful use of the user security attribute
+ administration functions;
+
+
+ Basic: All attempted uses of the user security attribute
+ administration functions;
+
+
+ Basic: Identification of which user security attributes
+ have been modified;
+
+
+ Detailed: With the exception of specific sensitive
+ attribute data items (e.g. passwords, cryptographic
+ keys), the new values of the attributes should be
+ captured.''
+
+
+
+ For each functional component that is chosen, the auditable
+ events that are indicated in that component, at and below the
+ level indicated in should be
+ auditable. If, for example, in the previous example ``Basic''
+ would be selected in , the
+ auditable events mentioned in a), b) and c) should be
+ auditable.
+
+ Observe that the categorisation of auditable events is
+ hierarchical. For example, when Basic Audit Generation is
+ desired, all auditable events identified as being either
+ Minimal or Basic, should also be included in the PP/ST
+ through the use of the appropriate assignment operation,
+ except when the higher level event simply provides more
+ detail than the lower level event. When Detailed Audit
+ Generation is desired, all identified auditable events
+ (Minimal, Basic, and Detailed) should be included in the
+ PP/ST.
+
+ A PP/ST author may decide to include other auditable events
+ beyond those required for a given audit level. For example,
+ the PP/ST may claim only minimal audit capabilities while
+ including most of the basic capabilities because the few
+ excluded capabilities conflict with other PP/ST constraints
+ (e.g. because they require the collection of unavailable
+ data).
+
+ The functionality that creates the auditable event should be
+ specified in the PP or ST as a functional requirement.
+
+ The following are examples of the types of the events that
+ should be defined as auditable within each PP/ST functional
+ component:
+
+
+ Introduction of objects within the control of the TSF into a
+ subject's address space;
+
+
+ Deletion of objects;
+
+
+ Distribution or revocation of access rights or
+ capabilities;
+
+
+ Changes to subject or object security attributes;
+
+
+ Policy checks performed by the TSF as a result of a
+ request by a subject;
+
+
+ The use of access rights to bypass a policy check;
+
+
+ Use of Identification and Authentication functions;
+
+
+ Actions taken by an operator, and/or authorised user
+ (e.g. suppression of a TSF protection mechanism as
+ human-readable labels);
+
+
+ Import/export of data from/to removable media
+ (e.g. printed output, tapes, diskettes).
+
+
+
+
+
+
+
+
+
+
+ This component defines requirements to identify the
+ auditable events for which audit records should be
+ generated, and the information to be provided in the audit
+ records.
+
+ by itself might be used
+ when the SFRs do not require that individual user identities
+ be associated with audit events. This could be appropriate
+ when the PP/ST also contains privacy requirements. If the
+ user identity must be incorporated could be used in addition.
+
+ If the subject is a user, the user identity may be recorded as
+ the subject identity. The identity of the user may not yet been
+ verified if has not been
+ applied. Therefore in the instance of an invalid login the
+ claimed user identity should be recorded. It should be
+ considered to indicate when a recorded identity has not been
+ authenticated.
+
+
+
+ There is a dependency on . If correctness of time is not an issue for
+ this TOE, elimination of this dependency could be
+ justified.
+
+
+
+ defines the level of auditable
+ events, and specifies the list of data that shall be
+ recorded in each record.
+
+
+ The TSF shall be able to generate an audit record of the
+ following auditable events:
+
+
+ Start-up and shutdown of the audit functions;
+
+
+ All auditable events for the
+
+ minimum
+ basic
+ detailed
+ not specified
+
+
+ the PP/ST author should select the level of
+ auditable events called out in the audit section of
+ other functional components included in the
+ PP/ST. This level is one of the following:
+ ``minimum'', ``basic'', ``detailed'' or ``not
+ specified''.
+
+
+ level of audit; and
+
+
+
+
+ other specifically defined auditable events
+
+
+
+ the PP/ST author should assign a list of other
+ specifically defined auditable events to be included
+ in the list of auditable events. The assignment may
+ comprise none, or events that could be auditable
+ events of a functional requirement that are of a
+ higher audit level than requested in , as well as the
+ events generated through the use of a specified
+ Application Programming Interface (API).
+
+ .
+
+
+
+
+ The TSF shall record within each audit record at least the
+ following information:
+
+
+ Date and time of the event, type of event, subject identity (if
+ applicable), and the outcome (success or failure) of the event;
+ and
+
+
+ For each audit event type, based on the auditable event
+ definitions of the functional components included in the
+ PP/ST,
+
+
+ other audit relevant information
+
+
+
+ the PP/ST author should assign, for each auditable
+ events included in the PP/ST, either a list of other
+ audit relevant information to be included in audit
+ events records or none.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ This component addresses the requirement of accountability
+ of auditable events at the level of individual user
+ identity. This component should be used in addition to
+ .
+
+ There is a potential conflict between the audit and privacy
+ requirements. For audit purposes it may be desirable to know
+ who performed an action. The user may want to keep his/her
+ actions to himself/herself and not be identified by other
+ persons (e.g. a site with job offers). Or it might be
+ required in the Organisational Security Policy that the
+ identity of the users must be protected. In those cases the
+ objectives for audit and privacy might contradict each
+ other. Therefore if this requirement is selected and privacy
+ is important, inclusion of the component user pseudonimity
+ might be considered. Requirements on determining the real
+ user name based on its pseudonym are specified in the
+ privacy class.
+
+ If the identity of the user has not yet been verified through
+ authentication, in the instance of an invalid login the claimed
+ user identity should be recorded. It should be considered to
+ indicate when a recorded identity has not been authenticated.
+
+
+
+ At , the TSF shall associate
+ auditable events to individual user identities.
+
+
+ For audit events resulting from actions of identified users, the
+ TSF shall be able to associate each auditable event with the
+ identity of the user that caused the event.
+
+
+
+
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible or
+ real security violations. This analysis may work in support of
+ intrusion detection, or automatic response to a potential
+ security violation.
+
+ The actions to be taken based on the detection can be
+ specified using the family as
+ desired.
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible
+ or real security violations. This analysis may work in
+ support of intrusion detection, or automatic response to a
+ potential security violation.
+
+ The action to be performed by the TSF on detection of a
+ potential violation is defined in components.
+
+ For real-time analysis, audit data could be transformed into a
+ useful format for automated treatment, but into a different
+ useful format for delivery to authorised users for
+ review.
+
+
+
+
+
+
+
+
+ This component is used to specify the set of auditable
+ events whose occurrence or accumulated occurrence held to
+ indicate a potential violation of the enforcement of the
+ SFRs, and any rules to be used to perform the violation
+ analysis.
+
+
+
+ In , basic threshold
+ detection on the basis of a fixed rule set is
+ required.
+
+
+ maintenance of the rules by (adding, modifying, deletion)
+ of rules from the set of rules.
+
+
+ Enabling and disabling of any of the analysis mechanisms;
+
+
+ Automated responses performed by the tool.
+
+
+ The TSF shall be able to apply a set of rules in monitoring
+ the audited events and based upon these rules indicate a
+ potential violation of the enforcement of the SFRs.
+
+
+ The TSF shall enforce the following rules for monitoring
+ audited events:
+
+
+ Accumulation or combination of
+
+
+ subset of defined auditable events
+
+
+
+ the PP/ST author should identify the subset of
+ defined auditable events whose occurrence or
+ accumulated occurrence need to be detected as an
+ indication of a potential violation of the
+ enforcement of the SFRs.
+
+
+ known to indicate a potential security violation;
+
+
+
+
+ any other rules
+
+
+
+ the PP/ST author should specify any other rules that
+ the TSF should use in its analysis of the audit
+ trail. Those rules could include specific
+ requirements to express the needs for the events to
+ occur in a certain period of time (e.g. period of
+ the day, duration). If there are no additional
+ rules that the TSF should use in the analysis of the
+ audit trail, this assignment can be completed with
+ ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ A profile is a structure that
+ characterises the behaviour of users and/or subjects; it
+ represents how the users/subjects interact with the TSF in
+ a variety of ways. Patterns of usage are established with
+ respect to the various types of activity the
+ users/subjects engage in (e.g. patterns in exceptions
+ raised, patterns in resource utilisation (when, which,
+ how), patterns in actions performed). The ways in which
+ the various types of activity are recorded in the profile
+ (e.g. resource measures, event counters, timers) are
+ referred to as profile metrics.
+
+ Each profile represents the expected patterns of usage
+ performed by members of the profile target
+ group. This pattern may be based on past use
+ (historical patterns) or on normal use for users of
+ similar target groups (expected behaviour). A profile
+ target group refers to one or more users who interact with
+ the TSF. The activity of each member of the profile group
+ is used by the analysis tool in establishing the usage
+ patterns represented in the profile. The following are
+ some examples of profile target groups:
+
+
+ Single user account: one profile per
+ user;
+
+
+ Group ID or Group Account: one profile
+ for all users who possess the same group ID or operate
+ using the same group account;
+
+
+ Operating Role: one profile for all users
+ sharing a given operating role;
+
+
+ System: one profile for all users of a
+ system.
+
+
+
+ Each member of a profile target group is assigned an
+ individual suspicion rating that
+ represents how closely that member's new
+ activity corresponds to the established patterns of usage
+ represented in the group profile.
+
+ The sophistication of the anomaly detection tool will
+ largely be determined by the number of target profile
+ groups required by the PP/ST and the complexity of the
+ required profile metrics.
+
+
+ The PP/ST author should enumerate specifically what activity
+ should be monitored and/or analysed by the TSF. The PP/ST
+ author should also identify specifically what information
+ pertaining to the activity is necessary to construct the
+ usage profiles.
+
+ requires that the TSF
+ maintain profiles of system usage. The word maintain implies
+ that the anomaly detector is actively updating the usage
+ profile based on new activity performed by the profile
+ target members. It is important here that the metrics for
+ representing user activity are defined by the PP/ST
+ author. For example, there may be a thousand different
+ actions an individual may be capable of performing, but the
+ anomaly detector may choose to monitor a subset of that
+ activity. Anomalous activity gets integrated into the
+ profile just like non-anomalous activity (assuming the tool
+ is monitoring those actions). Things that may have appeared
+ anomalous four months ago, might over time become the norm
+ (and vice-versa) as the user's work duties change. The TSF
+ wouldn't be able to capture this notion if it filtered out
+ anomalous activity from the profile updating
+ algorithms.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ suspicion rating.
+
+ The PP/ST author should define how to interpret suspicion
+ ratings and the conditions under which anomalous activity is
+ indicated to the
+ mechanism.
+
+
+
+ In , the TSF maintains
+ individual profiles of system usage, where a profile
+ represents the historical patterns of usage performed by
+ members of the profile target group. A profile target group
+ refers to a group of one or more individuals (e.g. a single
+ user, users who share a group ID or group account, users who
+ operate under an assigned role, users of an entire system or
+ network node) who interact with the TSF. Each member of a
+ profile target group is assigned an individual suspicion
+ rating that represents how well that member's current
+ activity corresponds to the established patterns of usage
+ represented in the profile. This analysis can be performed
+ at runtime or during a post-collection batch-mode
+ analysis.
+
+
+ maintenance (deletion, modification, addition) of the
+ group of users in the profile target group.
+
+
+
+ The TSF shall be able to maintain profiles of system usage,
+ where an individual profile represents the historical
+ patterns of usage performed by the member(s) of
+
+
+ the profile target group
+
+
+
+ the PP/ST author should specify the profile target
+ group. A single PP/ST may include multiple profile
+ target groups.
+
+ .
+
+
+ The TSF shall be able to maintain a suspicion rating
+ associated with each user whose activity is recorded in a
+ profile, where the suspicion rating represents the degree to
+ which the user's current activity is found
+ inconsistent with the established patterns of usage
+ represented in the profile.
+
+
+ The TSF shall be able to indicate a possible violation of
+ the enforcement of the SFRs when a user's suspicion rating exceeds
+ the following threshold conditions
+
+
+ conditions under which anomalous activity is reported by
+ the TSF
+
+
+
+ the PP/ST author should specify conditions under which
+ anomalous activity is reported by the TSF. Conditions
+ may include the suspicion rating reaching a certain
+ value, or be based on the type of anomalous activity
+ observed.
+
+ .
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant that they are always worthy of
+ independent review. Example of such events include the
+ deletion of a key TSF security data file (e.g. the
+ password file) or activity such as a remote user
+ attempting to gain administrative privilege. These events
+ are referred to as signature events in that their
+ occurrence in isolation from the rest of the system
+ activity are indicative of intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data).
+
+ The elements of do not
+ require that the TSF implementing the immediate attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able
+ to detect the occurrence of signature events that represent
+ a significant threat to enforcement of the SFRs. This search
+ for signature events may occur in real-time or during a
+ post-collection batch-mode analysis.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of system
+ events whose occurrence, in isolation from all other
+ system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by
+ themselves indicate a clear violation to the enforcement
+ of the SFRs, or whose occurrence is so significant that
+ they warrant actions.
+
+
+ that may indicate a violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events
+ against the record of system activity discernible from an
+ examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when a system event is found to match
+ a signature event that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant they are always worthy of independent
+ review. Example of such events include the deletion of a key
+ TSF security data file (e.g. the password file) or activity
+ such as a remote user attempting to gain administrative
+ privilege. These events are referred to as signature events
+ in that their occurrence in isolation from the rest of the
+ system activity are indicative of intrusive activity. Event
+ sequences are an ordered set of signature events that might
+ indicate intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events and event sequences.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data). Levelling, therefore, requires the
+ PP/ST author to specify the type of input data used to
+ monitor system activity.
+
+ The elements of do not
+ require that the TSF implementing the complex attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able to
+ represent and detect multi-step intrusion scenarios. The
+ TSF is able to compare system events (possibly performed
+ by multiple individuals) against event sequences known to
+ represent entire intrusion scenarios. The TSF shall be
+ able to indicate when a signature event or event sequence
+ is found that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events;
+
+
+ maintenance (deletion, modification, addition) of the set of
+ sequence of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following event sequences of known intrusion
+ scenarios
+
+
+ list of sequences of system events whose occurrence are
+ representative of known penetration scenarios
+
+
+
+ the PP/ST author should identify a base set of list of
+ sequences of system events whose occurrence are
+ representative of known penetration scenarios. These
+ event sequences represent known penetration
+ scenarios. Each event represented in the sequence should
+ map to a monitored system event, such that as the system
+ events are performed, they are bound (mapped) to the
+ known penetration event sequences.
+
+
+ and the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of
+ system events whose occurrence, in isolation from all
+ other system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by themselves indicate
+ a clear violation to the SFRs, or whose occurrence is
+ so significant they warrant action.
+
+
+ that may indicate a potential
+ violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events and
+ event sequences against the record of system activity
+ discernible from an examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when system activity is found to match
+ a signature event or event sequence that indicates a potential
+ violation of the enforcement of the SFRs.
+
+
+
+
+
+
+
+ This family defines the requirements for audit tools that
+ should be available to authorised users to assist in the
+ review of audit data.
+
+
+
+ The Security audit review family defines requirements
+ related to review of the audit information.
+
+ These functions should allow pre-storage or post-storage
+ audit selection that includes, for example, the ability to
+ selectively review:
+
+
+ the actions of one or more users (e.g. identification,
+ authentication, TOE entry, and access control actions);
+
+
+ the actions performed on a specific object or TOE
+ resource;
+
+
+ all of a specified set of audited exceptions;
+ or
+
+
+ actions associated with a specific SFR attribute.
+
+
+
+ The distinction between audit reviews is based on
+ functionality. Audit review (only) encompasses the ability to
+ view audit data. Selectable review is more sophisticated, and
+ requires the ability to select subsets of audit data based on a
+ single criterion or multiple criteria with logical (i.e. and/or)
+ relations, and order the audit data before it is
+ reviewed.
+
+
+
+
+
+
+
+
+ This component will provide authorised users the
+ capability to obtain and interpret the information. In
+ case of human users this information needs to be in a
+ human understandable presentation. In case of external IT
+ entities the information needs to be unambiguously
+ represented in an electronic fashion.
+
+
+
+ This component is used to specify that users and/or
+ authorised users can read the audit records. These audit
+ records will be provided in a manner appropriate to the
+ user. There are different types of users (human users,
+ machine users) that might have different needs.
+
+ The content of the audit records that can be viewed can be
+ specified.
+
+
+
+ , provides the capability to read
+ information from the audit records.
+
+
+ maintenance (deletion, modification, addition) of the group
+ of users with read access right to the audit records.
+
+
+ Reading of information from the audit records.
+
+
+ The TSF shall provide
+
+
+ authorised users
+
+
+
+ the PP/ST author should specify the authorised users
+ that can use this capability. If appropriate the PP/ST
+ author may include security roles (see ).
+
+
+ with the capability to read
+
+
+ list of audit information
+
+
+
+ the PP/ST author should specify the type of information
+ the specified user is permitted to obtain from the audit
+ records. Examples are ``all'', ``subject identity'',
+ ``all information belonging to audit records referencing
+ this user''. When employing the SFR, FAU_SAR.1, it is not
+ necessary to repeat, in full detail, the list of audit
+ information first specified in FAU_GEN.1. Use of terms
+ such as ``all'' or ``all audit information'' assist in
+ eliminating ambiguity and the further need for
+ comparative analysis between the two security
+ requirements.
+
+
+ from the audit records.
+
+
+ The TSF shall provide the audit records in a manner suitable
+ for the user to interpret the information.
+
+
+
+
+
+
+
+
+
+ This component specifies that any users not identified in
+ will not be able to read
+ the audit records.
+
+
+
+ , requires that there are
+ no other users except those that have been identified in
+ that can read the
+ information.
+
+
+ Unsuccessful attempts to read information from the audit
+ records.
+
+
+ The TSF shall prohibit all users read access to the audit
+ records, except those users that have been granted explicit
+ read-access.
+
+
+
+
+
+
+
+
+
+ This component is used to specify that it should be
+ possible to perform selection of the audit data to be
+ reviewed. If based on multiple criteria, those criteria
+ should be related together with logical
+ (i.e. ``and'' or
+ ``or'') relations, and the tools
+ should provide the ability to manipulate audit data
+ (e.g. sort, filter).
+
+
+
+ , requires audit review
+ tools to select the audit data to be reviewed based on
+ criteria.
+
+
+ the parameters used for the viewing.
+
+
+ The TSF shall provide the ability to apply
+
+ methods of selection and/or ordering
+
+ the PP/ST author should specify whether capabilities to
+ select and/or order audit data is required from the
+ TSF.
+ of audit data based on
+
+ criteria with logical relations
+
+ the PP/ST author should assign the criteria, possibly
+ with logical relations, to be used to select the audit
+ data for review. The logical relations are intended to
+ specify whether the operation can be on an individual
+ attribute or a collection of attributes. An example of
+ this assignment could be: ``application, user account
+ and/or location''. In this case the operation could be
+ specified using any combination of the three attributes:
+ application, user account and location..
+
+
+
+
+
+
+
+ This family defines requirements to select the set of events to
+ be audited during TOE operation from the set of all auditable
+ events.
+
+
+
+ The Security audit event selection family provides
+ requirements related to the capabilities of identifying which
+ of the possible auditable events are to be audited. The
+ auditable events are defined in the family, but those events should be defined as
+ being selectable in this component to be audited.
+
+ This family ensures that it is possible to keep the audit
+ trail from becoming so large that it becomes useless, by
+ defining the appropriate granularity of the selected
+ security audit events.
+
+
+
+
+
+
+
+
+
+ This component defines the selection criteria used, and the
+ resulting audited subsets of the set of all auditable events,
+ based on user attributes, subject attributes, object attributes,
+ or event types.
+
+ The existence of individual user identities is not assumed
+ for this component. This allows for TOEs such as routers
+ that may not support the notion of users.
+
+ For a distributed environment, the host identity could be
+ used as a selection criteria for events to be audited.
+
+ The management function
+ will handle the rights of authorised users to query or
+ modify the selections.
+
+
+
+ requires the ability to select the set of events to be audited
+ from the set of all auditable events, identified in , based upon attributes to be
+ specified by the PP/ST author.
+
+
+ maintenance of the rights to view/modify the audit events.
+
+
+ All modifications to the audit configuration that occur
+ while the audit collection functions are operating.
+
+
+ The TSF shall be able to select the set of audited events from
+ the set of all auditable events based on the following
+ attributes:
+ object identityuser identitysubject identityhost identityevent type
+ the PP/ST author should select whether the
+ security attributes upon which audit selectivity
+ is based, is related to object identity, user
+ identity, subject identity, host identity, or
+ event type.
+ list of additional attributes that audit selectivity
+ is based upon
+
+ the PP/ST author should specify any additional
+ attributes upon which audit selectivity is based. If
+ there are no additional rules upon which audit
+ selectivity is based, this assignment can be
+ completed with ``none''.
+
+
+
+
+
+
+ This family defines the requirements for the TSF to be able
+ to create and maintain a secure audit trail. Stored audit
+ records refers to those records within the audit trail, and
+ not the audit records that have been retrieved (to temporary
+ storage) through selection.
+
+
+
+ The Security audit event storage family describes
+ requirements for storing audit data for later use, including
+ requirements controlling the loss of audit information due
+ to TOE failure, attack and/or exhaustion of storage
+ space.
+
+
+
+
+
+
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+ The TSF will protect the stored audit records in the audit trail from unauthorised
+ deletion and modification. It is noted that in some TOEs the
+ auditor (role) might not be authorised to delete the audit
+ records for a certain period of time.
+
+
+
+ At , requirements are
+ placed on the audit trail. It will be protected from
+ unauthorised deletion and/or modification.
+
+
+ The TSF shall protect the stored audit records in the audit
+ trail from unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+
+
+
+
+
+
+
+
+ This component allows the PP/ST author to specify to which
+ metrics the audit trail should conform.
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+
+
+ , specifies the guarantees
+ that the TSF maintains over the audit data given the
+ occurrence of an undesired condition.
+
+
+ maintenance of the parameters that control the audit storage
+ capability.
+
+
+ The TSF shall protect the stored audit records in the audit trail from
+ unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+ The TSF shall ensure that
+
+
+ metric for saving audit records
+
+
+
+ the PP/ST author should specify the metric that the TSF
+ must ensure with respect to the stored audit
+ records. This metric limits the data loss by enumerating
+ the number of records that must be kept, or the time
+ that records are guaranteed to be maintained. An example
+ of the metric could be ``100,000'' indicating that
+ 100,000 audit records can be stored.
+
+
+ stored audit records will be maintained when the
+ following conditions occur:
+
+ audit storage exhaustion
+ failure
+ attack
+
+
+ the PP/ST author should specify the condition under which the
+ TSF shall still be able to maintain a defined amount of audit
+ data. This condition can be any of the following: audit
+ storage exhaustion, failure, attack.
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that actions will be taken when
+ the audit trail exceeds certain pre-defined limits.
+
+
+
+ , specifies actions to be taken if a
+ threshold on the audit trail is exceeded.
+
+
+ maintenance of the threshold;
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of imminent audit storage failure.
+
+
+ Actions taken due to exceeding of a threshold.
+
+
+ The TSF shall
+
+
+ actions to be taken in case
+ of possible audit storage failure
+
+
+
+ the PP/ST author should indicate the pre-defined
+ limit. If the management functions indicate that this
+ number might be changed by the authorised user, this
+ value is the default value. The PP/ST author might
+ choose to let the authorised user define this
+ limit. In that case the assignment can be for example
+ ``an authorised user set limit''.
+
+
+ if the audit trail exceeds
+
+
+ pre-defined limit
+
+
+
+ the PP/ST author should specify actions that should be
+ taken in case of imminent audit storage failure
+ indicated by exceeding the threshold. Actions might
+ include informing an authorised user.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies the behaviour of the TOE if the audit
+ trail is full: either audit records are ignored, or the TOE is
+ frozen such that no audited events can take place. The
+ requirement also states that no matter how the requirement is
+ instantiated, the authorised user with specific rights to this
+ effect, can continue to generate audited events (actions). The
+ reason is that otherwise the authorised user could not even
+ reset the TOE. Consideration should be given to the choice of
+ the action to be taken by the TSF in the case of audit storage
+ exhaustion, as ignoring events, which provides better
+ availability of the TOE, will also permit actions to be
+ performed without being recorded and without the user being
+ accountable.
+
+
+
+ , specifies actions in case the
+ audit trail is full.
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of audit storage failure.
+
+
+ Actions taken due to the audit storage failure.
+
+
+ The TSF shall
+ ``ignore audited
+ events''``prevent audited events,
+ except those taken by the authorised user with special
+ rights''
+ ``overwrite the oldest stored audit
+ records''
+
+ the PP/ST author should select whether the TSF shall ignore
+ audited actions, or whether it should prevent audited
+ actions from happening, or whether the oldest audit records
+ should be overwritten when the TSF can no longer store audit
+ records. Only one of these options may be chosen.
+ and
+
+ other actions to be taken in case of audit storage
+ failure
+
+ the PP/ST author should specify other actions that should be
+ taken in case of audit storage failure, such as informing the
+ authorised user. If there is no other action to be taken in
+ case of audit storage failure, this assignment can be
+ completed with ``none''.
+ if the audit trail is full.
+
+
+
+
+
+
+
+ This class provides two families specifically concerned with
+ assuring the identity of a party participating in a data
+ exchange. These families are related to assuring the identity
+ of the originator of transmitted information (proof of origin)
+ and assuring the identity of the recipient of transmitted
+ information (proof of receipt). These families ensure that an
+ originator cannot deny having sent the message, nor can the
+ recipient deny having received it.
+
+
+
+ This class describes requirements specifically of interest for
+ TOEs that are used for the transport of information. Families
+ within this class deal with non-repudiation.
+
+ In this class the concept of ``information'' is
+ used. This information should be interpreted as the object
+ being communicated, and could contain an electronic mail
+ message, a file, or a set of predefined attribute types.
+
+ In the literature, the terms ``proof of receipt''
+ and ``proof of origin'' are commonly used
+ terms. However it is recognised that the term
+ ``proof'' might be interpreted in a legal sense to
+ imply a form of mathematical rationale. The components in this
+ class interpret the de-facto use of the word
+ ``proof'' in the context of ``evidence''
+ that the TSF demonstrates the non-repudiated transport of
+ types of information.
+
+
+
+
+
+ Non-repudiation of origin ensures that the originator of
+ information cannot successfully deny having sent the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that receives information
+ during a data exchange is provided with evidence of the
+ origin of the information. This evidence can then be
+ verified by either this subject or other subjects.
+
+
+
+ Non-repudiation of origin defines requirements to provide
+ evidence to users/subjects about the identity of the
+ originator of some information. The originator cannot
+ successfully deny having sent the information because
+ evidence of origin (e.g. digital signature) provides
+ evidence of the binding between the originator and the
+ information sent. The recipient or a third party can verify
+ the evidence of origin. This evidence should not be
+ forgeable.
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of origin might
+ fail. Therefore a PP/ST author should consider including
+ integrity requirements such as in the
+ PP/ST.
+
+ In non-repudiation there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of origin (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of origin, for
+ example, a recipient or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was transmitted. For example, requests for
+ proposals must be transmitted before a certain date in order
+ to be considered. In such instances, these requirements can
+ be customised to provide a timestamp indication (time of
+ origin).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with the capability to request evidence of the
+ origin of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and recipients of evidence.
+
+
+ The identity of the user who requested that evidence of
+ origin would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall be able to generate evidence of origin for
+ transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection, should specify the third
+ parties that can request evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of origin.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+ list of information fields
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of origin for transmitted information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of origin
+ for transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at all times.
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ Non-repudiation of receipt ensures that the recipient of
+ information cannot successfully deny receiving the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that transmits information
+ during a data exchange is provided with evidence of receipt
+ of the information. This evidence can then be verified by
+ either this subject or other subjects.
+
+
+
+ Non-repudiation of receipt defines requirements to provide
+ evidence to other users/subjects that the information was
+ received by the recipient. The recipient cannot successfully
+ deny having received the information because evidence of
+ receipt (e.g. digital signature) provides evidence of the
+ binding between the recipient attributes and the
+ information. The originator or a third party can verify the
+ evidence of receipt. This evidence should not be forgeable.
+
+ It should be noted that the provision of evidence that the
+ information was received does not necessarily imply that the
+ information was read or comprehended, but only delivered
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of receipt with
+ respect to the original information might fail. Therefore a
+ PP/ST author should consider including integrity
+ requirements such as in the PP/ST.
+
+ In non-repudiation, there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of receipt (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided, (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of receipt, for
+ example, an originator or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case, the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was received. For example, when an offer expires
+ at a certain date, orders must be received before a certain
+ date in order to be considered. In such instances, these
+ requirements can be customised to provide a timestamp
+ indication (time of receipt).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with a capability to request evidence of the
+ receipt of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and third parties recipients of
+ evidence.
+
+
+ The identity of the user who requested that evidence of
+ receipt would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+ The TSF shall be able to generate
+ evidence of receipt for received
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can request
+ evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of receipt.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of receipt for received information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of receipt
+ for received
+
+ list of information types
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example electronic mail messages. at all times.
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+ For each cryptographic key generation method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key distribution method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key access method implemented by the
+ TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key destruction method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic operation (such as digital signature,
+ data encryption, key agreement, secure hash, etc.) performed
+ by the TOE, if any, the PP/ST author should select the component.
+
+ Cryptographic functionality may be used to meet objectives
+ specified in class , and in families , , ,
+ , , , to meet a variety of objectives. In the cases
+ where cryptographic functionality is used to meet objectives
+ for other classes, the individual functional components
+ specify the objectives that cryptographic functionality must
+ satisfy. The objectives in class should be
+ used when cryptographic functionality of the TOE is sought by
+ consumers.
+
+
+
+
+
+ Cryptographic keys must be managed throughout their life
+ cycle. This family is intended to support that lifecycle and
+ consequently defines requirements for the following
+ activities: cryptographic key generation, cryptographic key
+ distribution, cryptographic key access and cryptographic key
+ destruction. This family should be included whenever there
+ are functional requirements for the management of
+ cryptographic keys.
+
+
+
+ Cryptographic keys must be managed throughout their
+ lifetime. The typical events in the lifecycle of a
+ cryptographic key include (but are not limited to):
+ generation, distribution, entry, storage, access
+ (e.g. backup, escrow, archive, recovery) and destruction.
+
+ The inclusion of other stages is dependent on the key management
+ strategy being implemented, as the TOE need not be involved in
+ all of the key life-cycle (e.g. the TOE may only generate and
+ distribute cryptographic keys).
+
+ This family is intended to support the cryptographic key
+ lifecycle and consequently defines requirements for the
+ following activities: cryptographic key generation,
+ cryptographic key distribution, cryptographic key access and
+ cryptographic key destruction. This family should be
+ included whenever there are functional requirements for the
+ management of cryptographic keys.
+
+ If Security Audit Data Generation is
+ included in the PP/ST then, in the context of the events
+ being audited:
+
+
+ The object attributes may include the assigned user
+ for the cryptographic key, the user role, the
+ cryptographic operation that the cryptographic key is
+ to be used for, the cryptographic key identifier and
+ the cryptographic key validity period.
+
+
+ The object value may include the values of cryptographic
+ key(s) and parameters excluding any sensitive
+ information (such as secret or private cryptographic
+ keys).
+
+
+
+ Typically, random numbers are used to generate cryptographic
+ keys. If this is the case, then
+ should be used instead of the component .
+ In cases where random number generation is required for purposes other
+ than for the generation of cryptographic keys, the component
+ should be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic key sizes and
+ method used to generate cryptographic keys to be
+ specified, this can be in accordance with an assigned
+ standard. It should be used to specify the cryptographic
+ key sizes and the method (e.g. algorithm) used to generate
+ the cryptographic keys. Only one instance of the component
+ is needed for the same method and multiple key sizes. The
+ key size could be common or different for the various
+ entities, and could be either the input to or the output
+ from the method.
+
+
+
+ , requires cryptographic keys to be
+ generated in accordance with a specified algorithm and key
+ sizes which can be based on an assigned standard.
+
+
+
+ Success and failure of the activity.
+
+
+ The object attribute(s), and object value(s) excluding any
+ sensitive information (e.g. secret or private keys).
+
+
+ The TSF shall generate cryptographic keys in accordance with
+ a specified cryptographic key generation algorithm
+
+
+ cryptographic key generation algorithm
+
+
+
+ the PP/ST author should specify the cryptographic key
+ generation algorithm to be used.
+
+
+ and specified cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to generate
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to distribute
+ cryptographic keys to be specified, this can be in
+ accordance with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ distributed in accordance with a specified distribution
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall distribute cryptographic keys in accordance
+ with a specified cryptographic key distribution method
+
+
+ cryptographic key distribution method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ distribution method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to distribute
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to access
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires access to cryptographic
+ keys to be performed in accordance with a specified access
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall perform
+
+
+ type of cryptographic key access
+
+
+
+ the PP/ST author should specify the type of
+ cryptographic key access being used. Examples of types
+ of cryptographic key access include (but are not
+ limited to) cryptographic key backup, cryptographic
+ key archival, cryptographic key escrow and
+ cryptographic key recovery.
+
+
+ in accordance with a specified cryptographic key access
+ method
+
+
+ cryptographic key access method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ access method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to access cryptographic
+ keys. The assigned standard may comprise none, one or
+ more actual standards publications, for example, from
+ international, national, industry or organisational
+ standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to destroy
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ destroyed in accordance with a specified destruction
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall destroy cryptographic keys in accordance with
+ a specified cryptographic key destruction method
+
+
+ cryptographic key destruction method
+
+
+
+ the PP/ST author should specify the key destruction
+ method to be used to destroy cryptographic keys.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to destroy
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+ In order for a cryptographic operation to function
+ correctly, the operation must be performed in accordance
+ with a specified algorithm and with a cryptographic key of a
+ specified size. This family should be included whenever
+ there are requirements for cryptographic operations to be
+ performed.
+
+ Typical cryptographic operations include data encryption
+ and/or decryption, digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or verification of checksum, secure hash
+ (message digest), cryptographic key encryption and/or
+ decryption, and cryptographic key agreement.
+
+
+
+ A cryptographic operation may have cryptographic mode(s) of
+ operation associated with it. If this is the case, then the
+ cryptographic mode(s) must be specified. Examples of
+ cryptographic modes of operation are cipher block chaining,
+ output feedback mode, electronic code book mode, and cipher
+ feedback mode.
+
+ Cryptographic operations may be used to support one or more
+ TOE security services. The component
+ may need to be iterated more than once depending on:
+
+
+ the user application for which the security service is
+ being used.
+
+
+ the use of different cryptographic algorithms and/or
+ cryptographic key sizes.
+
+
+ the type or sensitivity of the data being operated on.
+
+
+
+ If Security audit data generation is
+ included in the PP/ST then, in the context of the
+ cryptographic operation events being audited:
+
+
+ The types of cryptographic operation may include digital
+ signature generation and/or verification, cryptographic
+ checksum generation for integrity and/or for
+ verification of checksum, secure hash (message digest)
+ computation, data encryption and/or decryption,
+ cryptographic key encryption and/or decryption,
+ cryptographic key agreement and random number
+ generation.
+
+
+ The subject attributes may include subject role(s) and
+ user(s) associated with the subject.
+
+
+ The object attributes may include the assigned user for
+ the cryptographic key, user role, cryptographic
+ operation the cryptographic key is to be used for,
+ cryptographic key identifier, and the cryptographic key
+ validity period.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic algorithm and
+ key size used to perform specified cryptographic
+ operation(s) which can be based on an assigned standard.
+
+
+
+ , requires a cryptographic operation
+ to be performed in accordance with a specified algorithm
+ and with a cryptographic key of specified sizes. The
+ specified algorithm and cryptographic key sizes can be
+ based on an assigned standard.
+
+
+ Success and failure, and the type of cryptographic
+ operation.
+
+
+ Any applicable cryptographic mode(s) of operation, subject
+ attributes and object attributes.
+
+
+ The TSF shall perform
+
+
+ list of cryptographic operations
+
+
+
+ the PP/ST author should specify the cryptographic
+ operations being performed. Typical cryptographic
+ operations include digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or for verification of checksum, secure
+ hash (message digest) computation, data encryption
+ and/or decryption, cryptographic key encryption and/or
+ decryption, cryptographic key agreement and random
+ number generation. The cryptographic operation may be
+ performed on user data or TSF data.
+
+
+ in accordance with a specified cryptographic algorithm
+
+
+ cryptographic algorithm
+
+
+
+ the PP/ST author should specify the cryptographic
+ algorithm to be used. Typical cryptographic algorithms
+ include, but are not limited to, DES, RSA and IDEA.
+
+
+ and cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents how the identified cryptographic
+ operation(s) are performed. The assigned standard may
+ comprise none, one or more actual standards
+ publications, for example, from international,
+ national, industry or organisational standards.
+
+ .
+
+
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. is split
+ into four groups of families (listed below) that address user
+ data within a TOE, during import, export, and storage as well
+ as security attributes directly related to user data.
+
+ The families in this class are organised into four groups:
+
+
+ User data protection security function policies:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families permit the PP/ST author to
+ name the user data protection security function policies
+ and define the scope of control of the policy, necessary
+ to address the security objectives. The names of these
+ policies are meant to be used throughout the remainder
+ of the functional components that have an operation that
+ calls for an assignment or selection of an "access
+ control SFP" or an "information flow control
+ SFP". The rules that define the functionality of
+ the named access control and information flow control
+ SFPs will be defined in the and
+ families (respectively).
+
+
+ Forms of user data protection:
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ; and
+
+
+ .
+
+
+
+
+ Off-line storage, import and export:
+
+
+ ;
+
+
+ ;
+
+
+ .
+
+
+
+ Components in these families address the trustworthy
+ transfer into or out of the TOE.
+
+
+ Inter-TSF communication:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families address communication
+ between the TSF of the TOE and another trusted IT
+ product.
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. This class differs from FIA and FPT
+ in that specifies components to
+ protect user data, FIA specifies components to protect
+ attributes associated with the user, and FPT specifies
+ components to protect TSF information.
+
+ The class does not contain explicit requirements for
+ traditional Mandatory Access Controls (MAC) or traditional
+ Discretionary Access Controls (DAC); however, such
+ requirements may be constructed using components from this
+ class.
+
+ does not explicitly deal with
+ confidentiality, integrity, or availability, as all three are
+ most often intertwined in the policy and mechanisms. However,
+ the TOE security policy must adequately cover these three
+ objectives in the PP/ST.
+
+ A final aspect of this class is that it specifies access
+ control in terms of ``operations''. An operation
+ is defined as a specific type of access on a specific
+ object. It depends on the level of abstraction of the PP/ST
+ author whether these operations are described as
+ ``read'' and/or ``write''
+ operations, or as more complex operations such as
+ ``update the database''.
+
+ The access control policies are policies that control access
+ to the information container. The attributes represent
+ attributes of the container. Once the information is out of
+ the container, the accessor is free to modify that
+ information, including writing the information into a
+ different container with different attributes. By contrast, an
+ information flow policies controls access to the information,
+ independent of the container. The attributes of the
+ information, which may be associated with the attributes of
+ the container (or may not, as in the case of a multi-level
+ database) stay with the information as it moves. The accessor
+ does not have the ability, in the absence of an explicit
+ authorisation, to change the attributes of the information.
+
+ This class is not meant to be a complete taxonomy of IT access
+ policies, as others can be imagined. Those policies included
+ here are simply those for which current experience with actual
+ systems provides a basis for specifying requirements. There
+ may be other forms of intent that are not captured in the
+ definitions here.
+
+ For example, one could imagine a goal of having user-imposed
+ (and user-defined) controls on information flow (e.g. an
+ automated implementation of the NO FOREIGN handling
+ caveat). Such concepts could be handled as refinements of, or
+ extensions to the components.
+
+ Finally, it is important when looking at the components in
+ to remember that these components are
+ requirements for functions that may be implemented by a
+ mechanism that also serves or could serve another purpose. For
+ example, it is possible to build an access control policy
+ () that uses labels () as the basis of the access control
+ mechanism.
+
+ A set of SFRs may encompass many security function
+ policies (SFPs), each to be identified by the two policy
+ oriented components , and . These policies will typically take
+ confidentiality, integrity, and availability aspects into
+ consideration as required, to satisfy the TOE
+ requirements. Care should be taken to ensure that all objects
+ are covered by at least one SFP and that there are no
+ conflicts arising from implementing the multiple SFPs.
+
+ When building a PP/ST using components from the class, the following information provides guidance
+ on where to look and what to select from the class.
+
+ The requirements in the class are defined in
+ terms of a set of SFRs that will
+ implement a SFP. Since a TOE may implement multiple SFPs
+ simultaneously, the PP/ST author must specify the name for
+ each SFP, so it can be referenced in other families. This name
+ will then be used in each component selected to indicate that
+ it is being used as part of the definition of requirements for
+ that SFP. This allows the author to easily indicate the
+ scope for operations such as objects covered, operations
+ covered, authorised users, etc.
+
+ Each instantiation of a component can apply to only one
+ SFP. Therefore if an SFP is specified in a component then
+ this SFP will apply to all the elements in this
+ component. The components may be instantiated multiple times
+ within a PP/ST to account for different policies if so
+ desired.
+
+ The key to selecting components from this family is to have a
+ well defined set of TOE security objectives to enable proper
+ selection of the components from the two policy components;
+ and . In and respectively, all access control
+ policies and all information flow control policies are
+ named. Furthermore the scope of control of these components in
+ terms of the subjects, objects and operations covered by this
+ security functionality. The names of these policies are meant
+ to be used throughout the remainder of the functional
+ components that have an operation that calls for an assignment
+ or selection of an ``access control SFP'' or an ``information
+ flow control SFP''. The rules that define the functionality
+ of the named access control and information flow control SFPs
+ will be defined in the and
+ families
+ (respectively).
+
+ The following steps are guidance on how this class is applied
+ in the construction of a PP/ST:
+
+
+ Identify the policies to be enforced from the , and families. These
+ families define scope of control for the policy,
+ granularity of control and may identify some rules to go
+ with the policy.
+
+
+ Identify the components and perform any applicable operations
+ in the policy components. The assignment operations may be
+ performed generally (such as with a statement ``All
+ files'') or specifically (``The files
+ ``A'', ``B'', etc.) depending upon
+ the level of detail known.
+
+
+ Identify any applicable function components from the and families to address
+ the named policy families from and
+ . Perform the operations to make the
+ components define the rules to be enforced by the named
+ policies. This should make the components fit the
+ requirements of the selected function envisioned or to be
+ built.
+
+
+ Identify who will have the ability to control and change
+ security attributes under the function, such as only a
+ security administrator, only the owner of the object,
+ etc. Select the appropriate components from
+ and perform the operations. Refinements may be useful here
+ to identify missing features, such as that some or all
+ changes must be done via trusted path.
+
+
+ Identify any appropriate components from the for initial values for new objects and subjects.
+
+
+ Identify any applicable rollback components from the family.
+
+
+ Identify any applicable residual information protection
+ requirements from the family.
+
+
+ Identify any applicable import or export components, and how
+ security attributes should be handled during import and
+ export, from the and families.
+
+
+ Identify any applicable internal TOE communication
+ components from the family.
+
+
+ Identify any requirements for integrity protection of stored
+ information from the .
+
+
+ Identify any applicable inter-TSF communication components
+ from the or
+ families.
+
+
+
+
+
+
+
+ This family identifies the access control SFPs (by name) and
+ defines the scope of control of the policies that form the
+ identified access control portion of the SFRs related to the
+ SFP. This scope of control is characterised by three sets: the
+ subjects under control of the policy, the objects under control
+ of the policy, and the operations among controlled subjects and
+ controlled objects that are covered by the policy. The criteria
+ allows multiple policies to exist, each having a unique name.
+ This is accomplished by iterating components from this family
+ once for each named access control policy. The rules that
+ define the functionality of an access control SFP will be
+ defined by other families such as and . The names
+ of the access control SFPs identified here in are meant to be used throughout the remainder of
+ the functional components that have an operation that calls for
+ an assignment or selection of an ``access control SFP.''
+
+
+
+ This family is based upon the concept of arbitrary controls
+ on the interaction of subjects and objects. The scope and
+ purpose of the controls is based upon the attributes of the
+ accessor (subject), the attributes of the container being
+ accessed (object), the actions (operations) and any
+ associated access control rules.
+
+ The components in this family are capable of identifying the
+ access control SFPs (by name) to be enforced by the traditional
+ Discretionary Access Control (DAC) mechanisms. It further
+ defines the subjects, objects and operations that are covered by
+ identified access control SFPs. The rules that define the
+ functionality of an access control SFP will be defined by other
+ families, such as and . The names of the access control SFPs
+ defined in are meant to be used
+ throughout the remainder of the functional components that have
+ an operation that calls for an assignment or selection of an
+ ``access control SFP.''
+
+ The access control SFP covers a set of triplets: subject,
+ object, and operations. Therefore a subject can be covered
+ by multiple access control SFPs but only with respect to a
+ different operation or a different object. Of course the
+ same applies to objects and operations.
+
+ A critical aspect of an access control function that
+ enforces an access control SFP is the ability for users to
+ modify the attributes involved in access control
+ decisions. The family does not address
+ these aspects. Some of these requirements are left
+ undefined, but can be added as refinements, while others are
+ covered elsewhere in other families and classes such as
+ .
+
+ There are no audit requirements in as
+ this family specifies access control SFP requirements. Audit
+ requirements will be found in families specifying functions
+ to satisfy the access control SFPs identified in this
+ family.
+
+ This family provides a PP/ST author the capability to
+ specify several policies, for example, a fixed access
+ control SFP to be applied to one scope of control, and a
+ flexible access control SFP to be defined for a different
+ scope of control. To specify more than one access control
+ policy, the components from this family can be iterated
+ multiple times in a PP/ST to different subsets of operations
+ and objects. This will accommodate TOEs that contain
+ multiple policies, each addressing a particular set of
+ operations and objects. In other words, the PP/ST author
+ should specify the required information in the ACC component
+ for each of the access control SFPs that the TSF will
+ enforce. For example, a TOE incorporating three access
+ control SFPs, each covering only a subset of the objects,
+ subjects, and operations within the TOE, will contain one
+ component for each of the three
+ access control SFPs, necessitating a total of three components.
+
+
+
+
+
+
+
+
+ The terms object and subject refer to generic elements in
+ the TOE. For a policy to be implementable, the entities
+ must be clearly identified. For a PP, the objects and
+ operations might be expressed as types such as: named
+ objects, data repositories, observe accesses, etc. For a
+ specific TOE these generic terms (subject, object) must be
+ refined, e.g. files, registers, ports, daemons, open
+ calls, etc.
+
+ This component specifies that the policy cover some
+ well-defined set of operations on some subset of the
+ objects. It places no constraints on any operations
+ outside the set - including operations on objects for
+ which other operations are controlled.
+
+
+
+ , requires that each identified
+ access control SFP be in place for a subset of the
+ possible operations on a subset of the objects in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects, objects, and operations among subjects
+ and objects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ objects, and operations among subjects and objects
+ covered by the SFP.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations on
+ objects, that are included in the SFP, are covered by an
+ access control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ objects and subjects is covered by an access control SFP.
+
+
+
+ , requires that each identified
+ access control SFP cover all operations on subjects and
+ objects covered by that SFP. It further requires that all
+ objects and operations protected by the TSF are covered by at
+ least one identified access control SFP.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects and objects
+
+
+
+ the PP/ST author should specify the list of subjects
+ and objects covered by the SFP. All operations among
+ those subjects and objects will be covered by the SFP.
+
+
+ and all operations among subjects and objects covered by the
+ SFP.
+
+
+ The TSF shall ensure that all operations between any subject
+ controlled by the TSF and any object controlled by the TSF are covered by an
+ access control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in . specifies the scope of control of the
+ policy.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in which also specifies the scope of
+ control of the policy.
+
+ This family provides a PP/ST author the capability to
+ describe the rules for access control. This results in a
+ TOE where the access to objects will not change. An
+ example of such an object is ``Message of the Day'', which
+ is readable by all, and changeable only by the authorised
+ administrator. This family also provides the PP/ST author
+ with the ability to describe rules that provide for
+ exceptions to the general access control rules. Such
+ exceptions would either explicitly allow or deny
+ authorisation to access an object.
+
+ There are no explicit components to specify other possible
+ functions such as two-person control, sequence rules for
+ operations, or exclusion controls. However, these
+ mechanisms, as well as traditional DAC mechanisms, can be
+ represented with the existing components, by careful
+ drafting of the access control rules.
+
+ A variety of acceptable access control functionality may be
+ specified in this family such as:
+
+
+ Access control lists (ACLs)
+
+
+ Time-based access control specifications
+
+
+ Origin-based access control specifications
+
+
+ Owner-controlled access control attributes
+
+
+
+
+
+
+
+
+
+
+ This component provides requirements for a mechanism that
+ mediates access control based on security attributes
+ associated with subjects and objects. Each object and
+ subject has a set of associated attributes, such as
+ location, time of creation, access rights (e.g., Access
+ Control Lists (ACLs)). This component allows the PP/ST
+ author to specify the attributes that will be used for the
+ access control mediation. This component allows access
+ control rules, using these attributes, to be
+ specified.
+
+ Examples of the attributes that a PP/ST author might
+ assign are presented in the following paragraphs.
+
+ An identity attribute may be associated with users,
+ subjects, or objects to be used for mediation. Examples of
+ such attributes might be the name of the program image
+ used in the creation of the subject, or a security
+ attribute assigned to the program image.
+
+ A time attribute can be used to specify that access will
+ be authorised during certain times of the day, during
+ certain days of the week, or during a certain calendar
+ year.
+
+ A location attribute could specify whether the location is
+ the location of the request for the operation, the
+ location where the operation will be carried out, or
+ both. It could be based upon internal tables to translate
+ the logical interfaces of the TSF into locations such as
+ through terminal locations, CPU locations, etc.
+
+ A grouping attribute allows a single group of users to be
+ associated with an operation for the purposes of access
+ control. If required, the refinement operation should be
+ used to specify the maximum number of definable groups,
+ the maximum membership of a group, and the maximum number
+ of groups to which a user can concurrently be
+ associated.
+
+ This component also provides requirements for the access
+ control security functions to be able to explicitly
+ authorise or deny access to an object based upon security
+ attributes. This could be used to provide privilege,
+ access rights, or access authorisations within the
+ TOE. Such privileges, rights, or authorisations could
+ apply to users, subjects (representing users or
+ applications), and objects.
+
+
+
+ This family addresses security attribute usage and
+ characteristics of policies. The component within this
+ family is meant to be used to describe the rules for the
+ function that implements the SFP as identified in . The PP/ST author may also
+ iterate this component to address multiple policies in the
+ TOE.
+
+ Security attribute
+ based access control allows the TSF to enforce access
+ based upon security attributes and named groups of
+ attributes. Furthermore, the TSF may have the ability to
+ explicitly authorise or deny access to an object based
+ upon security attributes.
+
+
+ Managing the attributes used to make explicit access or
+ denial based decisions.
+
+
+ Successful requests to perform an operation on an object
+ covered by the SFP.
+
+
+ All requests to perform an operation on an object covered by
+ the SFP.
+
+
+ The specific security attributes used in making an access
+ check.
+
+
+ The TSF shall enforce the
+
+ access control SFP
+
+ the PP/ST author should specify an access control SFP
+ name that the TSF is to enforce. The name of the access
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+ to objects based on the following:
+
+ list of subjects and objects controlled under the
+ indicated SFP, and for each, the SFP-relevant security
+ attributes, or named groups of SFP-relevant security
+ attributes
+
+ the PP/ST author should specify, for each controlled
+ subject and object, the security attributes and/or named
+ groups of security attributes that the function will use
+ in the specification of the rules. For example, such
+ attributes may be things such as the user identity,
+ subject identity, role, time of day, location, ACLs, or
+ any other attribute specified by the PP/ST author. Named
+ groups of security attributes can be specified to
+ provide a convenient means to refer to multiple security
+ attributes. Named groups could provide a useful way to
+ associate ``roles'' defined in , and
+ all of their relevant attributes, with subjects. In
+ other words, each role could relate to a named group of
+ attributes..
+
+
+ The TSF shall enforce the following rules to determine if an
+ operation among controlled subjects and controlled objects
+ is allowed:
+
+
+ rules governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects
+
+
+
+ the PP/ST author should specify the SFP rules
+ governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects. These rules specify when access
+ is granted or denied. It can specify general access
+ control functions (e.g. typical permission bits) or
+ granular access control functions (e.g. ACLs).
+
+ .
+
+
+ The TSF shall explicitly authorise access of subjects to
+ objects based on the following additional rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise access of subjects to objects
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise access
+ of subjects to objects that will be used to explicitly
+ authorise access. These rules are in addition to those
+ specified in . They are
+ included in as they are
+ intended to contain exceptions to the rules in . An example of rules to explicitly
+ authorise access is based on a privilege vector
+ associated with a subject that always grants access to
+ objects covered by the access control SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny access of subjects to objects
+ based on the
+
+
+ rules, based on security attributes, that explicitly
+ deny access of subjects to objects
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly deny access of
+ subjects to objects. These rules are in addition to
+ those specified in . They are
+ included in as they are
+ intended to contain exceptions to the rules in . An example of rules to explicitly
+ deny access is based on a privilege vector associated
+ with a subject that always denies access to objects
+ covered by the access control SFP that has been
+ specified. If such a capability is not desired, then
+ the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+
+
+
+
+
+ Data authentication permits an entity to accept
+ responsibility for the authenticity of information (e.g., by
+ digitally signing it). This family provides a method of
+ providing a guarantee of the validity of a specific unit of
+ data that can be subsequently used to verify that the
+ information content has not been forged or fraudulently
+ modified. In contrast to , this family is
+ intended to be applied to "static" data rather
+ than data that is being transferred.
+
+
+
+ This family describes specific functions that can be used to
+ authenticate ``static'' data.
+
+ Components in this family are to be used when there is a
+ requirement for ``static'' data
+ authentication, i.e. where data is to be signed but not
+ transmitted. (Note that the family
+ provides for non-repudiation of origin of information
+ received during a data exchange.)
+
+
+
+
+
+ This component may be satisfied by one-way hash functions
+ (cryptographic checksum, fingerprint, message digest), to
+ generate a hash value for a definitive document that may
+ be used as verification of the validity or authenticity of
+ its information content.
+
+
+
+ , requires that the TSF is capable
+ of generating a guarantee of authenticity of the
+ information content of objects (e.g. documents).
+
+
+ The assignment or modification of the objects for which data
+ authentication may apply could be configurable.
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element. The list of subjects could be
+ very specific, if the subjects are known, or it could
+ be more generic and refer to a
+ ``type'' of subject such
+ as an identified role.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information.
+
+
+
+
+
+
+
+
+
+
+ This component additionally requires the ability to verify
+ the identity of the user that provided the guarantee of
+ authenticity (e.g. a trusted third party).
+
+
+
+ additionally requires that the TSF
+ is capable of establishing the identity of the subject who
+ provided the guarantee of authenticity.
+
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The identity of the subject that generated the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element as well as the identity of the
+ user that created the data authentication evidence.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information and the identity of the user that
+ generated the evidence.
+
+
+
+
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes and protection
+ either can be explicitly preserved or can be ignored once it
+ has been exported. It is concerned with limitations on
+ export and with the association of security attributes with
+ the exported user data.
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes either can be
+ explicitly preserved or can be ignored once it has been
+ exported. Consistency of these security attributes are
+ addressed by .
+
+ is concerned with limitations on export
+ and association of security attributes with the exported
+ user data.
+
+ This family, and the corresponding Import family , address how the TOE deals with user data
+ transferred into and outside its control. In principle this
+ family is concerned with the TSF-mediated exporting of user data and its
+ related security attributes.
+
+ A variety of activities might be involved here:
+
+
+ exporting of user data without any security attributes;
+
+
+ exporting user data including security attributes where
+ the two are associated with one another and the security
+ attributes unambiguously represent the exported user
+ data.
+
+
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the TSF-mediated exporting of user data
+ without the export of its security attributes.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs when exporting user data outside the
+ TSF. User data that is exported by this function is
+ exported without its associated security attributes.
+
+
+ Successful export of information.
+
+
+ All attempts to export information.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data without the user
+ data's associated security attributes
+
+
+
+
+
+
+
+
+
+
+
+
+ The user data is exported together with its security
+ attributes. The security attributes are unambiguously
+ associated with the user data. There are several ways of
+ achieving this association. One way that this can be
+ achieved is by physically collocating the user data and
+ the security attributes (e.g. the same floppy), or by
+ using cryptographic techniques such as secure signatures
+ to associate the attributes and the user data. could be used to assure that the attributes
+ are correctly received at the other trusted IT product
+ while can be used to make sure that
+ those attributes are properly interpreted. Furthermore,
+ could be used to make sure that the
+ export is being initiated by the proper user.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs using a function that accurately and
+ unambiguously associates security attributes with the user
+ data that is exported.
+
+
+ The additional exportation control rules could be
+ configurable by a user in a defined role.
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data with the user
+ data's associated security attributes.
+
+
+ The TSF shall ensure that the security attributes, when
+ exported outside the TOE, are unambiguously associated with
+ the exported user data.
+
+
+ The TSF shall enforce the following rules when user data is
+ exported from the TOE:
+
+
+ additional exportation control rules
+
+
+
+ the PP/ST author should specify any additional
+ exportation control rules or
+ ``none'' if there are no
+ additional exportation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family identifies the information flow control SFPs (by
+ name) and defines the scope of control for each named
+ information flow control SFP. This scope of control is
+ characterised by three sets: the subjects under control of the
+ policy, the information under control of the policy, and
+ operations which cause controlled information to flow to and
+ from controlled subjects covered by the policy. The criteria
+ allows multiple policies to exist, each having a unique name.
+ This is accomplished by iterating components from this family
+ once for each named information flow control policy. The rules
+ that define the functionality of an information flow control SFP
+ will be defined by other families such as and . The names
+ of the information flow control SFPs identified here in are meant to be used throughout the
+ remainder of the functional components that have an operation
+ that calls for an assignment or selection of an ``information
+ flow control SFP.''
+
+ The TSF mechanism controls the flow of information in
+ accordance with the information flow control SFP. Operations
+ that would change the security attributes of information are
+ not generally permitted as this would be in violation of an
+ information flow control SFP. However, such operations may
+ be permitted as exceptions to the information flow control
+ SFP if explicitly specified.
+
+
+
+ This family covers the identification of information flow
+ control SFPs; and, for each, specifies the scope of control
+ of the SFP.
+
+ The components in this family are capable of identifying the
+ information flow control SFPs to be enforced by the traditional
+ Mandatory Access Control mechanisms that would be found in a
+ TOE. However, they go beyond just the traditional MAC mechanisms
+ and can be used to identify and describe non-interference
+ policies and state-transitions. It further defines the subjects
+ under control of the policy, the information under control of
+ the policy, and operations which cause controlled information to
+ flow to and from controlled subjects for each information flow
+ control SFP in the TOE. The information flow control SFP will be
+ defined by other families such as and . The
+ information flow control SFPs named here in are meant to be used throughout the remainder of
+ the functional components that have an operation that calls for
+ an assignment or selection of an ``information flow control
+ SFP.''
+
+ These components are quite flexible. They allow the domain
+ of flow control to be specified and there is no requirement
+ that the mechanism be based upon labels. The different
+ elements of the information flow control components also
+ permit different degrees of exception to the policy.
+
+ Each SFP covers a set of triplets: subject, information, and
+ operations that cause information to flow to and from
+ subjects. Some information flow control policies may be at a
+ very low level of detail and explicitly describe subjects in
+ terms of processes within an operating system. Other
+ information flow control policies may be at a high level and
+ describe subjects in the generic sense of users or
+ input/output channels. If the information flow control
+ policy is at too high a level of detail, it may not clearly
+ define the desired IT security functions. In such cases, it
+ is more appropriate to include such descriptions of
+ information flow control policies as objectives. Then the
+ desired IT security functions can be specified as supportive
+ of those objectives.
+
+ In the second component (), each
+ information flow control SFP will cover all possible
+ operations that cause information covered by that SFP to
+ flow to and from subjects covered by that SFP. Furthermore,
+ all information flows will need to be covered by a
+ SFP. Therefore for each action that causes information to
+ flow, there will be a set of rules that define whether the
+ action is allowed. If there are multiple SFPs that are
+ applicable for a given information flow, all involved SFPs
+ must allow this flow before it is permitted to take place.
+
+ An information flow control SFP covers a well-defined set of
+ operations. The SFPs coverage may be
+ ``complete'' with respect to some
+ information flows, or it may address only some of the
+ operations that affect the information flow.
+
+ An access control SFP controls access to the objects that
+ contain information. An information flow control SFP
+ controls access to the information, independent of its
+ container. The attributes of the information, which may be
+ associated with the attributes of the container (or may not,
+ as in the case of a multi-level database) stay with the
+ information as it flows. The accessor does not have the
+ ability, in the absence of an explicit authorisation, to
+ change the attributes of the information.
+
+ Information flows and operations can be expressed at
+ multiple levels. In the case of a ST, the information flows
+ and operations might be specified at a system-specific
+ level: TCP/IP packets flowing through a firewall based upon
+ known IP addresses. For a PP, the information flows and
+ operations might be expressed as types: email, data
+ repositories, observe accesses, etc.
+
+ The components in this family can be applied multiple times
+ in a PP/ST to different subsets of operations and
+ objects. This will accommodate TOEs that contain multiple
+ policies, each addressing a particular set of objects,
+ subjects, and operations.
+
+
+
+
+
+
+
+
+ This component requires that an information flow control
+ policy apply to a subset of the possible operations in the
+ TOE.
+
+
+
+ , requires that each identified
+ information flow control SFPs be in place for a subset of
+ the possible operations on a subset of information flows
+ in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects, information, and operations that cause
+ controlled information to flow to and from controlled
+ subjects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ information, and operations which cause controlled
+ information to flow to and from controlled subjects
+ covered by the SFP. As mentioned above, the list of
+ subjects could be at various levels of detail
+ depending on the needs of the PP/ST author. It could
+ specify users, machines, or processes for
+ example. Information could refer to data such as email
+ or network protocols, or more specific objects similar
+ to those specified under an access control policy. If
+ the information that is specified is contained within
+ an object that is subject to an access control policy,
+ then both the access control policy and information
+ flow control policy must be enforced before the
+ specified information could flow to or from the
+ object.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations that
+ cause information to flow to and from subjects included in
+ the SFP, are covered by an information flow control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ information flows and subjects is covered by an
+ information flow control SFP.
+
+
+
+ , requires that each identified
+ information flow control SFP cover all operations on
+ subjects and information covered by that SFP. It further
+ requires that all information flows and operations controlled
+ by the TSF are covered by at least one identified information
+ flow control SFP.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects and information
+
+
+
+ the PP/ST author should specify the list of subjects
+ and information that will be covered by the SFP. All
+ operations that cause that information to flow to and
+ from subjects will be covered by the SFP. As mentioned
+ above, the list of subjects could be at various levels
+ of detail depending on the needs of the PP/ST
+ author. It could specify users, machines, or processes
+ for example. Information could refer to data such as
+ email or network protocols, or more specific objects
+ similar to those specified under an access control
+ policy. If the information that is specified is
+ contained within an object that is subject to an
+ access control policy, then both the access control
+ policy and information flow control policy must be
+ enforced before the specified information could flow
+ to or from the object.
+
+
+ and all operations that cause that information to flow to
+ and from subjects covered by the SFP.
+
+
+ The TSF shall ensure that all operations that cause any
+ information in the TOE to flow to and from any subject in
+ the TOE are covered by an information flow control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policy. It consists of two kinds of
+ requirements: one addressing the common information flow
+ function issues, and a second addressing illicit information
+ flows (i.e. covert channels). This division arises because
+ the issues concerning illicit information flows are, in some
+ sense, orthogonal to the rest of an information flow control
+ SFP. By their nature they circumvent the information flow
+ control SFP resulting in a violation of the policy. As such,
+ they require special functions to either limit or prevent
+ their occurrence.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policies. It consists of two
+ ``trees:'' one addressing the common
+ information flow control function issues, and a second
+ addressing illicit information flows (i.e. covert channels)
+ with respect to one or more information flow control
+ SFPs. This division arises because the issues concerning
+ illicit information flows are, in some sense, orthogonal to
+ the rest of an SFP. Illicit information flows are flows in
+ violation of policy; thus they are not a policy issue.
+
+ In order to implement strong protection against disclosure
+ or modification in the face of untrusted software, controls
+ on information flow are required. Access controls alone are
+ not sufficient because they only control access to
+ containers, allowing the information they contain to flow,
+ without controls, throughout a system.
+
+ In this family, the phrase ``types of illicit
+ information flows'' is used. This phrase may be
+ used to refer to the categorisation of flows as
+ ``Storage Channels'' or
+ ``Timing Channels'', or it can refer to
+ improved categorisations reflective of the needs of a PP/ST
+ author.
+
+ The flexibility of these components allows the definition of
+ a privilege policy within and to allow the controlled bypass of all or
+ part of a particular SFP. If there is a need for a
+ predefined approach to SFP bypass, the PP/ST author should
+ consider incorporating a privilege policy.
+
+
+
+
+
+
+
+
+
+ This component requires security attributes on
+ information, and on subjects that cause that information
+ to flow and subjects that act as recipients of that
+ information. The attributes of the containers of the
+ information should also be considered if it is desired
+ that they should play a part in information flow control
+ decisions or if they are covered by an access control
+ policy. This component specifies the key rules that are
+ enforced, and describes how security attributes are
+ derived.
+
+ This component does not specify the details of how a
+ security attribute is assigned (i.e. user versus
+ process). Flexibility in policy is provided by having
+ assignments that allow specification of additional policy
+ and function requirements, as necessary.
+
+ This component also provides requirements for the
+ information flow control functions to be able to
+ explicitly authorise and deny an information flow based
+ upon security attributes. This could be used to implement
+ a privilege policy that covers exceptions to the basic
+ policy defined in this component.
+
+
+
+ , requires security attributes on
+ information, and on subjects that cause that information
+ to flow and on subjects that act as recipients of that
+ information. It specifies the rules that must be enforced
+ by the function, and describes how security attributes are
+ derived by the function.
+
+
+ Managing the attributes used to make explicit access based
+ decisions.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+ the PP/ST author should specify any additional information
+ flow control SFP rules that the TSF is to enforce. This
+ includes all rules of the SFP that are either not based on the
+ security attributes of the information and the subject or
+ rules that automatically modify the security attributes of
+ information or subjects as a result of an access operation.
+ An example for the first case is a rule of the SFP controlling
+ a threshold value for specific types of information. This
+ would for example be the case when the information flow SFP
+ contains rules on access to statistical data where a subject
+ is only allowed to access this type of information up to a
+ specific number of accesses. An example for the second case
+ would be a rule stating under which conditions and how the
+ security attributes of a subject or object change as the
+ result of an access operation. Some information flow policies
+ for example may limit the number of access operations to
+ information with specific security attributes. If there are
+ no additional rules then the PP/ST author should specify
+ ``none''.
+ .
+
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly deny information
+ flows. These rules are in addition to those specified
+ in the preceding elements. They are included in as they are intended to contain
+ exceptions to the rules in the preceding elements. An
+ example of rules to explicitly authorise information
+ flows is based on a privilege vector associated with a
+ subject that always denies the subject the ability to
+ cause an information flow for information that is
+ covered by the SFP that has been specified. If such a
+ capability is not desired, then the PP/ST author
+ should specify ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that the named information flow control
+ SFP uses hierarchical security attributes that
+ form a lattice.
+
+ It is important to note that the hierarchical relationship
+ requirements identified in need
+ only apply to the information flow control security
+ attributes for the information flow control SFPs that have
+ been identified in . This
+ component is not meant to apply to other SFPs such as
+ access control SFPs.
+ phrases the requirements for the set of
+ security attributes to form a lattice. A number of information
+ flow policies defined in the literature and implemented in IT
+ products are based on a set of security attributes that form a
+ lattice. is specifically included to
+ address this type of information flow policies.
+
+ If it is the case that multiple information flow control
+ SFPs are to be specified, and that each of these SFPs will
+ have their own security attributes that are not related to
+ one another, then the PP/ST author should iterate this
+ component once for each of those SFPs. Otherwise a
+ conflict might arise with the sub-items of since the required relationships will
+ not exist.
+
+
+ expands on the requirements
+ of by requiring that all
+ information flow control SFPs in the set of SFRs use
+ hierarchical security attributes that form a lattice (as defined
+ in mathematics). is derived from the
+ mathematical properties of a lattice. A lattice consists of a
+ set of elements with an ordering relationship with the property
+ defined in the first bullet, a greatest lower bound which is the
+ unique element in the set that is greater or equal (in the
+ ordering relationship) than any other element of the lattice,
+ and a least upper bound, which is the unique element in the set
+ that is smaller or equal than any other element of the lattice.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules, based on the
+ ordering relationships between security attributes hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce. These
+ relationships should be based upon the ordering
+ relationships between the security attributes.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+ the PP/ST author should specify any additional information
+ flow control SFP rules that the TSF is to enforce. This
+ includes all rules of the SFP that are either not based on the
+ security attributes of the information and the subject or
+ rules that automatically modify the security attributes of
+ information or subjects as a result of an access operation.
+ An example for the first case is a rule of the SFP controlling
+ a threshold value for specific types of information. This
+ would for example be the case when the information flow SFP
+ contains rules on access to statistical data where a subject
+ is only allowed to access this type of information up to a
+ specific number of accesses. An example for the second case
+ would be a rule stating under which conditions and how the
+ security attributes of a subject or object change as the
+ result of an access operation. Some information flow policies
+ for example may limit the number of access operations to
+ information with specific security attributes. If there are
+ no additional rules then the PP/ST author should specify
+ ``none''.
+ .
+
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly deny information
+ flows. These rules are in addition to those specified
+ in the preceding elements. They are included in as they are intended to contain
+ exceptions to the rules in the preceding elements. An
+ example of rules to explicitly authorise information
+ flows is based on a privilege vector associated with a
+ subject that always denies the subject the ability to
+ cause an information flow for information that is
+ covered by the SFP that has been specified. If such a
+ capability is not desired, then the PP/ST author
+ should specify ``none''.
+
+ .
+
+
+ The TSF shall enforce the following relationships for any
+ two valid information flow control security attributes:
+
+
+ There exists an ordering function that, given two valid
+ security attributes, determines if the security
+ attributes are equal, if one security attribute is
+ greater than the other, or if the security attributes
+ are incomparable; and
+
+
+ There exists a ``least upper bound''
+ in the set of security attributes, such that, given any
+ two valid security attributes, there is a valid security
+ attribute that is greater than or equal to the two valid
+ security attributes; and
+
+
+ There exists a ``greatest lower
+ bound'' in the set of security attributes,
+ such that, given any two valid security attributes,
+ there is a valid security attribute that is not greater
+ than the two valid security attributes.
+
+
+
+
+
+
+
+
+
+
+
+ This component should be used when at least one of the
+ SFPs that requires control of illicit information flows
+ does not require elimination of flows.
+
+ For the specified illicit information flows, certain
+ maximum capacities should be provided. In addition a PP/ST
+ author has the ability to specify whether the illicit
+ information flows must be audited.
+
+
+
+ , requires the SFP to cover illicit
+ information flows, but not necessarily eliminate them.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The use of identified illicit information flow channels.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The use of identified illicit information flow channels with
+ estimated maximum capacity exceeding a specified value.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when all the SFPs that
+ requires control of illicit information flows require
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+ , requires the SFP to cover the
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows which are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+ The TSF shall prevent
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows to be eliminated. This list may not
+ be empty as this component requires that some illicit
+ information flows are to be eliminated.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when the SFPs that require
+ control of illicit information flows require elimination
+ of all illicit information flows. However, the PP/ST
+ author should carefully consider the potential impact that
+ eliminating all illicit information flows might have on
+ the normal functional operation of the TOE. Many practical
+ applications have shown that there is an indirect
+ relationship between illicit information flows and normal
+ functionality within a TOE and eliminating all illicit
+ information flows may result in less than desired
+ functionality.
+
+
+
+ , requires SFP to cover the
+ elimination of all illicit information flows.
+
+
+
+
+
+ The TSF shall ensure that no illicit information flows exist
+ to circumvent
+
+
+ name of information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFP for which illicit information flows are to
+ be eliminated. The name of the information flow
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+
+ .
+
+
+
+
+
+
+
+
+
+ This component should be used when it is desired that the
+ TSF provide the ability to monitor the use of illicit
+ information flows that exceed a specified capacity. If it
+ is desired that such flows be audited, then this component
+ could serve as the source of audit events to be used by
+ components from the family.
+
+
+
+ , requires the SFP to monitor
+ illicit information flows for specified and maximum
+ capacities.
+
+
+ The enabling or disabling of the monitoring function.
+
+
+ Modification of the maximum capacity at which the monitoring
+ occurs.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to monitor
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that will be monitored for exceeding
+ a maximum capacity.
+
+
+ when it exceeds the
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ above which illicit information flows will be
+ monitored by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family defines the mechanisms for TSF-mediated importing of user
+ data into the TOE such that it has appropriate security
+ attributes and is appropriately protected. It is concerned
+ with limitations on importation, determination of desired
+ security attributes, and interpretation of security
+ attributes associated with the user data.
+
+
+
+ This family defines mechanisms for TSF-mediated importing of user data from
+ outside the TOE into the TOE such that the user data
+ security attributes can be preserved. Consistency of these
+ security attributes are addressed by .
+
+ is concerned with limitations on
+ import, user specification of security attributes, and
+ association of security attributes with the user data.
+
+ This family, and the corresponding export family , address how the TOE deals with user data
+ outside its control. This family is concerned with assigning
+ and abstraction of the user data security attributes.
+
+ A variety of activities might be involved here:
+
+
+ importing user data from an unformatted medium
+ (e.g. floppy disk, tape, scanner, video or audit
+ signal), without including any security attributes, and
+ physically marking the medium to indicate its contents;
+
+
+ importing user data, including security attributes, from
+ a medium and verifying that the object security
+ attributes are appropriate;
+
+
+ importing user data, including security attributes, from
+ a medium using a cryptographic sealing technique to
+ protect the association of user data and security
+ attributes.
+
+
+
+ This family is not concerned with the determination of
+ whether the user data may be imported. It is concerned with
+ the values of the security attributes to associate with the
+ imported user data.
+
+ There are two possibilities for the import of user data:
+ either the user data is unambiguously associated with
+ reliable object security attributes (values and meaning of
+ the security attributes is not modified), or no reliable
+ security attributes (or no security attributes at all) are
+ available from the import source. This family addresses both
+ cases.
+
+ If there are reliable security attributes available, they
+ may have been associated with the user data by physical
+ means (the security attributes are on the same media), or by
+ logical means (the security attributes are distributed
+ differently, but include unique object identification,
+ e.g. cryptographic checksum).
+
+ This family is concerned with TSF-mediated importing of user data and
+ maintaining the association of security attributes as
+ required by the SFP. Other families are concerned with other
+ import aspects such as consistency, trusted channels, and
+ integrity that are beyond the scope of this
+ family. Furthermore, is only concerned
+ with the interface to the import medium. is responsible for the other end point of the
+ medium (the source).
+
+ Some of the well known import requirements are:
+
+
+ importing of user data without any security attributes;
+
+
+ importing of user data including security attributes
+ where the two are associated with one another and the
+ security attributes unambiguously represent the
+ information being imported.
+
+
+
+ These import requirements may be handled by the TSF with or
+ without human intervention, depending on the IT limitations
+ and the organisational security policy. For example, if user
+ data is received on a ``confidential''
+ channel, the security attributes of the objects will be set
+ to ``confidential''.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that does not have reliable (or any) security attributes
+ associated with it. This function requires that the
+ security attributes for the imported user data be
+ initialised within the TSF. It could also be the case that
+ the PP/ST author specifies the rules for import. It may be
+ appropriate, in some environments, to require that these
+ attributes be supplied via a trusted path or a trusted
+ channel mechanism.
+
+
+
+ , requires that the security
+ attributes correctly represent the user data and are
+ supplied separately from the object.
+
+
+ The modification of the additional control rules used for
+ import.
+
+
+ Successful import of user data, including any security
+ attributes.
+
+
+ All attempts to import user data, including any security
+ attributes.
+
+
+ The specification of security attributes for imported user
+ data supplied by an authorised user.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s) and/or information flow control SFP(s)
+
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be
+ enforced when importing user data from outside of the
+ TOE. The user data that this function imports is
+ scoped by the assignment of these SFPs.
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall ignore any security attributes associated with
+ the user data when imported from outside the TOE.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that has reliable security attributes associated with
+ it. This function relies upon the security attributes that
+ are accurately and unambiguously associated with the
+ objects on the import medium. Once imported, those objects
+ will have those same attributes. This requires to ensure the consistency of the data. It
+ could also be the case that the PP/ST author specifies the
+ rules for import.
+
+
+
+ , requires that security attributes
+ correctly represent the user data and are accurately and
+ unambiguously associated with the user data imported from
+ outside the TOE.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when importing user data from outside
+ of the TOE. The user data that this function imports
+ is scoped by the assignment of these SFPs.
+
+
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall use the security attributes associated with
+ the imported user data.
+
+
+ The TSF shall ensure that the protocol used provides for the
+ unambiguous association between the security attributes and
+ the user data received.
+
+
+ The TSF shall ensure that interpretation of the security
+ attributes of the imported user data is as intended by the
+ source of the user data.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between separated parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and families,
+ which provide protection for user data when it is
+ transferred between distinct TSFs across an external
+ channel, and and ,
+ which address TSF-mediated transfer of data to or from outside the
+ TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and family, which
+ provide protection for user data when it is transferred
+ between distinct TSFs across an external channel, and and , which address
+ TSF-mediated transfer of data to or from outside the TOE.
+
+ The requirements in this family allow a PP/ST author to
+ specify the desired security for user data while in transit
+ within the TOE. This security could be protection against
+ disclosure, modification, or loss of availability.
+
+ The determination of the degree of physical separation above
+ which this family should apply depends on the intended
+ environment of use. In a hostile environment, there may be
+ risks arising from transfers between parts of the TOE
+ separated by only a system bus. In more benign environments,
+ the transfers may be across more traditional network media.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ , requires that user data be
+ protected when transmitted between parts of the TOE.
+
+
+ If the TSF provides multiple methods to protect user data
+ during transmission between physically separated parts of
+ the TOE, the TSF could provide a pre-defined role with the
+ ability to select the method that will be used.
+
+
+ Successful transfers of user data, including identification
+ of the protection method used.
+
+
+ All attempts to transfer user data, including the protection
+ method used and any errors that occurred.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component could, for example, be used to provide
+ different forms of protection to information with
+ different clearance levels.
+
+ One of the ways to achieve separation of data when it is
+ transmitted is through the use of separate logical or
+ physical channels.
+
+
+
+ , requires separation of data based
+ on the value of SFP-relevant attributes in addition to the
+ first component.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+ The TSF shall separate data controlled by the SFP(s) when
+ transmitted between physically-separated parts of the TOE,
+ based on the values of the following:
+
+
+ security attributes that require separation
+
+
+
+ the PP/ST author should specify the security
+ attributes, the values of which the TSF will use to
+ determine when to separate data that is being
+ transmitted between physically-separated parts of the
+ TOE. An example is that user data associated with the
+ identity of one owner is transmitted separately from
+ the user data associated with the identify of a
+ different owner. In this case, the value of the
+ identity of the owner of the data is what is used to
+ determine when to separate the data for transmission.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with either or . It ensures
+ that the TSF checks received user data (and their
+ attributes) for integrity. or will provide the data in a manner such
+ that it is protected from modification (so that can detect any modifications).
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ , requires that the TSF monitor user
+ data transmitted between parts of the TOE for identified
+ integrity errors.
+
+
+ The specification of the actions to be taken upon detection
+ of an integrity error could be configurable.
+
+
+ Successful transfers of user data, including identification
+ of the integrity protection method used.
+
+
+ All attempts to transfer user data, including the integrity
+ protection method used and any errors that occurred.
+
+
+ Unauthorised attempts to change the integrity protection
+ method.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with . It ensures that the TSF checks received
+ user data, that has been transmitted by separate channels
+ (based on values of specified security attributes), for
+ integrity. It allows the PP/ST author to specify actions
+ to be taken upon detection of an integrity error.
+
+ For example, this component could be used to provide
+ different integrity error detection and action for
+ information at different integrity levels.
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author should specify the attributes (and
+ associated transmission channels) that necessitate
+ integrity error monitoring
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ expands on the third component by
+ allowing the form of integrity monitoring to differ by
+ SFP-relevant attribute.
+
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow
+ control SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ , based on the following attributes:
+
+
+ security attributes that require separate transmission
+ channels
+
+
+
+ the PP/ST author should specify a list of security
+ attributes that require separate transmission
+ channels. This list is used to determine which user
+ data to monitor for integrity errors., based on its
+ security attributes and its transmission channel. This
+ element is directly related to .
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity
+ error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the need to ensure that any data contained
+ in a resource is not available when the resource is de-allocated
+ from one object and reallocated to a different object. This
+ family requires protection for any data contained in a resource
+ that has been logically deleted or released, but may still be
+ present within the TSF-controlled resource which in turn may be
+ re-allocated to another object.
+
+
+
+ Residual information protection ensures that TSF-controlled
+ resources when de-allocated from an object and before they are
+ reallocated to another object are treated by the TSF in a way
+ that it is not possible to reconstruct all or part of the data
+ contained in the resource before it was de-allocated.
+
+ A TOE usually has a number of functions that potentially
+ de-allocate resources from an object and potentially re-allocate
+ those resources to objects. Some, but not all of those resources
+ may have been used to store critical data from the previous use
+ of the resource and for those resources FDP_RIP requires that
+ they are prepared for reuse. Object reuse applies to explicit
+ requests of a subject or user to release resources as well as
+ implicit actions of the TSF that result in the de-allocation and
+ subsequent re-allocation of resources to different
+ objects. Examples of explicit requests are the deletion or
+ truncation of a file or the release of an area of main
+ memory. Examples of implicit actions of the TSF are the
+ de-allocation and re-allocation of cache regions.
+ The requirement for object reuse is related to the content of
+ the resource belonging to an object, not all information about
+ the resource or object that may be stored elsewhere in the
+ TSF. As an example to satisfy the FDP_RIP requirement for files
+ as objects requires that all sectors that make up the file need
+ to be prepared for re-use.
+
+ It also applies to resources that are serially reused by
+ different subjects within the system. For example, most
+ operating systems typically rely upon hardware registers
+ (resources) to support processes within the system. As
+ processes are swapped from a ``run'' state to a ``sleep''
+ state (and vice versa), these registers are serially reused
+ by different subjects. While this ``swapping'' action may
+ not be considered an allocation or deallocation of a
+ resource, could apply to
+ such events and resources.
+
+ typically controls access
+ to information that is not part of any currently defined or
+ accessible object; however, in certain cases this may not be
+ true. For example, object ``A'' is a file and object ``B''
+ is the disk upon which that file resides. If object ``A'' is
+ deleted, the information from object ``A'' is under the
+ control of even though it
+ is still part of object ``B''.
+
+ It is important to note that applies only to on-line objects and not
+ off-line objects such as those backed-up on tapes. For
+ example, if a file is deleted in the TOE, can be instantiated to require that no
+ residual information exists upon deallocation; however, the
+ TSF cannot extend this enforcement to that same file that
+ exists on the off-line back-up. Therefore that same file is
+ still available. If this is a concern, then the PP/ST author
+ should make sure that the proper environmental objectives
+ are in place to support operational user guidance to address
+ off-line objects.
+
+ and can conflict when is instantiated to require that residual
+ information be cleared at the time the application releases
+ the object to the TSF (i.e. upon deallocation). Therefore,
+ the selection of
+ ``deallocation'' should not be used with since there would be no information to roll
+ back. The other selection, ``unavailability upon
+ allocation'', may be used with , but there is the risk that the resource
+ which held the information has been allocated to a new
+ object before the roll back took place. If that were to
+ occur, then the roll back would not be possible.
+
+ There are no audit requirements in because this is not a user-invokable
+ function. Auditing of allocated or deallocated resources
+ would be auditable as part of the access control SFP or the
+ information flow control SFP operations.
+
+ This family should apply to the objects specified in the
+ access control SFP(s) or the information flow control SFP(s)
+ as specified by the PP/ST author.
+
+
+
+
+
+ This component requires that, for a subset of the objects
+ in the TOE, the TSF will ensure that there is no available
+ residual information contained in a resource allocated to
+ those objects or deallocated from those objects.
+
+
+
+ , requires that the TSF
+ ensure that any residual information content of any
+ resources is unavailable to a defined subset of the
+ objects controlled by the TSF upon the resource's
+ allocation or deallocation.
+
+
+ The choice of when to perform residual information
+ protection (i.e. upon allocation or deallocation) could be
+ made configurable within the TOE.
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ the following objects:
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ subject to residual information protection.
+
+ .
+
+
+
+
+
+
+
+ This component requires that for all objects in the TOE,
+ the TSF will ensure that there is no available residual
+ information contained in a resource allocated to those
+ objects or deallocated from those objects.
+
+
+
+ , requires that the TSF ensure that
+ any residual information content of any resources is
+ unavailable to all objects upon the resource's
+ allocation or deallocation.
+
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ all objects.
+
+
+
+
+
+
+
+ The rollback operation involves undoing the last operation
+ or a series of operations, bounded by some limit, such as a
+ period of time, and return to a previous known
+ state. Rollback provides the ability to undo the effects of
+ an operation or series of operations to preserve the
+ integrity of the user data.
+
+
+
+ This family addresses the need to return to a well defined
+ valid state, such as the need of a user to undo
+ modifications to a file or to undo transactions in case of
+ an incomplete series of transaction as in the case of
+ databases.
+
+ This family is intended to assist a user in returning to a
+ well defined valid state after the user undoes the last set
+ of actions, or, in distributed databases, the return of all
+ of the distributed copies of the databases to the state
+ before an operation failed.
+
+ and conflict when
+ enforces that the contents will be made
+ unavailable at the time that a resource is deallocated from
+ an object. Therefore, this use of
+ cannot be combined with as there would
+ be no information to roll back. can be
+ used only with when it enforces that
+ the contents will be unavailable at the time that a resource
+ is allocated to an object. This is because the mechanism will have an opportunity to access
+ the previous information that may still be present in the
+ TOE in order to successfully roll back the operation.
+
+ The rollback requirement is bounded by certain limits. For
+ example a text editor typically only allows you roll back up
+ to a certain number of commands. Another example would be
+ backups. If backup tapes are rotated, after a tape is
+ reused, the information can no longer be retrieved. This
+ also poses a bound on the rollback requirement.
+
+
+
+
+
+
+
+
+
+
+
+ This component allows a user or subject to undo a set of
+ operations on a predefined set of objects. The undo is
+ only possible within certain limits, for example up to a
+ number of characters or up to a time limit.
+
+
+
+ addresses a need to roll back or
+ undo a limited number of operations within the defined
+ bounds.
+
+
+ The boundary limit to which rollback may be performed could
+ be a configurable item within the TOE.
+
+
+ Permission to perform a rollback operation could be
+ restricted to a well defined role.
+
+
+ All successful rollback operations.
+
+
+ All attempts to perform rollback operations.
+
+
+ All attempts to perform rollback operations, including
+ identification of the types of operations rolled back.
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of the
+
+
+ list of operations
+
+
+
+ the PP/ST author should specify the list of operations
+ that can be rolled back.
+
+
+ on the
+
+ information and/or list of objects
+
+ the PP/ST author should specify the information and/or
+ list of objects that are subjected to the rollback policy..
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component enforces that the TSF provide the
+ capability to rollback all operations; however, the user
+ can choose to rollback only a part of them.
+
+
+
+ addresses the need to roll back or
+ undo all operations within the defined bounds.
+
+
+
+
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of all the operations on the
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ that are subjected to the rollback policy.
+
+ .
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF. Integrity
+ errors may affect user data stored in memory, or in a
+ storage device. This family differs from which protects the user data from integrity
+ errors while being transferred within the TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF.
+
+ Hardware glitches or errors may affect data stored in
+ memory. This family provides requirements to detect these
+ unintentional errors. The integrity of user data while
+ stored on storage devices controlled by the TSF are also addressed
+ by this family.
+
+ To prevent a subject from modifying the data, the or families are required
+ (rather than this family).
+
+ This family differs from that protects
+ the user data from integrity errors while being transferred
+ within the TOE.
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify different kinds of
+ user data attributes that will be used as the basis for
+ monitoring.
+
+
+
+ , requires that the TSF monitor user
+ data stored within containers controlled by the TSF for identified integrity
+ errors.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify which action should
+ be taken in case an integrity error is detected.
+
+
+
+ adds the additional capability to
+ the first component by allowing for actions to be taken as
+ a result of an error detection.
+
+
+ The actions to be taken upon the detection of an integrity
+ error could be configurable.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ action to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken in case an integrity error is detected.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT product.
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT
+ product. Confidentiality is enforced by preventing
+ unauthorised disclosure of user data in transit between the
+ two end points. The end points may be a TSF or a user.
+
+ This family provides a requirement for the protection of user
+ data during transit. In contrast, handles TSF data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The TSF has the ability to protect from disclosure some
+ user data which is exchanged.
+
+
+
+ In , the goal is to provide
+ protection from disclosure of user data while in transit.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any unauthorised user or subject attempting
+ to use the data exchange mechanisms.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the information.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s) and/or information flow control SFP(s)
+
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be
+ enforced when exchanging user data. The specified policies
+ will be enforced to make decisions about who can exchange
+ data and which data can be exchanged.
+ to be able to
+
+ transmit
+
+ receive
+
+ the PP/ST author should specify whether this element
+ applies to a mechanism that transmits or receives user
+ data.
+ user data in a manner protected from unauthorised disclosure.
+
+
+
+
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TOE and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TSF and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+ This family defines the requirements for providing integrity
+ for user data in transit; while handles
+ TSF data.
+
+ and are duals of
+ each other, as addresses user data
+ confidentiality. Therefore, the same mechanism that
+ implements could possibly be used to
+ implement other families such as and
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The TSF has a basic ability to send or receive user data
+ in a manner such that modification of the user data can be
+ detected. There is no requirement for a TSF mechanism to
+ attempt to recover from the modification.
+
+
+
+ addresses detection of
+ modifications, deletions, insertions, and replay errors of
+ the user data transmitted.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced on the transmitted data or on the
+ received data. The specified policies will be enforced
+ to make decisions about who can transmit or who can
+ receive data, and which data can be transmitted or
+ received.
+
+
+ to be able to
+
+
+ transmit
+
+
+ receive
+
+
+
+ the PP/ST author should specify whether this element
+ applies to a TSF that is transmitting or receiving
+ objects.
+
+
+ user data in a manner protected from
+
+
+ modification
+
+
+ deletion
+
+
+ insertion
+
+
+ replay
+
+
+
+ the PP/ST author should specify whether the data
+ should be protected from modification, deletion,
+ insertion or replay.
+
+
+ errors.
+
+
+ The TSF shall be able to determine on receipt of user data,
+ whether
+
+
+ modification
+
+
+ deletion
+
+
+ insertion
+
+
+ replay
+
+
+
+ the PP/ST author should specify whether the errors of
+ the type: modification, deletion, insertion or replay
+ are detected.
+
+
+ has occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors, if required, with the
+ help of the other trusted IT product. As the other trusted
+ IT product is outside the TOE, the TSF cannot control its
+ behaviour. However, it can provide functions that have the
+ ability to cooperate with the other trusted IT product for
+ the purposes of recovery. For example, the TSF could
+ include functions that depend upon the source trusted IT
+ product to re-send the data in the event that an error is
+ detected. This component deals with the ability of the TSF
+ to handle such an error recovery.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF with help from the source
+ trusted IT product.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ Successful recovery from errors including they type of error
+ that was detected.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the TSF, with the help of the source
+ trusted IT product, is be able to recover the original
+ user data.
+
+
+ with the help of the source trusted IT product.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors. It accomplishes this
+ task without help from the source trusted IT product. For
+ example, if certain errors are detected, the transmission
+ protocol must be robust enough to allow the TSF to recover
+ from the error based on checksums and other information
+ available within that protocol.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF on its own without any help
+ from the source trusted IT product.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the receiving TSF, alone, is able to
+ recover the original user data.
+
+
+ without any help from the source trusted IT product.
+
+
+
+
+
+
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user identity.
+
+ Identification and Authentication is required to ensure that
+ users are associated with the proper security attributes
+ (e.g. identity, groups, roles, security or integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the intended
+ security policies. The families in this class deal with
+ determining and verifying the identity of users, determining
+ their authority to interact with the TOE, and with the correct
+ association of security attributes for each authorised
+ user. Other classes of requirements (e.g. User Data
+ Protection, Security Audit) are dependent upon correct
+ identification and authentication of users in order to be
+ effective.
+
+
+
+ A common security requirement is to unambiguously identify the
+ person and/or entity performing functions in a TOE. This
+ involves not only establishing the claimed identity of each
+ user, but also verifying that each user is indeed who he/she
+ claims to be. This is achieved by requiring users to provide
+ the TSF with some information that is known by the TSF to be
+ associated with the user in question.
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user
+ identity. Identification and Authentication is required to
+ ensure that users are associated with the proper security
+ attributes (e.g. identity, groups, roles, security or
+ integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the security
+ policies.
+
+ The family addresses determining the
+ identity of a user.
+
+ The family addresses verifying the
+ identity of a user.
+
+ The family addresses defining limits on
+ repeated unsuccessful authentication attempts.
+
+ The family address the definition of user
+ attributes that are used in the enforcement of the SFRs.
+
+ The family addresses the correct
+ association of security attributes for each authorised user.
+
+ The family addresses the generation and
+ verification of secrets that satisfy a defined metric.
+
+
+
+
+
+ This family contains requirements for defining values for
+ some number of unsuccessful authentication attempts and TSF
+ actions in cases of authentication attempt
+ failures. Parameters include, but are not limited to, the
+ number of failed authentication attempts and time
+ thresholds.
+
+
+
+ This family addresses requirements for defining values for
+ authentication attempts and TSF actions in cases of
+ authentication attempt failure. Parameters include, but are
+ not limited to, the number of attempts and time thresholds.
+
+ The session establishment process is the interaction with
+ the user to perform the session establishment independent of
+ the actual implementation. If the number of unsuccessful
+ authentication attempts exceeds the indicated threshold,
+ either the user account or the terminal (or both) will be
+ locked. If the user account is disabled, the user cannot
+ log-on to the system. If the terminal is disabled, the
+ terminal (or the address that the terminal has) cannot be
+ used for any log-on. Both of these situations continue until
+ the condition for re-establishment is satisfied.
+
+
+
+
+
+
+
+
+ The PP/ST author may define the number of unsuccessful
+ authentication attempts or may choose to let the TOE
+ developer or the authorised user to define this
+ number. The unsuccessful authentication attempts need not
+ be consecutive, but rather related to an authentication
+ event. Such an authentication event could be the count
+ from the last successful session establishment at a given
+ terminal.
+
+ The PP/ST author could specify a list of actions that the
+ TSF shall take in the case of authentication failure. An
+ authorised administrator could also be allowed to manage
+ the events, if deemed opportune by the PP/ST author. These
+ actions could be, among other things, terminal
+ deactivation, user account deactivation, or administrator
+ alarm. The conditions under which the situation will be
+ restored to normal must be specified on the action.
+
+ In order to prevent denial of service, TOEs usually ensure
+ that there is at least one user account that cannot be
+ disabled.
+
+ Further actions for the TSF can be stated by the PP/ST
+ author, including rules for re-enabling the user session
+ establishment process, or sending an alarm to the
+ administrator. Examples of these actions are: until a
+ specified time has lapsed, until the authorised
+ administrator re-enables the terminal/account, a time
+ related to failed previous attempts (every time the
+ attempt fails, the disabling time is doubled).
+
+
+
+ , requires that the TSF be able to
+ terminate the session establishment process after a
+ specified number of unsuccessful user authentication
+ attempts. It also requires that, after termination of the
+ session establishment process, the TSF be able to disable
+ the user account or the point of entry (e.g. workstation)
+ from which the attempts were made until an
+ administrator-defined condition occurs.
+
+
+ management of the threshold for unsuccessful authentication
+ attempts;
+
+
+ management of actions to be taken in the event of an
+ authentication failure.
+
+
+ the reaching of the threshold for the unsuccessful
+ authentication attempts and the actions (e.g. disabling of a
+ terminal) taken and the subsequent, if appropriate,
+ restoration to the normal state (e.g. re-enabling of a
+ terminal).
+
+
+ The TSF shall detect when
+
+ positive integer number
+
+ if the assignment of a positive integer is selected,
+ the PP/ST author should specify the default number
+ (positive integer) of unsuccessful authentication
+ attempts that, when met or surpassed, will trigger
+ the events.
+ an administrator configurable positive integer within
+
+ range of acceptable values
+
+ if an administrator configurable positive integer is
+ selected, the PP/ST author should specify the range of
+ acceptable values from which the administrator of the
+ TOE may configure the number of unsuccessful
+ authentication attempts. The number of authentication
+ attempts should be less than or equal to the upper
+ bound and greater or equal to the lower bound values.
+ the PP/ST author should select either the assignment of a positive integer,
+ or the phrase ``an administrator configurable positive integer'' specifying
+ the range of acceptable values.
+ unsuccessful authentication attempts occur related to
+
+
+ list of authentication events
+
+
+
+ the PP/ST author should specify the authentication
+ events. Examples of these authentication events are:
+ the unsuccessful authentication attempts since the
+ last successful authentication for the indicated user
+ identity, the unsuccessful authentication attempts
+ since the last successful authentication for the
+ current terminal, the number of unsuccessful
+ authentication attempts in the last 10 minutes. At
+ least one authentication event must be specified.
+
+ .
+
+
+ When the defined number of unsuccessful authentication
+ attempts has been
+ metsurpassed
+ the PP/ST author should select whether the event of
+ meeting or surpassing the defined number of unsuccessful
+ authentication attemps shall trigger an action by the
+ TSF., the TSF shall
+
+ list of actions
+
+ the PP/ST author should specify the actions to be taken in
+ case the threshold is met or surpassed, as selected. These
+ actions could be disabling of an account for 5 minutes,
+ disabling the terminal for an increasing amount of time (2
+ to the power of the number of unsuccessful attempts in
+ seconds), or disabling of the account until unlocked by
+ the administrator and simultaneously informing the
+ administrator. The actions should specify the measures and
+ if applicable the duration of the measure (or the
+ conditions under which the measure will be ended)..
+
+
+
+
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that is used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that are used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+ There are dependencies on the individual security policy (SFP)
+ definitions. These individual definitions should contain the
+ listing of attributes that are necessary for policy
+ enforcement.
+
+
+
+
+
+ This component specifies the security attributes that
+ should be maintained at the level of the user. This means
+ that the security attributes listed are assigned to and
+ can be changed at the level of the user. In other words,
+ changing a security attribute in this list associated with
+ a user should have no impact on the security attributes of
+ any other user.
+
+ In case security attributes belong to a group of users
+ (such as Capability List for a group), the user will need
+ to have a reference (as security attribute) to the
+ relevant group.
+
+
+
+ , allows user security attributes
+ for each user to be maintained individually.
+
+
+ if so indicated in the assignment, the authorised
+ administrator might be able to define additional security
+ attributes for users.
+
+
+ The TSF shall maintain the following list of security
+ attributes belonging to individual users:
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that are associated to an individual
+ user. An example of such a list is
+ {``clearance'', ``group
+ identifier'', ``rights''}.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets and generate
+ secrets to satisfy the defined metric.
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets, and generate
+ secrets to satisfy the defined metric. Examples of such
+ mechanisms may include automated checking of user supplied
+ passwords, or automated password generation.
+
+ A secret can be generated outside the TOE (e.g. selected by
+ the user and introduced in the TOE). In such cases, the
+ component can be used to
+ ensure that the external generated secret adheres to certain
+ standards, for example a minimum size, not present in a
+ dictionary, and/or not previously used.
+
+ Secrets can also be generated by the TOE. In those cases,
+ the component can be used
+ to require the TOE to ensure that the secrets that will
+ adhere to some specified metrics.
+
+ Secrets contain the authentication data provided by the user
+ for an authentication mechanism that is based on knowledge
+ the user possesses. When cryptographic keys are employed,
+ the class should be used instead of this
+ family.
+
+
+
+
+
+ Secrets can be generated by the user. This component
+ ensures that those user generated secrets can be verified
+ to meet a certain quality metric.
+
+
+
+ , requires the TSF to verify that
+ secrets meet defined quality metrics.
+
+
+ the management of the metric used to verify the secrets.
+
+
+ Rejection by the TSF of any tested secret;
+
+
+ Rejection or acceptance by the TSF of any tested secret;
+
+
+ Identification of any changes to the defined quality
+ metrics.
+
+
+ The TSF shall provide a mechanism to verify that secrets
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed, or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+
+
+
+
+ This component allows the TSF to generate secrets for
+ specific functions such as authentication by means of
+ passwords.
+
+ When a pseudo-random number generator is used in a secret
+ generation algorithm, it should accept as input random
+ data that would provide output that has a high degree of
+ unpredictability. This random data (seed) can be derived
+ from a number of available parameters such as a system
+ clock, system registers, date, time, etc. The parameters
+ should be selected to ensure that the number of unique
+ seeds that can be generated from these inputs should be at
+ least equal to the minimum number of secrets that must be
+ generated.
+
+
+
+ , requires the TSF to be able to
+ generate secrets that meet defined quality metrics.
+
+
+ the management of the metric used to generate the secrets.
+
+
+
+
+
+ The TSF shall provide a mechanism to generate secrets that
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+ The TSF shall be able to enforce the use of TSF generated
+ secrets for
+
+
+ list of TSF functions
+
+
+
+ the PP/ST author should provide a list of TSF
+ functions for which the TSF generated secrets must be
+ used. An example of such a function could include a
+ password based authentication mechanism.
+
+ .
+
+
+
+
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family also defines
+ the required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family defines the
+ required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+
+
+
+
+
+ This component requires that the PP/ST author define the
+ TSF-mediated actions that can be performed by the TSF on
+ behalf of the user before the claimed identity of the user
+ is authenticated. The TSF-mediated actions should have no
+ security concerns with users incorrectly identifying
+ themselves prior to being authenticated. For all other
+ TSF-mediated actions not in the list, the user must be
+ authenticated before the action can be performed by the
+ TSF on behalf of the user.
+
+ This component cannot control whether the actions can also
+ be performed before the identification took place. This
+ requires the use of either or
+ with the appropriate assignments.
+
+
+
+ , allows a user to perform certain
+ actions prior to the authentication of the
+ user's identity.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the associated
+ user;
+
+
+ managing the list of actions that can be taken before the
+ user is authenticated.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism;
+
+
+ All TSF mediated actions performed before authentication of
+ the user.
+
+
+ The TSF shall allow
+
+
+ list of TSF mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the claimed identity of the user is
+ authenticated. This list cannot be empty. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ authenticated.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+
+
+
+
+ This component requires that a user is authenticated before any other
+ TSF-mediated action can take place on behalf of that user.
+
+
+ , requires that users are
+ authenticated before any other action will be allowed by the TSF.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the user associated
+ with this data.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+ This component addresses requirements for mechanisms that
+ provide protection of authentication data. Authentication
+ data that is copied from another user, or is in some way
+ constructed should be detected and/or rejected. These
+ mechanisms provide confidence that users authenticated by
+ the TSF are actually who they claim to be.
+
+ This component may be useful only with authentication
+ mechanisms that are based on authentication data that
+ cannot be shared (e.g. biometrics). It is impossible for a
+ TSF to detect or prevent the sharing of passwords outside
+ the control of the TSF.
+
+
+
+ Unforgeable authentication,
+ requires the authentication mechanism to be able to detect
+ and prevent the use of authentication data that has been
+ forged or copied.
+
+
+ Detection of fraudulent authentication data;
+
+
+ All immediate measures taken and results of checks on the
+ fraudulent data.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent forging of
+ authentication data.
+
+
+ use of authentication data that has been forged by any user
+ of the TSF.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent copying of
+ authentication data.
+
+
+ use of authentication data that has been copied from any
+ other user of the TSF.
+
+
+
+
+
+
+ This component addresses requirements for authentication
+ mechanisms based on single-use authentication
+ data. Single-use authentication data can be something the
+ user has or knows, but not something the user is. Examples
+ of single-use authentication data include single-use
+ passwords, encrypted time-stamps, and/or random numbers
+ from a secret lookup table.
+
+ The PP/ST author can specify to which authentication
+ mechanism(s) this requirement applies.
+
+
+
+ , requires an authentication
+ mechanism that operates with single-use authentication
+ data.
+
+
+ Attempts to reuse authentication data.
+
+
+ The TSF shall prevent reuse of authentication data related
+ to
+
+
+ identified authentication mechanism(s)
+
+
+
+ the PP/ST author should specify the list of
+ authentication mechanisms to which this requirement
+ applies. This assignment can be ``all
+ authentication mechanisms''. An example of
+ this assignment could be ``the
+ authentication mechanism employed to authenticate
+ people on the external network''.
+
+ .
+
+
+
+
+
+
+ The use of this component allows specification of
+ requirements for more than one authentication mechanism to
+ be used within a TOE. For each distinct mechanism,
+ applicable requirements must be chosen from the class to be applied to each
+ mechanism. It is possible that the same component could be
+ selected multiple times in order to reflect different
+ requirements for the different use of the authentication
+ mechanism.
+
+ The management functions in the class FMT may provide
+ maintenance capabilities for the set of authentication
+ mechanisms, as well as the rules that determine whether
+ the authentication was successful.
+
+ To allow anonymous users to interact with the TOE, a
+ ``none'' authentication mechanism can be incorporated. The
+ use of such access should be clearly explained in the
+ rules of .
+
+
+
+ , requires that different
+ authentication mechanisms be provided and used to
+ authenticate user identities for specific events.
+
+
+ the management of authentication mechanisms;
+
+
+ the management of the rules for authentication.
+
+
+ The final decision on authentication;
+
+
+ The result of each activated mechanism together with the
+ final decision.
+
+
+ The TSF shall provide
+
+
+ list of multiple authentication mechanisms
+
+
+
+ the PP/ST author should define the available
+ authentication mechanisms. An example of such a list
+ could be: ``none, password mechanism,
+ biometric (retinal scan), S/key mechanism''.
+
+
+ to support user authentication.
+
+
+ The TSF shall authenticate any user's claimed
+ identity according to the
+
+
+ rules describing how the multiple authentication
+ mechanisms provide authentication
+
+
+
+ the PP/ST author should specify the rules that
+ describe how the authentication mechanisms provide
+ authentication and when each is to be used. This means
+ that for each situation the set of mechanisms that
+ might be used for authenticating the user must be
+ described. An example of a list of such rules is:
+ ``if the user has special privileges a
+ password mechanism and a biometric mechanism both
+ shall be used, with success only if both succeed; for
+ all other users a password mechanism shall be
+ used.''
+
+ The PP/ST author might give the boundaries within
+ which the authorised administrator may specify
+ specific rules. An example of a rule is:
+ ``the user shall always be authenticated by
+ means of a token; the administrator might specify
+ additional authentication mechanisms that also must be
+ used.'' The PP/ST author also might choose
+ not to specify any boundaries but leave the
+ authentication mechanisms and their rules completely
+ up to the authorised administrator.
+
+ .
+
+
+
+
+
+
+ This component addresses potential needs to
+ re-authenticate users at defined points in time. These may
+ include user requests for the TSF to perform security
+ relevant actions, as well as requests from non-TSF
+ entities for re-authentication (e.g. a server application
+ requesting that the TSF re-authenticate the client it is
+ serving).
+
+
+
+ , requires the ability to specify
+ events for which the user needs to be re-authenticated.
+
+
+ if an authorised administrator could request
+ re-authentication, the management includes a
+ re-authentication request.
+
+
+ Failure of reauthentication;
+
+
+ All reauthentication attempts.
+
+
+ The TSF shall re-authenticate the user under the conditions
+
+
+ list of conditions under which re-authentication is
+ required
+
+
+
+ the PP/ST author should specify the list of conditions
+ requiring re-authentication. This list could include a
+ specified user inactivity period that has elapsed, the
+ user requesting a change in active security
+ attributes, or the user requesting the TSF to perform
+ some security critical function.
+
+ The PP/ST author might give the boundaries within
+ which the reauthentication should occur and leave the
+ specifics to the authorised administrator. An example
+ of such a rule is: ``the user shall always
+ be re-authenticated at least once a day; the
+ administrator might specify that the re-authentication
+ should happen more often but not more often than once
+ every 10 minutes.''
+
+ .
+
+
+
+
+
+
+
+
+
+ This component addresses the feedback on the
+ authentication process that will be provided to the
+ user. In some systems the feedback consists of indicating
+ how many characters have been typed but not showing the
+ characters themselves, in other systems even this
+ information might not be appropriate.
+
+ This component requires that the authentication data is
+ not provided as-is back to the user. In a workstation
+ environment, it could display a
+ ``dummy'' (e.g. star) for each
+ password character provided, and not the original
+ character.
+
+
+
+ , requires that only limited
+ feedback information is provided to the user during the
+ authentication.
+
+
+ The TSF shall provide only
+
+
+ list of feedback
+
+
+
+ the PP/ST author should specify the feedback related
+ to the authentication process that will be provided to
+ the user. An example of a feedback assignment is
+ ``the number of characters
+ typed'', another type of feedback is
+ ``the authentication mechanism that failed
+ the authentication''.
+
+
+ to the user while the authentication is in progress.
+
+
+
+
+
+
+
+ This family defines the conditions under which users shall
+ be required to identify themselves before performing any
+ other actions that are to be mediated by the TSF and which
+ require user identification.
+
+
+
+ This family defines the conditions under which users are
+ required to identify themselves before performing any other
+ actions that are to be mediated by the TSF and that require
+ user identification.
+
+
+
+
+
+ This component poses requirements for the user to be
+ identified. The PP/ST author can indicate specific actions
+ that can be performed before the identification takes
+ place.
+
+ If is used, the TSF-mediated
+ actions mentioned in should also
+ appear in this .
+
+
+
+ , allows users to perform certain
+ actions before being identified by the TSF.
+
+
+ the management of the user identities;
+
+
+ if an authorised administrator can change the actions
+ allowed before identification, the managing of the action
+ lists.
+
+
+ Unsuccessful use of the user identification mechanism,
+ including the user identity provided;
+
+
+ All use of the user identification mechanism, including the
+ user identity provided.
+
+
+ The TSF shall allow
+
+
+ list of TSF-mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the user has to identify itself. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ identified.
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ In this component users will be identified. A user is not
+ allowed by the TSF to perform any action before being
+ identified.
+
+
+
+ , requires that users identify
+ themselves before any other action will be allowed by the TSF.
+
+
+ the management of the user identities.
+
+
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ It is intended that a subject is
+ acting on behalf of the user who caused the subject to come into
+ being or to be activated to perform a certain task.
+ Therefore, when a subject is created, that subject is acting on
+ behalf of the user who initiated the creation. In cases where
+ anonymity is used, the subject is still acting on behalf of a
+ user, but the identity of that user is unknown. A special
+ category of subjects are those subjects that serve multiple
+ users (e.g. a server process). In such cases the user that
+ created this subject is assumed to be the ``owner''., requires the specification of any rules
+ governing the association between user attributes and the
+ subject attributes into which they are mapped.
+ an authorised administrator can define default subject security
+ attributes.
+
+ an authorised administrator can change subject security
+ attributes.
+
+ Unsuccessful binding of user security attributes to a subject
+ (e.g. creation of a subject).
+
+ Success and failure of binding of user security attributes to a
+ subject (e.g. success or failure to create a subject).
+
+ The TSF shall associate the following user security attributes
+ with subjects acting on the behalf of that user:
+
+ list of user security attributes
+
+ the PP/ST author should specify a list of the user security
+ attributes that are to be bound to subjects..
+
+ The TSF shall enforce the following rules on the initial
+ association of user security attributes with subjects acting on
+ the behalf of users:
+
+ rules for the initial association of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ upon initial association of attributes with subjects, or
+ ``none''..
+
+ The TSF shall enforce the following rules governing changes to the
+ user security attributes associated with subjects acting on the
+ behalf of users:
+
+ rules for the changing of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ when changes are made to the user security attributes
+ associated with subjects acting on behalf of users, or
+ ``none''..
+
+
+
+
+
+
+ This class is intended to specify the management of several
+ aspects of the TSF: security attributes, TSF data and
+ functions. The different management roles and their
+ interaction, such as separation of capability, can be
+ specified.
+
+ This class has several objectives:
+
+
+ management of TSF data, which include, for example,
+ banners;
+
+
+ management of security attributes, which include, for
+ example, the Access Control Lists, and Capability Lists;
+
+
+ management of functions of the TSF, which includes, for
+ example, the selection of functions, and rules or
+ conditions influencing the behaviour of the TSF;
+
+
+ definition of security roles.
+
+
+
+
+
+ This class specifies the management of several aspects of the
+ TSF: security attributes, TSF data and functions in the
+ TSF. The different management roles and their interaction,
+ such as separation of capability, can also be specified
+
+ In an environment where the TOE is made up of multiple
+ physically separated parts, the timing issues with respect to
+ propagation of security attributes, TSF data, and function
+ modification become very complex, especially if the
+ information is required to be replicated across the parts of
+ the TOE. This should be considered when selecting components
+ such as , or , where the behaviour might be
+ impaired. In such situations, use of components from is advisable.
+
+
+
+
+
+ This family allows authorised users control over the
+ management of functions in the TSF. Examples of functions in
+ the TSF include the audit functions and the multiple
+ authentication functions.
+
+
+
+ The TSF management functions enable authorised users to set
+ up and control the secure operation of the TOE. These
+ administrative functions typically fall into a number of
+ different categories:
+
+
+ Management functions that relate to access control,
+ accountability and authentication controls enforced by
+ the TOE. For example, definition and update of user
+ security characteristics (e.g. unique identifiers
+ associated with user names, user accounts, system entry
+ parameters) or definition and update of auditing system
+ controls (e.g. selection of audit events, management of
+ audit trails, audit trail analysis, and audit report
+ generation), definition and update of per-user policy
+ attributes (such as user clearance), definition of known
+ system access control labels, and control and management
+ of user groups.
+
+
+ Management functions that relate to controls over
+ availability. For example, definition and update of
+ availability parameters or resource quotas.
+
+
+ Management functions that relate to general installation
+ and configuration. For example, TOE configuration,
+ manual recovery, installation of TOE security fixes (if
+ any), repair and reinstallation of hardware.
+
+
+ Management functions that relate to routine control and
+ maintenance of TOE resources. For example, enabling and
+ disabling peripheral devices, mounting of removable
+ storage media, backup and recovery.
+
+
+
+ Note that these functions need to be present in a TOE based
+ on the families included in the PP or ST. It is the
+ responsibility of the PP/ST author to ensure that adequate
+ functions will be provided to manage the TOE in a secure
+ fashion.
+
+ The TSF might contain functions that can be controlled by an
+ administrator. For example, the auditing functions could be
+ switched off, the time synchronisation could be switchable,
+ and/or the authentication mechanism could be modifiable.
+
+
+
+
+
+
+
+
+
+ This component allows identified roles to manage the
+ security functions of the TSF. This might entail obtaining
+ the current status of a security function, disabling or
+ enabling the security function, or modifying the behaviour
+ of the security function. An example of modifying the
+ behaviour of the security functions is changing of
+ authentication mechanisms.
+
+
+
+ allows the authorised users (roles)
+ to manage the behaviour of functions in the TSF that use
+ rules or have specified conditions that may be manageable.
+
+
+ managing the group of roles that can interact with the
+ functions in the TSF;
+
+
+ All modifications in the behaviour of the functions in the
+ TSF.
+
+
+ The TSF shall restrict the ability to
+
+
+ determine the behaviour of
+
+
+ disable
+
+
+ enable
+
+
+ modify the behaviour of
+
+
+
+ the PP/ST author should select whether the role can
+ determine the behaviour of, disable, enable, and/or
+ modify the behaviour of the security functions.
+
+
+ the functions
+
+
+ list of functions
+
+
+
+ the PP/ST author should specify the functions that can
+ be modified by the identified roles. Examples include
+ auditing and time determination.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the functions in the TSF. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+ This family allows authorised users control over the
+ management of security attributes. This management might
+ include capabilities for viewing and modifying of security
+ attributes.
+
+
+
+ This family defines the requirements on the management of
+ security attributes.
+
+ Security attributes affect the behaviour of the TSF. Examples of
+ security attributes are the groups to which a user belongs, the
+ roles he/she might assume, the priority of a process (subject),
+ and the rights belonging to a role or a user. These security
+ attributes might need to be managed by the user, a subject, a
+ specific authorised user (a user with explicitly given rights
+ for this management) or inherit values according to a given
+ policy/set of rules.
+
+ It is noted that the right to assign rights to users is
+ itself a security attribute and/or potentially subject to
+ management by .
+ can be used to ensure that any
+ accepted combination of security attributes is within a
+ secure state. The definition of what
+ ``secure'' means is left to the TOE guidance.
+
+ In some instances subjects, objects or user accounts are
+ created. If no explicit values for the related security
+ attributes are given, default values need to be used. can be used to specify that these default
+ values can be managed.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component allows users acting in certain roles to
+ manage identified security attributes. The users are
+ assigned to a role within the component .
+
+ The default value of a parameter is the value the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter, and
+ overrides the default value.
+
+
+
+ allows authorised users (roles) to
+ manage the specified security attributes.
+
+
+ managing the group of roles that can interact with the
+ security attributes;
+
+ management of rules by which security attributes inherit
+ specified values.
+
+
+ All modifications of the values of security attributes.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s), information flow control SFP(s)
+
+ the PP/ST author should list the access control SFP(s) or
+ the information flow control SFP(s) for which the security
+ attributes are applicable.
+ to restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example of such an operation could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified security
+ attributes. The PP/ST author can specify that the role
+ can modify the default value (change_default), query,
+ modify the security attribute, delete the security
+ attributes entirely or define their own operation.
+
+
+ the security attributes
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that can be operated on by the identified
+ roles. It is possible for the PP/ST author to specify
+ that the default value such as default access-rights
+ can be managed. Examples of these security attributes
+ are user-clearance, priority of service level, access
+ control list, default access rights.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the security attributes. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component contains requirements on the values that
+ can be assigned to security attributes. The assigned
+ values should be such that the TOE will remain in a secure
+ state.
+
+ The definition of what ``secure'' means is
+ not answered in this component but is left to the
+ development of the TOE and the resulting information in the
+ guidance. An example could be that if a user account is
+ created, it should have a non-trivial password.
+
+
+
+ ensures that values assigned to
+ security attributes are valid with respect to the secure
+ state.
+
+ management of rules by which security attributes inherit
+ specified values.
+
+
+ All offered and rejected values for a security attribute;
+
+
+ All offered and accepted secure values for a security
+ attribute.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for
+ list of security attributes
+
+ the PP/ST author should specify the list of security
+ attributes that require only secure values to be provided..
+
+
+
+
+
+
+
+
+
+
+ This component requires that the TSF provide default
+ values for relevant object security attributes, which can
+ be overridden by an initial value. It may still be
+ possible for a new object to have different security
+ attributes at creation, if a mechanism exists to specify
+ the permissions at time of creation.
+
+
+
+ ensures that the default values of
+ security attributes are appropriately either permissive or
+ restrictive in nature.
+
+
+ managing the group of roles that can specify initial values;
+
+
+ managing the permissive or restrictive setting of default values
+ for a given access control SFP;
+
+ management of rules by which security attributes inherit specified values.
+
+
+ Modifications of the default setting of permissive or
+ restrictive rules.
+
+
+ All modifications of the initial values of security
+ attributes.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP, information flow control SFP
+
+
+
+ the PP/ST author should list the access control SFP or
+ the information flow control SFP for which the
+ security attributes are applicable.
+
+
+ to provide
+
+
+ restrictive
+
+
+ permissive
+
+
+ other property
+
+ if the PP/ST author selects another property, the PP/ST
+ author should specify the desired characteristics of the
+ default values.
+
+
+ the PP/ST author should select whether the default property
+ of the access control attribute will be restrictive,
+ permissive, or another property. Only one of these options
+ may be chosen.
+
+
+ default values for security attributes that are used to
+ enforce the SFP.
+
+
+ The TSF shall allow the
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the values of the security
+ attributes. The possible roles are specified in .
+
+
+ to specify alternative initial values to override the
+ default values when an object or information is created.
+
+
+ This component requires specification of the set of rules
+ through which the security attribute inherits values and the
+ conditions to be met for these rules to be applied. allows the rules/policies
+ to be specified that will dictate the value to be inherited
+ by a security attribute.
+ specification of the role permitted to establish or modify
+ security attributes.
+
+ Modifications of security attributes, possibly with the old
+ and/or values of security attributes that were modified.
+
+ The TSF shall use the following rules to set the value of security attributes:
+
+ rules for setting the values of security attributes
+
+ the PP/ST author specifies the rules governing the value
+ that will be inherited by the specified security
+ attribute, including the conditions that are to be met
+ for the rules to be applied. For example, if a new file
+ or directory is created (in a multilevel filesystem),
+ its label is the label at which the user is logged in at
+ the time it is created.
+
+
+
+
+
+ This family allows authorised users (roles) control over the
+ management of TSF data. Examples of TSF data include audit
+ information, clock and other TSF
+ configuration parameters.
+
+
+
+ This component imposes requirements on the management of TSF
+ data. Examples of TSF data are the current time and the
+ audit trail. So, for example, this family allows the
+ specification of whom can read, delete or create the audit
+ trail.
+
+
+
+
+
+
+
+
+ This component allows users with a certain role to manage
+ values of TSF data. The users are assigned to a role
+ within the component .
+
+ The default value of a parameter is the values the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter and
+ overrides the default value.
+
+
+
+ allows authorised users to manage
+ TSF data.
+
+
+ managing the group of roles that can interact with the TSF
+ data.
+
+
+ All modifications to the values of TSF data.
+
+
+ The TSF shall restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+ clear
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified TSF data. The PP/ST
+ author can specify that the role can modify the
+ default value (change_default), clear, query or modify
+ the TSF data, or delete the TSF data entirely. If so
+ desired the PP/ST author could specify any type of
+ operation. To clarify ``clear TSF data'' means that
+ the content of the TSF data is removed, but that the
+ entity that stores the TSF data remains in the
+ TOE.
+
+
+ the
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ be operated on by the identified roles. It is possible
+ for the PP/ST author to specify that the default value
+ can be managed.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the TSF data. The possible roles
+ are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies limits on TSF data, and actions
+ to be taken if these limits are exceeded. This component,
+ for example, will allow limits on the size of the audit
+ trail to be defined, and specification of the actions to
+ be taken when these limits are exceeded.
+
+
+
+ specifies the action to be taken if
+ limits on TSF data are reached or exceeded.
+
+
+ managing the group of roles that can interact with the
+ limits on the TSF data.
+
+
+ All modifications to the limits on TSF data;
+
+
+ All modifications in the actions to be taken in case of
+ violation of the limits.
+
+
+ The TSF shall restrict the specification of the limits for
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ have limits, and the value of those limits. An example
+ of such TSF data is the number of users logged-in.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the limits on the TSF data and the
+ actions to be taken. The possible roles are specified
+ in .
+
+ .
+
+
+ The TSF shall take the following actions, if the TSF data
+ are at, or exceed, the indicated limits:
+
+
+ actions to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken if the specified limit on the specified TSF data
+ is exceeded. An example of such TSF action is that the
+ authorised user is informed and an audit record is
+ generated.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component covers requirements on the values that can
+ be assigned to TSF data. The assigned values should be
+ such that the TOE will remain in a secure state.
+
+ The definition of what ``secure'' means is not
+ answered in this component but is left to the development of
+ the TOE and the
+ resulting information in the guidance.
+
+
+
+ ensures that values assigned to TSF
+ data are valid with respect to the secure state.
+
+
+ All rejected values of TSF data.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for
+ list of TSF data
+
+ the PP/ST author should specify what TSF data require only
+ secure values to be accepted..
+
+
+
+
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+
+
+
+
+
+ This component specifies requirements on the revocation of
+ rights. It requires the specification of the revocation
+ rules. Examples are:
+
+
+ Revocation will take place on the next login of the
+ user;
+
+
+ Revocation will take place on the next attempt to open
+ the file;
+
+
+ Revocation will take place within a fixed time. This
+ might mean that all open connections are re-evaluated
+ every x minutes.
+
+
+
+
+
+ provides for revocation of security
+ attributes to be enforced at some point in time.
+
+
+ managing the group of roles that can invoke revocation of
+ security attributes;
+
+
+ managing the lists of users, subjects, objects and other
+ resources for which revocation is possible;
+
+
+ managing the revocation rules.
+
+
+ Unsuccessful revocation of security attributes;
+
+
+ All attempts to revoke security attributes.
+
+
+ The TSF shall restrict the ability to revoke
+
+ list of security attributes
+
+ the PP/ST author should specify which security attributes
+ are to be revoked when a change is made to the associated
+ object/subject/user/other resource.
+ associated with the
+
+ users
+
+ subjects
+
+ objects
+ other additional resources
+ the PP/ST author should, if additional resources is
+ selected, specify whether the ability to revoke their
+ security attributes shall be provided by the
+ TSF.
+ the PP/ST author should specify whether the ability to
+ revoke security attributes from users, subjects, objects,
+ or any additional resources shall be provided by the
+ TSF.
+ under the control of the TSF to
+
+ the authorised identified roles
+
+ the PP/ST author should specify the roles that are allowed
+ to modify the functions in the TSF. The possible roles are
+ specified in ..
+
+
+ The TSF shall enforce the rules
+
+
+ specification of revocation rules
+
+
+
+ the PP/ST author should specify the revocation
+ rules. Examples of these rules could include:
+ ``prior to the next operation on the
+ associated resource'', or ``for
+ all new subject creations''.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes.
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes. This family can be
+ applied to specify expiration requirements for access
+ control attributes, identification and authentication
+ attributes, certificates (key certificates such as ANSI X509
+ for example), audit attributes, etc.
+
+
+
+
+
+
+
+
+
+ provides the capability for an
+ authorised user to specify an expiration time on specified
+ security attributes.
+
+
+ managing the list of security attributes for which
+ expiration is to be supported;
+
+
+ the actions to be taken if the expiration time has passed.
+
+
+ Specification of the expiration time for an attribute;
+
+
+ Action taken due to attribute expiration.
+
+
+ The TSF shall restrict the capability to specify an
+ expiration time for
+
+
+ list of security attributes for which expiration is to
+ be supported
+
+
+
+ the PP/ST author should provide the list of security
+ attributes for which expiration is to be supported. An
+ example of such an attribute might be a
+ user's security clearance.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the security attributes in the
+ TSF. The possible roles are specified in .
+
+ .
+
+
+ For each of these security attributes, the TSF shall be able
+ to
+
+
+ list of actions to be taken for each security attribute
+
+
+
+ the PP/ST author should provide a list of actions to
+ be taken for each security attribute when it
+ expires. An example might be that the
+ user's security clearance, when it expires,
+ is set to the lowest allowable clearance on the
+ TOE. If immediate revocation is desired by the PP/ST,
+ the action ``immediate
+ revocation'' should be specified.
+
+
+ after the expiration time for the indicated security
+ attribute has passed.
+
+
+
+ This family allows the specification of the management
+ functions to be provided by the TOE. Management functions
+ provide TSFI that allow administrators to define the
+ parameters that control the operation of security-related
+ aspects of the TOE, such as data protection attributes, TOE
+ protection attributes, audit attributes, and identification
+ and authentication attributes. Management functions also
+ include those functions performed by an operator to ensure
+ continued operation of the TOE, such as backup and
+ recovery. This family works in conjunction with the other
+ components in the class: the component in
+ this family calls out the management functions, and other
+ families in restrict the ability to use
+ these management functions.
+ This family allows the specification of the management
+ functions to be provided by the TOE. Each security
+ management function that is listed in fulfilling the
+ assignment is either security attribute management, TSF data
+ management, or security function management.
+ This component specifies the management functions to be
+ provided.
+ PP/ST authors should consult the ``Management'' sections
+ for components included in their PP/ST to provide a basis
+ for the management functions to be listed via this
+ component. requires that the TSF provide
+ specific management functions.
+ Use of the management functions.
+
+ The TSF shall be capable of performing the following
+ management functions:
+
+ list of management functions to be provided by
+ the TSF
+
+ the PP/ST author should specify the management
+ functions to be provided by the TSF, either security
+ attribute management, TSF data management, or security
+ function management..
+
+
+
+
+
+ This family is intended to control the assignment of
+ different roles to users. The capabilities of these roles
+ with respect to security management are described in the
+ other families in this class.
+
+
+
+ This family reduces the likelihood of damage resulting from
+ users abusing their authority by taking actions outside
+ their assigned functional responsibilities. It also
+ addresses the threat that inadequate mechanisms have been
+ provided to securely administer the TSF.
+
+ This family requires that information be maintained to
+ identify whether a user is authorised to use a particular
+ security-relevant administrative function.
+
+ Some management actions can be performed by users, others
+ only by designated people within the organisation. This
+ family allows the definition of different roles, such as
+ owner, auditor, administrator, daily-management.
+
+ The roles as used in this family are security related
+ roles. Each role can encompass an extensive set of
+ capabilities (e.g. root in UNIX), or can be a single right
+ (e.g. right to read a single object such as the
+ helpfile). This family defines the roles. The capabilities
+ of the role are defined in , and .
+
+ Some type of roles might be mutually exclusive. For example
+ the daily-management might be able to define and activate
+ users, but might not be able to remove users (which is
+ reserved for the administrator (role)). This class will
+ allow policies such as two-person control to be specified.
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise. Often the system distinguishes between
+ the owner of an entity, an administrator and other users.
+
+
+
+ specifies the roles with respect to
+ security that the TSF recognises.
+
+
+ managing the group of users that are part of a role.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor and administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise, and conditions on how those roles could
+ be managed. Often the system distinguishes between the
+ owner of an entity, an administrator and other users.
+
+ The conditions on those roles specify the
+ interrelationship between the different roles, as well as
+ restrictions on when the role can be assumed by a user.
+
+
+
+ specifies that in addition to the
+ specification of the roles, there are rules that control
+ the relationship between the roles.
+
+
+ managing the group of users that are part of a role;
+
+
+ managing the conditions that the roles must satisfy.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ unsuccessful attempts to use a role due to the given
+ conditions on the roles;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles:
+
+
+ authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor, administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+ The TSF shall ensure that the conditions
+
+
+ conditions for the different roles
+
+
+
+ the PP/ST author should specify the conditions that
+ govern role assignment. Examples of these conditions
+ are: ``an account cannot have both the
+ auditor and administrator role'' or
+ ``a user with the assistant role must also
+ have the owner role''.
+
+
+ are satisfied.
+
+
+
+
+
+
+
+
+
+ This component specifies that an explicit request must be
+ given to assume the specific role.
+
+
+
+ , requires that an explicit request
+ is given to the TSF to assume a role.
+
+
+ explicit request to assume a role.
+
+
+ The TSF shall require an explicit request to assume the
+ following roles:
+
+
+ the roles
+
+
+
+ the PP/ST author should specify the roles that require
+ an explicit request to be assumed. Examples are:
+ auditor and administrator.
+
+ .
+
+
+
+
+
+
+
+ This class contains privacy requirements. These requirements
+ provide a user protection against discovery and misuse of
+ identity by other users.
+
+
+
+ This class describes the requirements that could be levied to
+ satisfy the users' privacy needs, while still allowing
+ the system flexibility as far as possible to maintain
+ sufficient control over the operation of the system.
+
+ In the components of this class there is flexibility as to
+ whether or not authorised users are covered by the required
+ security functionality. For example, a PP/ST author might
+ consider it appropriate not to require protection of the privacy
+ of users against a suitably authorised user.
+
+ This class, together with other classes (such as those
+ concerned with audit, access control, trusted path, and
+ non-repudiation) provides the flexibility to specify the
+ desired privacy behaviour. On the other hand, the requirements
+ in this class might impose limitations on the use of the
+ components of other classes, such as or . For example, if
+ authorised users are not allowed to see the user identity
+ (e.g. Anonymity or Pseudonymity), it will obviously not be
+ possible to hold individual users accountable for any security
+ relevant actions they perform that are covered by the privacy
+ requirements. However, it may still be possible to include
+ audit requirements in a PP/ST, where the fact that a
+ particular security relevant event has occurred is more
+ important than knowing who was responsible for it.
+
+ Additional information is provided in the application notes
+ for class , where it is explained that the
+ definition of ``identity'' in the context of
+ auditing can also be an alias or other information that could
+ identify a user.
+
+ This class describes four families: Anonymity, Pseudonymity,
+ Unlinkability and Unobservability. Anonymity, Pseudonymity and
+ Unlinkability have a complex interrelationship. When choosing
+ a family, the choice should depend on the threats
+ identified. For some types of privacy threats, pseudonymity
+ will be more appropriate than anonymity (e.g. if there is a
+ requirement for auditing). In addition, some types of privacy
+ threats are best countered by a combination of components from
+ several families.
+
+ All families assume that a user does not explicitly perform an
+ action that discloses the user's own identity. For
+ example, the TSF is not expected to screen the user name in
+ electronic messages or databases.
+
+ All families in this class have components that can be scoped
+ through operations. These operations allow the PP/ST author to
+ state the cooperating users/subjects to which the TSF must be
+ resistant. An example of an instantiation of anonymity could
+ be: `` The TSF shall ensure that the users and/or
+ subjects are unable to determine the user identity bound to
+ the teleconsulting application''.
+
+ It is noted that the TSF should not only provide this
+ protection against individual users, but also against users
+ cooperating to obtain the information.
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing the user's identity. The
+ requirements for Anonymity provide protection of the user
+ identity. Anonymity is not intended to protect the subject
+ identity.
+
+
+
+ Anonymity ensures that a subject may use a resource or
+ service without disclosing its user identity.
+
+ The intention of this family is to specify that a user or
+ subject might take action without releasing its user
+ identity to others such as users, subjects, or objects. The
+ family provides the PP/ST author with a means to identify
+ the set of users that cannot see the identity of someone
+ performing certain actions.
+
+ Therefore if a subject, using anonymity, performs an action,
+ another subject will not be able to determine either the
+ identity or even a reference to the identity of the user
+ employing the subject. The focus of the anonymity is on the
+ protection of the users identity, not on the protection of
+ the subject identity; hence, the identity of the subject is
+ not protected from disclosure.
+
+ Although the identity of the subject is not released to
+ other subjects or users, the TSF is not explicitly
+ prohibited from obtaining the users identity. In case the
+ TSF is not allowed to know the identity of the user, could be invoked. In that case
+ the TSF should not request the user information.
+
+ The interpretation of ``determine'' should be
+ taken in the broadest sense of the word.
+
+ The component levelling distinguishes between the users and
+ an authorised user. An authorised user is often excluded
+ from the component, and therefore allowed to retrieve a
+ user's identity. However, there is no specific
+ requirement that an authorised user must be able to have the
+ capability to determine the user's identity. For
+ ultimate privacy the components would be used to say that no
+ user or authorised user can see the identity of anyone
+ performing any action.
+
+ Although some systems will provide anonymity for all
+ services that are provided, other systems provide anonymity
+ for certain subjects/operations. To provide this
+ flexibility, an operation is included where the scope of the
+ requirement is defined. If the PP/ST author wants to address
+ all subjects/operations, the words ``all subjects and
+ all operations'' could be provided.
+
+ Possible applications include the ability to make enquiries
+ of a confidential nature to public databases, respond to
+ electronic polls, or make anonymous payments or donations.
+
+ Examples of potential hostile users or subjects are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts (e.g. Trojan Horses) into
+ systems. All of these users can investigate usage patterns
+ (e.g. which users used which services) and misuse this
+ information.
+
+
+
+
+
+ This component ensures that the identity of a user is
+ protected from disclosure. There may be instances,
+ however, that a given authorised user can determine who
+ performed certain actions. This component gives the
+ flexibility to capture either a limited or total privacy
+ policy.
+
+
+
+ , requires that other users or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation.
+
+
+ The invocation of the anonymity mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+
+
+
+
+
+ This component is used to ensure that the TSF is not
+ allowed to know the identity of the user.
+
+
+
+ enhances the
+ requirements of by
+ ensuring that the TSF does not ask for the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the anonymity requirement, for
+ example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which the real user name of the subject should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to the real user name.
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing its user identity, but can still
+ be accountable for that use.
+
+
+
+ Pseudonymity ensures that a user may use a resource or
+ service without disclosing its identity, but can still be
+ accountable for that use. The user can be accountable by
+ directly being related to a reference (alias) held by the
+ TSF, or by providing an alias that will be used for
+ processing purposes, such as an account number.
+
+ In several respects, pseudonymity resembles anonymity. Both
+ pseudonymity and anonymity protect the identity of the user,
+ but in pseudonymity a reference to the user's
+ identity is maintained for accountability or other purposes.
+
+ The component does not
+ specify the requirements on the reference to the user's
+ identity. For the purpose of specifying requirements on this
+ reference two sets of requirements are presented: and .
+
+ A way to use the reference is by being able to obtain the
+ original user identity. For example, in a digital cash
+ environment it would be advantageous to be able to trace the
+ user's identity when a check has been issued multiple times
+ (i.e. fraud). In general, the user's identity needs to be
+ retrieved under specific conditions. The PP/ST author might
+ want to incorporate to
+ describe those services.
+
+ Another usage of the reference is as an alias for a
+ user. For example, a user who does not wish to be
+ identified, can provide an account to which the resource
+ utilisation should be charged. In such cases, the reference
+ to the user identity is an alias for the user, where other
+ users or subjects can use the alias for performing their
+ functions without ever obtaining the user's
+ identity (for example, statistical operations on use of the
+ system). In this case, the PP/ST author might wish to
+ incorporate to specify the rules to
+ which the reference must conform.
+
+ Using these constructs above, digital money can be created
+ using specifying that the user
+ identity will be protected and, if so specified in the
+ condition, that there be a requirement to trace the user
+ identity if the digital money is spent twice. When the user
+ is honest, the user identity is protected; if the user tries
+ to cheat, the user identity can be traced.
+
+ A different kind of system could be a digital credit card,
+ where the user will provide a pseudonym that indicates an
+ account from which the cash can be subtracted. In such
+ cases, for example, could be
+ used. This component would specify that the user identity
+ will be protected and, furthermore, that the same user will
+ only get assigned values for which he/she has provided money
+ (if so specified in the conditions).
+
+ It should be realised that the more stringent components
+ potentially cannot be combined with other requirements, such
+ as identification and authentication or audit. The
+ interpretation of ``determine the identity''
+ should be taken in the broadest sense of the word. The
+ information is not provided by the TSF during the operation,
+ nor can the entity determine the subject or the owner of the
+ subject that invoked the operation, nor will the TSF record
+ information, available to the users or subjects, which might
+ release the user identity in the future.
+
+ The intent is that the TSF not reveal any information that
+ would compromise the identity of the user, e.g. the identity
+ of subjects acting on the user's behalf. The
+ information that is considered to be sensitive depends on
+ the effort an attacker is capable of spending.
+
+ Possible applications include the ability to charge a caller
+ for premium rate telephone services without disclosing his
+ or her identity, or to be charged for the anonymous use of
+ an electronic payment system.
+
+ Examples of potential hostile users are providers, system
+ operators, communication partners and users, who smuggle
+ malicious parts (e.g. Trojan Horses) into systems. All of
+ these attackers can investigate which users used which
+ services and misuse this information. Additionally to
+ Anonymity services, Pseudonymity Services contains methods
+ for authorisation without identification, especially for
+ anonymous payment (``Digital Cash''). This
+ helps providers to obtain their payment in a secure way
+ while maintaining customer anonymity.
+
+
+
+
+
+ This component provides the user protection against
+ disclosure of identity to other users. The user will
+ remain accountable for its actions.
+
+
+
+ requires that a set of users and/or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation, but that this user is
+ still accountable for its actions.
+
+
+ The subject/user that requested resolution of the user
+ identity should be audited.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that under
+ specified conditions the user identity related to a
+ provided reference can be determined.
+
+ In the TSF shall provide an alias
+ instead of the user identity. When the specified
+ conditions are satisfied, the user identity to which the
+ alias belong can be determined. An example of such a
+ condition in an electronic cash environment is: ``
+ The TSF shall provide the notary a capability to determine
+ the user identity based on the provided alias only under
+ the conditions that a check has been issued
+ twice.''.
+
+
+
+ , requires the TSF to provide a
+ capability to determine the original user identity based
+ on a provided alias.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF, is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide
+
+
+ an authorised user
+
+
+
+
+ list of trusted subjects
+
+
+
+ the PP/ST author should identify the list of trusted
+ subjects that can obtain the real user name under a
+ specified condition, for example, a notary or
+ special authorised user.
+
+
+
+
+
+ the PP/ST author should select whether the authorised
+ user and/or trusted subjects can determine the real
+ user name.
+
+
+ a capability to determine the user identity based on the
+ provided alias only under the following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions under which the trusted subjects and
+ authorised user can determine the real user name based
+ on the provided reference. These conditions can be
+ conditions such as time of day, or they can be
+ administrative such as on a court order.
+
+ .
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that the provided
+ reference meets certain construction rules, and thereby
+ can be used in a secure way by potentially insecure
+ subjects.
+
+ If a user wants to use disk resources without disclosing
+ its identity, pseudonymity can be used. However, every
+ time the user accesses the system, the same alias must be
+ used. Such conditions can be specified in this component.
+
+
+
+ , requires the TSF to
+ follow certain construction rules for the alias to the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes which might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide an alias to the real user name which
+ shall be identical to an alias provided previously under the
+ following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions that indicate when the used reference for
+ the real user name shall be identical and when it
+ shall be different, for example, ``when the
+ user logs on to the same host'' it will use a
+ unique alias.
+
+
+ otherwise the alias provided shall be unrelated to
+ previously provided aliases.
+
+
+
+
+
+
+ This family ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together.
+
+
+
+ Unlinkability ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together. Unlinkability differs from pseudonymity
+ that, although in pseudonymity the user is also not known,
+ relations between different actions can be provided.
+
+ The requirements for unlinkability are intended to protect
+ the user identity against the use of profiling of the
+ operations. For example, when a telephone smart card is
+ employed with a unique number, the telephone company can
+ determine the behaviour of the user of this telephone
+ card. When a telephone profile of the users is known, the
+ card can be linked to a specific user. Hiding the
+ relationship between different invocations of a service or
+ access of a resource will prevent this kind of information
+ gathering.
+
+ As a result, a requirement for unlinkability could imply
+ that the subject and user identity of an operation must be
+ protected. Otherwise this information might be used to link
+ operations together.
+
+ Unlinkability requires that different operations cannot be
+ related. This relationship can take several forms. For
+ example, the user associated with the operation, or the
+ terminal which initiated the action, or the time the action
+ was executed. The PP/ST author can specify what kind of
+ relationships are present that must be countered.
+
+ Possible applications include the ability to make multiple
+ use of a pseudonym without creating a usage pattern that
+ might disclose the user's identity.
+
+ Examples for potential hostile subjects and users are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts, (e.g. Trojan Horses)
+ into systems, they do not operate but want to get
+ information about. All of these attackers can investigate
+ (e.g. which users used which services) and misuse this
+ information. Unlinkability protects users from linkages,
+ which could be drawn between several actions of a
+ customer. An example is a series of phone calls made by an
+ anonymous customer to different partners, where the
+ combination of the partner's identities might disclose the
+ identity of the customer.
+
+
+
+
+
+ This component ensures that users cannot link different
+ operations in the system and thereby obtain information.
+
+
+
+ , requires that users and/or subjects
+ are unable to determine whether the same user caused
+ certain specific operations.
+
+
+ the management of the unlinkability function.
+
+
+ The invocation of the unlinkability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine whether
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations which should be subjected to the
+ unlinkability requirement, for example,
+ ``sending email''.
+
+
+
+
+ were caused by the same user
+
+
+ are related as follows
+
+
+ list of relations
+
+
+
+ the PP/ST author should identify the list of
+ relations which should be protected against, for
+ example, ``originate from the same
+ terminal''.
+
+
+
+
+
+ the PP/ST author should select the relationships that
+ should be obscured. The selection allows either the
+ user identity or an assignment of relations to be
+ specified.
+
+ .
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+
+
+ Unobservability ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+ Unobservability approaches the user identity from a
+ different direction than the previous families Anonymity,
+ Pseudonymity and Unlinkability. In this case, the intent is
+ to hide the use of a resource or service, rather than to
+ hide the user's identity.
+
+ A number of techniques can be applied to implement
+ unobservability. Examples of techniques to provide
+ unobservability are:
+
+
+ Allocation of information impacting unobservability:
+ Unobservability relevant information (e.g. information
+ that describes that an operation occurred) can be
+ allocated in several locations within the TOE. The
+ information might be allocated to a single randomly
+ chosen part of the TOE such that an attacker does not
+ know which part of the TOE should be attacked. An
+ alternative system might distribute the information such
+ that no single part of the TOE has sufficient
+ information that, if circumvented, the privacy of the
+ user would be compromised. This technique is explicitly
+ addressed in .
+
+
+ Broadcast: When information is broadcast (e.g. ethernet,
+ radio), users cannot determine who actually received and
+ used that information. This technique is especially
+ useful when information should reach receivers which
+ have to fear a stigma for being interested in that
+ information (e.g. sensitive medical information).
+
+
+ Cryptographic protection and message padding: People
+ observing a message stream might obtain information from
+ the fact that a message is transferred and from
+ attributes on that message. By traffic padding, message
+ padding and encrypting the message stream, the
+ transmission of a message and its attributes can be
+ protected.
+
+
+
+ Sometimes, users should not see the use of a resource, but an
+ authorised user must be allowed to see the use of the resource
+ in order to perform his duties. In such cases, the could be used, which provides the
+ capability for one or more authorised users to see the
+ usage.
+
+ This family makes use of the concept ``parts of the
+ TOE''. This is considered any part of the TOE that is either
+ physically or logically separated from other parts of the
+ TOE.
+
+ Unobservability of communications may be an important factor
+ in many areas, such as the enforcement of constitutional
+ rights, organisational policies, or in defence related
+ applications.
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by unauthorised users.
+
+
+
+ , requires that users and/or
+ subjects cannot determine whether an operation is being
+ performed.
+
+
+ the management of the behaviour of the unobservability
+ function.
+
+
+ The invocation of the unobservability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users and/or
+ subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual user
+ or subject, but must protect with respect to cooperating
+ users and/or subjects. A set of users, for example,
+ could be a group of users which can operate under the
+ same role or can all use the same process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by specified users or
+ subjects. Furthermore this component specifies that
+ information related to the privacy of the user is
+ distributed within the TOE such that attackers might not
+ know which part of the TOE to target, or they need to
+ attack multiple parts of the TOE.
+
+ An example of the use of this component is the use of a
+ randomly allocated node to provide a function. In such a
+ case the component might require that the privacy related
+ information shall only be available to one identified part
+ of the TOE, and will not be communicated outside this part
+ of the TOE.
+
+ A more complex example can be found in some
+ ``voting algorithms''. Several parts of the
+ TOE will be involved in the service, but no individual
+ part of the TOE will be able to violate the policy. So a
+ person may cast a vote (or not) without the TOE being able
+ to determine whether a vote has been cast and what the
+ vote happened to be (unless the vote was unanimous).
+
+
+
+
+ , requires that the TSF
+ provide specific mechanisms to avoid the concentration of
+ privacy related information within the TOE. Such
+ concentrations might impact unobservability if a security
+ compromise occurs.
+
+
+
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+ The TSF shall allocate the
+
+
+ unobservability related information
+
+
+
+ the PP/ST author should identify which privacy related
+ information should be distributed in a controlled
+ manner. Examples of this information could be: IP
+ address of subject, IP address of object, time, used
+ encryption keys.
+
+
+ among different parts of the TOE such that the following
+ conditions hold during the lifetime of the information:
+
+
+ list of conditions
+
+
+
+ the PP/ST author should specify the conditions to
+ which the dissemination of the information should
+ adhere. These conditions should be maintained
+ throughout the lifetime of the privacy related
+ information of each instance. Examples of these
+ conditions could be: ``the information shall
+ only be present at a single separated part of the TOE
+ and shall not be communicated outside this part of the
+ TOE.'', ``the information shall only
+ reside in a single separated part of the TOE, but
+ shall be moved to another part of the TOE
+ periodically'', ``the information shall
+ be distributed between the different parts of the TOE
+ such that compromise of any 5 separated parts of the
+ TOE will not compromise the security policy''.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component is used to require that the TSF does not
+ try to obtain information that might compromise
+ unobservability when provided specific services. Therefore
+ the TSF will not solicit (i.e. try to obtain from other
+ entities) any information that might be used to compromise
+ unobservability.
+
+
+
+ , requires that the TSF
+ does not try to obtain privacy related information that
+ might be used to compromise unobservability.
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the unobservability requirement,
+ for example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which privacy related information should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to
+
+
+ privacy related information
+
+
+
+ the PP/ST author should specify the privacy related
+ information that will be protected from the specified
+ subjects. Examples include the identity of the subject
+ that used a service and the quantity of a service that
+ has been used such as memory resource
+ utilisation.
+
+ .
+
+
+
+
+
+
+ This component is used to require that there will be one
+ or more authorised users with the rights to view the
+ resource utilisation. Without this component, this review
+ is allowed, but not mandated.
+
+
+
+ , requires the TSF to
+ provide one or more authorised users with a capability to
+ observe the usage of resources and/or services.
+
+
+ the list of authorised users that are capable of determining
+ the occurrence of operations.
+
+
+ The observation of the use of a resource or service by a
+ user or subject.
+
+
+ The TSF shall provide
+
+
+ set of authorised users
+
+
+
+ the PP/ST author should specify the set of authorised
+ users for which the TSF must provide the capability to
+ observe the resource utilisation. A set of authorised
+ users, for example, could be a group of authorised users
+ which can operate under the same role or can all use the
+ same process(es).
+
+
+ with the capability to observe the usage of
+
+
+ list of resources and/or services
+
+
+
+ the PP/ST author should specify the set of resources
+ and/or services that the authorised user must be able
+ to observe.
+
+ .
+
+
+
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the integrity of TSF data. In some
+ sense, families in this class may appear to duplicate
+ components in the class; they may
+ even be implemented using the same mechanisms. However, focuses on user data protection, while
+ focuses on TSF data
+ protection. In fact, components from the class are necessary to provide requirements that
+ the SFPs in the TOE cannot be tampered with or
+ bypassed.
+
+ From the point of view of this class, regarding to the
+ TSF there are three significant elements:
+
+ The TSF's implementation, which executes and implements the
+ mechanisms that enforce the SFRs.
+
+ The TSF's data, which are the administrative databases that guide the
+ enforcement of the SFRs.
+
+ The external entities that the TSF may interact with in order to
+ enforce the SFRs.
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the
+ integrity of TSF data. In some sense, families in this class may
+ appear to duplicate components in the
+ class; they may even be implemented using the
+ same mechanisms. However, focuses on user
+ data protection, while focuses on TSF data
+ protection. In fact, components from the
+ class are necessary to provide requirements that the SFPs in
+ the TOE cannot be tampered with or bypassed.
+
+ From the point of view of this class, regarding to the
+ TSF there are three significant elements:
+
+ The TSF's implementation, which executes and implements the
+ mechanisms that enforce the SFRs.
+
+ The TSF's data, which are the administrative databases that guide the
+ enforcement of the SFRs.
+
+ The external entities that the TSF may interact with in order to
+ enforce the SFRs.
+
+
+ All of the families in the class can be
+ related to these areas, and fall into the following groupings:
+ , which provides an authorised user
+ with the ability to detect external attacks on the parts
+ of the TOE that comprise the TSF.
+ and ,
+ which provide an authorised user with the ability to verify the correct
+ operation of the external entities interacting with the TSF to enforce
+ the SFRs, and the integrity of the TSF data and executable code.
+ , , and , which address the behaviour of the TSF
+ when failure occurs and immediately after.
+ , , ,
+ which address the protection and availability of TSF data between the TSF and another trusted IT product.
+ , which addresses protection of TSF
+ data when it is transmitted between physically-separated
+ parts of the TOE.
+ , which addresses the replay of
+ various types of information and/or operations.
+ , which addresses the synchronisation
+ of states, based upon TSF data, between different parts of
+ a distributed TSF.
+ , which addresses reliable timing.
+ , which addresses the consistency of
+ TSF data shared between the TSF and another trusted IT product.
+
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TOE will always enforce
+ its SFRs in the event of identified categories of
+ failures in the TSF.
+
+
+
+ The requirements of this family ensure that the TOE will
+ always enforce its SFRs in the event of certain
+ types of failures in the TSF.
+
+
+
+
+
+ The term ``secure state'' refers to a state in which the
+ TSF data are consistent and the TSF continues correct
+ enforcement of the SFRs.
+
+ Although it is desirable to audit situations in which
+ failure with preservation of secure state occurs, it is
+ not possible in all situations. The PP/ST author should
+ specify those situations in which audit is desired and
+ feasible.
+
+ Failures in the TSF may include
+ ``hard'' failures, which indicate an
+ equipment malfunction and which may require maintenance,
+ service or repair of the TSF. Failures in the TSF may also
+ include recoverable ``soft'' failures,
+ which may only require initialisation or resetting of the
+ TSF.
+
+
+
+ This family consists of only one component, , which requires that the TSF preserve a
+ secure state in the face of the identified failures.
+
+
+ Failure of the TSF.
+
+
+ The TSF shall preserve a secure state when the following
+ types of failures occur:
+
+
+ list of types of failures in the TSF
+
+
+
+ the PP/ST author should list the types of failures in
+ the TSF for which the TSF should ``fail
+ secure,'' that is, should preserve a secure
+ state and continue to correctly enforce the SFRs.
+
+ .
+
+
+
+
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and another
+ trusted IT product. This data could, for example, be TSF
+ critical data such as passwords, keys, audit data, or TSF
+ executable code.
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and another
+ trusted IT product. This data could be TSF critical data
+ such as passwords, keys, audit data, or TSF executable code.
+
+ This family is used in a distributed context where the TSF
+ is providing TSF data to another trusted IT product. The
+ TSF can only take the measures at its site and cannot be
+ held responsible for the TSF at the other trusted IT
+ product.
+
+ If there are different availability metrics for different
+ types of TSF data, then this component should be iterated
+ for each unique pairing of metrics and types of TSF data.
+
+
+
+
+
+ This family consists of only one component, .
+ This component requires that the TSF ensure, to an identified degree of probability, the
+ availability of TSF data provided to another trusted IT product.
+
+
+ management of the list of types of TSF data that must be
+ available to another trusted IT product.
+
+
+ the absence of TSF data when required by a TOE.
+
+
+ The TSF shall ensure the availability of
+
+ list of types of TSF data
+
+ the PP/ST author should specify the types of TSF data
+ that are subject to the availability metric.
+ provided to another trusted IT product within
+
+ a defined availability metric
+
+ the PP/ST should specify the availability metric for
+ the applicable TSF data.
+ given the following conditions
+
+ conditions to ensure availability
+
+ the PP/ST author should specify the conditions under
+ which availability must be ensured. For example:
+ there must be a connection between the TOE and
+ another trusted IT product..
+
+
+
+
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data during transmission
+ between the TSF and another trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data moving between the TSF
+ and another trusted IT product. Examples of this data are
+ TSF critical data such as passwords, keys, audit data, or
+ TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is providing TSF data to another trusted IT
+ product. The TSF can only take the measures at its site and
+ cannot be held responsible for the behaviour of the other
+ trusted IT product.
+
+
+
+
+
+ Confidentiality of TSF Data during transmission is
+ necessary to protect such information from
+ disclosure. Some possible implementations that could
+ provide confidentiality include the use of cryptographic
+ algorithms as well as spread spectrum techniques.
+
+
+
+ This family consists of only one component, ,
+ which requires that the TSF ensure that data transmitted between the TSF and another trusted IT
+ product is protected from disclosure while in transit.
+
+
+ The TSF shall protect all TSF data transmitted from the TSF
+ to another trusted IT product from unauthorised disclosure
+ during transmission.
+
+
+
+
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and another trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and another trusted IT product. Examples of
+ this data are TSF critical data such as passwords, keys,
+ audit data, or TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is exchanging TSF data with another trusted IT
+ product. Note that a requirement that addresses
+ modification, detection, or recovery at another trusted
+ IT product cannot be specified, as the mechanisms that
+ another trusted IT product will use to protect its data
+ cannot be determined in advance. For this reason, these
+ requirements are expressed in terms of the ``TSF
+ providing a capability'' which another trusted
+ IT product can use.
+
+
+
+
+
+ This component should be used in situations where it is
+ sufficient to detect when data have been modified. An
+ example of such a situation is one in which another
+ trusted IT product can request the TOE's TSF to
+ retransmit data when modification has been detected, or
+ respond to such types of request.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a weak checksum
+ and parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches.
+
+
+ , provides the ability to detect
+ modification of TSF data during transmission between the
+ TSF and another trusted IT product, under the assumption
+ that another trusted IT product is cognisant of the mechanism used.
+
+
+ the detection of modification of transmitted TSF data.
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and
+ another trusted IT product within the following metric:
+
+ a defined modification metric
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection..
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and another
+ trusted IT product and perform
+
+ action to be taken
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+ if modifications are detected.
+
+
+
+
+
+
+
+ This component should be used in situations where it is
+ necessary to detect or correct modifications of TSF
+ critical data.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a checksum and
+ parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches. The metric that needs to be defined can either
+ refer to the attacks it will resist (e.g. only 1 in a 1000
+ random messages will be accepted), or to mechanisms that
+ are well known in the public literature (e.g. the strength
+ must be conformant to the strength offered by Secure Hash
+ Algorithm).
+
+ The approach taken to correct modification might be done
+ through some form of error correcting checksum.
+
+
+
+ Some possible means of satisfying this requirement
+ involves the use of cryptographic functions or some form
+ of checksum.
+
+
+ , provides the ability for
+ another trusted IT product not only to detect modification,
+ but to correct modified TSF data under the assumption that
+ another trusted IT product is cognisant of the mechanism used.
+
+
+ management of the types of TSF data that the TSF should try
+ to correct if modified in transit;
+
+
+ management of the types of action that the TSF could take if
+ TSF data is modified in transit.
+
+
+ the detection of modification of transmitted TSF data;
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ the use of the correction mechanism.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and
+ another trusted IT product within the following metric:
+
+ a defined modification metric
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection..
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and another
+ trusted IT product and perform
+
+ action to be taken
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+ if modifications are detected.
+
+
+ The TSF shall provide the capability to correct
+
+ type of modification
+
+ the PP/ST author should define the types of
+ modification from which the TSF should be capable of
+ recovering.
+ of all TSF data transmitted between the TSF and another
+ trusted IT product.
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+ The determination of the degree of separation (i.e.,
+ physical or logical) that would make application of this
+ family useful depends on the intended environment of use. In
+ a hostile environment, there may be risks arising from
+ transfers between parts of the TOE separated by only a
+ system bus or an inter-process communications channel. In
+ more benign environments, the transfers may be across more
+ traditional network media.
+
+
+
+ One practical mechanism available to a TSF to provide this
+ protection is cryptographically-based.
+
+
+
+
+
+ , requires that TSF data be
+ protected when transmitted between separate parts of the
+ TOE.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+ One of the ways to achieve separation of TSF data based on
+ SFP-relevant attributes is through the use of separate
+ logical or physical channels.
+
+
+
+ , requires that the TSF separate
+ user data from TSF data during transmission.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the separation mechanism.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+ The TSF shall separate user data from TSF data when such
+ data is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+
+
+ , requires that the TSF data
+ transmitted between separate parts of the TOE is monitored
+ for identified integrity errors.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the types of modification of TSF data the TSF
+ should try to detect;
+
+
+ management of the action>s that will be taken.
+
+
+ the detection of modification of TSF data;
+
+
+ the action taken following detection of an integrity error.
+
+
+ The TSF shall be able to detect
+
+
+ modification of data
+
+
+ substitution of data
+
+
+ re-ordering of data
+
+
+ deletion of data
+
+
+
+
+ other integrity errors
+
+
+
+ if the PP/ST author chooses the latter selection
+ noted in the preceding paragraph, then the author
+ should also specify what those other integrity
+ errors are that the TSF should be capable of
+ detecting.
+
+
+
+
+
+ the PP/ST author should specify the desired type of
+ modification that the TSF shall be able to detect. The
+ PP/ST author should select from: modification of data,
+ substitution of data, re-ordering of data, deletion of
+ data, or any other integrity errors.
+
+
+ for TSF data transmitted between separate parts of the TOE.
+
+
+ Upon detection of a data integrity error, the TSF shall take
+ the following actions:
+
+
+ specify the action to be taken
+
+
+
+ the PP/ST author should specify the action to be taken
+ when an integrity error is identified.
+
+ .
+
+
+
+
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements of components in this family ensure that
+ the TSF is protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is enforced. Without these
+ components, the protection functions of a TSF lose their
+ effectiveness in environments where physical damage cannot
+ be prevented. This family also provides requirements
+ regarding how the TSF shall respond to physical tampering
+ attempts.
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements in this family ensure that the TSF is
+ protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is measurable based on
+ defined work factors. Without these components, the
+ protection functions of a TSF lose their effectiveness in
+ environments where physical damage cannot be prevented. This
+ component also provides requirements regarding how the TSF
+ must respond to physical tampering attempts.
+
+ Examples of physical tampering scenarios include mechanical
+ attack, radiation, changing the temperature.
+
+ It is acceptable for the functions that are available to an
+ authorised user for detecting physical tampering to be
+ available only in an off-line or maintenance mode. Controls
+ should be in place to limit access during such modes to
+ authorised users. As the TSF may not be
+ ``operational'' during those modes, it
+ may not be able to provide normal enforcement for authorised
+ user access. The physical implementation of a TOE might
+ consist of several structures: for example an outer
+ shielding, cards, and chips. This set of
+ ``elements'' as a whole must protect
+ (protect, notify and resist) the TSF from physical
+ tampering. This does not mean that all devices must provide
+ these features, but the complete physical construct as a
+ whole should.
+
+ Although there is only minimal auditing associating with
+ these components, this is solely because there is the
+ potential that the detection and alarm mechanisms may be
+ implemented completely in hardware, below the level of
+ interaction with an audit subsystem (for example, a
+ hardware-based detection system based on breaking a circuit
+ and lighting a light emitting diode (LED) if the circuit is
+ broken when a button is pressed by the authorised
+ user). Nevertheless, a PP/ST author may determine that for a
+ particular anticipated threat environment, there is a need
+ to audit physical tampering. If this is the case, the PP/ST
+ author should include appropriate requirements in the list
+ of audit events. Note that inclusion of these requirements
+ may have implications on the hardware design and its
+ interface to the software.
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are not
+ countered by procedural methods. It addresses the threat of
+ undetected physical tampering with the TSF. Typically, an
+ authorised user would be given the function to verify whether
+ tampering took place. As written, this component simply provides
+ a TSF capability to detect tampering. Specification of
+ management functions in should be
+ considered to specify who can make use of that capability, and
+ how they can make use of that capability. If this is done by non-IT mechanisms
+ (e.g. physical inspection) management functions are not required.
+
+
+
+ , provides for features that
+ indicate when a TSF device or TSF element is subject to
+ tampering. However, notification of tampering is not
+ automatic; an authorised user must invoke a security
+ administrative function or perform manual inspection to
+ determining if tampering has occurred.
+
+ management of the user or role that determines whether physical
+ tampering has occurred.
+
+
+ if detection by IT means, detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether
+ physical tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+
+
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are
+ not countered by procedural methods, and it is required
+ that designated individuals be notified of physical
+ tampering. It addresses the threat that physical tampering
+ with TSF elements, although detected, may not be noticed.
+ Specification of management functions in FMT_MOF.1 Management of
+ security functions behaviour should be considered to specify who
+ can make use of that capability, and how they can make use of that capability.
+
+
+
+ , provides for automatic
+ notification of tampering for an identified subset of
+ physical penetrations.
+
+
+ management of the user or role that gets informed about
+ intrusions;
+
+
+ management of the list of devices that should inform the
+ indicated user or role about the intrusion.
+
+
+ detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether physical
+ tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+ For
+
+
+ list of TSF devices/elements for which active detection
+ is required
+
+
+
+ the PP/ST author should provide a list of TSF
+ devices/elements for which active detection of
+ physical tampering is required.
+
+ , the TSF shall monitor the devices and
+ elements and notify
+
+
+ a designated user or role
+
+
+
+ the PP/ST author should designate a user or role that
+ is to be notified when tampering is detected. The type
+ of user or role may vary depending on the particular
+ security administration component (from the family) included in the PP/ST.
+
+
+ when physical tampering with the
+ TSF's devices or TSF's elements has
+ occurred.
+
+
+
+
+
+
+ For some forms of tampering, it is necessary that the TSF
+ not only detects the tampering, but actually resists it or
+ delays the attacker.
+
+ This component should be used when TSF devices and TSF
+ elements are expected to operate in an environment where a
+ physical tampering (e.g. observation, analysis, or
+ modification) of the internals of a TSF device or TSF
+ element itself is a threat.
+
+
+
+ , provides for features that prevent
+ or resist physical tampering with TSF devices and TSF
+ elements.
+
+
+ management of the automatic responses to physical tampering.
+
+
+ The TSF shall resist
+
+
+ physical tampering scenarios
+
+
+
+ the PP/ST author should specify tampering scenarios to
+ a list of TSF devices/elements for which the TSF
+ should resist physical tampering. This list may be
+ applied to a defined subset of the TSF physical
+ devices and elements based on considerations such as
+ technology limitations and relative physical exposure
+ of the device. Such subsetting should be clearly
+ defined and justified. Furthermore, the TSF should
+ automatically respond to physical tampering. The
+ automatic response should be such that the policy of
+ the device is preserved; for example, with a
+ confidentiality policy, it would be acceptable to
+ physically disable the device so that the protected
+ information may not be retrieved.
+
+
+ to the
+
+
+ list of TSF devices/elements
+
+
+
+ the PP/ST author should specify the list of TSF
+ devices/elements for which the TSF should resist
+ physical tampering in the scenarios that have been
+ identified.
+
+
+ by responding automatically such that the SFRs are always enforced.
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started-up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+ Recovery components reconstruct the TSF secure states, or
+ prevent transitions to insecure states, as a direct response
+ to occurrences of expected failures, discontinuity of
+ operation or start-up. Failures that must be generally
+ anticipated include the following:
+
+
+ Unmaskable action failures that always result in a
+ system crash (e.g. persistent inconsistency of critical
+ system tables, uncontrolled transfers within the TSF
+ code caused by transient failures of hardware or
+ firmware, power failures, processor failures,
+ communication failures).
+
+
+ Media failures causing part or all of the media
+ representing the TSF objects to become inaccessible or
+ corrupt (e.g. parity errors, disk head crash, persistent
+ read/write failure caused by misaligned disk heads,
+ worn-out magnetic coating, dust on the disk surface).
+
+
+ Discontinuity of operation caused by erroneous
+ administrative action or lack of timely administrative
+ action (e.g. unexpected shutdowns by turning off power,
+ ignoring the exhaustion of critical resources,
+ inadequate installed configuration).
+
+
+
+ Note that recovery may be from either a complete or partial
+ failure scenario. Although a complete failure might occur in
+ a monolithic operating system, it is less likely to occur in
+ a distributed environment. In such environments, subsystems
+ may fail, but other portions remain operational. Further,
+ critical components may be redundant (disk mirroring,
+ alternative routes), and checkpoints may be available. Thus,
+ recovery is expressed in terms of recovery to a secure
+ state.
+ There are different interactions between
+ and components to be considered when
+ selecting :
+
+ The need for trusted recovery may be indicated through
+ the results of TSF self-testing, where the results of
+ the self-tests indicate that the TSF is in an insecure
+ state and return to a secure state or entrance in
+ maintenance mode is required.
+
+ A failure, as discussed above, may be identified by an
+ administrator. Either the administrator may perform
+ the actions to return the TOE to a secure state and
+ then invoke TSF self-tests to confirm that the secure
+ state has been achieved. Or, the TSF self-tests may be
+ invoked to complete the recovery process.
+
+ A combination of a. and b. above, where the need for
+ trusted recovery is indicated through the results of
+ TSF self-testing, the administrator performs the
+ actions to return the TOE to a secure state and then
+ invokes TSF self-tests to confirm that the secure
+ state has been achieved.
+
+ Self tests detect a failure/service discontinuity,
+ then either automated recovery or entrance to a
+ maintenance mode.
+
+
+ This family identifies a maintenance mode. In this
+ maintenance mode normal operation might be impossible or
+ severely restricted, as otherwise insecure situations might
+ occur. Typically, only authorised users should be allowed
+ access to this mode but the real details of who can access
+ this mode is a function of . If does not put any controls on who can access this
+ mode, then it may be acceptable to allow any user to restore
+ the system if the TOE enters such a state. However, in
+ practice, this is probably not desirable as the user
+ restoring the system has an opportunity to configure the TOE
+ in such a way as to violate the SFRs.
+
+ Mechanisms designed to detect exceptional conditions during
+ operation fall under , , and other areas that address the
+ concept of ``Software Safety.'' It is likely that the use of
+ one of these families will be required to support the adoption
+ of . This is to ensure that
+ the TOE will be able to detect when recovery is
+ required.
+
+ Throughout this family, the phrase ``secure state'' is
+ used. This refers to some state in which the TOE has
+ consistent TSF data and a TSF that can correctly enforce the
+ policy. This state may be the initial ``boot'' of a clean
+ system, or it might be some checkpointed state.
+
+ Following recovery, it may be necessary to confirm that the
+ secure state has been achieved through self-testing of the
+ TSF. However, if the recovery is performed in a manner such
+ that only a secure state can be achieved, else recovery
+ fails, then the dependency to the TSF
+ self-test component may be argued away.
+
+
+
+
+
+
+
+
+ In the hierarchy of the trusted recovery family, recovery
+ that requires only manual intervention is the least
+ desirable, for it precludes the use of the system in an
+ unattended fashion.
+
+ This component is intended for use in TOEs that do not
+ require unattended recovery to a secure state. The
+ requirements of this component reduce the threat of
+ protection compromise resulting from an attended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+
+
+ , allows a TOE to only provide
+ mechanisms that involve human intervention to return to a
+ secure state.
+
+
+ management of who can access the restore capability within
+ the maintenance mode.
+
+
+ the fact that a failure or service discontinuity occurred;
+
+
+ resumption of the regular operation;
+
+
+ type of failure or service discontinuity.
+
+
+ After
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion, any failure or discontinuity)
+ following which the TOE will enter a maintenance mode. the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, as it allows the machine to operate in an
+ unattended fashion.
+
+ The component extends the feature
+ coverage of by requiring that there
+ be at least one automated method of recovery from failure
+ or service discontinuity. It addresses the threat of
+ protection compromise resulting from an unattended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ For , it is the responsibility of
+ the developer of the TSF to determine the set of
+ recoverable failures and service discontinuities.
+
+ It is assumed that the robustness of the automated
+ recovery mechanisms will be verified.
+
+
+
+ , provides, for at least one type of
+ service discontinuity, recovery to a secure state without
+ human intervention; recovery for other discontinuities may
+ require human intervention.
+
+
+ management of who can access the restore capability within
+ the maintenance mode;
+
+
+ management of the list of failures/service discontinuities
+ that will be handled through the automatic procedures.
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode. is not possible, the TSF shall enter a
+ maintenance mode where the ability to return to a secure state
+ is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, but it runs the risk of losing a
+ substantial number of objects. Preventing undue loss of
+ objects provides additional utility to the recovery
+ effort.
+
+ The component extends the feature
+ coverage of by requiring that there
+ not be undue loss of TSF data or objects under the control
+ of the TSF. At , the automated recovery
+ mechanisms could conceivably recover by deleting all
+ objects and returning the TSF to a known secure
+ state. This type of drastic automated recovery is
+ precluded in .
+
+ This component addresses the threat of protection
+ compromise resulting from an unattended TOE returning to
+ an insecure state after recovery from a failure or other
+ discontinuity with a large loss of TSF data or objects
+ under the control of the TSF.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ It is assumed that the evaluators will verify the
+ robustness of the automated recovery mechanisms.
+
+
+
+ , also provides for automated
+ recovery, but strengthens the requirements by disallowing
+ undue loss of protected objects.
+
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode.
+ is not possible, the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+ The functions provided by the TSF to recover from failure or
+ service discontinuity shall ensure that the secure initial
+ state is restored without exceeding
+
+
+ quantification
+
+
+
+ the PP/ST author should provide a quantification for
+ the amount of loss of TSF data or objects that is
+ acceptable.
+
+
+ for loss of TSF data or objects under the control of the TSF.
+
+
+ The TSF shall provide the capability to determine the
+ objects that were or were not capable of being recovered.
+
+
+
+
+
+
+ Function recovery requires that if there should be some
+ failure in the TSF, that certain functions in the TSF should
+ either complete successfully or recover to a secure state.
+
+
+
+ , provides for recovery at the level
+ of particular functions, ensuring either successful completion
+ or rollback of TSF data to a secure state.
+
+
+ if possible, the impossibility to return to a secure state
+ after a failure of the TSF;
+
+
+ if possible, the detection of a failure of a function.
+
+
+ The TSF shall ensure that
+
+
+ list of functions and failure scenarios
+
+
+
+ the PP/ST author should specify a list the functions and
+ failure scenarios. In the event that any of the
+ identified failure scenarios happen, the functions that have
+ been specified must either complete successfully or
+ recover to a consistent and secure state.
+
+
+ have the property that the function either completes successfully,
+ or for the indicated failure scenarios, recovers to a
+ consistent and secure state.
+
+
+
+
+
+
+
+ This family addresses detection of replay for various types
+ of entities (e.g. messages, service requests, service
+ responses) and subsequent actions to correct. In the case
+ where replay may be detected, this effectively prevents it.
+
+
+
+ This family addresses detection of replay for various types
+ of entities and subsequent actions to correct.
+
+
+
+
+
+ The entities included here are, for example, messages,
+ service requests, service responses, or sessions.
+
+
+
+ The family consists of only one component, , which requires that the TSF shall be
+ able to detect the replay of identified entities.
+
+
+ management of the list of identified entities for which
+ replay shall be detected;
+
+
+ management of the list of actions that need to be taken in
+ case of replay.
+
+
+ Detected replay attacks.
+
+
+ Action to be taken based on the specific actions.
+
+
+ The TSF shall detect replay for the following entities:
+
+
+ list of identified entities
+
+
+
+ the PP/ST author should provide a list of identified
+ entities for which detection of replay should be
+ possible. Examples of such entities might include:
+ messages, service requests, service responses, and
+ user sessions.
+
+ .
+
+
+ The TSF shall perform
+
+
+ list of specific actions
+
+
+
+ the PP/ST author should specify the list of actions to
+ be taken by the TSF when replay is detected. The
+ potential set of actions that can be taken includes:
+ ignoring the replayed entity, requesting confirmation
+ of the entity from the identified source, and
+ terminating the subject from which the re-played
+ entity originated.
+
+
+ when replay is detected.
+
+
+
+
+
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use this trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases, synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use a trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+ Some states may never be synchronised, or the transaction
+ cost may be too high for practical use; encryption key
+ revocation is an example, where knowing the state after the
+ revocation action is initiated can never be known. Either
+ the action was taken and acknowledgment cannot be sent, or
+ the message was ignored by hostile communication partners
+ and the revocation never occurred. Indeterminacy is unique
+ to distributed TOEs. Indeterminacy and state synchrony
+ are related, and the same solution may apply. It is futile
+ to design for indeterminate states; the PP/ST author should
+ express other requirements in such cases (e.g. raise an
+ alarm, audit the event).
+
+
+
+
+
+
+
+
+ In this component, the TSF must supply an acknowledgement
+ to another part of the TSF when requested. This
+ acknowledgement should indicate that one part of a
+ distributed TOE successfully received an unmodified
+ transmission from a different part of the distributed TOE.
+
+
+
+ , requires only a simple
+ acknowledgment by the data recipient.
+
+
+ failure to receive an acknowledgement when expected.
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data transmission.
+
+
+
+
+
+
+
+
+
+
+ In this component, in addition to the TSF being able to
+ provide an acknowledgement for the receipt of a data
+ transmission, the TSF must comply with a request from
+ another part of the TSF for an acknowledgement to the
+ acknowledgement.
+
+ For example, the local TSF transmits some data to a remote
+ part of the TSF. The remote part of the TSF acknowledges
+ the successful receipt of the data and requests that the
+ sending TSF confirm that it receives the
+ acknowledgement. This mechanism provides additional
+ confidence that both parts of the TSF involved in the data
+ transmission know that the transmission completed
+ successfully.
+
+
+
+ , requires mutual acknowledgment of
+ the data exchange.
+
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data
+ transmission.
+
+
+ The TSF shall ensure that the relevant parts of the TSF know
+ the correct status of transmitted data among its different
+ parts, using acknowledgements.
+
+
+
+
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+ It is the responsibility of the PP/ST author to clarify the
+ meaning of the phrase ``reliable time
+ stamp'', and to indicate where the responsibility
+ lies in determining the acceptance of trust.
+
+
+
+
+
+ Some possible uses of this component include providing
+ reliable time stamps for the purposes of audit as well as
+ for security attribute expiration.
+
+
+
+ This family consists of only one component, , which requires that the TSF provide
+ reliable time stamps for TSF functions.
+
+
+ management of the time.
+
+
+ changes to the time;
+
+
+ providing a timestamp.
+
+
+ The TSF shall be able to provide reliable time stamps.
+
+
+
+
+
+
+
+ In a distributed environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and a different trusted IT product.
+
+
+
+ In a distributed or composite environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT Product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and that of a different trusted IT Product.
+
+ The components in this family are intended to provide
+ requirements for automated support for TSF data consistency
+ when such data is transmitted between the TSF of the TOE and
+ another trusted IT Product. It is also possible that wholly
+ procedural means could be used to produce security attribute
+ consistency, but they are not provided for here.
+
+ This family is different from FDP_ETC and FDP_ITC, as those
+ two families are concerned only with resolving the security
+ attributes between the TSF and its import/export medium.
+
+ If the integrity of the TSF data is of concern, requirements
+ should be chosen from the family. These
+ components specify requirements for the TSF to be able to
+ detect or detect and correct modifications to TSF data in
+ transit.
+
+
+
+
+
+ The TSF is responsible for maintaining the consistency of
+ TSF data used by or associated with the specified function
+ and that are common between two or more trusted
+ systems. For example, the TSF data of two different
+ systems may have different conventions internally. For the
+ TSF data to be used properly (e.g. to afford the user data
+ the same protection as within the TOE) by the receiving
+ trusted IT product, the TOE and the other trusted IT
+ product must use a pre-established protocol to exchange
+ TSF data.
+
+
+
+ , requires that the TSF provide the
+ capability to ensure consistency of attributes between
+ TSFs.
+
+
+ Successful use of TSF data consistency mechanisms.
+
+
+ Use of the TSF data consistency mechanisms.
+
+
+ Identification of which TSF data have been interpreted.
+
+
+ Detection of modified TSF data.
+
+
+ The TSF shall provide the capability to consistently
+ interpret
+
+
+ list of TSF data types
+
+
+
+ the PP/ST author should define the list of TSF data
+ types, for which the TSF shall provide the capability
+ to consistently interpret, when shared between the TSF
+ and another trusted IT product.
+
+
+ when shared between the TSF and another trusted IT product.
+
+
+ The TSF shall use
+
+
+ list of interpretation rules to be applied by the TSF
+
+
+
+ the PP/ST should assign the list of interpretation
+ rules to be applied by the TSF,
+
+
+ when interpreting the TSF data from another trusted IT
+ product.
+
+
+
+ This family defines requirements for the TSF to perform tests
+ on one or more external entities.
+ This component is not intended to be applied to human users.
+ External entities may include applications running on the TOE, hardware or
+ software running ``underneath'' the TOE (platforms, operating systems etc.)
+ or applications/boxes connected to the TOE (intrusion detection systems,
+ firewalls, login servers, time servers etc.).
+ This family defines requirements for the testing of one or more external
+ entities by the TSF. These external entities are not human users, and they can
+ include combinations of software and/or hardware interacting with the TOE.
+ Examples of the types of tests that may be run are:
+
+ Tests for the presence of a firewall, and possibly whether it is
+ correctly configured;
+
+ Tests of some of the properties of the operating system that an
+ application TOE runs on;
+
+ Tests of some of the properties of the IC that a smart card OS TOE
+ runs on (e.g. the random number generator).
+
+ Note that the external entity may ``lie'' about the test results, either on
+ purpose or because it is not working correctly.
+ These tests can be carried out either in some maintenance state, at start-up,
+ on-line, or continuously. The actions to be taken by the TOE as the result of
+ testing are defined also in this family.
+ The tests of external entities should be sufficient to test all of the
+ characteristics of them upon which the TSF relies.
+ This component is not intended to be applied to human users.
+ This component provides support for the periodic testing of properties
+ related to external entities upon which the TSF's operation depends, by
+ requiring the ability to periodically invoke testing functions.
+ The PP/ST author may refine the requirement to state whether the function
+ should be available in off-line, on-line or maintenance mode.
+ It is acceptable for the functions for periodic testing to be available only in
+ an off-line or maintenance mode. Controls should be in place to limit access,
+ during maintenance, to authorised users., provides for testing of the
+ external entities by the TSF.
+ management of the conditions under which the testing of external
+ entities occurs, such as during initial start-up, regular interval, or
+ under specified conditions;
+
+ management of the time interval if appropriate.
+
+ Execution of the tests of the external entities and the results of
+ the tests.
+
+ The TSF shall run a suite of tests
+
+ during initial start-up
+
+ periodically during normal operation
+
+ at the request of an authorised user
+
+ other conditions
+
+ the PP/ST author should, if other conditions are
+ selected, specify the frequency with which the self tests will be run.
+ An example of this other frecuency or condition may be to run the
+ tests each time a user requests to initiate a session with the TOE. For
+ instance, this could be the case of testing a directory server before its
+ interaction with the TSF during the user authentication process.
+ the PP/ST author should specify when the TSF will
+ run the testing of external entities, during initial start-up, periodically
+ during normal operation, at the request of an authorised user, or under
+ other conditions. If the tests are run often, then the end users should
+ have more confidence that the TOE is operating correctly than if the
+ tests are run less frequently. However, this need for confidence that
+ the TOE is operating correctly must be balanced with the potential
+ impact on the availability of the TOE, as often times, self tests may
+ delay the normal operation of a TOE.
+ to check the fulfillment of
+
+ list of properties of the external entities
+
+ the PP/ST author should specify the properties of the
+ external entities to be checked by the tests. Examples of these
+ properties may include configuration or availability properties of
+ a directory server supporting some access control part of the TSF.
+ .
+
+ If the test fails, the TSF shall
+
+ action(s)
+
+ the PP/ST author should specify what are the action(s)
+ that the TSF shall perform when the testing fails. Examples of these
+ action(s), illustrated by a directory server instance, may include to
+ connect to an alternative available server or otherwise to look for a
+ backup server.
+ .
+
+
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if
+ the internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network and parts of the TOE network connections are broken,
+ this may occur when parts become disabled.
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if an
+ internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network of parts of the TOE, this can occur when parts
+ become disabled, network connections are broken, and so on.
+
+ The method of ensuring consistency is not specified in this
+ component. It could be attained through a form of
+ transaction logging (where appropriate transactions are
+ ``rolled back'' to a site upon
+ reconnection); it could be updating the replicated data
+ through a synchronisation protocol. If a particular protocol
+ is necessary for a PP/ST, it can be specified through
+ refinement.
+
+ It may be impossible to synchronise some states, or the cost
+ of such synchronisation may be too high. Examples of this
+ situation are communication channel and encryption key
+ revocations. Indeterminate states may also occur; if a
+ specific behaviour is desired, it should be specified via
+ refinement.
+
+
+
+
+
+
+
+
+ This family consists of only one component, , which requires that the TSF ensure the
+ consistency of TSF data that is replicated in multiple
+ locations.
+
+
+ restoring consistency upon reconnection.
+
+
+ Detected inconsistency between TSF data.
+
+
+ The TSF shall ensure that TSF data is consistent when
+ replicated between parts of the TOE.
+
+
+ When parts of the TOE containing replicated TSF data are
+ disconnected, the TSF shall ensure the consistency of the
+ replicated TSF data upon reconnection before processing any
+ requests for
+
+
+ list of functions dependent on TSF data replication
+ consistency
+
+
+
+ the PP/ST author should specify the list of functions
+ dependent on TSF data replication consistency.
+
+ .
+
+
+
+
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of the authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF executable code (i.e. TSF software)
+ and TSF data by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of an authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF executable code (i.e. TSF software)
+ and TSF data by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+ In addition, use of this component may, with appropriate
+ conditions, help to prevent inappropriate or damaging TSF
+ changes being applied to an operational TOE as the result of
+ maintenance activities.
+
+ The term ``correct operation of the TSF'' refers primarily to
+ the operation of the TSF software and the integrity of the TSF
+ data.
+
+
+
+
+
+
+ This component provides support for the testing of the
+ critical functions of the TSF's operation by
+ requiring the ability to invoke testing functions and
+ check the integrity of TSF data and executable code.
+
+
+
+ It is acceptable for the functions that are available to
+ the authorised user for periodic testing to be available
+ only in an off-line or maintenance mode. Controls should
+ be in place to limit access during these modes to
+ authorised users.
+
+
+
+ , provides the ability to test the
+ TSF's correct operation. These tests may be
+ performed at start-up, periodically, at the request of the
+ authorised user, or when other conditions are met. It also
+ provides the ability to verify the integrity of TSF data
+ and executable code.
+
+
+ management of the conditions under which TSF self testing
+ occurs, such as during initial start-up, regular interval,
+ or under specified conditions;
+
+
+ management of the time interval if appropriate.
+
+
+ Execution of the TSF self tests and the results of the
+ tests.
+
+
+ The TSF shall run a suite of self tests
+
+ during initial start-up
+
+ periodically during normal operation
+
+ at the request of the authorised user
+
+ at the conditions
+
+ conditions under which self test should occur
+
+ the PP/ST author should, if selected, specify the
+ conditions under which the self test should take
+ place.
+ the PP/ST author should specify when the TSF will execute
+ the TSF test; during initial start-up, periodically during
+ normal operation, at the request of an authorised user, at
+ other conditions. In the case of the latter option, the
+ PP/ST author should also assign what those conditions are
+ via the following assignment.
+ to demonstrate the correct operation of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of parts of the TSF that will be subject to TSF
+ self-testing.
+ the TSF
+
+ the PP/ST author should specify whether the self tests
+ are to be carried out to demonstrate the correct
+ operation of the entire TSF, or of only specified parts
+ of TSF..
+
+
+ The TSF shall provide authorised users with the capability to
+ verify the integrity of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of TSF data that will be verified for
+ integrity.
+ TSF data
+
+ the PP/ST author should specify whether data integrity
+ is to be verified for all TSF data, or only for selected
+ data..
+
+
+ The TSF shall provide authorised users with the capability
+ to verify the integrity of stored TSF executable code.
+
+
+
+
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks, and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+
+
+ The requirements of this family ensure that the TOE will
+ maintain correct operation even in the event of failures.
+
+
+
+ This family provides requirements for the availability of
+ capabilities even in the case of failures. Examples of such
+ failures are power failure, hardware failure, or software
+ error. In case of these errors, if so specified, the TOE
+ will maintain the specified capabilities. The PP/ST author
+ could specify, for example, that a TOE used in a nuclear
+ plant will continue the operation of the shut-down procedure
+ in the case of power-failure or communication-failure.
+
+ Because the TOE can only continue its correct operation if
+ the SFRs are enforced, there is a requirement that the system
+ must remain in a secure state after a failure. This
+ capability is provided by .
+
+ The mechanisms to provide fault tolerance could be active or
+ passive. In case of an active mechanism, specific functions
+ are in place that are activated in case the error
+ occurs. For example, a fire alarm is an active mechanism:
+ the TSF will detect the fire and can take action such as
+ switching operation to a backup. In a passive scheme, the
+ architecture of the TOE is capable of handling the
+ error. For example, the use of a majority voting scheme with
+ multiple processors is a passive solution; failure of one
+ processor will not disrupt the operation of the TOE
+ (although it needs to be detected to allow correction).
+
+ For this family, it does not matter whether the failure has
+ been initiated accidentally (such as flooding or unplugging
+ the wrong device) or intentionally (such as monopolising).
+
+
+
+
+
+
+
+
+ This component is intended to specify which capabilities
+ the TOE will still provide after a failure of the
+ system. Since it would be difficult to describe all
+ specific failures, categories of failures may be
+ specified. Examples of general failures are flooding of
+ the computer room, short term power interruption,
+ breakdown of a CPU or host, software failure, or buffer
+ overflow.
+
+
+
+ , requires the TOE to continue
+ correct operation of identified capabilities in the event
+ of identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ All TOE capabilities being discontinued due to a failure.
+
+
+ The TSF shall ensure the operation of
+
+
+ list of TOE capabilities
+
+
+
+ the PP/ST author should specify the list of TOE
+ capabilities the TOE will maintain during and after a
+ specified failure.
+
+
+ when the following failures occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component is intended to specify against what type of
+ failures the TOE must be resistant. Since it would be
+ difficult to describe all specific failures, categories of
+ failures may be specified. Examples of general failures
+ are flooding of the computer room, short term power
+ interruption, breakdown of a CPU or host, software
+ failure, or overflow of buffer.
+
+
+
+ , requires the TOE to continue
+ correct operation of all capabilities in the event of
+ identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ The TSF shall ensure the operation of all the
+ TOE's capabilities when the following failures
+ occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without undue interference or delay caused by
+ low priority activities.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without interference or delay due to low
+ priority activities. In other words, time critical tasks
+ will not be delayed by tasks that are less time critical.
+
+ This family could be applicable to several types of
+ resources, for example, processing capacity, and
+ communication channel capacity.
+
+ The Priority of Service mechanism might be passive or
+ active. In a passive Priority of Service system, the system
+ will select the task with the highest priority when given a
+ choice between two waiting applications. While using passive
+ Priority of Service mechanisms, when a low priority task is
+ running, it cannot be interrupted by a high priority
+ task. While using an active Priority of Service mechanisms,
+ lower priority tasks might be interrupted by new high
+ priority tasks.
+
+ The audit requirement states that all reasons for rejection
+ should be audited. It is left to the developer to argue that
+ an operation is not rejected but delayed.
+
+
+
+
+
+ This component defines priorities for a subject, and the
+ resources for which this priority will be used. If a
+ subject attempts to take action on a resource controlled
+ by the Priority of Service requirements, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of a subset of the resources
+ under the control of the TSF.
+
+
+ assignment of priorities to each subject in the TSF.
+
+
+ Rejection of operation based on the use of priority within
+ an allocation.
+
+
+ All attempted uses of the allocation function which involves
+ the priority of the service functions.
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which the TSF enforces priority of service
+ (e.g. resources such as processes, disk space, memory,
+ bandwidth).
+
+
+ shall be mediated on the basis of the subjects assigned
+ priority.
+
+
+
+
+
+
+
+ This component defines priorities for a subject. All
+ shareable resources under the control of the TSF will be subjected to the
+ Priority of Service mechanism. If a subject attempts to
+ take action on a shareable TSF resource, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of all of the resources under the control of the TSF.
+
+
+
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to all shareable
+ resources shall be mediated on the basis of the subjects
+ assigned priority.
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources by users and subjects such that denial of
+ service will not occur because of unauthorised
+ monopolisation of resources.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that unauthorised denial of service will not take place by
+ means of monopolisation of resources by other users or
+ subjects.
+
+ Resource allocation rules allow the creation of quotas or
+ other means of defining limits on the amount of resource
+ space or time that may be allocated on behalf of a specific
+ user or subjects. These rules may, for example:
+
+
+ Provide for object quotas that constrain the number
+ and/or size of objects a specific user may allocate.
+
+
+ Control the allocation/deallocation of preassigned
+ resource units where these units are under the control
+ of the TSF.
+
+
+
+ In general, these functions will be implemented through the
+ use of attributes assigned to users and resources.
+
+ The objective of these components is to ensure a certain
+ amount of fairness among the users (e.g. a single user
+ should not allocate all the available space) and
+ subjects. Since resource allocation often goes beyond the
+ lifespan of a subject (i.e. files often exist longer than
+ the applications that generated them), and multiple
+ instantiations of subjects by the same user should not
+ negatively affect other users too much, the components allow
+ that the allocation limits are related to the users. In some
+ situations the resources are allocated by a subject
+ (e.g. main memory or CPU cycles). In those instances the
+ components allow that the resource allocation be on the
+ level of subjects.
+
+ This family imposes requirements on resource allocation, not
+ on the use of the resource itself. The audit requirements
+ therefore, as stated, also apply to the allocation of the
+ resource, not to the use of the resource.
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to only a specified set of the shareable
+ resources in the TOE. The requirements allow the quotas to
+ be associated with a user, possibly assigned to groups of
+ users or subjects as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will not
+ monopolise a controlled resource.
+
+
+ specifying maximum limits for a resource for groups and/or
+ individual users and/or subjects by an administrator.
+
+
+ Rejection of allocation operation due to resource limits.
+
+
+ All attempted uses of the resource allocation functions for
+ resources that are under control of the TSF.
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources:
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which maximum resource allocation limits
+ are required (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to a specified set of the shareable resources
+ in the TOE. The requirements allow the quotas to be
+ associated with a user, or possibly assigned to groups of
+ users as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will always
+ have at least a minimum of a specified resource and that
+ they will not be able to monopolise a controlled resource.
+
+
+ specifying minimum and maximum limits for a resource for
+ groups and/or individual users and/or subjects by an
+ administrator.
+
+
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which maximum and minimum resource
+ allocation limits are required (e.g. processes, disk
+ space, memory, bandwidth). If all resources under the control of the TSF
+ need to be included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+ The TSF shall ensure the provision of minimum quantity of
+ each
+
+
+ controlled resource
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which a minimum allocation limit needs
+ to be set (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included the words ``all TSF resources''
+ can be specified.
+
+
+ that is available for
+
+
+ an individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ to use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This family specifies functional requirements for controlling
+ the establishment of a user's session.
+
+
+
+ The establishment of a user's session typically
+ consists of the creation of one or more subjects that perform
+ operations in the TOE on behalf of the user. At the end of the
+ session establishment procedure, provided the TOE access
+ requirements are satisfied, the created subjects bear the
+ attributes determined by the identification and authentication
+ functions. This family specifies functional requirements for
+ controlling the establishment of a user's session.
+
+ A user session is defined as the period starting at the time
+ of the identification/authentication, or if more appropriate,
+ the start of an interaction between the user and the system,
+ up to the moment that all subjects (resources and attributes)
+ related to that session have been deallocated.
+
+
+
+
+
+ This family defines requirements to limit the scope of
+ session security attributes that a user may select for a
+ session.
+
+
+
+ This family defines requirements that will limit the session
+ security attributes a user may select, and the subjects to
+ which a user may be bound, based on: the method of access;
+ the location or port of access; and/or the time
+ (e.g. time-of-day, day-of-week).
+
+ This family provides the capability for a PP/ST author to
+ specify requirements for the TSF to place limits on the
+ domain of an authorised user's security attributes
+ based on an environmental condition. For example, a user may
+ be allowed to establish a ``secret session''
+ during normal business hours but outside those hours the
+ same user may be constrained to only establishing
+ ``unclassified sessions''. The identification of
+ relevant constraints on the domain of selectable attributes
+ can be achieved through the use of the selection
+ operation. These constraints can be applied on an
+ attribute-by-attribute basis. When there exists a need to
+ specify constraints on multiple attributes this component
+ will have to be replicated for each attribute. Examples of
+ attributes that could be used to limit the session security
+ attributes are:
+
+
+ The method of access can be used to specify in which
+ type of environment the user will be operating
+ (e.g. file transfer protocol, terminal, vtam).
+
+
+ The location of access can be used to constrain the
+ domain of a user's selectable attributes based
+ on a user's location or port of access. This
+ capability is of particular use in environments where
+ dial-up facilities or network facilities are available.
+
+
+ The time of access can be used to constrain the domain
+ of a user's selectable attributes. For example,
+ ranges may be based upon time-of-day, day-of-week, or
+ calendar dates. This constraint provides some
+ operational protection against user actions that could
+ occur at a time where proper monitoring or where proper
+ procedural measures may not be in place.
+
+
+
+
+
+
+
+ , provides the requirement for a TOE
+ to limit the scope of the session security attributes
+ during session establishment.
+
+
+ management of the scope of the session security attributes
+ by an administrator.
+
+
+ All failed attempts at selecting a session security
+ attributes;
+
+
+ All attempts at selecting a session security attributes;
+
+
+ Capture of the values of each session security attributes.
+
+
+ The TSF shall restrict the scope of the session security
+ attributes
+
+
+ session security attributes
+
+
+
+ the PP/ST author should specify the set of session
+ security attributes that are to be
+ constrained. Examples of these session security
+ attributes are user clearance level, integrity level
+ and roles.
+
+ , based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the set of attributes
+ that can be use to determine the scope of the session
+ security attributes. Examples of such attributes are
+ user identity, originating location, time of access,
+ and method of access.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements to place limits on the
+ number of concurrent sessions that belong to the same user.
+
+
+
+ This family defines how many sessions a user may have at the
+ same time (concurrent sessions). This number of concurrent
+ sessions can either be set for a group of users or for each
+ individual user.
+
+
+
+
+
+
+
+
+ This component allows the system to limit the number of
+ sessions in order to effectively use the resources of the
+ TOE.
+
+
+
+ , provides limitations that apply to
+ all users of the TSF.
+
+
+ management of the maximum allowed number of concurrent user
+ sessions by an administrator.
+
+
+ Rejection of a new session based on the limitation of
+ multiple concurrent sessions.
+
+
+ Capture of the number of currently concurrent user sessions
+ and the user security attribute(s).
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user.
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+
+
+
+ This component provides additional capabilities over those
+ of , by allowing further constraints
+ to be placed on the number of concurrent sessions that
+ users are able to invoke. These constraints are in terms
+ of a user's security attributes, such as a
+ user's identity, or membership of a role.
+
+
+
+ extends by
+ requiring the ability to specify limitations on the number
+ of concurrent sessions based on the related security
+ attributes.
+
+
+ management of the rules that govern the maximum allowed
+ number of concurrent user sessions by an administrator.
+
+
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user according to the rules
+
+
+ rules for the number of maximum concurrent sessions
+
+
+
+ the PP/ST author should specify the rules that
+ determine the maximum number of concurrent
+ sessions. An example of a rule is ``maximum
+ number of concurrent sessions is one if the user has a
+ classification level of ``secret''
+ and five otherwise''.
+
+ .
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to provide the
+ capability for TSF-initiated and user-initiated locking,
+ unlocking, and termination of interactive sessions.
+
+
+ This family defines requirements for the TSF to provide the
+ capability for TSF-initiated and user-initiated locking,
+ unlocking, and termination of interactive sessions.
+ When a user is directly interacting with subjects in the TOE
+ (interactive session), the user's terminal is vulnerable if
+ left unattended. This family provides requirements for the TSF
+ to disable (lock) the terminal or terminate the session after
+ a specified period of inactivity, and for the user to initiate
+ the disabling (locking) of the terminal or terminate the
+ session. To reactivate the terminal, an event specified by the
+ PP/ST author, such as the user re-authentication must
+ occur.
+ A user is considered inactive, if he/she has not provided any
+ stimulus to the TOE for a specified period of time.
+ A PP/ST author should consider whether
+ should be included. In that case, the function ``session
+ locking'' should be included in the operation in .
+
+
+
+
+
+
+
+ , provides the capability for the
+ TSF to lock an active user session after a specified
+ period of time. Locking a terminal would prevent any
+ further interaction with an existing active session
+ through the use of the locked terminal.
+
+ If display devices are overwritten, the replacement
+ contents need not be static (i.e. ``screen
+ savers'' are permitted).
+
+ This component allows the PP/ST author to specify what
+ events will unlock the session. These events may be
+ related to the terminal (e.g. fixed set of keystrokes to
+ unlock the session), the user (e.g. reauthentication), or
+ time.
+
+
+
+ includes system initiated locking
+ of an interactive session after a specified period of user
+ inactivity.
+
+
+ specification of the time of user inactivity after which
+ lock-out occurs for an individual user;
+
+
+ specification of the default time of user inactivity after
+ which lock-out occurs;
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+ Locking of an interactive session by the session locking
+ mechanism.
+
+
+ Successful unlocking of an interactive session.
+
+
+ Any attempts at unlocking an interactive session.
+
+
+ The TSF shall lock an interactive session after
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the locking of an
+ interactive session. If so desired the PP/ST author
+ could, through the assignment, specify that the time
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+
+ by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'' or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+
+
+ , provides the capability for
+ an authorised user to lock and unlock his/her own interactive
+ session. This would provide authorised users with the ability to
+ effectively block further use of their active sessions without
+ having to terminate the active session.
+
+ If devices are overwritten, the replacement contents need
+ not be static (i.e. ``screen savers''
+ are permitted).
+
+
+
+ , provides capabilities for the user
+ to lock and unlock the user's own interactive
+ sessions.
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+
+
+ The TSF shall allow user-initiated locking of the
+ user's own interactive session, by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'', or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+ , requires that the TSF terminate an
+ interactive user session after a period of inactivity.
+
+ The PP/ST author should be aware that a session may
+ continue after the user terminated his/her activity, for
+ example, background processing. This requirement would
+ terminate this background subject after a period of
+ inactivity of the user without regard to the status of the
+ subject.
+
+
+ , provides requirements for
+ the TSF to terminate the session after a specified period of
+ user inactivity.
+
+
+ specification of the time of user inactivity after which
+ termination of the interactive session occurs for an
+ individual user;
+
+
+ specification of the default time of user inactivity after
+ which termination of the interactive session occurs.
+
+
+ Termination of an interactive session by the session locking
+ mechanism.
+
+
+ The TSF shall terminate an interactive session after a
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the termination of an
+ interactive session. If so desired, the PP/ST author
+ could, through the assignment, specify that the
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+ .
+
+ , provides the capability for an
+ authorised user to terminate his/her interactive
+ session..
+ The PP/ST author should be aware that a session may continue
+ after the user terminated his/her activity, for example,
+ background processing. This requirement would allow the user
+ to terminate this background subject without regard to the
+ status of the subject., provides capabilities for the user
+ to terminate the user's own interactive sessions.
+ Termination of an interactive session by the user.
+
+ The TSF shall allow user-initiated termination of the user's own
+ interactive session.
+
+
+
+
+
+
+ This family defines requirements to display a configurable
+ advisory warning message to users regarding the appropriate
+ use of the TOE.
+
+
+
+ Prior to identification and authentication, TOE access
+ requirements provide the ability for the TOE to display an
+ advisory warning message to potential users pertaining to
+ appropriate use of the TOE.
+
+
+
+
+
+ This component requires that there is an advisory warning
+ regarding the unauthorised use of the TOE. A PP/ST author
+ could refine the requirement to include a default banner.
+
+
+
+ , provides the requirement for a TOE
+ Access Banner. This banner is displayed prior to the
+ establishment dialogue for a session.
+
+
+ maintenance of the banner by the authorised administrator.
+
+
+ Before establishing a user session, the TSF shall display an
+ advisory warning message regarding unauthorised use of the
+ TOE.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to display to a
+ user, upon successful session establishment, a history of
+ successful and unsuccessful attempts to access the
+ user's account.
+
+
+
+ This family defines requirements for the TSF to display to
+ users, upon successful session establishment to the TOE, a
+ history of unsuccessful attempts to access the account. This
+ history may include the date, time, means of access, and
+ port of the last successful access to the TOE, as well as
+ the number of unsuccessful attempts to access the TOE since
+ the last successful access by the identified user.
+
+
+
+
+
+
+ This family can provide authorised users with information
+ that may indicate the possible misuse of their user
+ account.
+
+ This component request that the user is presented with the
+ information. The user should be able to review the
+ information, but is not forced to do so. If a user so
+ desires he might, for example, create scripts that ignore
+ this information and start other processes.
+
+
+
+ , provides the requirement for a TOE
+ to display information related to previous attempts to
+ establish a session.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last successful session establishment that will
+ be shown at the user interface. The items are: date,
+ time, method of access (such as ftp), and/or location
+ (e.g. terminal 50).
+
+
+ of the last successful session establishment to the user.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last unsuccessful session establishment that
+ will be shown at the user interface. The items are:
+ date, time, method of access (such as ftp), and/or
+ location (e.g. terminal 50).
+
+
+ of the last unsuccessful attempt to session establishment
+ and the number of unsuccessful attempts since the last
+ successful session establishment.
+
+
+ The TSF shall not erase the access history information from
+ the user interface without giving the user an opportunity to
+ review the information.
+
+
+
+
+
+
+ This family defines requirements to deny a user permission
+ to establish a session with the TOE.
+
+
+
+ This family defines requirements to deny an user permission
+ to establish a session with the TOE based on attributes such
+ as the location or port of access, the user's security
+ attribute (e.g. identity, clearance level, integrity level,
+ membership in a role), ranges of time (e.g. time-of-day,
+ day-of-week, calendar dates) or combinations of parameters.
+
+ This family provides the capability for the PP/ST author to
+ specify requirements for the TOE to place constraints on the
+ ability of an authorised user to establish a session with
+ the TOE. The identification of relevant constraints can be
+ achieved through the use of the selection
+ operation. Examples of attributes that could be used to
+ specify the session establishment constraints are:
+
+
+ The location of access can be used to constrain the
+ ability of a user to establish an active session with
+ the TOE, based on the user's location or port
+ of access. This capability is of particular use in
+ environments where dial-up facilities or network
+ facilities are available.
+
+
+ The user's security attributes can be used to
+ place constraints on the ability of a user to establish
+ an active session with the TOE. For example, these
+ attributes would provide the capability to deny session
+ establishment based on any of the following:
+
+
+ a user's identity;
+
+
+ a user's clearance level;
+
+
+ a user's integrity level; and
+
+
+ a user's membership in a role.
+
+
+
+
+
+ This capability is particularly relevant in situations where
+ authorisation or login may take place at a different
+ location from where TOE access checks are performed.
+
+
+ The time of access can be used to constrain the ability
+ of a user to establish an active session with the TOE
+ based on ranges of time. For example, ranges may be
+ based upon time-of-day, day-of-week, or calendar
+ dates. This constraint provides some operational
+ protection against actions that could occur at a time
+ where proper monitoring or where proper procedural
+ measures may not be in place.
+
+
+
+
+
+
+
+ , provides requirements for denying
+ users access to the TOE based on attributes.
+
+
+ management of the session establishment conditions by the
+ authorised administrator.
+
+
+ Denial of a session establishment due to the session
+ establishment mechanism.
+
+
+ All attempts at establishment of a user session.
+
+
+ Capture of the value of the selected access parameters
+ (e.g. location of access, time of access).
+
+
+ The TSF shall be able to deny session establishment based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the attributes that
+ can be used to restrict the session
+ establishment. Example of possible attributes are user
+ identity, originating location (e.g. no remote
+ terminals), time of access (e.g. outside hours), or
+ method of access (e.g. X-windows).
+
+ .
+
+
+
+
+
+
+
+ Families in this class provide requirements for a trusted
+ communication path between users and the TSF, and for a
+ trusted communication channel between the TSF and other
+ trusted IT products. Trusted paths and channels have the
+ following general characteristics:
+
+
+ The communications path is constructed using internal and
+ external communications channels (as appropriate for the
+ component) that isolate an identified subset of TSF data
+ and commands from the remainder of the TSF and user data.
+
+
+ Use of the communications path may be initiated by the
+ user and/or the TSF (as appropriate for the component).
+
+
+ The communications path is capable of providing assurance
+ that the user is communicating with the correct TSF, and
+ that the TSF is communicating with the correct user (as
+ appropriate for the component).
+
+
+
+ In this paradigm, a trusted channel is a communication channel
+ that may be initiated by either side of the channel, and
+ provides non-repudiation characteristics with respect to the
+ identity of the sides of the channel.
+
+ A trusted path provides a means for users to perform functions
+ through an assured direct interaction with the TSF. Trusted
+ path is usually desired for user actions such as initial
+ identification and/or authentication, but may also be desired
+ at other times during a user's session. Trusted
+ path exchanges may be initiated by a user or the TSF. User
+ responses via the trusted path are guaranteed to be protected
+ from modification by or disclosure to untrusted applications.
+
+
+
+ Users often need to perform functions through direct
+ interaction with the TSF. A trusted path provides confidence
+ that a user is communicating directly with the TSF whenever it
+ is invoked. A user's response via the trusted path
+ guarantees that untrusted applications cannot intercept or
+ modify the user's response. Similarly, trusted
+ channels are one approach for secure communication between the
+ TSF and another trusted IT product.
+
+ Absence of a trusted path may allow breaches of accountability
+ or access control in environments where untrusted applications
+ are used. These applications can intercept user-private
+ information, such as passwords, and use it to impersonate
+ other users. As a consequence, responsibility for any system
+ actions cannot be reliably assigned to an accountable
+ entity. Also, these applications could output erroneous
+ information on an unsuspecting user's display,
+ resulting in subsequent user actions that may be erroneous and
+ may lead to a security breach.
+
+
+
+
+
+ This family defines requirements for the creation of a
+ trusted channel between the TSF and other trusted IT
+ products for the performance of security critical
+ operations. This family should be included whenever there
+ are requirements for the secure communication of user or TSF
+ data between the TOE and other trusted IT products.
+
+
+
+ This family defines the rules for the creation of a trusted
+ channel connection that goes between the TSF and another
+ trusted IT product for the performance of security critical
+ operations between the products. An example of such a
+ security critical operation is the updating of the TSF
+ authentication database by the transfer of data from a
+ trusted product whose function is the collection of audit
+ data.
+
+
+
+
+
+ This component should be used when a trusted communication
+ channel between the TSF and another trusted IT product is
+ required.
+
+
+
+ , requires that the TSF provide a
+ trusted communication channel between itself and another
+ trusted IT product.
+
+
+ Configuring the actions that require trusted channel, if
+ supported.
+
+
+ Failure of the trusted channel functions.
+
+
+ Identification of the initiator and target of failed trusted
+ channel functions.
+
+
+ All attempted uses of the trusted channel functions.
+
+
+ Identification of the initiator and target of all trusted
+ channel functions.
+
+
+ The TSF shall provide a communication channel between itself
+ and another trusted IT product that is logically distinct
+ from other communication channels and provides assured
+ identification of its end points and protection of the
+ channel data from modification or disclosure.
+
+
+ The TSF shall permit
+
+ the TSF
+
+ another trusted IT product
+
+ the PP/ST author must specify whether the local TSF,
+ another trusted IT product, or both shall have the
+ capability to initiate the trusted channel.
+ to initiate communication via the trusted channel.
+
+
+ The TSF shall initiate communication via the trusted channel
+ for
+
+
+ list of functions for which a trusted channel is
+ required
+
+
+
+ the PP/ST author should specify the functions for
+ which a trusted channel is required. Examples of these
+ functions may include transfer of user, subject,
+ and/or object security attributes and ensuring
+ consistency of TSF data.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+
+
+ This component should be used when trusted communication
+ between a user and the TSF is required, either for initial
+ authentication purposes only or for additional specified
+ user operations.
+
+
+
+ , requires that a trusted path
+ between the TSF and a user be provided for a set of events
+ defined by a PP/ST author. The user and/or the TSF may
+ have the ability to initiate the trusted path.
+
+
+ Configuring the actions that require trusted path, if
+ supported.
+
+
+ Failures of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ failures, if available.
+
+
+ All attempted uses of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ invocations, if available.
+
+
+ The TSF shall provide a communication path between itself and
+
+ remote
+
+ local
+
+ the PP/ST author should specify whether the trusted path
+ must be extended to remote and/or local users.
+ users that is logically distinct from other communication
+ paths and provides assured identification of its end points
+ and protection of the communicated data from
+
+ modification
+
+ disclosure
+
+ other types of integrity or confidentiality violation
+
+ if selected, the PP/ST author should identify any
+ additional types of integrity or confidentiality
+ violation against which the trusted path shall protect
+ the data.
+ the PP/ST author should specify whether the trusted path
+ shall protect the data from modification, disclosure,
+ and/or other types of integrity or confidentiality
+ violation..
+
+
+ The TSF shall permit
+
+
+ the TSF
+
+
+ local users
+
+
+ remote users
+
+
+
+ the PP/ST author should specify whether the TSF, local
+ users, and/or remote users should be able to initiate
+ the trusted path.
+
+
+ to initiate communication via the trusted path.
+
+
+ The TSF shall require the use of the trusted path for
+
+
+ initial user authentication
+
+
+
+
+ other services for which trusted path is required
+
+
+
+ if selected, the PP/ST author should identify
+ other services for which trusted path is required,
+ if any.
+
+
+
+
+
+ the PP/ST author should specify whether the trusted
+ path is to be used for initial user authentication
+ and/or for other specified services.
+
+ .
+
+
+
+
+
+
+
+ The class encompasses five
+ families. These families specify assurance requirements that
+ are designed to provide confidence that a composed TOE will
+ operate securely when relying upon security functionality
+ provided by previously evaluated software, firmware or
+ hardware components.
+
+ Composition involves taking two or more IT entities
+ successfully evaluated against CC security assurance
+ requirements packages (base components and dependent
+ components, see ) and
+ combining them for use, with no further development of either
+ IT entity. The development of additional IT entities is not
+ included (entities that have not previously been the subject
+ of a component evaluation). The composed TOE forms a new
+ product that can be installed and integrated into any specific
+ environment instance that meets the objectives for the
+ environment.
+
+ This approach does not provide an alternative approach for the
+ evaluation of components. Composition under provides a composed TOE integrator a method, which
+ can be used as an alternative to other assurance levels
+ specified in the CC, to gain confidence in a TOE that is the
+ combination of two or more successfully evaluated components
+ without having to re-evaluate the composite TSF. (The composed
+ TOE integrator is referred to as ``developer'' throughout the
+ class, with any references to the
+ developer of the base or dependent components clarified as
+ such.)
+
+ Composed Assurance Packages, as defined in Clauses and , is an
+ assurance scale for composed TOEs. This assurance scale is
+ required in addition to EALs because to combine components
+ evaluated against EALs and gain a resulting EAL assurance, all
+ SARs in the EAL have to be applied to the composed
+ TOE. Although reuse can be made of the component TOE
+ evaluation results, there are often additional aspects of the
+ components that have to be considered in the composed TOE, as
+ described in Annex . Due to the different parties involved in a
+ composed TOE evaluation activity it is generally not possible
+ to gain all necessary evidence about these additional aspects
+ of the components to apply the appropriate EAL. Hence, CAPs
+ have been defined to address the issue of combining evaluated
+ components and gaining a meaningful result. This is discussed
+ further in .
+
+
+
+
+ In a composed TOE it is generally the case that one component
+ relies on the services provided by another component. The
+ component requiring services is termed the dependent component
+ and the component providing the services is termed the base
+ component. This interaction and distinct is discussed further
+ in Annex B. It is assumed to be the case that the developer of
+ the dependent component is supporting the composed TOE
+ evaluation in some manner (as developer, sponsor, or just
+ cooperating and providing the necessary evaluation evidence
+ from the dependent component evaluation) The components included in the CAP assurance packages
+ should not be used as augmentations for component TOE
+ evaluations, as this would provide no meaningful assurance for
+ the component.
+
+ The families within the class
+ interact in a similar manner to the , and classes in a component TOE evaluation and hence
+ leverage from the specification of requirements from those
+ classes where applicable. There are however a few items
+ specific to composed TOE evaluations. To determine how the
+ components interact and identify any deviations from the
+ evaluations of the components, the dependencies that the
+ dependent component has upon the underlying base component are
+ identified (). This reliance on
+ the base component is specified in terms of the interfaces
+ through which the dependent component makes calls for services
+ in support of the dependent component SFRs. The interfaces,
+ and at higher levels the supporting behaviour, provided by the
+ base component in response to those service requests are
+ analysed in . The family is based on the family, as at the simplest level the
+ TSF of each component can be viewed as a subsystem of the
+ composed TOE, with additional portions of each component seen
+ as additional subsystems. Therefore, the interfaces between
+ the components are seen as interactions between subsystems in
+ a component TOE evaluation.
+
+ It is possible that the interfaces and supporting behaviour
+ descriptions provided for are
+ incomplete. This is determined during the conduct of . The
+ family takes the outputs of and
+ and determines whether the
+ components are being used in their evaluated configuration and
+ identifies where any specifications are incomplete, which are
+ then identified as inputs into testing () and vulnerability analysis () activities of the composed TOE.
+
+ Testing of the composed TOE is performed to determine that the
+ composed TOE exhibits the expected behaviour as determined by
+ the composed TOE SFRs, and at higher levels demonstrates the
+ compatibility of the interfaces between the components of the
+ composed TOE.
+
+ The vulnerability analysis of the composed TOE leverages from
+ the outputs of the vulnerability analysis of the component
+ evaluations. The composed TOE vulnerability analysis considers
+ any residual vulnerabilities from the component evaluations to
+ determine that the residual vulnerabilities are not applicable
+ to the composed TOE. A search of publicly available
+ information relating to the components is also performed to
+ identify any issues reported in the components since the
+ completion of the respective evaluations.
+
+ The interaction between the
+ families is depicted in Figure below. This shows by solid arrowed lines where
+ the evidence and understanding gained in one family feeds into
+ the next activity and the dashed arrows identify where an
+ activity explicitly traces back to the composed TOE SFRs, as
+ described above.
+
+
+
+
+ Further discussion of the definition and interactions within
+ composed TOEs is provided in .
+
+
+
+ Assurance class defines
+ requirements of the information necessary to ensure that two
+ or more components, which have themselves been the subject of
+ a CC evaluation, can be integrated in a secure manner.
+
+ The assurance requirements will
+ be applied to the composed TOE to:
+
+
+ determine that the required assurance is provided by the
+ base component;
+
+ determine that the base component and dependent component
+ are compatible; and
+
+ search for any vulnerabilities introduced through
+ composing the base and dependent components into a single
+ composed TOE entity.
+
+
+
+ The goal of this activity is to determine whether the
+ components can be integrated in a secure manner, as defined in
+ the ST for the composed TOE. This is achieved through
+ examination and testing of the interfaces between the
+ components, supported by examination of the design of the
+ components and the conduct of vulnerability analysis.
+
+
+
+ The family identifies where
+ the dependent component is reliant upon IT in its operational
+ environment (satisfied by a base component in the composed TOE
+ evaluation) in order to provide its own security
+ services. This reliance is identified in terms of the
+ interfaces expected by the dependent component to be provided
+ by the base component. then
+ determines which interfaces of the base component were
+ considered (as TSFI) during the component evaluation of the
+ base component.
+
+ It should be noted that does
+ not cover other evidence that may be needed to address the
+ technical integration problem of composing components
+ (e.g. descriptions of non-TSF interfaces of the operating
+ system, rules for integration, etc.). This is outside the
+ security assessment of the composition and is a functional
+ composition issue.
+
+ As part of the evaluator will
+ perform testing of the composed TOE SFRs at the composed TOE
+ interfaces and of the interfaces of the base component relied
+ upon by the dependent component to confirm they operate as
+ specified. The subset selected will consider the possible
+ effects of changes to the configuration/use of the base
+ component as used in the composed TOE. These changes are
+ identified from the configuration of the base component
+ determined during the base component evaluation. The developer
+ will provide test evidence for each of the base component
+ interfaces (the requirements for coverage are consistent with
+ those applied to the evaluation of the base component).
+
+ requires the evaluator to
+ determine whether the appropriate assurance measures have been
+ applied to the base component, and whether the base component
+ is being used in its evaluated configuration. This includes
+ determination of whether all security functionality required
+ by the dependent component was within the TSF of the base
+ component. The requirement
+ may be met through the production of evidence that each of
+ these is demonstrated to be upheld. This evidence may be in
+ the form of the security target and a public report of the
+ component evaluation (e.g. certification report).
+
+ If, on the other hand, one of the above have not been upheld,
+ then it may be possible that an argument can be made as to why
+ the assurance gained during an original evaluation is
+ unaffected. If this is not possible then additional evaluation
+ evidence for those aspects of the base component not covered
+ may have to be provided. This material is then assessed in
+ .
+
+ For example, it may be the case as described in the
+ Interactions between entities (see Annex in CC Part 3) that the
+ dependent component requires the base component to provide
+ more security functionality in the composed TOE than included
+ in the base component evaluation. This would be determined
+ during the application of the
+ and families. In this case
+ the composition rationale evidence provided for would demonstrate that the
+ assurance gained from the base component evaluation is
+ unaffected. This may be achieved by means including:
+
+
+ Performing a re-evaluation of the base component focusing
+ on the evidence relating to the extended part of the
+ TSF;
+
+ Demonstrating that the extended part of the TSF cannot
+ affect other portions of the TSF, and providing evidence
+ that the extended part of the TSF provides the necessary
+ security functionality.
+
+
+
+
+ This family addresses the requirement to demonstrate that
+ the base component can provide an appropriate level of
+ assurance for use in composition.
+
+
+
+ The family is used to
+ determine whether or not the appropriate assurance measures
+ have been applied to the base component for successful
+ integration in the composed TOE. That is, the SARs claimed
+ by the base component are consistent with the SARs in the
+ assurance package for the composed TOE. (e.g. if the
+ assurance package for the composed TOE included , a base component that was
+ evaluated against would
+ not have had the appropriate assurance measures applied, as
+ insufficient design evidence would have been
+ examined.)
+
+ The family calls for
+ evidence that the appropriate assurance is provided, without
+ being specific about how this is achieved. If the
+ appropriate evidence is not available, then it may be
+ necessary to report an assessment of the residual risk to
+ assist consumers of the composed TOE
+ (e.g. accreditors). This report would need to identify the
+ change to the base component that may have an effect on the
+ assurance gained during the original evaluation, along with
+ any known effects.
+
+
+
+
+ There is only a single component in this family.
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+ the composition rationale;
+
+ the reliance information;
+
+ the development information;
+
+ unique identifier.
+
+
+
+
+ The developer shall provide composition rationale for the
+ base component.
+
+
+ The composition rationale shall demonstrate that a level of
+ assurance at least as high as that of the dependent
+ component has been obtained for the support functionality of
+ the base component, when the base component is configured as
+ required to support the TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the correspondence analysis
+ with the development information and the reliance
+ information to identify the interfaces that are relied
+ upon by the dependent component which are not detailed
+ in the development information.
+
+ The evaluator's goal in this work unit is two fold:
+
+
+ to determine which interfaces relied upon by the
+ dependent component have had the appropriate
+ assurance measures applied.
+
+ to determine that the assurance package applied to
+ the base component during the base component
+ evaluation contained either the same assurance
+ requirements as those in the package applied to the
+ dependent component during its' evaluation, or
+ hierarchically higher assurance requirements.
+
+
+ The evaluator may use the correspondence tracing in the
+ development information developed during the activities (e.g. , , ) to
+ help identify the interfaces identified in the reliance
+ information that are not considered in the development
+ information.
+
+ The evaluator will record the SFR-enforcing interfaces
+ described in the reliance information that are not
+ included in the development information. These will
+ provide input to
+ work unit, helping to identify the portions of the base
+ component in which further assurance is required.
+
+ If the both the base and dependent components were
+ evaluated against the same assurance package, then the
+ determination of whether the level of assurance in the
+ portions within the base component evaluation is at
+ least as high as that of the dependent component is
+ trivial. If however, the assurance packages applied to
+ the components during the component evaluations differ,
+ the evaluator needs to determine that the assurance
+ requirements applied to the base component are all
+ hierarchically higher to the assurance requirements
+ applied to the dependent component.
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine, for those included base component interfaces
+ on which the dependent TSF relies, whether the interface
+ was considered during the evaluation of the base
+ component.
+
+ The ST, component public evaluation report (e.g. certification
+ report) and guidance documents for the base component all
+ provide information on the scope and boundary of the base
+ component. The ST provides details of the logical scope and
+ boundary of the composed TOE, allowing the evaluator to
+ determine whether an interface relates to a portion of the
+ product that was within the scope of the evaluation. The
+ guidance documentation provides details of use of all interfaces
+ for the composed TOE. Although the guidance documentation may
+ include details of interfaces in the product that are not within
+ the scope of the evaluation, any such interfaces should be
+ identifiable, either from the scoping information in the ST or
+ through a portion of the guidance that deals with the evaluated
+ configuration. The public evaluation report may provide any
+ additional constraints on the use of the composed TOE that are
+ necessary.
+
+ Therefore, the combination of these inputs allows the
+ evaluator to determine whether an interface described in
+ the composition rationale has the necessary assurance
+ associated with it, or whether further assurance is
+ required. The evaluator will record those interfaces of
+ the base component for which additional assurance is
+ required, for consideration during .
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine that the necessary assurance measures have
+ been applied to the base component.
+
+ The evaluation verdicts, and resultant assurance, for
+ the base component can be reused provided the same
+ portions of the base component are used in the composed
+ TOE and they are used in a consistent manner.
+
+ In order to determine whether the necessary assurance
+ measures have already been applied to the component, and
+ the portions of the component for which assurance
+ measures still need to be applied, the evaluator should
+ use the output of the .*.2E action and the work units and :
+
+
+
+ For those interfaces identified in the reliance
+ information (), but
+ not discussed in development information (), additional information
+ is required. (Identified in .)
+
+ For those interfaces used inconsistently in the
+ composed TOE from the base component (difference
+ between the information provided in and the impact of the differences in use
+ need to be considered. (Identified in .*.2E.)
+
+ For those interfaces identified in composition
+ rationale for which no assurance has previously been
+ gained, additional information is
+ required. (Identified in .)
+
+ For those interfaces consistently described in the
+ reliance information, composition rationale and the
+ development information, no further action is
+ required as the results from the base component
+ evaluation can be re-used.
+
+ The interfaces of the base component reported to be
+ required by the reliance information but not included in
+ the development information indicate the portions of the
+ base component where further assurance is required. The
+ interfaces identify the entry points into the base
+ component.
+
+ For those interfaces included in both the development
+ information and reliance information, the evaluator is
+ to determine whether the interfaces are being used in
+ the composed TOE in a manner that is consistent with the
+ base component evaluation. The method of use of the
+ interface will be considered during the activities to determine that
+ the use of the interface is consistent in both the base
+ component and the composed TOE. The remaining
+ consideration is the determination of whether the
+ configurations of the base component and the composed
+ TOE are consistent. To determine this, the evaluator
+ will consider the guidance documentation of each to
+ ensure they are consistent (see further guidance below
+ regarding consistent guidance documentation). Any
+ deviation in the documentation will be further analysed
+ by the evaluation to determine the possible
+ effects.
+
+ For those interfaces that are consistently described in
+ the reliance information and development information,
+ and for which the guidance is consistent for the base
+ component and the composed TOE, the required level of
+ assurance has been provided.
+
+ The following subsubclauses provide guidance on how to
+ determine consistency between assurance gained in the
+ base component, the evidence provided for the composed
+ TOE, and the analysis performed by the evaluator in the
+ instances where inconsistencies are identified.
+
+
+ The reliance information identifies the interfaces in
+ the dependent component that are to be matched by the
+ base component. If an interface identified in the
+ reliance information is not identified in the
+ development information, then the composition
+ rationale is to provide a justification of how the
+ base component provides the required
+ interfaces.
+
+ If an interface identified in the reliance information
+ is identified in the development information, but
+ there are inconsistencies between the descriptions,
+ further analysis is required. The evaluator identifies
+ the differences in use of the base component as
+ considered in the base component evaluation and the
+ composed TOE evaluation. The evaluator will devise
+ testing to be performed (during the conduct of ) to test the
+ interface.
+
+ The patch status of the base and dependent components
+ as used in the composed TOE should be compared to the
+ patch status of the components during the component
+ evaluations. If any patches have been applied to the
+ components, the composition rationale is to include
+ details of the patches, including any potential impact
+ to the SFRs of the evaluated component. The evaluator
+ should consider the details of the changes provided
+ and verify the accuracy of the potential impact of the
+ change on the component SFRs. The evaluator should
+ then consider whether the changes made by the patch
+ should be verified through testing, and will identify
+ the necessary testing approach. The testing may take
+ the form of repeating the applicable
+ evaluator/developer testing performed for the
+ component evaluation of the component or it may be
+ necessary for the evaluator to devise new tests to
+ confirm the modified component.
+
+ If any of the individual components have been the
+ subject of assurance continuity activities since the
+ completion of the component evaluation, the evaluator
+ will consider the changes assessed in the assurance
+ continuity activities during the independent
+ vulnerability analysis activity for the composed TOE
+ (in ).
+
+
+
+ The guidance for the composed TOE is likely to make
+ substantial reference out to the guidance for the
+ individual components. The minimal guidance expected
+ to be necessary is the identification of any ordering
+ dependencies in the application of guidance for the
+ dependent and base components, particularly during the
+ preparation (installation) of the composed TOE.
+
+ In addition to the application of the and families to the guidance for the
+ composed TOE, it is necessary to analyse the
+ consistency between the guidance for the components
+ and the composed TOE, to identify any
+ deviations.
+
+ If the composed TOE guidance refers out to the base
+ component and dependent component guidance, then the
+ consideration for consistency is limited to
+ consistency between the guidance documentation
+ provided for each of the components (i.e. consistency
+ between the base component guidance and the dependent
+ component guidance). However, if additional guidance
+ is provided for the composed TOE, to that provided for
+ the components, greater analysis is required, as
+ consistency is also required between the guidance
+ documentation for the components and guidance
+ documentation for the composed TOE.
+
+ Consistent in this instance is
+ understood to mean that either the guidance is the
+ same or it places additional constraints on the
+ operation of the individual components when combined,
+ in a similar manner to refinement of
+ functional/assurance components.
+
+ With the information available (that used as input for
+ or the development
+ aspects discussed above) the evaluator may be able to
+ determine all possible impacts of the deviation from
+ the configuration of the base component specified in
+ the component evaluation. However, for high EALs
+ (where evaluation of the base component included requirements) it is
+ possible that, unless detailed design abstractions for
+ the base component are delivered as part of the
+ development information for the composed TOE, the
+ possible impacts of the modification to the guidance
+ cannot be fully determined as the internals are
+ unknown. In this case the evaluator will report the
+ residual risk of the analysis.
+
+ These residual risks are to be included in any public
+ evaluation report for the composed TOE.
+
+ The evaluator will note these variances in the
+ guidance for input into evaluator independent testing
+ activities ().
+
+ The guidance for the composed TOE may add to the
+ guidance for the components, particularly in terms of
+ installation and the ordering of installation steps
+ for the base component in relation to the installation
+ steps for the dependent component. The ordering of
+ the steps for the installation of the individual
+ components should not change, however they may need to
+ be interleaved. The evaluator will examine this
+ guidance to ensure that it still meets the requirement
+ of the activity
+ performed during the evaluations of the
+ components.
+
+ It may be the case that the reliance information
+ identifies that interfaces of the base component, in
+ addition to those identified as TSFIs of the base
+ component, are relied upon by the dependent component
+ are identified in the reliance information. It may be
+ necessary for guidance to be provided for the use of
+ any such additional interfaces in the base
+ component. Provided the consumer of the composed TOE
+ is to receive the guidance documentation for the base
+ component, then the results of the and
+ verdicts for the base component can be reused for
+ those interfaces considered in the evaluation of the
+ base component. However, for the additional interfaces
+ relied upon by the dependent component, the evaluator
+ will need to determine that the guidance documentation
+ for the base component meets the requirements of and , as applied in the base component
+ evaluations.
+
+ For those interfaces considered during the base
+ component evaluation, and therefore, for which
+ assurance has already been gained, the evaluator will
+ ensure that the guidance for the use of each interface
+ for the composed TOE is consistent with that provided
+ for the base component. To determine the guidance for
+ the composed TOE is consistent with that for the base
+ component, the evaluator should perform a mapping for
+ each interface to the guidance provided for both the
+ composed TOE and the base component. The evaluator
+ then compares the guidance to determine
+ consistency.
+
+ Examples of additional constraints provided in
+ composed TOE guidance that would be considered to be
+ consistent with component guidance are (guidance for a
+ component is given followed by an example of guidance
+ for a composed TOE that would be considered to provide
+ additional constraints):
+
+
+ Component: The password length must be set to a
+ minimum of 8 characters length, including
+ alphabetic and numeric characters.
+
+ Composed TOE: The password length must be set to a
+ minimum of 10 characters in length, including
+ alphabetic and numeric characters and at
+ least one of the following special characters: ( )
+ { } ^ < > - _
+
+ NOTE: It would only be acceptable to increase the
+ password length to [integer >
+ 8] characters while removing the mandate
+ for the inclusion of both alphabetic and numeric
+ characters for the composed TOE, if the same or a
+ higher metric was achieved for the strength rating
+ (taking into account the likelihood of the
+ password being guessed).
+
+ Component: The following services are to be
+ disabled in the registry settings: WWW Publishing
+ Service and ICDBReporter service.
+
+ Composed TOE: The following services are to be
+ disabled in the registry settings:
+ Publishing Service, ICDBReporter service,
+ Remote Procedure Call (RPC) Locator and Procedure
+ Call (RPC) Service.
+
+ Component: Select the following attributes to be
+ included in the accounting log files: date, time,
+ type of event, subject identity and
+ success/failure.
+
+ Composed TOE: Select the following attributes to
+ be included in the accounting log files: date,
+ time, type of event, subject identity,
+ success/failure, event message and process
+ thread.
+
+ If the guidance for the composed TOE deviates (is not
+ a refinement) from that provided for the base
+ component, the evaluator will assess the potential
+ risks of the modification to the guidance. The
+ evaluator will use the information available
+ (including that provided in the public domain, the
+ architectural description of the base component in the
+ public evaluation report (e.g. certification report),
+ the context of the guidance from the remainder of the
+ guidance documentation) to identify likely impact of
+ the modification to the guidance on the SFRs of the
+ composed TOE.
+
+ If during the dependent component evaluation the trial
+ installation used the base component to satisfy the
+ environment requirements of the dependent component
+ this work unit for the composed TOE is considered to
+ be satisfied. If the base component was not used in
+ satisfaction of the work unit during the dependent component
+ evaluation, the evaluator will apply the user
+ procedures provided for the composed TOE to prepare
+ the composed TOE, in accordance with the guidance
+ specified in . This will allow the evaluator to
+ determine that the preparative guidance provided for
+ the composed TOE is sufficient to prepare the composed
+ TOE and its operational environment securely.
+
+
+
+
+ If there is a different delivery mechanism used for
+ the delivery of the composed TOE (i.e. the
+ components are not delivered to the consumer in
+ accordance with the secure delivery procedures
+ defined and assessed during the evaluation of the
+ components), the delivery procedures for the
+ composed TOE will require evaluation against the
+ requirements
+ applied during the components evaluations.
+
+ The composed TOE may be delivered as an integrated
+ product or may require the components to be
+ delivered separately.
+
+ If the components are delivered separately, the
+ results of the delivery of the base component and
+ dependent component are reused. The delivery of the
+ base component is checked during the evaluator trial
+ installation of the dependent component, using the
+ specified guidance and checking the aspects of
+ delivery that are the responsibility of the user, as
+ described in the guidance documentation for the base
+ component.
+
+ If the composed TOE is delivered as a new entity,
+ then the method of delivery of that entity must be
+ considered in the composed TOE evaluation
+ activities.
+
+ The assessment of the delivery procedures for
+ composed TOE items is to be performed in accordance
+ with the methodology for as for any other [component] TOE,
+ ensuring any additional items (e.g. additional
+ guidance documents for the composed TOE) are
+ considered in the delivery procedures.
+
+
+
+ The unique identification of the composed TOE is
+ considered during the application of and the items from
+ which that composed TOE is comprised are considered
+ during the application of .
+
+ Although additional guidance may be produced for the
+ composed TOE, the unique identification of this
+ guidance (considered as part of the unique
+ identification of the composed TOE during ) is considered
+ sufficient control of the guidance.
+
+ The verdicts of the remaining (not considered above)
+ activities can be
+ reused from the base component evaluation, as no
+ further development is performed during integration
+ of the composed TOE.
+
+ There are no additional considerations for
+ development security as the integration is assumed
+ to take place at either the consumer's site or, in
+ the instance that the composed TOE is delivered as
+ an integrated product, at the site of the dependent
+ component developer. Control at the consumer's site
+ is outside the consideration of the CC. No
+ additional requirements or guidance are necessary if
+ integration is at the same site as that for the
+ dependent component, as all components are
+ considered to be configuration items for the
+ composed TOE, and should therefore be considered
+ under the dependent component developer's security
+ procedures anyway.
+
+ Tools and techniques adopted during integration will
+ be considered in the evidence provided by the
+ dependent component developer. Any tools/techniques
+ relevant to the base component will have been
+ considered during the evaluation of the base
+ component. For example, if the base component is
+ delivered as source code and requires compilation by
+ the consumer (e.g. dependent component developer who
+ is performing integration) the compiler would have
+ been specified and assessed, along with the
+ appropriate arguments, during evaluation of the base
+ component.
+
+ There is no life-cycle definition applicable to the
+ composed TOE, as no further development of items is
+ taking place.
+
+ The results of flaw remediation for a component are
+ not applicable to the composed TOE. If flaw
+ remediation is included in the assurance package for
+ the composed TOE, then the requirements are to be applied during
+ the composed TOE evaluation (as for any
+ augmentation).
+
+
+
+
+ The composed TOE will have been tested during the
+ conduct of the activities
+ for evaluation of the dependent component, as the
+ configurations used for testing of the dependent
+ component should have included the base component to
+ satisfy the requirements for IT in the operational
+ environment. If the base component was not used in the
+ testing of the dependent component for the dependent
+ component evaluation, or the configuration of either
+ component varied from their evaluated configurations,
+ then the developer testing performed for evaluation of
+ the dependent component to satisfy the requirements is to be repeated
+ on the composed TOE.
+
+
+
+
+
+
+
+
+ This family sets out requirements for a specification of the
+ base component in increasing levels of detail. Such
+ information is required to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component (as identified
+ in the reliance information).
+
+
+
+ provides details of the
+ base component interfaces and internals in increasing levels
+ of detail, mirroring the level of detail provided by . The application of these two
+ families will provide the specifications of security
+ services from each perspective of the TSF making the call
+ and the TSF servicing the call.
+
+ Having the two descriptions then allows a determination to
+ be made, as part of the
+ activities (.*.2E actions),
+ that these two descriptions are consistent.
+
+
+
+ The components are levelled on the basis of increasing
+ amounts of detail about the interfaces provided, and how
+ they are implemented.
+
+
+
+ The TSF of the base component is often defined without
+ knowledge of the dependencies of the possible applications
+ with which it may by composed. The TSF of this base
+ component is defined to include all parts of the base
+ component that have to be relied upon for enforcement of the
+ base component SFRs. This will include all parts of the base
+ component required to implement the base component
+ SFRs.
+
+ The functional specification of the base component will
+ describe the TSFI in terms of the interfaces the base
+ component provides to allow an external entity to invoke
+ operations of the TSF. This includes interfaces to the
+ human user to permit interaction with the operation of the
+ TSF invoking SFRs and also interfaces allowing an external
+ IT entity to make calls into the TSF.
+
+ The functional specification only provides a description of
+ what the TSF provides at its interface and the means by
+ which that TSF functionality are invoked. Therefore, the
+ functional specification does not necessarily provide a
+ complete interface specification of all possible interfaces
+ available between an external entity and the base
+ component. It does not include what the TSF expects/requires
+ from the operational environment. The description of what a
+ dependent component TSF relies upon of a base component is
+ considered in and the
+ development information evidence provides a response to the
+ interfaces specified.
+
+ The development information evidence includes a
+ specification of the base component. This may be the
+ evidence used during evaluation of the base component to
+ satisfy the requirements, or may
+ be another form of evidence produced by either the base
+ component developer or the composed TOE developer. This
+ specification of the base component is used during to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component. The level of
+ detail required of this evidence increases to reflect the
+ level of required assurance in the composed TOE. This is
+ expected to broadly reflect the increasing confidence gained
+ from the application of the assurance packages to the
+ components. The evaluator determines that this description
+ of the base component is consistent with the reliance
+ information provided for the dependent component.
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces of the base
+ component to determine that they are consistent with the
+ interfaces specified in the reliance information; those
+ required by the dependent component.
+
+ The description of the interfaces into the base component
+ is to be provided at a level of detail consistent with
+ although not all of the
+ aspects necessary for satisfaction of are required for , as once the interface has been identified
+ and the purpose described the remaining detail of the
+ interface specification can be reused from evaluation of
+ the base component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose of
+ each interface of the base component used in the composed
+ TOE.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during activity).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ In addition, the security behaviour of the base component
+ that supports the dependent component TSF is
+ described.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component, which
+ supports the enforcement of the dependent component SFRs.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component that supports the enforcement of the dependent
+ component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ The interface description of the architecture of the base
+ component is provided to enable the evaluator to determine
+ whether or not that interface formed part of the TSF of
+ the base component.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+ In addition to the interface description, the subsystems
+ of the base component that provide the security
+ functionality required by the dependent component will be
+ described to enable the evaluator to determine whether or
+ not that interface formed part of the TSF of the base
+ component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall identify the subsystems of
+ the base component that provide interfaces of the base
+ component used in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component
+ subsystems, which support the enforcement of the dependent
+ component SFRs.
+
+
+ The development information shall provide a mapping from the
+ interfaces to the subsystems of the base component.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that all subsystems of the base component
+ that provide interfaces to the dependent component are
+ identified.
+
+ For those interfaces that are considered to form part of
+ the TSFI of the base component, the subsystems
+ associated with the interface will be subsystems
+ considered in the
+ activity during the base component evaluation. The
+ interfaces on which the dependent component relies that
+ did not form part of the TSFI of the base component will
+ map to subsystems outside of the base component
+ TSF.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component subsystems that support the enforcement of the
+ dependent component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that the correspondence between the
+ interfaces and subsystems of the base component is
+ accurate.
+
+ If the TOE design and functional specification evidence
+ from the base component evaluation is available, this
+ can be used to verify the accuracy of the correspondence
+ between the interfaces and subsystems of the base
+ component as used in the composed TOE. Those interfaces
+ of the base component, which formed part of the base
+ component TSFI will be described in the base component
+ functional specification, and the associated subsystems
+ will be described in the base component TOE design
+ evidence. The tracing between the two will be provided
+ in the base component TOE design evidence.
+
+ If, however, the base component interface did not form
+ part of the TSFI of the base component, the description
+ of the subsystem behaviour provided in the development
+ information will be used to verify the accuracy of the
+ correspondence.
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+ The purpose of this family is to provide evidence that
+ describes the reliance that a dependent component has upon
+ the base component. This information is useful to persons
+ responsible for integrating the component with other
+ evaluated IT components to form the composed TOE, and for
+ providing insight into the security properties of the
+ resulting composition.
+
+ This provides a description of the interface between the
+ dependent and base components of the composed TOE that may
+ not have been analysed during evaluation of the individual
+ components, as the interfaces were not TSFIs of the
+ individual component TOEs.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant during
+ evaluation of the component, either because of the inherent
+ purpose of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces when evaluating the base component, and are in
+ addition to the security interfaces (TSFIs) considered in
+ the functional specification.
+
+
+
+ The components in this family are levelled according to the
+ amount of detail provided in the description of the reliance
+ by the dependent component upon the base component.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant in the
+ component evaluation, either because of the inherent purpose
+ of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces in the evaluation of the base component, and are
+ in addition to the security interfaces (TSFI) considered in
+ the functional specification.
+
+ In summary, the TSFIs described in the functional
+ specification only include the calls made into a TSF by
+ external entities and responses to those calls. Calls made
+ by a TSF, which were not explicitly considered during
+ evaluation of the components, are described by the reliance
+ information provided to satisfy .
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. These are
+ provided in terms of a high-level description.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF protects
+ itself from interference and tampering by the base
+ component.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. This is
+ provided in terms of the interfaces between the
+ dependent and base component and the return values from
+ those interfaces called by the dependent component.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component implementation representation;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe each interaction in
+ terms of the interface used and the return values from those
+ interfaces.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see Annex in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The reliance information shall describe each interaction
+ in terms of the interface used and the return values
+ from those interfaces.
+
+ The identification of the interfaces used by the
+ dependent component TSF when making services requests of
+ the base component allows an integrator to determine
+ whether the base component provides all the necessary
+ corresponding interfaces. This understanding is further
+ gained through the specification of the return values
+ expected by the dependent component. The evaluator
+ ensures that interfaces are described for each
+ interaction specified (as analysed in ).
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF protects
+ itself from interference and tampering by the base
+ component.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ This family requires that testing of composed TOE and
+ testing of the base component, as used in the composed TOE,
+ is performed.
+
+
+
+ The family details
+ requirements for testing to demonstrate that the composed
+ TOE operates as specified in the composed TOE SFRs and the
+ base component interfaces match the design descriptions as
+ provided in the development information (). Testing evidence is to be provided of all
+ SFRs specified in the composed TOE ST and to exercise all
+ base component interfaces used by the dependent component,
+ as identified in .
+
+
+
+ The components in this family are levelled on the basis of
+ increasing rigour of interface testing and increasing rigour
+ of the analysis of the sufficiency of the tests to
+ demonstrate that the composed TSF operates in accordance
+ with the reliance information and the composed TOE
+ SFRs.
+
+
+
+ There are two distinct aspects of testing associated with
+ this family:
+
+
+ testing of the interfaces between the base component and
+ the dependent component, which the dependent component
+ rely upon for enforcement of security functionality, to
+ demonstrate their compatibility;
+
+
+ testing of the composed TOE to demonstrate that the TOE
+ behaves in accordance with the SFRs for the composed
+ TOE.
+
+
+
+ If the test configurations used during evaluation of the
+ dependent component included use of the base component as a
+ ``platform'' and the test analysis sufficiently demonstrates
+ that the TSF behaves in accordance with the SFRs, the
+ developer need perform no further testing of the composed
+ TOE functionality. However, if the base component was not
+ used in the testing of the dependent component, or the
+ configuration of either component varied, then the developer
+ is to perform testing of the composed TOE. This may take
+ the form of repeating the dependent component developer
+ testing of the dependent component, provided this adequately
+ demonstrates the composed TOE TSF behaves in accordance with
+ the SFRs.
+
+ The developer is to provide evidence of testing the base
+ component interfaces used in the composition. The operation
+ of base component TSFIs would have been tested as part of
+ the activities during
+ evaluation of the base component. Therefore, provided the
+ appropriate interfaces were included within the test sample
+ of the base component evaluation and it was determined in
+ that the base component is
+ operating in accordance with the base component evaluated
+ configuration, with all security functionality required by
+ the dependent component included in the TSF, the evaluator
+ action may be met
+ through reuse of the base component verdicts.
+
+ If this is not the case, the base component interfaces used
+ relevant to the composition that are affected by any
+ variations to the evaluated configuration and any additional
+ security functionally will be tested to ensure they
+ demonstrate the expected behaviour. The expected behaviour
+ to be tested is that described in the reliance information
+ ( evidence).
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to ensure the expected behaviour of all composed TOE SFRs
+ and interfaces of the base component relied upon by the
+ dependent component is demonstrated.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the SFRs specified
+ for the composed TOE to identify which SFRs have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the interfaces of
+ the base component relied upon by the dependent
+ component (as specified in the reliance information,
+ examined under ) to
+ identify which base component interfaces have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to verify the
+ developer test results.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to confirm that the
+ TSF operates as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to fully demonstrate the expected behaviour of the
+ composed TOE and the interfaces of the base component
+ relied upon by the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified and is complete.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified and is complete.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the composed TOE and the composed TOE
+ SFRs in the composed TOE security target.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and SFRs presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the base component interfaces relied upon
+ by the dependent component and the interfaces specified
+ in the reliance information.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and interfaces presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The tests are to be selected and executed in accordance
+ with , to
+ demonstrate the correct behaviour of the SFRs specified
+ in the composed TOE security target.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to confirm that the
+ TSF operates as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+ The evaluator shall perform testing, in accordance with
+ , for a subset of the
+ interfaces to the base component to confirm they operate
+ as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the base component to test,
+ the evaluator should take into account any modifications
+ to the base component from the evaluated version or
+ configuration. In particular, the evaluator should
+ consider the development of tests to demonstrate the
+ correct behaviour of interfaces of the base component
+ that were not considered during the evaluation of the
+ base component. These additional interfaces and other
+ modifications to the base component will have been
+ identified during the
+ activity.
+
+
+
+
+
+
+
+ This family calls for an analysis of vulnerability
+ information available in the public domain and of
+ vulnerabilities that may be introduced as a result of the
+ composition.
+
+
+
+ The vulnerability analysis in includes determination of two different
+ aspects of resistance by the composed TOE, namely:
+
+
+ Residual vulnerabilities in the base and dependent
+ components remain unexploitable in the operational
+ environment of the composed TOE;
+
+ The composed TOE is resistant to attackers with a given
+ level of attack potential.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing scrutiny of vulnerability information from the
+ public domain and independent vulnerability analysis.
+
+
+
+ The developer will provide details of any residual
+ vulnerabilities reported during evaluation of the
+ components. These may be gained from the component
+ developers or evaluation reports for the components. These
+ will be used as inputs into the evaluator's vulnerability
+ analysis of the composed TOE in the operational
+ environment.
+
+
+ The operational environment of the composed TOE is examined
+ to ensure that the assumptions and objectives for the
+ component operational environment (specified in each
+ component ST) are satisfied in the composed TOE. An initial
+ analysis of the consistency of assumptions and objectives
+ between the components and the composed TOE STs will have
+ been performed during the conduct of the activities for the composed TOE. However, this
+ analysis is revisited with the knowledge acquired during the
+ , and the
+ activities to ensure that, for example, assumptions of the
+ dependent component that were addressed by the environment
+ in the dependent component ST are not reintroduced as a
+ result of composition (i.e. that the base component
+ adequately addresses the assumptions of the dependent
+ component ST in the composed TOE).
+
+ A search by the evaluator for issues in each component will
+ identify potential vulnerabilities reported in the public
+ domain since completion of the evaluation of the components.
+ Any potential vulnerabilities will then be subject to
+ testing.
+
+ If the base component used in the composed TOE has been the
+ subject of assurance continuity activities since
+ certification, the evaluator will consider during the
+ composed TOE vulnerability analysis activities the changes
+ made in base component.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ easily exploitable vulnerabilities.
+
+ The developer provides details of any residual
+ vulnerabilities reported from evaluation of the
+ components. The evaluator performs an analysis of the
+ disposition the residual vulnerabilities reported and also
+ performs a search of the public domain, to identify any
+ new potential vulnerabilities in the components
+ (i.e. those issues that have been reported in the public
+ domain since evaluation of the base component). The
+ evaluator then performs penetration testing to demonstrate
+ that the potential vulnerabilities cannot be exploited in
+ the TOE, in its operational environment, by an attacker
+ with basic attack potential.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities;
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes a component from the
+ family, then the
+ evaluator may refer to the result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the base component
+ that have become known since the completion of
+ evaluation of the base component.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the
+ dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (i.e. ), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing basic
+ attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the evaluation
+ of the components). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information publicly
+ available to support the identification of possible security
+ vulnerabilities in the base component that have become known
+ since the completion of the base component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public domain as
+ described in to search for
+ vulnerabilities in the dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components of the composed TOE
+ in the independent evaluator vulnerability analysis will
+ take a slightly different form to that documented in
+ for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the components, but the evidence may
+ not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the individual
+ components. The focus of the vulnerability analysis
+ during the composed TOE evaluation is to identify any
+ vulnerabilities introduced as a result of the
+ integration of the components or due to any changes in
+ the use of the components between the evaluated
+ component configuration to the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ development information and composition rationale for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact and
+ identify potential vulnerabilities that may be
+ introduced as a result of this interaction.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch(es) in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report) will be the main source of
+ input material of the change. This will be supplemented
+ by any updates to the guidance documentation resulting
+ from the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether the
+ composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Enhanced-Basic attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the component
+ evaluations). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information publicly
+ available to support the identification of possible security
+ vulnerabilities in the base component that have become known
+ since the completion of the base component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since completion of the
+ dependent component evaluation.
+
+ The evaluator will use the information in the public domain as
+ described in to search for
+ vulnerabilities in the dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components in the independent
+ evaluator vulnerability analysis will take a slightly
+ different form to that documented in for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the base component, but the evidence
+ may not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the components. The focus
+ of the vulnerability analysis during the composed TOE
+ evaluation is to identify any vulnerabilities introduced
+ as a result of the integration of the components or due
+ to any changes in the use of the components between the
+ configuration of the component determined during the
+ component evaluation and the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ composition rationale and development information for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report). This will be supplemented by
+ any updates to the guidance documentation resulting from
+ the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on the
+ identified vulnerabilities, to demonstrate that the composed TOE
+ is resistant to attacks by an attacker with Enhanced-Basic
+ attack potential.
+
+ The evaluator shall conduct penetration testing as detailed
+ for .
+ The evaluator will apply all work units necessary for the
+ satisfaction of evaluator action , reporting in the ETR for the composed TOE all
+ analysis and verdicts as dictated by the work units.
+ The evaluator will also apply the work units for the
+ evaluator action to
+ determine that the composed TOE provided by the developer is
+ suitable for testing.
+
+
+
+
+
+
+ The requirements of the Development class provide information
+ about the TOE. The knowledge obtained by this information is
+ used as the basis for conducting vulnerability analysis and
+ testing upon the TOE, as described in the and classes.
+
+ The Development class encompasses six families of requirements
+ for structuring and representing the TSF at various levels and
+ varying forms of abstraction. These families include:
+
+ requirements for the description (at the various
+ levels of abstraction) of the design and implementation of
+ the SFRs (, , )
+ requirements for the description of the
+ architecture-oriented features of domain separation, TSF
+ self-protection and non-bypassability of the security
+ functionality ()
+ requirements for a security policy model and for correspondence
+ mappings between security policy model and the functional
+ specification ()
+ requirements on the internal structure of the TSF,
+ which covers aspects such as modularity, layering, and
+ minimisation of complexity ()
+
+ When documenting the security functionality of a TOE, there
+ are two properties that need to be demonstrated. The first
+ property is that the security functionality works correctly;
+ that is, it performs as specified. The second property, and
+ one that is arguably harder to demonstrate, is that the TOE
+ cannot be used in a way such that the security functionality
+ can be corrupted or bypassed. These two properties require
+ somewhat different approaches in analysis, and so the families
+ in are structured to support these
+ different approaches. The families , , , and deal with the first property: the specification
+ of the security functionality. The families and deal with
+ the second property: the specification of the design of the
+ TOE demonstrating the security functionality cannot be
+ corrupted or bypassed. It should be noted that both properties
+ need to be realised: the more confidence one has that the
+ properties are satisfied, the more trustworthy the TOE is. The
+ components in the families are designed so that more assurance
+ can be gained as the components hierarchically
+ increase.
+
+ The paradigm for the families targeted at the first property
+ is one of design decomposition. At the highest level, there is
+ a functional specification of the TSF in terms of its
+ interfaces (describing what the TSF does in
+ terms of requests to the TSF for services and resulting
+ responses), decomposing the TSF into smaller units (dependent
+ on the assurance desired and the complexity of the TOE) and
+ describing how the TSF accomplishes its
+ functions (to a level of detail commensurate with the
+ assurance level), and showing the implementation of the TSF. A
+ formal model of the security behaviour also may be given. All
+ levels of decomposition are used in determining the
+ completeness and accuracy of all other levels, ensuring that
+ the levels are mutually supportive. The requirements for the
+ various TSF representations are separated into different
+ families, to allow the PP/ST author to specify which TSF
+ representations are required. The level chosen will dictate
+ the assurance desired/gained.
+
+ Figure indicates the
+ relationships among the various TSF representations of the
+ class, as well as their
+ relationships with other classes. As the figure indicates, the
+ and
+ classes define the requirements for the correspondence between
+ the SFRs and the security objectives for the TOE. Class also defines requirements for the
+ correspondence between both the security objectives and SFRs,
+ and for the TOE summary specification which explains how the
+ TOE meets its SFRs. The activities of include the verification that the TSF that is
+ tested under the and classes is in fact the one described by all of the
+ decomposition levels.
+
+
+ The requirements for all other correspondence shown in Figure
+ are defined in the
+ class. The family defines the requirements for formally
+ modelling selected SFRs, and providing correspondence between
+ the functional specification and the formal model. Each
+ assurance family specific to a TSF representation (i.e., ,
+ and ) defines requirements
+ relating that TSF representation to the SFRs. All
+ decompositions must accurately reflect all other
+ decompositions (i.e., be mutually supportive); the developer
+ supplies the tracings in the last .C elements of the
+ components. Assurance relating to this factor is obtained
+ during the analysis for each of the levels of decomposition by
+ referring to other levels of decomposition (in a recursive
+ fashion) while the analysis of a particular level of
+ decomposition is being performed; the evaluator verifies the
+ correspondence as part of the second E element. The
+ understanding gained from these levels of decomposition form
+ the basis of the functional and penetration testing
+ efforts.
+
+ The family is not represented
+ in this figure, as it is related to the internal structure of
+ the TSF, and is only indirectly related to the process of
+ refinement of the TSF representations. Similarly, the family is not represented in the
+ figure because it relates to the architectural soundness,
+ rather than representation, of the TSF. Both and
+ relate to the analysis of the property that the TOE cannot be
+ made to circumvent or corrupt its security
+ functionality.
+
+ The TOE security functionality (TSF) consists of all parts of
+ the TOE that have to be relied upon for enforcement of the
+ SFRs. The TSF includes both functionality that directly
+ enforces the SFRs, as well as functionality that, while not
+ directly enforcing the SFRs, contributes to their enforcement
+ in a more indirect manner, including functionality with the
+ capability to cause the SFRs to be violated. This includes
+ portions of the TOE that are invoked on start-up that are
+ responsible for putting the TSF into its initial secure
+ state.
+
+ Several important concepts were used in the development of the
+ components of the families. These
+ concepts, while introduced briefly here, are explained more
+ fully in the application notes for the families.
+
+ One over-riding notion is that, as more information becomes
+ available, greater assurance can be obtained that the security
+ functionality 1) is correctly implemented; 2) cannot be
+ corrupted; and 3) cannot be bypassed. This is done through the
+ verification that the documentation is correct and consistent
+ with other documentation, and by providing information that
+ can be used to ensure that the testing activities (both
+ functional and penetration testing) are comprehensive. This is
+ reflected in the levelling of the components of the
+ families. In general, components are levelled based on the
+ amount of information that is to be provided (and subsequently
+ analysed).
+
+ While not true for all TOEs, it is generally the case that the
+ TSF is sufficiently complex that there are portions of the TSF
+ that deserve more intense examination than other portions of
+ the TSF. Determining those portions is unfortunately somewhat
+ subjective, thus terminology and components have been defined
+ such that as the level of assurance increases, the
+ responsibility for determining what portions of the TSF need
+ to be examined in detail shifts from the developer to the
+ evaluator. To aid in expressing this concept, the following
+ terminology is introduced. It should be noted that in the
+ families of the class, this terminology is used when
+ expressing SFR-related portions of the TOE (that is, elements
+ and work units embodied in the , , and families). While the general
+ concept (that some portions of the TOE are more
+ interesting than others) applies to other
+ families, the criteria are expressed differently in order to
+ obtain the assurance required.
+
+ All portions of the TSF are security
+ relevant, meaning that they must preserve the
+ security of the TOE as expressed by the SFRs and
+ requirements for domain separation and
+ non-bypassability. One aspect of security relevance is the
+ degree to which a portion of the TSF enforces a security
+ requirement. Since different portions of the TOE play
+ different roles (or no apparent role at all) in enforcing
+ security requirements, this creates a continuum of SFR
+ relevance: at one end of this continuum are portions of the
+ TOE that are termed SFR-enforcing. Such
+ portions play a direct role in implementing any SFR on the
+ TOE. Such SFRs refer to any functionality provided by one of
+ the SFRs contained in the ST. It should be noted that the
+ definition of plays a role in for
+ SFR-enforcing functionality is impossible to express
+ quantitatively. For example, in the implementation of a
+ Discretionary Access Control (DAC) mechanism, a very narrow
+ view of SFR-enforcing might be the several
+ lines of code that actually perform the check of a subject's
+ attributes against the object's attributes. A broader view
+ would include the software entity (e.g., C function) that
+ contained the several lines of code. A broader view still
+ would include callers of the C function, since they would be
+ responsible for enforcing the decision returned by the
+ attribute check. A still broader view would include any code
+ in the call tree (or programming equivalent for the
+ implementation language used) for that C function (e.g., a
+ sort function that sorted access control list entries in a
+ first-match algorithm implementation). At some point, the
+ component is not so much enforcing the
+ security policy but rather plays a
+ supporting role; such components are termed
+ SFR supporting.
+
+ One of the characteristics of SFR-supporting functionality is
+ that it is trusted to preserve the correctness of the SFR
+ implementation by operating without error. Such functionality
+ may be depended on by SFR-enforcing functionality, but the
+ dependence is generally at a functional level; for example,
+ memory management, buffer management, etc. Further down on the
+ security relevance continuum is functionality termed
+ SFR non-interfering. Such functionality has
+ no role in implementing the SFRs, and is likely part of the
+ TSF because of its environment; for example, any code running
+ in a privileged hardware mode on an operating system. It needs
+ to be considered part of the TSF because, if compromised (or
+ replaced by malicious code), it could compromise the correct
+ operation of an SFR by virtue of its operating in the
+ privileged hardware mode. An example of SFR non-interfering
+ functionality might be a set of mathematical floating point
+ operations implemented in kernel mode for speed
+ considerations.
+
+ The architecture family ()
+ provides for requirements and analysis of the TOE based on
+ properties of domain separation, self-protection, and
+ non-bypassability. These properties relate to the SFRs in
+ that, if these properties are not present, it will likely lead
+ to the failure of mechanisms implementing SFRs. Functionality
+ and design relating to these properties is
+ not considered a part of the continuum described
+ above, but instead is treated separately due to its
+ fundamentally different nature and analysis
+ requirements.
+
+ The difference in analysis of the implementation of SFRs
+ (SFR-enforcing and SFR-supporting functionality) and the
+ implementation of somewhat fundamental security properties of
+ the TOE, which include the initialisation, self-protection,
+ and non-bypassability concerns, is that the SFR-related
+ functionality is more or less directly visible and relatively
+ easy to test, while the above-mentioned properties require
+ varying degrees of analysis on a much broader set of
+ functionality. Further, the depth of analysis for such
+ properties will vary depending on the design of the TOE. The
+ families are constructed to address
+ this by a separate family ()
+ devoted to analysis of the initialisation, self-protection,
+ and non-bypassability requirements, while the other families
+ are concerned with analysis of the functionality supporting
+ SFRs.
+
+ Even in cases where different descriptions are necessary for
+ the multiple levels of abstraction, it is not absolutely
+ necessary for each and every TSF representation to be in a
+ separate document. Indeed, it may be the case that a single
+ document meets the documentation requirements for more than
+ one TSF representation, since it is the information about each
+ of these TSF representations that is required, rather than the
+ resulting document structure. In cases where multiple TSF
+ representations are combined within a single document, the
+ developer should indicate which portions of the documents meet
+ which requirements.
+
+ Three types of specification style are mandated by this class:
+ informal, semiformal and formal. The functional specification
+ and TOE design documentation are always written in either
+ informal or semiformal style. A semiformal style reduces the
+ ambiguity in these documents over an informal presentation. A
+ formal specification may also be required in addition
+ to the semi-formal presentation; the value is that a
+ description of the TSF in more than one way will add increased
+ assurance that the TSF has been completely and accurately
+ specified.
+
+ An informal specification is written as prose in natural
+ language. Natural language is used here as meaning
+ communication in any commonly spoken tongue (e.g. Spanish,
+ German, French, English, Dutch). An informal specification is
+ not subject to any notational or special restrictions other
+ than those required as ordinary conventions for that language
+ (e.g. grammar and syntax). While no notational restrictions
+ apply, the informal specification is also required to provide
+ defined meanings for terms that are used in a context other
+ than that accepted by normal usage.
+
+ The difference between semiformal and informal documents is
+ only a matter of formatting or presentation: a semiformal
+ notation includes such things as an explicit glossary of
+ terms, a standardised presentation format, etc. A semiformal
+ specification is written to a standard presentation
+ template. The presentation should use terms consistently if
+ written in a natural language. The presentation may also use
+ more structured languages/diagrams (e.g. data-flow diagrams,
+ state transition diagrams, entity-relationship diagrams, data
+ structure diagrams, and process or program structure
+ diagrams). Whether based on diagrams or natural language, a
+ set of conventions must be used in the presentation. The
+ glossary explicitly identifies the words that are being used
+ in a precise and constant manner; similarly, the standardised
+ format implies that extreme care has been taken in
+ methodically preparing the document in a manner that maximises
+ clarity. It should be noted that fundamentally different
+ portions of the TSF may have different semiformal notation
+ conventions and presentation styles (as long as the number of
+ different ``semiformal notations'' is small); this still
+ conforms to the concept of a semiformal
+ presentation.
+
+ A formal specification is written in a notation based upon
+ well-established mathematical concepts, and is typically
+ accompanied by supporting explanatory (informal) prose. These
+ mathematical concepts are used to define the syntax and
+ semantics of the notation and the proof rules that support
+ logical reasoning. The syntactic and semantic rules supporting
+ a formal notation should define how to recognise constructs
+ unambiguously and determine their meaning. There needs to be
+ evidence that it is impossible to derive contradictions, and
+ all rules supporting the notation need to be defined or
+ referenced.
+
+
+
+ The purpose of the Development class is to provide evidence
+ about the TOE. Without the knowledge about the TOE that is
+ gained from this information, there could be no useful
+ vulnerability analysis or testing conducted upon the TOE (as
+ described in the and classes).
+
+
+ The purpose of the development activity is to assess the
+ design documentation in terms of its adequacy to understand
+ how the TSF meets the SFRs and how the implementation of these
+ SFRs cannot be tampered with or bypassed. This understanding
+ is achieved through examination of increasingly refined
+ descriptions of the TSF design documentation. Design
+ documentation consists of a functional specification (which
+ describes the interfaces of the TSF), a TOE design description
+ (which describes the architecture of the TSF in terms of how
+ it works in order to perform the functions related to the SFRs
+ being claimed), and an implementation description (a source
+ code level description). In addition, there is a security
+ architecture description (which describes the architectural
+ properties of the TSF to explain how its security enforcement
+ cannot be compromised or bypassed), an internals description
+ (which describes how the TSF was constructed in a manner that
+ encourages understandability), and a security policy model
+ (which formally describes the security policies enforced by
+ the TSF).
+
+
+
+ The CC requirements for design documentation are levelled by
+ the amount, and detail of information provided, and the degree
+ of formality of the presentation of the information. At lower
+ levels, the most security-critical portions of the TSF are
+ described with the most detail, while less security-critical
+ portions of the TSF are merely summarised; added assurance is
+ gained by increasing the amount of information about the most
+ security-critical portions of the TSF, and increasing the
+ details about the less security-critical portions. The most
+ assurance is achieved when thorough details and information of
+ all portions are provided.
+
+ The CC considers a document's degree of formality (that is,
+ whether it is informal or semiformal) to be hierarchical. An
+ informal document is one that is expressed in a natural
+ language. The methodology does not dictate the specific
+ language that must be used; that issue is left for the
+ scheme. The following paragraphs differentiate the contents of
+ the different informal documents.
+
+ A functional specification provides a description of the
+ purpose and method-of-use of interfaces to the TSF. For
+ example, if an operating system presents the user with a means
+ of self-identification, of creating files, of modifying or
+ deleting files, of setting permissions defining what other
+ users may access files, and of communicating with remote
+ machines, its functional specification would contain
+ descriptions of each of these and how they are realised
+ through interactions with the externally-visible interfaces to
+ the TSF. If there is also audit functionality that detects and
+ record the occurrences of such events, descriptions of this
+ audit functionality would also be expected to be part of the
+ functional specification; while this functionality is
+ technically not directly invoked by the user at the external
+ interface, it certainly is affected by what occurs at the
+ user's external interface.
+
+ A design description is expressed in terms of logical
+ divisions (subsystems or modules) that each provide a
+ comprehensible service or function. For example, a firewall
+ might be composed of subsystems that deal with packet
+ filtering, with remote administration, with auditing, and with
+ connection-level filtering. The design description of the
+ firewall would describe the actions that are taken, in terms
+ of what actions each subsystem takes when an incoming packet
+ arrives at the firewall.
+
+
+
+
+ The objective of this family is for the developer to provide
+ a description of the security architecture of the TSF. This
+ will allow analysis of the information that, when coupled
+ with the other evidence presented for the TSF, will confirm
+ the TSF achieves the desired properties. The security
+ architecture descriptions supports the implicit claim that
+ security analysis of the TOE can be achieved by examining
+ the TSF; without a sound architecture, the entire TOE
+ functionality would have to be examined.
+
+
+
+ The information presented for the security architecture of
+ the TOE is related to the information contained in other
+ decomposition documentation (functional specification and
+ TOE design documentation) provided for the TSF, but presents
+ the design in a manner that supports architectural arguments
+ (e.g., the TSF cannot be compromised; the TSF provides
+ security domains consistent with its SFRs; the TSF cannot be
+ bypassed).
+
+
+
+ This family contains only one component.
+
+
+
+ The properties of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed by Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the TSF
+ that are achieved through the design of the TOE and TSF, and
+ enforced by the correct implementation of that
+ design.
+
+ The approach used in this family is for the developer to
+ design and provide a TSF that exhibits the above-mentioned
+ properties, and to provide evidence (in the form of
+ documentation) that explains these properties of the
+ TSF. This explanation is provided at the same level of
+ detail as the description of the SFR-enforcing elements of
+ the TOE in the TOE design document. The evaluator has the
+ responsibility for looking at the evidence and, coupled with
+ other evidence delivered for the TOE and TSF, determining
+ that the properties are achieved.
+
+ Specification of security functionality implementing the
+ SFRs (in the and ) will not necessarily describe
+ mechanisms employed in implementing self-protection and
+ non-bypassability (e.g. memory management
+ mechanisms). Therefore, the material needed to provide the
+ assurance that these requirements are being achieved is
+ better suited to a presentation separate from the design
+ decomposition of the TSF as embodied in and . This is not
+ to imply that the security architecture description called
+ for by this component cannot reference or make use of the
+ design decomposition material; but it is likely that much of
+ the detail present in the decomposition documentation will
+ not be relevant to the argument being provided for the
+ security architecture description document.
+
+ The description of architectural soundness can be thought of
+ as a developer's vulnerability analysis, in that it provides
+ the justification for why the TSF is sound and enforces all
+ of its SFRs. Where the soundness is achieved through
+ specific security mechanisms, these will be tested as part
+ of the requirements; where
+ the soundness is achieved solely through the architecture,
+ the behaviour will be tested as part of the requirements.
+
+ This family consists of requirements for a security
+ architecture description that describes the self-protection,
+ domain separation, non-bypassability principles, including a
+ description of how these principles are supported by the
+ parts of the TOE that are used for TSF
+ initialisation.
+ Additional information on the security architecture
+ properties of self-protection, domain separation, and
+ non-bypassability can be found in Annex .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is structured such that it cannot be tampered with
+ or bypassed, and whether TSFs that provide security
+ domains isolate those domains from each other.
+
+
+
+ The notions of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed in Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the
+ TSF that are achieved through the design of the TOE, and
+ enforced by the correct implementation of that
+ design. Also, the evaluation of these properties is less
+ straight-forward than the evaluation of mechanisms; it is
+ more difficult to check for the absence of functionality
+ than for its presence. However, the determination that
+ these properties are being satisfied is just as critical
+ as the determination that the mechanisms are properly
+ implemented.
+
+ The overall approach used is that the developer provides a
+ TSF that meets the above-mentioned properties, and
+ provides evidence (in the form of documentation) that can
+ be analysed to show that the properties are indeed
+ met. The evaluator has the responsibility for looking at
+ the evidence and, coupled with other evidence delivered
+ for the TOE, determining that the properties are
+ achieved. The work units can be characterised as those
+ detailing with what information has to be provided, and
+ those dealing with the actual analysis the evaluator
+ performs.
+
+ The security architecture description describes how
+ domains are defined and how the TSF keeps them
+ separate. It describes what prevents untrusted processes
+ from getting to the TSF and modifying it. It describes
+ what ensures that all resources under the TSF's control
+ are adequately protected and that all actions related to
+ the SFRs are mediated by the TSF. It explains any role the
+ environment plays in any of these (e.g. presuming it gets
+ correctly invoked by its underlying environment, how is
+ its security functionality invoked?). In short, it
+ explains how the TOE is considered to be providing any
+ kind of security service.
+
+ The analyses the evaluator performs must be done in the
+ context of all of the development evidence provided for
+ the TOE, at the level of detail the evidence is
+ provided. At lower assurance levels there should not be
+ the expectation that, for example, TSF self-protection is
+ completely analysed, because only high-level design
+ representations will be available. The evaluator also
+ needs to be sure to use information gleaned from other
+ portions of their analysis (e.g., analysis of the TOE
+ design) in making their assessments for the properties
+ being examined in the following work units.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation (if available);
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall design and implement the TOE so that the
+ security features of the TSF cannot be bypassed.
+
+
+ The developer shall design and implement the TSF so that it
+ is able to protect itself from tampering by untrusted active
+ entities.
+
+
+ The developer shall provide a security architecture
+ description of the TSF.
+
+
+ The security architecture description shall be at a level of
+ detail commensurate with the description of the
+ SFR-enforcing abstractions described in the TOE design
+ document.
+
+
+ The security architecture description shall describe the
+ security domains maintained by the TSF consistently with the
+ SFRs.
+
+
+ The security architecture description shall describe how the
+ TSF initialisation process is secure.
+
+
+ The security architecture description shall demonstrate that
+ the TSF protects itself from tampering.
+
+
+ The security architecture description shall demonstrate that
+ the TSF prevents bypass of the SFR-enforcing functionality.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the information provided
+ in the evidence is presented at a level of detail
+ commensurate with the descriptions of the SFR-enforcing
+ abstractions contained in the functional specification
+ and TOE design document.
+
+ With respect to the functional specification, the
+ evaluator should ensure that the self-protection
+ functionality described cover those effects that are
+ evident at the TSFI. Such a description might include
+ protection placed upon the executable images of the TSF,
+ and protection placed on objects (e.g., files used by
+ the TSF). The evaluator ensures that the functionality
+ that might be invoked through the TSFI is
+ described.
+
+ If or is included, the evaluator
+ ensures the security architecture description contains
+ information on how any subsystems that contribute to TSF
+ domain separation work.
+
+ If or higher is
+ available, the evaluator ensures that the security
+ architecture description also contains
+ implementation-dependent information. For example, such
+ a description might contain information pertaining to
+ coding conventions for parameter checking that would
+ prevent TSF compromises (e.g. buffer overflows), and
+ information on stack management for call and return
+ operations. The evaluator checks the descriptions of the
+ mechanisms to ensure that the level of detail is such
+ that there is little ambiguity between the description
+ in the security architecture description and the
+ implementation representation.
+
+ The evaluator action related to this work unit is assigned a fail verdict
+ if the security architecture description mentions any module, subsystem, or interface
+ that is not described in the functional specification or TOE design document.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it describes the security
+ domains maintained by the TSF.
+
+ Security domains refer to environments supplied by the
+ TSF for use by potentially-harmful entities; for
+ example, a typical secure operating system supplies a
+ set of resources (address space, per-process environment
+ variables) for use by processes with limited access
+ rights and security properties. The evaluator determines
+ that the developer's description of the security domains
+ takes into account all of the SFRs claimed by the
+ TOE.
+
+ For some TOEs such domains do not exist because all of
+ the interactions available to users are severely
+ constrained by the TSF. A packet-filter firewall is an
+ example of such a TOE. Users on the LAN or WAN do not
+ interact with the TOE, so there need be no security
+ domains; there are only data structures maintained by
+ the TSF to keep the users' packets separated. The
+ evaluator ensures that any claim that there are no
+ domains is supported by the evidence and that no such
+ domains are, in fact, available.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the initialisation process
+ preserves security.
+
+ The information provided in the security architecture
+ description relating to TSF initialisation is directed
+ at the TOE components that are involved in bringing the
+ TSF into an initial secure state (i.e. when all parts of
+ the TSF are operational) when power-on or a reset is
+ applied. This discussion in the security architecture
+ description should list the system initialisation
+ components and the processing that occurs in
+ transitioning from the ``down'' state to the initial
+ secure state.
+
+ It is often the case that the components that perform
+ this initialisation function are not accessible after
+ the secure state is achieved; if this is the case then
+ the security architecture description identifies the components and
+ explains how they are not reachable by untrusted
+ entities after the TSF has been established. In this
+ respect, the property that needs to be preserved is that
+ these components either 1) cannot be accessed by
+ untrusted entities after the secure state is achieved,
+ or 2) if they provide interfaces to untrusted entities,
+ these TSFI cannot be used to tamper with the TSF.
+
+ The TOE components related to TSF initialisation, then,
+ are treated themselves as part of the TSF, and analysed
+ from that perspective. It should be noted that even
+ though these are treated as part of the TSF, it is
+ likely that a justification (as allowed by ) can be made that they do not
+ have to meet the internal structuring requirements of
+ .
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it contains information
+ sufficient to support a determination that the TSF is
+ able to protect itself from tampering by untrusted
+ active entities.
+
+ ''Self-protection'' refers to the ability of the TSF to
+ protect itself from manipulation from external entities
+ that may result in changes to the TSF. For TOEs that
+ have dependencies on other IT entities, it is often the
+ case that the TOE uses services supplied by the other IT
+ entities in order to perform its functions. In such
+ cases, the TSF alone does not protect itself because it
+ depends on the other IT entities to provide some of the
+ protection. For the purposes of the security
+ architecture description, the notion of
+ self-protection applies only to the
+ services provided by the TSF through its TSFI, and not
+ to services provided by underlying IT entities that it
+ uses.
+
+ Self-protection is typically achieved by a variety of
+ means, ranging from physical and logical restrictions on
+ access to the TOE; to hardware-based means (e.g.
+ ``execution rings'' and memory management
+ functionality); to software-based means (e.g. boundary
+ checking of inputs on a trusted server). The evaluator
+ determines that all such mechanisms are
+ described.
+
+ The evaluator determines that the design description
+ covers how user input is handled by the TSF in such a
+ way that the TSF does not subject itself to being
+ corrupted by that user input. For example, the TSF might
+ implement the notion of privilege and protect itself by
+ using privileged-mode routines to handle user input. The
+ TSF might make use of processor-based separation
+ mechanisms such as privilege levels or rings. The TSF
+ might implement software protection constructs or coding
+ conventions that contribute to implementing separation of
+ software domains, perhaps by delineating user address
+ space from system address space. And the TSF might have
+ reliance its environment to provide some support to the
+ protection of the TSF.
+
+ All of the mechanisms contributing to the domain
+ separation functions are described. The evaluator should
+ use knowledge gained from other evidence (functional
+ specification, TOE design, TSF internals description,
+ other parts of the security architecture description, or
+ implementation representation, as included in the
+ assurance package for the TOE) in determining if any
+ functionality contributing to self-protection was
+ described that is not present in the security
+ architecture description.
+
+ Accuracy of the description of the self-protection
+ mechanisms is the property that the description
+ faithfully describes what is implemented. The evaluator
+ should use other evidence (functional specification, TOE
+ design, TSF Internals documentation, other parts of the
+ security architectural description, implementation
+ representation, as included in the ST for the TOE) in
+ determining whether there are discrepancies in any
+ descriptions of the self-protection mechanisms. If is included in the assurance
+ package for the TOE, the evaluator will choose a sample
+ of the implementation representation; the evaluator
+ should also ensure that the descriptions are accurate
+ for the sample chosen. If an evaluator cannot
+ understand how a certain self-protection mechanism works
+ or could work in the system architecture, it may be the
+ case that the description is not accurate.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it presents an analysis
+ that adequately describes how the SFR-enforcing
+ mechanisms cannot be bypassed.
+
+ Non-bypassability is a property that the security
+ functionality of the TSF (as specified by the SFRs) is
+ always invoked. For example, if access control to files
+ is specified as a capability of the TSF via an SFR,
+ there must be no interfaces through which files can be
+ accessed without invoking the TSF's access control
+ mechanism (such as an interface through which a raw disk
+ access takes place).
+
+ Describing how the TSF mechanisms cannot be bypassed
+ generally requires a systematic argument based on the
+ TSF and the TSFIs. The description of how the TSF works
+ (contained in the design decomposition evidence, such as
+ the functional specification, TOE design documentation)
+ - along with the information in the TSS - provides the
+ background necessary for the evaluator to understand
+ what resources are being protected and what security
+ functions are being provided. The functional
+ specification provides descriptions of the TSFIs through
+ which the resources/functions are accessed.
+
+ The evaluator assesses the description provided (and other
+ information provided by the developer, such as the functional
+ specification) to ensure that no available interface can be used
+ to bypass the TSF. This means that every available interface
+ must be either unrelated to the SFRs that are claimed in the ST
+ (and does not interact with anything that is used to satisfy
+ SFRs) or else uses the security functionality that is described
+ in other development evidence in the manner described. For
+ example, a game would likely be unrelated to the SFRs, so there
+ must be an explanation of how it cannot affect security. Access
+ to user data, however, is likely to be related to access control
+ SFRs, so the explanation would describe how the security
+ functionality works when invoked through the data-access
+ interfaces. Such a description is needed for every available
+ interface.
+
+ An example of a description follows. Suppose the TSF
+ provides file protection. Further suppose that although
+ the ``traditional'' system call TSFIs for open, read,
+ and write invoke the file protection mechanism described
+ in the TOE design, there exists a TSFI that allows
+ access to a batch job facility (creating batch jobs,
+ deleting jobs, modifying unprocessed jobs). The
+ evaluator should be able to determine from the
+ vendor-provided description that this TSFI invokes the
+ same protection mechanisms as do the ``traditional''
+ interfaces. This could be done, for example, by
+ referencing the appropriate subclauses of the TOE design
+ that discuss how the batch job facility
+ TSFI achieves its security objectives.
+
+ Using this same example, suppose there is a TSFI whose
+ sole purpose is to display the time of day. The
+ evaluator should determine that the description
+ adequately argues that this TSFI is not capable of
+ manipulating any protected resources and should not
+ invoke any security functionality.
+
+ Another example of bypass is when the TSF is supposed to
+ maintain confidentiality of a cryptographic key (one is
+ allowed to use it for cryptographic operations, but is
+ not allowed to read/write it). If an attacker has direct
+ physical access to the device, he might be able to
+ examine side-channels such as the power usage of the
+ device, the exact timing of the device, or even any
+ electromagnetic emanations of the device and, from this,
+ infer the key.
+
+ If such side-channels may be present, the demonstration
+ should address the mechanisms that prevent these
+ side-channels from occurring, such as random internal
+ clocks, dual-line technology etc. Verification of these
+ mechanisms would be verified by a combination of purely
+ design-based arguments and testing.
+
+ For a final example using security functionality rather
+ than a protected resource, consider an ST that contains
+ , which requires that
+ the TSF provides evidence of origination for information
+ types specified in the ST. Suppose that the
+ ``information types'' included all information that is
+ sent by the TOE via e-mail. In this case the evaluator
+ should examine the description to ensure that all TSFI
+ that can be invoked to send e-mail perform the
+ ``evidence of origination generation'' function are
+ detailed. The description might point to user guidance
+ to show all places where e-mail can originate (e.g.,
+ e-mail program, notification from scripts/batch jobs)
+ and then how each of these places invokes the evidence
+ generation function.
+
+ The evaluator should also ensure that the description is
+ comprehensive, in that each interface is analysed with
+ respect to the entire set of claimed SFRs. This may
+ require the evaluator to examine supporting information
+ (functional specification, TOE design, other parts of
+ the security architectural description, operational user
+ guidance, and perhaps even the implementation
+ representation, as provided for the TOE) to determine
+ that the description has correctly capture all aspects
+ of an interface. The evaluator should consider what SFRs
+ each TSFI might affect (from the description of the TSFI
+ and its implementation in the supporting documentation),
+ and then examine the description to determine whether it
+ covers those aspects.
+
+
+
+
+
+
+
+ This family levies requirements upon the functional
+ specification, which describes the TSF interfaces (TSFIs). The
+ TSFIs consist of all means for users to invoke a service from
+ the TSF (by supplying data that is processed by the TSF) and the
+ corresponding responses to those service invocations. It does
+ not describe how the TSF processes those
+ service requests, nor does it describe the communication when
+ the TSF invokes services from its operational environment; this
+ information is addressed by the
+ and families,
+ respectively.
+
+ This family provides assurance directly by allowing the
+ evaluator to understand how the TSF meets the claimed SFRs. It
+ also provides assurance indirectly, as input to other assurance
+ families and classes:
+ , where the description of
+ the TSFIs may be used to gain better understanding of how the
+ TSF is protected against corruption (i.e. subversion of
+ self-protection or domain separation) and/or bypass;
+ , where the description of the
+ TSFIs is an important input for both developer and evaluator
+ testing;
+ , where the description of the
+ TSFIs is used to search for vulnerabilities.
+
+
+
+
+ The information presented in the functional specification
+ describes the interfaces through which the TSF services are
+ invoked. At the lower levels of assurance, there is an
+ effort to reduce the amount of information that must be
+ supplied by requiring only the most security-critical
+ information.
+
+
+
+ The components in this family are levelled on the degree of
+ detail required of the description of the TSFIs, and the degree
+ of formalism required of the description of the TSFIs.
+
+
+
+ Once the TSFIs are determined (see for guidance and
+ examples of determining TSFI), they are described. At
+ lower-level components, developers focus their documentation
+ (and evaluators focus their analysis) on the more
+ security-relevant aspects of the TOE. Three categories of
+ TSFIs are defined, based upon the relevance the services
+ available through them have to the SFRs being claimed:
+ If a service available through an interface can be
+ traced to one of the SFRs levied on the TSF, then that
+ interface is termed SFR-enforcing.
+ Note that it is possible that an interface may have
+ various services and results, some of which may be
+ SFR-enforcing and some of which may not.
+ interfaces to (or services available through an
+ interface relating to) services that SFR-enforcing
+ functionality depends upon, but need only to function
+ correctly in order for the security policies of the TOE
+ to be preserved, are termed
+ SFR-supporting.
+ Interfaces to services on which SFR-enforcing
+ functionality has no dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR-supporting or SFR non-interfering it must have
+ no SFR-enforcing services or results. In
+ contrast, an SFR-enforcing interface may have SFR-supporting
+ services (for example, the ability to set the system clock
+ may be an SFR-enforcing service of an interface, but if that
+ same interface is used to display the system date that
+ service may be only SFR-supporting). An example of a purely
+ SFR-supporting interface is a system call interface that is
+ used both by users and by a portion of the TSF that is
+ running on behalf of users.
+
+ As more information about the TSFIs becomes available, the
+ greater the assurance that can be gained that the interfaces are
+ correctly categorised/analysed. The requirements are structured
+ such that, at the lowest level, the information required for SFR
+ non-interfering interfaces is the minimum necessary in order for
+ the evaluator to make this determination in an effective
+ manner. At higher levels, more information becomes available so
+ that the evaluator has greater confidence in the
+ designation.
+
+ The purpose in defining these labels (SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering) and for levying
+ different requirements upon each (at the lower assurance
+ components) is to provide a first approximation of where to
+ focus the analysis and the evidence upon which that analysis
+ is performed. If the developer's documentation of the TSF
+ interfaces describes all of the interfaces to the degree
+ specified in the requirements for the SFR-enforcing
+ interfaces (that is, if the documentation exceeds the
+ requirements), there is no need for the developer to create
+ new evidence to match the requirements. Similarly, because
+ the labels are merely a means of differentiating the
+ interface types within the requirements, there is no need
+ for the developer to update the evidence solely to label the
+ interfaces as SFR-enforcing, SFR-supporting, and
+ SFR-non-interfering. The primary purpose of this labelling
+ is to allow developers with less mature development
+ methodologies (and associated artifacts, such as detailed
+ interface and design documentation) to provide only the
+ necessary evidence without undue cost.
+
+ The last C element of each component within this family provides
+ a direct correspondence between the SFRs and the functional
+ specification; that is, an indication of which interfaces are
+ used to invoke each of the claimed SFRs. In the cases where the
+ ST contains such functional requirements as , whose functionality may not manifest itself at
+ the TSFIs, the functional specification and/or the tracing is
+ expected to identify these SFRs; including them in the functional
+ specification helps to ensure that they are not lost at lower
+ levels of decomposition, where they will be relevant.
+
+
+ The requirements define collections of details about TSFI
+ to be provided. For the purposes of the requirements,
+ interfaces are specified (in varying degrees of detail) in
+ terms of their purpose, method of use, parameters,
+ parameter descriptions, and error messages.
+
+ The purpose of an interface is a
+ high-level description of the general goal of the
+ interface (e.g. process GUI commands, receive network
+ packets, provide printer output, etc.)
+
+ The interface's method of use describes
+ how the interface is supposed to be used. This description
+ should be built around the various interactions available
+ at that interface. For instance, if the interface were a Unix
+ command shell, ls, mv
+ and cp would be interactions for that
+ interface. For each interaction the method of use
+ describes what the interaction does, both for behaviour
+ seen at the interface (e.g. the programmer calling the
+ API, the Windows users changing a setting in the registry,
+ etc.) as well as behaviour at other interfaces
+ (e.g. generating an audit record).
+
+ Parameters are explicit inputs to and
+ outputs from an interface that control the behaviour of
+ that interface. For example, parameters are the arguments
+ supplied to an API; the various fields in a packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; the flags that can be set for the
+ ls, etc. The parameters are
+ ``identified'' with a simple list of what they are.
+
+ A parameter description tells what the
+ parameter is in some meaningful way. For instance, an
+ acceptable parameter description for interface
+ foo(i) would be ``parameter i is an
+ integer that indicates the number of users currently
+ logged in to the system''. A description such as
+ ``parameter i is an integer'' is not an acceptable.
+
+ The description of an interface's actions
+ describes what the interface does. This is more detailed
+ than the purpose in that, while the ``purpose'' reveals
+ why one might want to use it, the ``actions'' reveals
+ everything that it does. These actions might be related to
+ the SFRs or not. In cases where the interface's action is
+ not related to SFRs, its description is said to be
+ summarised, meaning the description
+ merely makes clear that it is indeed not SFR-related.
+
+ The error message description identifies
+ the condition that generated it, what the message is, and
+ the meaning of any error codes. An error message is
+ generated by the TSF to signify that a problem or
+ irregularity of some degree has been encountered. The
+ requirements in this family refer to different kinds of
+ error messages:
+ a ``direct'' error message is a
+ security-relevant response through a specific TSFI
+ invocation.
+ an ``indirect'' error cannot be tied to a
+ specific TSFI invocation because it results from
+ system-wide conditions (e.g. resource exhaustion,
+ connectivity interruptions, etc.). Error messages that
+ are not security-relevant are also considered
+ ``indirect''.
+ ``remaining'' errors are any other errors, such as those
+ that might be referenced within the code. For example, the use of
+ condition-checking code that checks for conditions that would not
+ logically occur (e.g. a final ``else'' after a list of ``case''
+ statements), would provide for generating a catch-all error
+ message; in an operational TOE, these error messages should never
+ be seen.
+
+ An example functional specification is provided in .
+
+
+
+ Increasing assurance through increased completeness and
+ accuracy in the interface specification is reflected in
+ the documentation required from the developer as detailed
+ in the various hierarchical components of this
+ family.
+
+ At , the only
+ documentation required is a characterisation of all TSFIs
+ and a high level description of SFR-enforcing and
+ SFR-supporting TSFIs. To provide some assurance that the
+ ``important'' aspects of the TSF have been correctly
+ characterised at the TSFIs, the developer is required to
+ provide the purpose and method of use, parameters for the
+ SFR-enforcing and SFR-supporting TSFIs.
+
+ At , the developer is
+ required to provide the purpose, method of use,
+ parameters, and parameter descriptions for all
+ TSFIs. Additionally, for the SFR-enforcing TSFIs the
+ developer has to describe the SFR-enforcing actions and
+ direct error messages.
+
+ At , the developer must now,
+ in addition to the information required at , provide enough information about the SFR-supporting
+ and SFR-non-interfering actions to show that they are not
+ SFR-enforcing. Further, the developer must now document all of
+ the direct error messages resulting from the invocation of
+ SFR-enforcing TSFIs.
+
+ At , all TSFIs - whether
+ SFR-enforcing, SFR-supporting, SFR-non-interfering - must
+ be described to the same degree, including all of the
+ direct error messages.
+
+ At , the TSFIs descriptions
+ also include error messages that do not result from an
+ invocation of a TSFI.
+
+ At , in addition to the
+ information required by , all
+ remaining error messages are included. The developer must also
+ provide a formal description of the TSFI. This provides an
+ alternative view of the TSFI that may expose inconsistencies or
+ incomplete specification.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has provided a high-level description of at least the
+ SFR-enforcing and SFR-supporting TSFIs, in terms of descriptions
+ of their parameters. There is no other required evidence that
+ can be expected to be available to measure the accuracy of these
+ descriptions; the evaluator merely ensures the descriptions seem
+ plausible.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall describe the purpose and
+ method of use for each SFR-enforcing and SFR-supporting
+ TSFI.
+
+
+ The functional specification shall identify all parameters
+ associated with each SFR-enforcing and SFR-supporting TSFI.
+
+
+ The functional specification shall provide rationale for the
+ implicit categorisation of interfaces as
+ SFR-non-interfering.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ SFR-supporting and SFR-enforcing TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of the parameters; this can be done in
+ association with other work units for this
+ component.
+
+ If an action available through an interface plays a role in
+ enforcing any security policy on the TOE (that is, if one of the
+ actions of the interface can be traced to one of the SFRs levied
+ on the TSF), then that interface is
+ SFR-enforcing. Such policies are not limited to
+ the access control policies, but also refer to any functionality
+ specified by one of the SFRs contained in the ST. Note that it
+ is possible that an interface may have various actions and
+ results, some of which may be SFR-enforcing and some of which
+ may not.
+
+ Interfaces to (or actions available through an interface
+ relating to) actions that SFR-enforcing functionality
+ depends on, but need only to function correctly in order
+ for the security policies of the TOE to be preserved,
+ are termed SFR supporting. Interfaces
+ to actions on which SFR-enforcing functionality has no
+ dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR supporting or SFR non-interfering it must have
+ no SFR-enforcing actions or results. In
+ contrast, an SFR-enforcing interface may have
+ SFR-supporting actions (for example, the ability to set
+ the system clock may be an SFR-enforcing action of an
+ interface, but if that same interface is used to display
+ the system date that action may only be SFR
+ supporting). An example of a purely SFR-supporting
+ interface is a system call interface that is used both
+ by untrusted users and by a portion of the TSF that is
+ running in user mode.
+
+ At this level, it is unlikely that a developer will have
+ expended effort to label interfaces as SFR-enforcing and
+ SFR-supporting. In the case that this has been done,
+ the evaluator should verify to the extent that
+ supporting documentation (e.g., operational user
+ guidance) allows that this identification is correct.
+ Note that this identification activity is necessary for
+ several work units for this component.
+
+ In the more likely case that the developer has not
+ labelled the interfaces, the evaluator must perform
+ their own identification of the interfaces first, and
+ then determine whether the required information (for
+ this work unit, the purpose) is present. Again, because
+ of the lack of supporting evidence this identification
+ will be difficult and have low assurance that all
+ appropriate interfaces have been correctly identified,
+ but nonetheless the evaluator examines other evidence
+ available for the TOE to ensure as complete coverage as
+ is possible.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each
+ SFR-supporting and SFR-enforcing TSFI is given.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it identifies all parameters
+ associated with each SFR-enforcing and SFR-supporting
+ TSFI.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for
+ identified TSFI. Parameters are explicit inputs or
+ outputs to an interface that control the behaviour of
+ that interface. For examples, parameters are the
+ arguments supplied to an API; the various fields in
+ packet for a given network protocol; the individual key
+ values in the Windows Registry; the signals across a set
+ of pins on a chip; etc.
+
+ While difficult to obtain much assurance that all
+ parameters for the applicable TSFI have been identified,
+ the evaluator should also check other evidence provided
+ for the evaluation (e.g., operational user guidance) to
+ see if behaviour or additional parameters are described
+ there but not in the functional specification.
+
+
+
+
+ The evaluator shall examine the rationale provided by
+ the developer for the implicit categorisation of
+ interfaces as SFR-non-interfering to determine that it
+ is accurate.
+
+ In the case where the developer has provided adequate
+ documentation to perform the analysis called for by the
+ rest of the work units for this component without
+ explicitly identifying SFR-enforcing and SFR-supporting
+ interfaces, this work unit should be considered
+ satisfied.
+
+ This work unit is intended to apply to cases where the developer
+ has not described a portion of the TSFI, claiming that it is
+ SFR-non-interfering and therefore not subject to other
+ requirements of this component. In such a case, the developer
+ provides a rationale for this characterisation in sufficient
+ detail such that the evaluator understands the rationale, the
+ characteristics of the interfaces affected (e.g., their
+ high-level function with respect to the TOE, such as ``colour
+ palette manipulation''), and that the claim that these are
+ SFR-non-interfering is supported. Given the level of assurance
+ the evaluator should not expect more detail than is provided for
+ the SFR-enforcing or SFR-supporting interfaces, and in fact the
+ detail should be much less. In most cases, individual
+ interfaces should not need to be addressed in the
+ developer-provided rationale subclause.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis, the
+ evaluator may build upon the developer's tracing (see a map between the TOE security
+ functional requirements and the TSFI). Note that this map may
+ have to be at a level of detail below the component or even
+ element level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that have
+ little or no manifestation at the TSF boundary (e.g., ) it is not expected that they
+ completely map those requirements to the TSFI. The analysis for
+ those requirements will be performed in the analysis for the TOE
+ design () when included in the
+ ST. It is also important to note that since the parameters
+ associated with TSFIs must be fully specified, the evaluator
+ should be able to determine if all aspects of an SFR appear to
+ be implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the SFR-enforcing actions, results and error
+ messages of each TSFI that is SFR-enforcing are also
+ described.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For SFR-enforcing TSFIs, the functional specification shall
+ describe direct error messages resulting from processing
+ associated with the SFR-enforcing actions.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer"; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface can be
+ traced to one of the SFRs levied on the TSF, then that
+ interface is SFR-enforcing. Such
+ policies are not limited to the access control policies,
+ but also refer to any functionality specified by one of
+ the SFRs contained in the ST. Note that it is possible
+ that an interface may have various actions and results,
+ some of which may be SFR-enforcing and some of which may not.
+
+ The developer is not required to ``label'' interfaces as
+ SFR-enforcing, and likewise is not required to identify
+ actions available through an interface as SFR-enforcing.
+ It is the evaluator's responsibility to examine the
+ evidence provided by the developer and determine that
+ the required information is present. In the case where
+ the developer has identified the SFR-enforcing TSFI and
+ SFR-enforcing actions available through those TSFI, the
+ evaluator must judge completeness and accuracy based on
+ other information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and on the other information presented
+ for the interfaces (parameters and parameter
+ descriptions, error messages, etc.).
+
+ In this case (where the developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing.
+
+ In the case where the developer has provided the same
+ level of information on all interfaces, the evaluator
+ performs the same type of analysis mentioned in the
+ previous paragraphs. The evaluator should determine
+ which interfaces are SFR-enforcing and which are not,
+ and subsequently ensure that the SFR-enforcing aspects
+ of the SFR-enforcing actions are appropriately
+ described.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from SFR-enforcing
+ actions associated with each SFR-enforcing TSFI.
+
+ This work unit should be performed in conjunction with,
+ or after, work unit
+ in order to ensure the set of SFR-enforcing TSFI and
+ SFR-enforcing actions is correctly identified. The
+ developer may provide more information than is required
+ (for example, all error messages associated with each
+ interface), in which the case the evaluator should
+ restrict their assessment of completeness and accuracy
+ to only those that they determine to be associated with
+ SFR-enforcing actions of SFR-enforcing TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+ In order to determine that the description of the
+ error messages of a TSFI is accurate and complete, the
+ evaluator measures the interface description against the
+ other evidence provided for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), as well as other evidence available for
+ that TSFI (parameters, analysis from work unit ).
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the actions, results and error messages of each
+ TSFI are also described sufficiently that it can be
+ determined whether they are SFR-enforcing, with the
+ SFR-enforcing TSFI being described in more detail than
+ other TSFIs.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe direct error messages resulting from security enforcing
+ effects and exceptions associated with invocation of the TSFI.
+
+
+ The functional specification shall summarise the SFR-supporting
+ and SFR-non-interfering actions associated with each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface plays a role
+ in enforcing any security policy on the TOE (that is, if
+ one of the actions of the interface can be traced to one
+ of the SFRs levied on the TSF), then that interface is
+ SFR-enforcing. Such policies are not
+ limited to the access control policies, but also refer
+ to any functionality specified by one of the SFRs
+ contained in the ST. Note that it is possible that an
+ interface may have various actions and results, some of
+ which may be SFR-enforcing and some of which may
+ not.
+ The developer is not required to ``label''
+ interfaces as SFR-enforcing, and likewise is not
+ required to identify actions available through an
+ interface as SFR-enforcing. It is the evaluator's
+ responsibility to examine the evidence provided by the
+ developer and determine that the required information is
+ present. In the case where the developer has identified
+ the SFR-enforcing TSFI and SFR-enforcing actions
+ available through those TSFI, the evaluator must judge
+ completeness and accuracy based on other information
+ supplied for the evaluation (e.g., TOE design, security
+ architecture description, operational user guidance),
+ and on the other information presented for the
+ interfaces (parameters and parameter descriptions, error
+ messages, etc.).
+
+ In this case (developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing. The analysis
+ done for work units
+ and are also used in
+ making this determination.
+ In the case where the developer has provided the
+ same level of information on all interfaces, the
+ evaluator performs the same type of analysis mentioned
+ in the previous paragraphs. The evaluator should
+ determine which interfaces are SFR-enforcing and which
+ are not, and subsequently ensure that the SFR-enforcing
+ aspects of the SFR-enforcing actions are appropriately
+ described. Note that in this case, the evaluator should
+ be able to perform the bulk of the work associated with
+ work unit in the
+ course of performing this SFR-enforcing analysis.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from an invocation of
+ each SFR-enforcing TSFI.
+
+ This work unit should be performed in conjunction with, or
+ after, work unit in order
+ to ensure the set of SFR-enforcing TSFI is correctly identified.
+ The evaluator should note that the requirement and associated
+ work unit is that all direct error messages associated with an
+ SFR-enforcing TSFI must be described, that are associated with
+ SFR-enforcing actions. This is because at this level of
+ assurance, the ``extra'' information provided by the error
+ message descriptions should be used in determining whether all
+ of the SFR-enforcing aspects of an interface have been
+ appropriately described. For instance, if an error message
+ associated with a TSFI (e.g., ``access denied'') indicated that
+ an SFR-enforcing decision or action had taken place, but in the
+ description of the SFR-enforcing actions there was no mention of
+ that particular SFR-enforcing mechanism, then the description
+ may not be complete.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+
+ In order to determine that the description of the error messages
+ of a TSFI is accurate and complete, the evaluator measures the
+ interface description against the other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance), as well as for other
+ evidence supplied for that TSFI (description of SFR-enforcing
+ actions, summary of SFR-supporting and SFR-non-interfering
+ actions and results).
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to
+ determine that it summarises the SFR-supporting and
+ SFR-non-interfering actions associated with each TSFI.
+
+ The purpose of this work unit is to supplement the details about
+ the SFR-enforcing actions (provided in work unit ) with a summary of the remaining
+ actions (i.e., those that are not SFR-enforcing). This covers
+ all SFR-supporting and SFR-non-interfering
+ actions, whether invokable through SFR-enforcing TSFI or through
+ SFR-supporting or SFR-non-interfering TSFI. Such a summary
+ about all SFR-supporting and SFR-non-interfering actions helps
+ to provide a more complete picture of the functions provided by
+ the TSF, and is to be used by the evaluator in determining
+ whether an action or TSFI may have been mis-categorised.
+
+ The information to be provided is more abstract than that
+ required for SFR-enforcing actions. While it should still be
+ detailed enough so that the reader can understand what the
+ action does, the description does not have to be detailed enough
+ to support writing tests against it, for instance. For the
+ evaluator, the key is that the information must be sufficient to
+ make a positive determination that the action is SFR-supporting
+ or SFR-non-interfering. If that level of information is
+ missing, the summary is insufficient and more information must
+ be obtained.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST.
+
+
+
+ The functional specification describes the interfaces to
+ the TSF (the TSFI) in a structured manner. Because of the
+ dependency on , the
+ evaluator is expected to have identified the TSF prior to
+ beginning work on this sub-activity. Without firm
+ knowledge of what comprises the TSF, it is not possible to
+ assess the completeness of the TSFI.
+
+ In performing the various work units included in this family,
+ the evaluator is asked to make assessments of accuracy and
+ completeness of several factors (the TSFI itself, as well as the
+ individual components (parameters, actions, error messages,
+ etc.) of the TSFI). In doing this analysis, the evaluator is
+ expected to use the documentation provided for the
+ evaluation. This includes the ST, the TOE design, and may
+ include other documentation such as the operational user
+ guidance, security architecture description, and implementation
+ representation. The documentation should be examined in an
+ iterative fashion. The evaluator may read, for example, in the
+ TOE design how a certain function is implemented, but see no way
+ to invoke that function from the interface. This might cause the
+ evaluator to question the completeness of a particular TSFI
+ description, or whether an interface has been left out of the
+ functional specification altogether. Describing analysis
+ activities of this sort in the ETR is a key method in providing
+ rationale that the work units have been performed
+ appropriately.
+
+ It should be recognised that there exist functional
+ requirements whose functionality is manifested wholly or
+ in part architecturally, rather than through a specific
+ mechanism. An example of this is the implementation of
+ mechanisms implementing the requirements. Such mechanisms typically are
+ implemented to ensure a behaviour isn't present, which is
+ difficult to test and typically is verified through
+ analysis. In the cases where such functional requirements
+ are included in the ST, it is expected that the evaluator
+ recognise that there may be SFRs of this type that have no
+ interfaces, and that this should not be considered a
+ deficiency in the functional specification.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+ The evaluator shall examine the functional specification to
+ determine the completeness of the TSFI
+ The evaluator shall use the design documentation to identify the possible types of
+ interfaces. The evaluator shall search the design documentation and the guidance
+ documentation for potential TSFI not contained in the developer's documentation,
+ thus indicating that the set of TSFI defined by the developer is incomplete. The
+ evaluator shall examine the arguments presented by the developer that the TSFI is
+ complete and check down to the lowest level of design or with the
+ implementation representation that no additional TSFI exist.
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ Actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the meaning of all errors associated with each
+ TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation
+ (e.g. TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST. The completeness of the interfaces
+ is judged based upon the implementation
+ representation.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the implementation representation.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ semi-formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+ The functional specification
+ shall describe all error messages that do not result from an
+ invocation of a TSFI.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation yet
+ does not result from an invocation of a TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is presented using a semiformal
+ style.
+
+ A semi-formal presentation is characterised by a
+ standardised format with a well-defined syntax that
+ reduces ambiguity that may occur in informal
+ presentations. Since the intent of the semi-formal
+ format is to enhance the reader's ability to understand
+ the presentation, use of certain structured presentation
+ methods (pseudo-code, flow charts, block diagrams) are
+ appropriate, though not required.
+
+ For the purposes of this activity, the evaluator should
+ ensure that the interface descriptions are formatted in
+ a structured, consistent manner and use common
+ terminology. A semiformal presentation of the interfaces
+ also implies that the level of detail of the
+ presentation for the interfaces is largely consistent
+ across all TSFI. For the functional specification, it is
+ acceptable to refer to external specifications for
+ portions of the interface as long as those external
+ specifications are themselves semiformal.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system''. is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the meaning of all errors associated with each
+ TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation (e.g.,
+ TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it completely and accurately describes
+ all errors messages that do not result from an
+ invocation of any TSFI.
+
+ This work unit complements work unit , which describes those
+ error messages that result from an invocation of the
+ TSFI. Taken together, these work units cover all error
+ messages that might be generated by the TSF.
+
+ The evaluator assesses the completeness and accuracy of
+ the functional specification by comparing its contents
+ to instances of error message generation within the
+ implementation representation. Most of these error
+ messages will have already been covered by work unit
+ .
+
+ The error messages related to this work unit are
+ typically those that are not expected to be generated,
+ but are constructed as a matter of good programming
+ practises. For example, a case statement that defines
+ actions resulting from each of a list of cases may end
+ with a final else statement to apply
+ to anything that might not be expected; this practise
+ ensures the TSF does not get into an undefined state.
+ However, it is not expected that the path of execution
+ would ever get to this else
+ statement; therefore, any error message generation
+ within this else statement would
+ never be generated. Although it would not get
+ generated, it must still be included in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it provides a rationale for each error
+ message contained in the TSF implementation yet does not
+ result from an invocation of a TSFI.
+
+ The evaluator ensures that every error message found
+ under work unit
+ contains a rationale describing why it cannot be invoked
+ from the TSFI.
+
+ As was described in the previous work unit, this
+ rationale might be as straightforward as the fact that
+ the error message in question is provided for
+ completeness of execution logic and that it is never
+ expected to be generated. The evaluator ensures that the
+ rationale for each such error message is logical.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ (Need Objectives text for FSP.6 methodology)
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a formal presentation of the
+ functional specification of the TSF.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+
+ The functional specification shall describe all error messages
+ contained in the TSF implementation representation.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation that
+ is not otherwise described in the functional specification
+ justifying why it is not associated with a TSFI.
+
+
+ The formal presentation of the functional specification of
+ the TSF shall describe the TSFI using a formal style,
+ supported by informal, explanatory text where appropriate.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+
+
+
+
+ The function of the family
+ is for the developer to make available the implementation
+ representation (and, at higher levels, the implementation
+ itself) of the TOE in a form that can be analysed by the
+ evaluator. The implementation representation is used in
+ analysis activities for other families (analysing the TOE
+ design, for instance) to demonstrate that the TOE conforms
+ its design and to provide a basis for analysis in other
+ areas of the evaluation (e.g., the search for
+ vulnerabilities). The implementation representation is
+ expected to be in a form that captures the detailed internal
+ workings of the TSF. This may be software source code,
+ firmware source code, hardware diagrams and/or IC hardware
+ design language code or layout data.
+
+
+
+ The implementation representation of the TOE is made
+ available so that it can be analysed by the evaluator to
+ demonstrate that the TOE conforms its design and to provide
+ a basis for analysis in other areas of the evaluation (e.g.,
+ the search for vulnerabilities). The implementation
+ representation captures the detailed internal workings of
+ the TSF. This may be software source code, firmware source
+ code, hardware diagrams and/or chip specifications.
+
+
+
+ The components in this family are levelled on the amount of
+ implementation that is mapped to the TOE design
+ description.
+
+
+
+ Source code or hardware diagrams and/or IC hardware design
+ language code or layout data that are used to build the
+ actual hardware are examples of parts of an implementation
+ representation. It is important to note that while the
+ implementation representation must be made available to the
+ evaluator, this does not imply that the evaluator needs to
+ possess that representation. For instance, the developer may
+ require that the evaluator review the implementation
+ representation at a site of the developer's choosing.
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due to
+ lack of information. This does not, however, imply that all
+ of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. The implementation representation is made
+ available to allow analysis of other TOE design
+ decompositions (e.g., functional specification, TOE design),
+ and to gain confidence that the security functionality
+ described at a higher level in the design actually appear to
+ be implemented in the TOE. Conventions in some forms of the
+ implementation representation may make it difficult or
+ impossible to determine from just the implementation
+ representation itself what the actual result of the
+ compilation or run-time interpretation will be. For example,
+ compiler directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code. For this reason, it is important that such ``extra''
+ information or related tools (scripts, compilers, etc.) be
+ provided so that the implementation representation can be
+ accurately determined.
+
+ The purpose of the mapping between the implementation
+ representation and the TOE design description is to aid the
+ evaluator's analysis. The internal workings of the TOE may
+ be better understood when the TOE design is analysed with
+ corresponding portions of the implementation representation.
+ The mapping serves as an index into the implementation
+ representation. At the lower component, only a subset of the
+ implementation representation is mapped to the TOE design
+ description. Because of the uncertainty of which portions of
+ the implementation representation will need such a mapping,
+ the developer may choose either to map the entire
+ implementation representation beforehand, or to wait to see
+ which portions of the implementation representation the
+ evaluator requires to be mapped.
+
+ The implementation representation is manipulated by the
+ developer in a form that is suitable for transformation to
+ the actual implementation. For instance, the developer may
+ work with files containing source code, which is eventually
+ compiled to become part of the TSF. The developer makes
+ available the implementation representation in the form used
+ by the developer, so that the evaluator may use automated
+ techniques in the analysis. This also increases the
+ confidence that the implementation representation examined
+ is actually the one used in the production of the TSF (as
+ opposed to the case where it is supplied in an alternate
+ presentation format, such as a word processor document). It
+ should be noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to supply
+ the evaluator with the information that will maximise the
+ effectiveness of the evaluator's analysis efforts.
+
+ Some forms of the implementation representation may require
+ additional information because they introduce significant
+ barriers to understanding and analysis. Examples include
+ ``shrouded'' source code or source code that has been
+ obfuscated in other ways such that it prevents understanding
+ and/or analysis. These forms of implementation
+ representation typically result from the TOE developer
+ taking a version of the implementation representation and
+ running a shrouding or obfuscation program on it. While the
+ shrouded representation is what is compiled and may be
+ closer to the implementation (in terms of structure) than
+ the original, un-shrouded representation, supplying such
+ obfuscated code may cause significantly more time to be
+ spent in analysis tasks involving the representation. When
+ such forms of representation are created, the components
+ require details on the shrouding tools/algorithms used so
+ that the un-shrouded representation can be supplied, and the
+ additional information can be used to gain confidence that
+ the shrouding process does not compromise any security
+ functionality.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer is suitable for use in other analysis
+ activities; suitability is judged by its
+ conformance to the requirements for this component.
+
+
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due
+ to lack of information. This does not, however, imply that
+ all of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. For this sub-activity, this is even
+ truer. It would not be productive for the evaluator to
+ spend large amounts of time verifying the requirements for
+ one portion of the implementation representation, and then
+ use a different portion of the implementation
+ representation in performing analysis for other work
+ units. Therefore, the evaluator is encouraged to select
+ the sample of the implementation representation from the
+ areas of the TOE that will be of most interest during the
+ analysis performed during work units from other families
+ (e.g. , and ).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the sample of the implementation
+ representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ sample of the implementation representation shall
+ demonstrate their correspondence.
+
+
+ The evaluator shall confirm that, for the selected sample of
+ the implementation representation, the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the implementation
+ representation defines the TSF to a level of detail such
+ that the TSF can be generated without further design
+ decisions.
+
+ Source code or hardware diagrams and/or IC hardware
+ design language code or layout data that are used to
+ build the actual hardware are examples of parts of an
+ implementation representation. The evaluator samples the
+ implementation representation to gain confidence that it
+ is at the appropriate level and not, for instance, a
+ pseudo-code level which requires additional design
+ decisions to be made. The evaluator is encouraged to
+ perform a quick check when first looking at the
+ implementation representation to assure themselves that
+ the developer is on the right track. However, the
+ evaluator is also encourage to perform the bulk of this
+ check while working on other work units that call for
+ examining the implementation; this will ensure the
+ sample examined for this work unit is relevant.
+
+
+
+
+ The evaluator shall check that the implementation
+ representation is in the form used by development
+ personnel.
+
+ The implementation representation is manipulated by the
+ developer in form that it suitable for transformation to
+ the actual implementation. For instance, the developer
+ may work with files containing source code, which is
+ eventually compiled to become part of the TSF. The
+ developer makes available the implementation
+ representation in the form they use, so that the
+ evaluator may use automated techniques in the
+ analysis. This also increases the confidence that the
+ implementation representation examined is actually the
+ one used in the production of the TSF (as opposed to the
+ case where it is supplied in an alternate presentation
+ format, such as a word processor document). It should be
+ noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to
+ supply the evaluator with the information that will
+ maximise the evaluator's analysis efforts.
+
+ The evaluator samples the implementation representation
+ to gain confidence that it is the version that is usable
+ by the developer. The sample is such that the evaluator
+ has assurance that all areas of the implementation
+ representation are in conformance with the requirement;
+ however, a complete examination of the entire
+ implementation representation is unnecessary.
+
+ Conventions in some forms of the implementation
+ representation may make it difficult or impossible to
+ determine from just the implementation representation
+ itself what the actual result of the compilation or
+ run-time interpretation will be. For example, compiler
+ directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code.
+
+ Some forms of the implementation representation may
+ require additional information because they introduce
+ significant barriers to understanding and
+ analysis. Examples include shrouded source code or
+ source code that has been obfuscated in other ways such
+ that it prevents understanding and/or analysis. These
+ forms of implementation representation typically result
+ from by taking a version of the implementation
+ representation that is used by the TOE developer and
+ running a shrouding or obfuscation program on it. While
+ the shrouded representation is what is compiled and may
+ be closer to the implementation (in terms of structure)
+ than the original, un-shrouded representation, supplying
+ such obfuscated code may cause significantly more time
+ to be spent in analysis tasks involving the
+ representation. When such forms of representation are
+ created, the components require details on the shrouding
+ tools/algorithms used so that the un-shrouded
+ representation can be supplied, and the additional
+ information can be used to gain confidence that the
+ shrouding process does not compromise any security
+ mechanisms.
+
+ The evaluator samples the implementation representation
+ to gain confidence that all of the information needed to
+ interpret the implementation representation has been
+ supplied. Note that the tools are among those referenced
+ by components. The
+ evaluator is encouraged to perform a quick check when
+ first looking at the implementation representation to
+ assure themselves that the developer is on the right
+ track. However, the evaluator is also encouraged to
+ perform the bulk of this check while working on other
+ work units that call for examining the implementation;
+ this will ensure the sample examined for this work unit
+ is relevant.
+
+
+
+
+ The evaluator shall examine the mapping between the TOE
+ design description and the sample of the implementation
+ representation to determine that it is accurate.
+
+ The evaluator augments the determination of existence
+ (specified in work unit ) by verifying the accuracy of a portion of
+ the implementation representation and the TOE design
+ description. For parts of the TOE design description
+ that are interesting, the evaluator would verify the
+ implementation representation accurately reflects the
+ description provided in the TOE design
+ description.
+
+ For example, the TOE design description might identify a
+ login module that is used to identify and authenticate
+ users. If user authentication is sufficiently
+ significant, the evaluator would verify that the
+ corresponding code in fact implements that service as
+ described in the TOE design description. It might also
+ be worthwhile to verify that the code accepts the
+ parameters as described in the functional
+ specification.
+
+ It is worth pointing out the developer must choose
+ whether to perform the mapping for the entire
+ implementation representation, thereby guaranteeing that
+ the chosen sample will be covered, or waiting for the
+ sample to be chosen before performing the mapping. The
+ first option is likely more work, but may be completed
+ before the evaluation begins. The second option is less
+ work, but will produce a suspension of evaluation
+ activity while the necessary evidence is being
+ produced.
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer can be transformed into the implementation that
+ is used in the testing activities.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the entire implementation representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ entire implementation representation shall demonstrate their
+ correspondence.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ This family addresses the assessment of the internal
+ structure of the TSF. A TSF whose internals are
+ well-structured is easier to implement and less likely to
+ contain flaws that could lead to vulnerabilities; it is also
+ easier to maintain without the introduction of flaws.
+
+
+
+ The internal structure of the TSF can aid or hamper
+ understandability of the implementation representation.
+ Source code that conforms to coding standards, that exhibit
+ a minimum of interactions, and that is written in modules
+ each with a single purpose, is much easier to understand
+ than poorly-structured code with unnecessary or
+ loosely-defined interactions.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of structure and minimisation of complexity
+ required. places
+ requirements for well-structured internals on only selected
+ parts of the TSF. This component is not included in an EAL
+ because this component is viewed for use in special
+ circumstances (e.g., the sponsor has a specific concern
+ regarding a cryptographic module, which is isolated from the
+ rest of the TSF) and would not be widely applicable.
+
+ At the next level, the requirements for well-structured
+ internals are placed on the entire TSF. Finally,
+ minimisation of complexity is introduced in the highest
+ component.
+
+
+
+ These requirements, when applied to the internal structure
+ of the TSF, typically result in improvements that aid both
+ the developer and the evaluator in understanding the TSF,
+ and also provide the basis for designing and evaluating test
+ suites. Further, improving understandability of the TSF
+ should assist the developer in simplifying its
+ maintainability.
+
+ The requirements in this family are presented at a fairly
+ abstract level. The wide variety of TOEs makes it impossible
+ to codify anything more specific than ``well-structured'' or
+ ``minimum complexity''. Judgements on structure and
+ complexity are expected to be derived from the specific
+ technologies used in the TOE. For example, software is
+ likely to be considered well-structured if it exhibits the
+ characteristics cited in the software engineering
+ disciplines. The components within this family call for
+ identifying the standards for measuring the characteristic
+ of being well-structured and not overly-complex.
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring specific portions of the TSF to be
+ well-structured. The intent is that the entire TSF has
+ been designed and implemented using sound engineering
+ principles, but the analysis is performed upon only a
+ specific subset.
+
+
+
+ This component requires the PP or ST author to fill in an
+ assignment with the subset of the TSF. This subset may be
+ identified in terms of the internals of the TSF at any
+ layer of abstraction. For example:
+
+ the structural elements of the TSF as identified
+ in the TOE design (e.g. ``The developer shall design
+ and implement the audit subsystem
+ such that it has well-structured internals.'')
+ the implementation (e.g. ``The developer shall
+ design and implement the encrypt.c and
+ decrypt.c files such that it has
+ well-structured internals.'' or ``The developer shall
+ design and implement the 6227 IC chip
+ such that it has well-structured
+ internals.'')
+
+ It is likely this would not be readily accomplished by
+ referencing the claimed SFRs (e.g. ``The developer shall
+ design and implement the portion of the TSF that
+ provide anonymity as defined in
+ such that it has well-structured
+ internals.'') because this does not indicate where to
+ focus the analysis.
+
+ This component has limited value and would be suitable in cases
+ where potentially-malicious users/subjects have limited or
+ strictly controlled access to the TSFIs or where there is
+ another means of protection (e.g., domain separation) that
+ ensures the chosen subset of the TSF cannot be adversely
+ affected by the rest of the TSF (e.g., the cryptographic
+ functionality, which is isolated from the rest of the TSF, is
+ well-structured).
+
+
+
+ The objective of this sub-activity is to determine whether
+ the defined subset of the TSF is designed and structured
+ such that the likelihood of flaws is reduced and that
+ maintenance can be more readily performed without the
+ introduction of flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The use of the assignment in this component levies stricter
+ constraints on the subset of the TSF that is explicitly
+ identified in the assignment
+ than on the remainder of the TSF.
+ While the entire TSF is to be designed using good
+ engineering principles and result in a well-structured TSF, only
+ the specified subset is specifically analysed for this
+ characteristic. The evaluator determines that the developer's
+ application of coding standards result in a TSF that is
+ understandable.
+
+ The primary goal of this component is to ensure the TSF
+ subset's implementation representation is understandable
+ to facilitate maintenance and analysis (of both the
+ developer and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance);
+
+
+ the architectural description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement subset
+ of the TSF such that it has well-structured
+ internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall explain the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ assigned subset of the TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF subset:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ subset
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the TSF
+ subset
+
+ For other types of technologies used in the TOE - such as
+ non-procedural software (e.g. object-oriented programming),
+ widespread commodity hardware (e.g. PC microprocessors), and
+ special-purpose hardware (e.g. smart-card processors) - the
+ evaluator should seek guidance from the evaluation authority for
+ determining the adequacy of criteria for being
+ ``well-structured''.
+
+
+
+ The evaluator shall check the TSF internals
+ description to determine that it identifies the Assigned
+ subset of the TSF.
+
+ This subset may be identified in terms of the internals
+ of the TSF at any layer of abstraction. For example, it
+ may be in terms of the structural elements of the TSF as
+ identified in the TOE design (e.g. the audit subsystem),
+ or in terms of the implementation
+ (e.g. encrypt.c and
+ decrypt.c files, or the 6227 IC
+ chip).
+
+ It is insufficient to identify this subset in terms of
+ the claimed SFRs (e.g. the portion of the TSF that
+ provide anonymity as defined in ) because this does not indicate where to
+ focus the analysis.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ assigned TSF subset is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF subset meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF subset meets the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF subset and
+ the modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ assigned subset of the TSF.
+
+
+ The evaluator shall determine that the TOE design for
+ the assigned TSF subset is well-structured.
+
+ The evaluator examines a sample of the TOE design to
+ verify the accuracy of the justification. For example, a
+ sample of the TOE design is analysed to determine its
+ adherence to the design standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the assigned TSF
+ subset is well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF subset to
+ verify the accuracy of the internals description. For
+ example, a sample of the procedural software portions of
+ the TSF subset is analysed to determine its cohesion and
+ coupling, its adherence to the coding standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured. The intent is
+ that the entire TSF has been designed and implemented
+ using sound engineering principles.
+
+
+
+ Judgements on the adequacy of the structure are expected to
+ be derived from the specific technologies used in the TOE.
+ This component calls for identifying the standards for
+ measuring the characteristic of being
+ well-structured.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is designed and structured such that the
+ likelihood of flaws is reduced and that maintenance can be
+ more readily performed without the introduction of
+ flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The primary goal of this component is to ensure the TSF's
+ implementation representation is understandable to
+ facilitate maintenance and analysis (of both the developer
+ and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance));
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall describe the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the
+ TSF
+
+ For other types of technologies used in the TOE - such
+ as non-procedural software (e.g. object-oriented
+ programming), widespread commodity hardware (e.g. PC
+ microprocessors), and special-purpose hardware
+ (e.g. smart-card processors) - the evaluation authority
+ should be consulted for determining the adequacy of
+ criteria for being ``well-structured''.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ TSF is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF meet the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF and the
+ modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ TSF.
+
+
+ The evaluator shall determine that the TOE design is
+ well-structured.
+
+ The evaluator examines the TOE design of a sample of the
+ TSF to verify the accuracy of the justification. For
+ example, a sample of the TOE design is analysed to
+ determine its adherence to the design standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the TSF is
+ well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF to verify the
+ accuracy of the internals description. For example, a
+ sample of the procedural software portions of the TSF is
+ analysed to determine its cohesion and coupling, its
+ adherence to the coding standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured and of minimal
+ complexity. The intent is that the entire TSF has been
+ designed and implemented using sound engineering
+ principles.
+
+
+
+ Judgements on the adequacy of the structure and complexity
+ are expected to be derived from the specific technologies
+ used in the TOE. This component calls for identifying the
+ standards for measuring the structure and
+ complexity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall describe the characteristics used to
+ judge the meaning of ``well-structured'' and ``complex''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured and is not overly complex.
+
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform an internals analysis on the
+ entire TSF.
+
+
+
+
+
+
+ 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.
+
+
+
+ A formal security model precisely describes important
+ aspects of security and their relationship to the behaviour
+ of the TSF. Formalism helps to prove mathematically the
+ thoroughness of the security.
+
+
+
+ This family contains only one component.
+
+
+
+ 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.
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+ 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.
+
+ 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. contains an assignment for identifying these
+ policies that are formally modelled.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the formal TOE security policy model clearly and
+ consistently describes the rules of operation, states,
+ transition, invariants, and other security properties of
+ the claimed SFRs and whether this description corresponds
+ with the description of the security functionality in the
+ functional specification.
+
+
+
+ This activity applies to cases where the developer has
+ formally modelled all security policies of the TOE that
+ are capable of being modelled formally.
+
+ A formal TOE security policy model is a representation of
+ the rules (synonymously termed ``principles'') and
+ characteristics of security policies in mathematical
+ terms. Their formal counterparts are called security
+ properties and security features, respectively. The
+ representation includes but is not limited to algebraic
+ specifications, finite state machines and logic formalisms
+ strong enough to formally infer the properties from the
+ features. The formal security policy model is accompanied
+ by an informal interpretation explaining how the rules and
+ characteristics are mapped to the respective properties
+ and features.
+
+ It is recognised that not all policies (see work unit
+ ) can be formally
+ modelled for all TOEs. This is because either the state of
+ the art is insufficient to formally model a given policy,
+ or because the nature of the TOE renders impossible the
+ modelling of policies that would otherwise be possible to
+ model. If none of the SFRs can be formally modelled, this
+ component cannot be met.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a formal security policy model for
+ the list of policies that are formally
+ modelled.
+
+ 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.
+
+
+ The developer shall provide a formal proof of correspondence
+ between the model and any formal functional specification.
+
+
+ The developer shall provide a demonstration of
+ correspondence between the model and the functional
+ specification.
+
+
+ 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.
+
+
+ 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.
+
+
+ The correspondence between the model and the functional
+ specification shall be at the correct level of formality.
+
+
+ The correspondence shall show that the functional
+ specification is consistent and complete with respect to the
+ model.
+
+
+ The demonstration of correspondence shall show that the
+ interfaces in the functional specification are consistent
+ and complete with respect to the policies in the assignment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it is written in a formal
+ style.
+
+ The evaluator identifies the formal framework upon which
+ the TOE security policy model is based and ensures that
+ it is founded on well established mathematical concepts,
+ and identifies the security properties and features
+ addressed in the application notes and ensures the
+ formalisation of at least one security policy. If no
+ policy is formally modelled, this component cannot be
+ successfully claimed.
+
+ For additional guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all necessary
+ informal explanatory text.
+
+ Supporting narrative descriptions are necessary for all
+ parts of the model (for example, to make clear the
+ meaning of any formal notation and how they are used)
+ including the security properties and features.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all policies that
+ can be formally modelled.
+
+ It is recognised that not all policies can be formally
+ modelled for all TOEs. This is because either the state
+ of the art is insufficient to formally model a given
+ policy, or because the nature of the TOE renders
+ impossible the modelling of policies that would
+ otherwise be possible to model.
+
+ While access control, information flow control, and data
+ integrity policies have all been formally modelled
+ successfully, the possibility of modelling other
+ policies is based on a case by case decision. Abstention
+ from formally modelling security relevant policies
+ requires argumentation and rests the burden of proof
+ entirely on the developer's side.
+
+ For any security policy where formal models are not
+ possible, the policy must be identified in the
+ assignment of .
+
+
+
+
+ The evaluator shall examine the model to determine that
+ the security behaviour of the TOE is clearly
+ articulated.
+
+ The security policy model's properties describe the
+ TOE's behaviour in enforcing the principles of the
+ policy. For example, a policy that is modelled on the
+ basis of state transitions would include principles of
+ its states, identify its initial state, and define what
+ it means to be a secure state.
+
+ The security policy model's features describe the
+ attributes and conditions of the TOE that come into
+ consideration when enforcing its policy's
+ characteristics. For example, a policy that is modelled
+ on the basis of state transitions would describe the
+ necessary conditions to transform the TOE from one state
+ to the next.
+
+ An informal interpretation of all formal concepts
+ (including attributes, predicates and variables, if
+ available) must also be provided in order to make clear
+ their intended meaning.
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the formal functional
+ specification to determine that it is presented in a
+ formal style.
+
+ If no part of the functional specification is formal,
+ this work unit is not applicable and is therefore
+ considered to be satisfied. The corresponding work will
+ be performed under work unit .
+
+ For any part of the functional specification that is
+ formally presented, the correspondence between that part
+ of the functional specification and the security policy
+ model must be formal. Analysis of the content is
+ performed as part of work units through .
+
+ For guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the semiformal functional
+ specification to determine that it is presented in a
+ semiformal style.
+
+ If the entire functional specification is formal, this
+ work unit is not applicable and is therefore considered
+ to be satisfied. The corresponding work will be
+ performed under work unit .
+
+ For formally-modelled policies whose corresponding
+ description in the functional specification is not
+ formally presented, the correspondence between the model
+ and the functional specification must be a semiformal
+ demonstration. Analysis of the content is performed as
+ part of work units
+ through .
+
+ If a security policy model exists, either this work unit
+ or the previous work unit (or both) will be
+ applicable.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it formally proves the
+ correspondence between the security properties and the
+ security features.
+
+ The proof shall show that the security features enforce
+ the security properties. To determine the enforcement,
+ the evaluator considers the security properties and the
+ security features and verifies that the arguments used
+ in the proof are valid. The proof of correspondence
+ between the security properties and the security
+ features shall be formal.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it proves the internal
+ consistency of the TOE security policy model.
+
+ The proof shall show the absence of contradictions
+ within the TOE security policy model. In determining the
+ absence of contradictions, the evaluator verifies that
+ the arguments used in the proof are valid.
+
+ Since the TOE security policy model is formal, the proof
+ of its internal consistency shall be formal. It is
+ recognised that a complete formal proof of the internal
+ consistency of the TOE security policy model usually is
+ not possible due to the fundamental nature of formal
+ frameworks. Generally, it is sufficient to generate
+ evidence using formal proofs based on the specific TOE
+ security policy model that prove the internal
+ consistency by means of a combination with generic
+ arguments of the formal framework.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is consistent with respect to policies described by the
+ security policies (as articulated by the functional
+ requirements in the ST).
+
+ The examination considers the informal relationships of
+ the model. Hence the meaning of consistency reflects
+ the conventional understanding in contrast to the
+ internal consistency concept of the previous work
+ unit.
+
+ In determining consistency, the evaluator verifies that
+ the rationale shows that each description of properties
+ and features in the security policy model accurately
+ reflects the intent of the security policies. For
+ example, if a policy stated that access control was
+ necessary to the granularity of a single individual,
+ then a security policy model describing the security
+ behaviour of a TOE in the context of controlling groups
+ of users would not be consistent. Likewise, if the
+ policy stated that access control for groups of users
+ was necessary, then a security policy model describing
+ the security behaviour of a TOE in the context of
+ controlling individual users would also not be
+ consistent.
+
+ The evaluator also examines whether the security
+ policies are reflected within their formal counterparts
+ of the security policy model.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is complete with respect to the policies described by
+ the security policies (i.e. as articulated by the
+ functional requirements in the ST).
+
+ In determining completeness of this rationale, the
+ evaluator considers the properties and features of the
+ security policy model and maps those properties and
+ features to explicit policy statements (i.e. functional
+ requirements). The rationale should show that all
+ policies that are required to be modelled have an
+ associated property or feature description in the TOE
+ security policy model.
+
+ Abstention from formally modelling policy statements
+ always calls for justification on the developer's side
+ (also confer the application notes above).
+
+
+
+
+ The evaluator shall examine the demonstration of
+ correspondence to determine that all Assigned policies
+ are mapped to functions within the functional
+ specification.
+
+ If all policies are included within the security policy
+ model (i.e. they are all formally modelled) and the
+ assignment in is
+ therefore empty, this work unit is not applicable and is
+ therefore considered to be satisfied.
+
+ The evaluator verifies that the correspondence
+ demonstrates that the descriptions of the SFR-related
+ functions in the functional specification correspond to
+ the SFRs. This may be done as part of the work units addressing
+ correspondence to the SFRs. However, if the developer
+ provides a well-structured semiformal or informal
+ security policy model to better articulate the notions
+ of security enforced by the TOE, the evaluator will
+ verify that such a model is consistent with the
+ SFRs.
+
+
+
+
+
+
+
+ The design description of a TOE provides both context for a
+ description of the TSF, and a thorough description of the
+ TSF. As assurance needs increase, the level of detail
+ provided in the description also increases. As the size and
+ complexity of the TSF increase, multiple levels of
+ decomposition are appropriate. The design requirements are
+ intended to provide information (commensurate with the given
+ assurance level) so that a determination can be made that
+ the security functional requirements are realised.
+
+
+
+ The design description provides a further-refined
+ description of the TSF from that presented in the functional
+ specification. The functional specification provides a
+ description of what the TSF does at its
+ interface; the design description provides more insight into
+ the TSF by describing how the TSF works in
+ order to perform the functions supporting the SFRs. At lower
+ assurance levels, complete details relating to all portions
+ of the TSF are not required. As the desired assurance
+ increases, more detail is made available so that analysis
+ can be performed that supports the assurance claims being
+ made.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of information that is required to be presented
+ with respect to the TSF, and on the degree of formalism
+ required of the design description.
+
+
+
+ The goal of design documentation is to provide sufficient
+ information to determine the TSF boundary, and to describe
+ how the TSF implements the Security
+ Functional Requirements. The amount and structure of the
+ design documentation will depend on the complexity of the
+ TOE and the number of SFRs; in general, a very complex TOE
+ with a large number of SFRs will require more design
+ documentation than a very simple TOE implementing only a few
+ SFRs. Very complex TOEs will benefit (in terms of the
+ assurance provided) from the production of differing levels
+ of decomposition in describing the design, while very simple
+ TOEs do not require both high-level and low-level
+ descriptions of its implementation.
+
+ This family uses two levels of decomposition: the
+ subsystem and the module.
+ A module is the most specific description of functionality:
+ it is a description of the implementation. A developer
+ should be able to implement the part of the TOE described by
+ the module with no further design decisions. A subsystem is
+ a description of the design of the TOE; it helps to provide
+ a high-level description of what a portion of the TOE is
+ doing and how. As such, a subsystem may be further divided
+ into lower-level subsystems, or into modules. Very complex
+ TOEs might require several levels of subsystems in order to
+ adequately convey a useful description of how the TOE works.
+ Very simple TOEs, in contrast, might not require a subsystem
+ level of description; the module might clearly describe how
+ the TOE works.
+
+ The general approach adopted for design documentation is
+ that, as the level of assurance increases, the emphasis of
+ description shifts from the general (subsystem level) to
+ more (module level) detail. In cases where a module-level
+ of abstraction is appropriate because the TOE is simple
+ enough to be described at the module level, yet the level of
+ assurance calls for a subsystem level of description, the
+ module-level description alone will suffice. For complex
+ TOEs, however, this is not the case: an enormous amount of
+ (module-level) detail would be incomprehensible without an
+ accompanying subsystem level of description.
+
+ This approach follows the general paradigm that providing
+ additional detail about the implementation of the TSF will
+ result in greater assurance that the SFRs are implemented
+ correctly, and provide information that can be used to
+ demonstrate this in testing ().
+
+ In the requirements for this family, the term
+ interface is used as the means of
+ communication (between two subsystems or modules). It
+ describes how the communication is invoked; this is similar
+ to the details of TSFI (see ). The term interaction is
+ used to identify the purpose for communication; it
+ identifies why two subsystems or modules are
+ communicating.
+
+
+ The requirements define collections of details about
+ subsystems and modules to be provided:
+
+ The subsystems and modules are
+ identified with a simple list of what
+ they are.
+
+ Subsystems and modules may be categorised
+ (either implicitly or explicitly) as ``SFR-enforcing'',
+ ``SFR-supporting'', or ``SFR-non-interfering''; these terms are
+ used the same as they are used in .
+
+ A subsystem's behaviour is what it does. The
+ behaviour may also be categorised as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering. The behaviour of the
+ subsystem is never categorised as more SFR-relevant than the
+ category of the subsystem itself. For example, an SFR-enforcing
+ subsystem can have SFR-enforcing behaviour as well as
+ SFR-supporting or SFR-non-interfering behaviour.
+ A behaviour summary of a
+ subsystem is an overview of the actions it performs
+ (e.g. ``The TCP subsystem assembles IP datagrams into
+ reliable byte streams'').
+ A behaviour description of a
+ subsystem is an explanation of everything it
+ does. This description should be at a level of detail
+ that one can readily determine whether the behaviour
+ has any relevance to the enforcement of the
+ SFRs.
+
+ A description of interactions among or between
+ subsystems or modules identifies the reason that subsystems or
+ modules communicate, and characterises the information that is
+ passed. It need not define the information to the same level of
+ detail as an interface specification. For example, it would be
+ sufficient to say ``subsystem X requests a block of memory from
+ the memory manager, which responds with the location of the
+ allocated memory.
+ A description of interfaces provides the
+ details of how the interactions among modules are achieved.
+ Rather than describing the reason the modules are communicating
+ or the purpose of their communication (that is, the description
+ of interactions), the description of interfaces describes the
+ details of how that communication is accomplished, in terms of
+ the structure and contents of the messages, semaphores, internal
+ process communications, etc.
+
+
+ The purpose describes how a module provides
+ their functionality. It provides sufficient detail that no
+ further design decisions are needed. The correspondence between
+ the implementation representation that implements the module,
+ and the purpose of the module should be readily apparent.
+ A module is otherwise described
+ in terms of whatever is identified in the
+ element. Subsystems and modules, and
+ ``SFR-enforcing'', etc. are all further explained in
+ greater detail in .
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each
+ SFR-supporting or SFR-non-interfering TSF subsystem in
+ sufficient detail to determine that it is not SFR-enforcing.
+
+
+ The design shall summarise the SFR-enforcing behaviour of
+ the SFR-enforcing subsystems.
+
+
+ The design shall provide a description of the interactions
+ among SFR-enforcing subsystems of the TSF, and between the
+ SFR-enforcing subsystems of the TSF and other subsystems of
+ the TSF.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-supporting or SFR-non-interfering subsystem of the TSF
+ is described such that the evaluator can determine that the
+ subsystem is SFR-supporting or SFR-non-interfering.
+
+ SFR-supporting and SFR-non-interfering subsystems do not need to
+ be described in detail as to how they function in the system.
+ However, the evaluator makes a determination, based on the
+ evidence provided by the developer, that the subsystems that do
+ not have high-level descriptions are SFR-supporting or
+ SFR-non-interfering. Note that if the developer provides a
+ uniform level of detailed documentation then this work unit will
+ be largely satisfied, since the point of categorising the
+ subsystems is to allow the developer to provide less information
+ for SFR-supporting and SFR-non-interfering subsystems than for
+ SFR-enforcing subsystems.
+
+ An SFR-supporting subsystem is one that is depended on
+ by an SFR-enforcing subsystem in order to implement an
+ SFR, but does not play as direct a role as an
+ SFR-enforcing subsystem. An SFR-non-interfering
+ subsystem is one that is not depended upon, in either a
+ supporting or enforcing role, to implement an
+ SFR.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and high-level
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. A high-level description need not refer to
+ specific data structures (although it may), but instead
+ talks about more general data flow, message flow, and
+ control relationships within a subsystem. The goal of
+ these descriptions is to give the evaluator enough
+ information to understand how the
+ SFR-enforcing behaviour is achieved. Note that the
+ evaluator should find unacceptable asserts of
+ SFR-enforcement in the TOE design documentation for this
+ work unit. It should be noted that it is the
+ evaluator's determination with respect to what
+ ``high-level'' means for a particular TOE, and the
+ evaluator obtains enough information from the developer
+ to make a sound verdict for this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work
+ unit
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the
+ SFR-enforcing subsystems and other subsystems is to help provide
+ the reader a better understanding of how the TSF performs it
+ functions. These interactions do not need to be characterised at
+ the implementation level (e.g., parameters passed from one
+ routine in a subsystem to a routine in a different subsystem;
+ global variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem), but the
+ data elements identified for a particular subsystem that are
+ going to be used by another subsystem need to be covered in this
+ discussion. Any control relationships between subsystems (e.g.,
+ a subsystem responsible for configuring a rule base for a
+ firewall system and the subsystem that actually implements these
+ rules) should also be described.
+
+ The evaluators need to use their own judgement in assessing the
+ completeness of the description. If the reason for an
+ interaction is unclear, or if there are SFR-related interactions
+ (discovered, for instance, in examining the descriptions of
+ subsystem behaviour) that do not appear to be described, the
+ evaluator ensures that this information is provided by the
+ developer. However, if the evaluator can determine that
+ interactions among a particular set of subsystems, while
+ incompletely described by the developer, will not aid in
+ understanding the overall functionality nor security
+ functionality provided by the TSF, then the evaluator may choose
+ to consider the description sufficient, and not pursue
+ completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each SFR
+ non-interfering subsystem of the TSF in detail sufficient to
+ determine that it is SFR non-interfering.
+
+
+ The design shall describe the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+
+ The design shall summarise the SFR-supporting and
+ SFR-non-interfering behaviour of the SFR-enforcing subsystems.
+
+
+ The design shall summarise the behaviour of the
+ SFR-supporting subsystems.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each SFR-non-interfering subsystem of the TSF is
+ described such that the evaluator can determine that the
+ subsystem is SFR-non-interfering.
+
+ SFR-non-interfering subsystems do not need to be
+ described in detail as to how they function in the
+ system. However, the evaluator makes a determination,
+ based on the evidence provided by the developer, that
+ the subsystems that do not have detailed descriptions
+ are SFR-non-interfering. Note that if the developer
+ provides a uniform level of detailed documentation then
+ this work unit will be largely satisfied, since the
+ point of categorising the subsystems is to allow the
+ developer to provide less information for
+ SFR-non-interfering subsystems than for SFR-enforcing
+ and SFR-supporting subsystems.
+
+ An SFR-non-interfering subsystem is one on which the
+ SFR-enforcing and SFR-supporting subsystems have no
+ dependence; that is, they play no role in implementing
+ SFR functionality.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and detailed
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. While not at the level of an algorithmic
+ description, a detailed description of behaviour
+ typically discusses how the functionality is provided in
+ terms of what key data and data structures are, what
+ control relationships exist within a subsystem, and how
+ these elements work together to provide the
+ SFR-enforcing behaviour. Such a description also
+ references SFR-supporting behaviour, which the evaluator
+ should consider in performing subsequent work
+ units.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work
+ unit
+
+
+
+
+ The evaluator shall examine the TOE design to determine that it
+ provides a complete and accurate high-level description of the
+ SFR-supporting and SFR-non-interfering behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous work unit, this work unit calls for
+ the evaluator to assess the information provided for
+ SFR-enforcing subsystems that is SFR-supporting or
+ SFR-non-interfering. The goal of this assessment is two-fold.
+ First, it should provide the evaluator greater understanding of
+ the way each subsystem works. Second, the evaluator determines
+ that all SFR-enforcing behaviour exhibited by a subsystem has
+ been described. Unlike the previous work unit, the information
+ provided for the SFR-supporting or SFR-non-interfering behaviour
+ does not have to be as detailed as that provided by the
+ SFR-enforcing behaviour. For example, data structures or data
+ items that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all. It is the
+ evaluator's determination, however, with respect to what
+ ``high-level'' means for a particular TOE, and the evaluator
+ obtains enough information from the developer (even if it turns
+ out to be equivalent to information provided for the parts of
+ the subsystem that are SFR-enforcing) to make a sound verdict
+ for this work unit.
+
+ The evaluator is cautioned, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator examines
+ other information available (e.g., functional specification,
+ security architecture description, implementation
+ representation). Descriptions of functionality in these
+ documents should be consistent with what is provided for
+ evidence for this work unit. In particular, the functional
+ specification should be used to determine that the behaviour
+ required to implement the TSF Interfaces described by the
+ functional specification are completely described by the
+ subsystem, since the behaviour will either be SFR-enforcing,
+ SFR-supporting or SFR-non-interfering.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete and accurate high-level
+ description of the behaviour of the SFR-supporting
+ subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous two work units, this work
+ unit calls for the developer to provide (and the
+ evaluator to assess) information about SFR supporting
+ subsystems. Such subsystems should be referenced by the
+ descriptions of the SFR-enforcing subsystems, as well as
+ by the descriptions of interactions in work unit . The goal of evaluator's
+ assessment, like that for the previous work unit, is
+ two-fold. First, it should provide the evaluator with
+ an understanding of the way each SFR-supporting
+ subsystem works. Second, the evaluator determines that
+ the behaviour is described in enough detail so that the
+ way in which the subsystem supports the SFR-enforcing
+ behaviour is clear, and that the behaviour is not itself
+ SFR-enforcing. The information provided for
+ SFR-supporting subsystem's behaviour does not have to be
+ as detailed as that provided by the SFR-enforcing
+ behaviour. For example, data structures or data items
+ that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all.
+ It is the evaluator's determination, however, with
+ respect to what ``high-level'' means for a particular
+ TOE, and the evaluator obtains enough information from
+ the developer (even if it turns out to be equivalent to
+ information provided for the parts of the subsystem that
+ are SFR-enforcing) to make a sound verdict for this work
+ unit.
+
+ The evaluator is cautions, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work unit.
+ In particular, the functional specification should be
+ used to determine that the behaviour required to
+ implement the TSF Interfaces described by the functional
+ specification are completely described by the
+ subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs it functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem need to
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be
+ described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the descriptions of subsystem behaviour) that do not
+ appear to be described, the evaluator ensures that this
+ information is provided by the developer. However, if the
+ evaluator can determine that interactions among a particular set
+ of subsystems, while incompletely described by the developer,
+ will not aid in understanding the overall functionality nor
+ security functionality provided by the TSF, then the evaluator
+ may choose to consider the description sufficient, and not
+ pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing
+ modules and enough information about the SFR-supporting
+ and SFR-non-interfering modules for the evaluator to
+ determine that the SFRs are completely and accurately
+ implemented; as such, the TOE design provides an
+ explanation of the implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the evaluator
+ determines that the TSF boundary has been adequately
+ described. Second, the evaluator determines that the developer
+ has provided documentation that conforms to the content and
+ presentation requirements for this subsystem, and that is
+ consistent with other documentation provided for the
+ TOE. Finally, the evaluator must analyse the design information
+ provided for the SFR-enforcing modules (at a detailed level) and
+ the SFR-supporting and SFR-non-interfering modules (at a less detailed level) to
+ understand how the system is implemented, and with that
+ knowledge ensure that the TSFI in the functional specification
+ are adequately described, and that the test information
+ adequately tests the TSF (done in the work units).
+
+ It is important to note that while the developer is obligated to
+ provide a complete description of the TSF (although
+ SFR-enforcing modules will have more detail than the
+ SFR-supporting or SFR-non-interfering modules), the evaluator is
+ expected to use their judgement in performing their
+ analysis. While the evaluator is expected to look at every
+ module, the detail to which they examine each module may
+ vary. The evaluator analyses each module in order to gain enough
+ understanding to determine the effect of the functionality of
+ the module on the security of the system, and the depth to which
+ they need to analyse the module may vary depending on the
+ module's role in the system. An important aspect of this
+ analysis is that the evaluator should use the other
+ documentation provided (TSS, functional specification, security
+ architecture description, and the TSF internal document) in
+ order to determine that the functionality that is described is
+ correct, and that the implicit designation of SFR-supporting or
+ SFR-non-interfering modules (see below) is supported by their
+ role in the system architecture.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a description of each subsystem of
+ the TSF.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing module in terms of
+ its purpose and interaction with other modules.
+
+
+ The design shall describe each SFR-enforcing module in terms
+ of its SFR-related interfaces, return values from those
+ interfaces, interaction with and called interfaces to other modules.
+
+
+ The design shall describe each SFR-supporting or
+ SFR-non-interfering module in terms of its purpose and
+ interaction with other modules.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules). Depending upon the
+ complexity of the TOE, its design may be described in terms of
+ subsystems and modules, as described in CC Part 3 . For a very simple TOE that can be
+ described solely at the ``module'' level (see ), this work unit is not
+ applicable and therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ security architecture description) in making this
+ determination. For example, if the
+ functional specification contains interfaces to
+ functionality that does not appear to be described in
+ the TOE design description, it may be the case that a
+ portion of the TSF has not been included
+ appropriately. Making this determination will likely be
+ an iterative process, where as more analysis is done on
+ the other evidence, more confidence can be gained with
+ respect to the completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation
+ in a level of detail that can serve as a guide to
+ reviewing the implementation representation. A
+ description of a module should be such that one could
+ create an implementation of the module from the
+ description, and the resulting implementation would be
+ 1) identical to the actual TSF implementation in terms
+ of the interfaces presented and used by the module, and
+ 2) algorithmically identical to the TSF module. For
+ instance, RFC 793 provides a high-level description of
+ the TCP protocol. It is necessarily implementation
+ independent. While it provides a wealth of detail, it is
+
+ not a suitable design
+ description because it is not specific to an
+ implementation. An actual implementation can add to the
+ protocol specified in the RFC, and implementation
+ choices (for instance, the use of global data vs. local
+ data in various parts of the implementation) may have an
+ impact on the analysis that is performed. The design
+ description of the TCP module would list the interfaces
+ presented by the implementation (rather than just those
+ defined in RFC 793), as well as an algorithm description
+ of the processing associated with the modules
+ implementing TCP (assuming it was part of the
+ TSF).
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a subsystem-level
+ description of the TSF in addition to the modular description,
+ the goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs its functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem should
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the module-level documentation) that do not appear to
+ be described, the evaluator ensures that this information is
+ provided by the developer. However, if the evaluator can
+ determine that interactions among a particular set of
+ subsystems, while incompletely described by the developer, and a
+ complete description will not aid in understanding the overall
+ functionality nor security functionality provided by the TSF,
+ then the evaluator may choose to consider the description
+ sufficient, and not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing module is complete and accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for component. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing module contain an accurate and complete
+ description of the SFR-related parameters, the
+ invocation conventions for each interface, and any
+ values returned directly by the interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are fixed)
+ need not be specified or described, since they are not a factor in testing.
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of SFR-related
+ parameters, and descriptions of these parameters. Note
+ that global data would also be considered parameters if
+ used by the module (either as inputs or outputs) when
+ invoked. If a parameter were expected to take on a set
+ of values (e.g., a ``flag'' parameter), the complete set
+ of values the parameter could take on that would have an
+ effect on module processing would be
+ specified. Likewise, parameters representing data
+ structures are described such that each field of the
+ data structure is identified and described. Note that
+ different programming languages may have additional
+ ``interfaces'' that would be non-obvious; an example
+ would be operator/function overloading in C++. This
+ ``implicit interface'' in the class description would
+ also be described as part of the low-level TOE
+ design. Note that although a module could present only
+ one interface, it is more common that a module presents
+ a small set of related interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TOE design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the TSF internals, or the security architecture
+ description. However, the evaluator uses the information present
+ in those documents to the extent possible to help ensure that
+ the purpose is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that
+ SFR-supporting and SFR-non-interfering modules are correctly
+ categorised.
+
+ In the cases where the developer has provided different amounts
+ of information for different modules, an implicit categorisation
+ has been done. That is, modules (for instance) with detail
+ presented on their SFR-related interfaces (see ) are candidate SFR-enforcing
+ modules, although examination by the evaluator may lead to a
+ determination that some set of them are SFR-supporting or
+ SFR-non-interfering. Those with only a description of their
+ purpose and interaction with other modules (for instance) are
+ ``implicitly categorised'' as SFR-supporting or
+ SFR-non-interfering.
+
+ In these cases, a key focus of the evaluator for this work unit
+ is attempting to determine from the evidence provided for each
+ module implicitly categorised as SFR-supporting or
+ SFR-non-interfering and the evaluation information about other
+ modules (in the TOE design, the functional specification, the
+ security architecture description, and the operational user
+ guidance), whether the module is indeed SFR-supporting or
+ SFR-non-interfering. At this level of assurance some error
+ should be tolerated; the evaluator does not have to be
+ absolutely sure that a given module is SFR-supporting or
+ SFR-non-interfering, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ SFR-supporting or SFR-non-interfering module is SFR-enforcing,
+ the evaluator requests additional information from the developer
+ in order to resolve the apparent inconsistency. For instance,
+ suppose the documentation for Module A (an SFR-enforcing module)
+ indicates that it calls Module B to perform an access check on a
+ certain type of construct. When the evaluator examines the
+ information associated with Module B, they find that all the
+ developer has provided is a purpose and a set of interactions
+ (thus implicitly categorising Module B as SFR-supporting or
+ SFR-non-interfering). On examining the purpose and interactions
+ from Module A, the evaluator finds no mention of Module B
+ performing any access checks, and Module A is not listed as a
+ module with which Module B interacts. At this point the
+ evaluator should approach the developer to resolve the
+ discrepancies between the information provided in Module A and
+ that in Module B.
+
+ Another example would be where the evaluator examines the
+ mapping of the TSFI to the modules as provided by . This examination shows that
+ Module C is associated with an SFR requiring identification of
+ the user. Again, when the evaluator examines the information
+ associated with Module C, they find that all the developer has
+ provided is a purpose and a set of interactions (thus implicitly
+ categorising Module C as SFR-supporting or
+ SFR-non-interfering). Examining the purpose and interactions
+ presented for Module C, the evaluator is unable to determine why
+ Module C, listed as mapping to a TSFI concerned with user
+ identification, would not be classified as SFR-enforcing. Again,
+ the evaluator should approach the developer to resolve this
+ discrepancy.
+
+
+ A final example is from the opposite point of view. As
+ before, the developer has provided information associated
+ with Module D consisting of a purpose and a set of
+ interactions (thus implicitly categorising Module D as
+ SFR-supporting or SFR-non-interfering). The evaluator
+ examines all of the evidence provided, including the purpose
+ and interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the TOE,
+ the interactions are consistent with that description, and
+ there is nothing to indicate that Module D is
+ SFR-enforcing. In this case, the evaluator should not demand
+ more information about Module D ``just be to sure'' it is
+ correctly categorised. The developer has met their
+ obligations and the resulting assurance the evaluator has in
+ the implicit categorisation of Module D is (by definition)
+ appropriate for this assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that the
+ description of the purpose of each SFR-supporting or
+ SFR-non-interfering module is complete and accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ In these cases, a key focus of the evaluator for this work unit
+ is attempting to determine from the evidence provided for each
+ module implicitly categorised as SFR-supporting or SFR-non-interfering and the
+ evaluation information about other modules (in the TOE design,
+ the functional specification, the security architecture
+ description, and the operational user guidance), whether the
+ module is indeed SFR-supporting or SFR-non-interfering. At this level of assurance
+ some error should be tolerated; the evaluator does not have to
+ be absolutely sure that a given module is SFR-supporting or SFR-non-interfering,
+ even though it is labelled as such. However, if the evidence
+ provided indicates that a SFR-supporting or SFR-non-interfering module is
+ SFR-enforcing, the evaluator requests additional information
+ from the developer in order to resolve the apparent
+ inconsistency. For instance, suppose the documentation for
+ Module A (an SFR-enforcing module) indicates that it calls
+ Module B to perform an access check on a certain type of
+ construct. When the evaluator examines the information
+ associated with Module B, they find that all the developer has
+ provided is a purpose and a set of interactions (thus implicitly
+ categorising Module B as SFR-supporting or SFR-non-interfering). On examining the
+ purpose and interactions from Module A, the evaluator finds no
+ mention of Module B performing any access checks, and Module A
+ is not listed as a module with which Module B interacts. At this
+ point the evaluator should approach the developer to resolve the
+ discrepancies between the information provided in Module A and
+ that in Module B.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that the
+ description of a SFR-supporting or SFR-non-interfering module's
+ interaction with other modules is complete and accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the function is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the interactions are accurately and completely described.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a description of
+ the implementation of the TSF. The TSFI provide a description of
+ how the implementation is exercised. The evidence from the
+ developer identifies the module that is initially invoked when
+ an operation is requested at the TSFI, and identifies the chain
+ of modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However, a
+ complete call tree for each TSFI is not required for this work
+ unit. The cases in which more than one module would have to be
+ identified are where there are ``entry point'' modules or
+ wrapper modules that have no functionality other than
+ conditioning inputs or de-multiplexing an input. Mapping to one
+ of these modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the interactions are accurately and completely
+ described.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems, and later to modules. Note that this map may have to be
+ at a level of detail below the component or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to modules x, y, and z of subsystem A;
+ (rule 2) to modules x, p, and q of subsystem A; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems, and modules that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and modules, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems, and modules implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems and modules have been identified, or if
+ adequate detail had been provided for those subsystems and modules.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing and
+ SFR-supporting modules and enough information about the
+ SFR-non-interfering modules for the evaluator to determine
+ that the SFRs are completely and accurately implemented;
+ as such, the TOE design provides an explanation of the
+ implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the evaluator
+ determines that the TSF boundary has been adequately
+ described. Second, the evaluator determines that the developer
+ has provided documentation that conforms to the content and
+ presentation requirements this subsystem, and that is consistent
+ with other documentation provided for the TOE. Finally, the
+ evaluator must analyse the design information provided for the
+ SFR-enforcing modules (at a detailed level) and the
+ SFR-supporting and SFR-non-interfering modules (at a less detailed level) to
+ understand how the system is implemented, and with that
+ knowledge ensure that the TSFI in the functional specification
+ are adequately described, and that the test information
+ adequately tests the TSF (done in the work units).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each subsystem of
+ the TSF, supported by informal, explanatory text where appropriate.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing and SFR-supporting
+ module in terms of its purpose and interaction with other
+ modules.
+
+
+ The design shall describe each SFR-enforcing and
+ SFR-supporting module in terms of its SFR-related
+ interfaces, return values from those interfaces, interaction
+ with and called interfaces to other modules.
+
+
+ The design shall describe each SFR-non-interfering module in
+ terms of its purpose and interaction with other modules.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . For a very
+ simple TOE that can be described solely at the
+ ``module'' level (see ), this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+ The evaluator shall examine the TDS documentation to determine
+ that the semiformal notation used for describing the
+ subsystems, modules and their interfaces is defined or
+ referenced.
+ A semiformal notation can be either defined by the sponsor or
+ a corresponding standard be referenced. The evaluator should
+ provide a mapping of security functions and their interfaces
+ outlining in what part of the documentation a function or
+ interface is semiformal described and what notation is used.
+ The evaluator examines all semiformal notations used to
+ make sure that they are of a semiformal style and to justify
+ the appropriateness of the manner how the semiformal notations
+ are used for the TOE.
+ The evaluator is reminded that a semi-formal presentation is
+ characterised by a standardised format with a well-defined
+ syntax that reduces ambiguity that may occur in informal
+ presentations. The syntax of all semiformal notations used in
+ the functional specification shall be defined or a
+ corresponding standard be referenced. The evaluator verifies
+ that the semiformal notations used for expressing the
+ functional specification are capable of expressing features
+ relevant to security. In order to determine this, the
+ evaluator can refer to the SFR and compare the TSF security
+ features stated in the ST and those described in the FSP
+ using the semiformal notations.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ architectural description) in making this
+ determination. For example, if the functional
+ specification contains interfaces to functionality that
+ does not appear to be described in the TOE design
+ description, it may be the case that a portion of the
+ TSF has not been included appropriately. Making this
+ determination will likely be an iterative process, where
+ as more analysis is done on the other evidence, more
+ confidence can be gained with respect to the
+ completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation
+ in a level of detail that can serve as a guide to
+ reviewing the implementation representation. A
+ description of a module should be such that one could
+ create an implementation of the module from the
+ description, and the resulting implementation would be
+ 1) identical to the actual TSF implementation in terms
+ of the interfaces presented and used by the module, and
+ 2) algorithmically identical to the TSF module. For
+ instance, RFC 793 provides a high-level description of
+ the TCP protocol. It is necessarily implementation
+ independent. While it provides a wealth of detail, it is
+
+ not a suitable design
+ description because it is not specific to an
+ implementation. An actual implementation can add to the
+ protocol specified in the RFC, and implementation
+ choices (for instance, the use of global data vs. local
+ data in various parts of the implementation) may have an
+ impact on the analysis that is performed. The design
+ description of the TCP module would list the interfaces
+ presented by the implementation (rather than just those
+ defined in RFC 793), as well as an algorithm description
+ of the processing associated with the modules
+ implementing TCP (assuming it was part of the
+ TSF).
+
+
+
+
+ The evaluator shall check the TOE design to determine
+ that the TSF modules are identified as either
+ SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The purpose of designating each module (according to the role a
+ particular module plays in the enforcement of the SFRs) is to
+ allow developers to provide less information about the parts of
+ the TSF that have little role in security. It is always
+ permissible for the developer to provide more information or
+ detail than the requirements demand, as might occur when the
+ information has been gathered outside the evaluation context. In
+ such cases the developer must still designate the modules as
+ either SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The accuracy of these designations is continuously
+ reviewed as the evaluation progresses. The concern is
+ the mis-designation of modules as being less important
+ (and hence, having less information) than is really the
+ case. While blatant mis-designations may be immediately
+ apparent (e.g., designating an authentication module as
+ anything but SFR-enforcing when is one of the SFRs being claimed), other
+ mis-designations might not be discovered until the TSF
+ is better understood. The evaluator must therefore keep
+ in mind that these designations are the developer's
+ initial best effort, but are subject to change. Further
+ guidance is provided under work unit , which examines the
+ accuracy of these designations.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a subsystem-level
+ description of the TSF in addition to the modular description,
+ the goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs it functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem need to
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be
+ described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the module-level documentation) that do not appear to
+ be described, the evaluator ensures that this information is
+ provided by the developer. However, if the evaluator can
+ determine that interactions among a particular set of
+ subsystems, while incompletely described by the developer, and a
+ complete description will not aid in understanding the overall
+ functionality nor security functionality provided by the TSF,
+ then the evaluator may choose to consider the description
+ sufficient, and not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF to
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing and SFR-supporting module is complete and
+ accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the modules
+ have been categorised by the developer or not, it is the
+ evaluator's responsibility to determine that the modules
+ have the appropriate information for their role
+ (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for subsystems. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing and SFR-supporting module contain an
+ accurate and complete description of the SFR-related
+ parameters, the invocation conventions for each
+ interface, and any values returned directly by the
+ interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are
+ fixed).
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of parameters, and
+ descriptions of these parameters. Note that global data
+ would also be considered parameters if used by the
+ module (either as inputs or outputs) when invoked. If a
+ parameter were expected to take on a set of values
+ (e.g., a ``flag'' parameter), the complete set of values
+ the parameter could take on that would have an effect on
+ module processing would be specified. Likewise,
+ parameters representing data structures are described
+ such that each field of the data structure is identified
+ and described. Note that different programming languages
+ may have additional ``interfaces'' that would be
+ non-obvious; an example would be operator/function
+ overloading in C++. This ``implicit interface'' in the
+ class description would also be described as part of the
+ low-level TOE design. Note that although a module could
+ present only one interface, it is more common that a
+ module presents a small set of related
+ interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TDS design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the TSF internals, or the security architecture
+ description. However, the evaluator uses the information present
+ in those documents to the extent possible to help ensure that
+ the purpose is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that SFR-non-interfering modules are correctly
+ categorised.
+
+ As mentioned in work unit ,
+ less information is required about modules that are
+ SFR-non-interfering. A key focus of the evaluator for this work
+ unit is attempting to determine from the evidence provided for
+ each module implicitly categorised as SFR-non-interfering and
+ the evaluation (information about other modules in the TOE
+ design, the functional specification, the security architecture
+ description, the operational user guidance, the TSF internals
+ document, and perhaps even the implementation representation)
+ whether the module is indeed SFR-non-interfering. At this level
+ of assurance some error should be tolerated; the evaluator does
+ not have to be absolutely sure that a given module is
+ SFR-non-interfering, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ SFR-non-interfering module is SFR-enforcing or SFR-supporting,
+ the evaluator requests additional information from the developer
+ in order to resolve the apparent inconsistency. For example,
+ suppose the documentation for Module A (an SFR-enforcing module)
+ indicates that it calls Module B to perform an access check on a
+ certain type of construct. When the evaluator examines the
+ information associated with Module B, it is discovered that the
+ only information the developer has provided is a purpose and a
+ set of interactions (thus implicitly categorising Module B as
+ SFR-supporting or SFR-non-interfering). On examining the purpose and interactions
+ from Module A, the evaluator finds no mention of Module B
+ performing any access checks, and Module A is not listed as a
+ module with which Module B interacts. At this point the
+ evaluator should approach the developer to resolve the
+ discrepancies between the information provided in Module A and
+ that in Module B.
+
+ Another example would be where the evaluator examines
+ the mapping of the TSFI to the modules as provided by
+ . This examination
+ shows that Module C is associated with an SFR requiring
+ identification of the user. Again, when the evaluator
+ examines the information associated with Module C, they
+ find that all the developer has provided is a purpose
+ and a set of interactions (thus implicitly categorising
+ Module C as SFR-non-interfering). Examining the purpose
+ and interactions presented for Module C, the evaluator
+ is unable to determine why Module C, listed as mapping
+ to a TSFI concerned with user identification, would not
+ be classified as SFR-enforcing or SFR-supporting. Again,
+ the evaluator should approach the developer to resolve
+ this discrepancy.
+
+ A final example illustrates the opposite situation. As
+ before, the developer has provided information
+ associated with Module D consisting of a purpose and a
+ set of interactions (thus implicitly categorising Module
+ D as SFR-non-interfering). The evaluator examines all of
+ the evidence provided, including the purpose and
+ interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the
+ TOE, the interactions are consistent with that
+ description, and there is nothing to indicate that
+ Module D is SFR-enforcing or SFR-supporting. In this
+ case, the evaluator should not demand more information
+ about Module D ``just be to sure'' it is correctly
+ categorised. The developer has met the obligations and
+ the resulting assurance the evaluator has in the
+ implicit categorisation of Module D is (by definition)
+ appropriate for this assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-non-interfering module is complete and
+ accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the function is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of a SFR-non-interfering module's
+ interaction with other modules is complete and
+ accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ A module's interaction with other modules can be captured in
+ many ways. The intent for the TOE design is to allow the
+ evaluator to understand (in part through analysis of module
+ interactions) the role of the SFR-supporting and
+ SFR-non-interfering modules in the overall TOE
+ design. Understanding of this role will aid the evaluator in
+ performing work unit .
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the interactions are accurately and completely
+ described.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a
+ description of the implementation of the TSF. The TSFI
+ provide a description of how the implementation is
+ exercised. The evidence from the developer identifies
+ the module that is initially invoked when an operation
+ is requested at the TSFI, and identify the chain of
+ modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However,
+ a complete call tree for each TSFI is not required for
+ this work unit. The cases in which more than one module
+ would have to be identified are where there are ``entry
+ point'' modules or wrapper modules that have no
+ functionality other than conditioning inputs or
+ de-multiplexing an input. Mapping to one of these
+ modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a module at the TSF boundary. This determination can
+ be made by reviewing the module description and its
+ interfaces/interactions. The next aspect of accuracy is
+ that each TSFI identifies a chain of modules between the
+ initial module identified and a module that is primarily
+ responsible for implementing the function presented at
+ the TSF. Note that this may be the initial module, or
+ there may be several modules, depending on how much
+ pre-conditioning of the inputs is done. It should be
+ noted that one indicator of a pre-conditioning module is
+ that it is invoked for a large number of the TSFI, where
+ the TSFI are all of similar type (e.g., system
+ call). The final aspect of accuracy is that the mapping
+ makes sense. For instance, mapping a TSFI dealing with
+ access control to a module that checks passwords is not
+ accurate. The evaluator should again use judgement in
+ making this determination. The goal is that this
+ information aids the evaluator in understanding the
+ system and implementation of the SFRs, and ways in which
+ entities at the TSF boundary can interact with the
+ TSF. The bulk of the assessment of whether the SFRs are
+ described accurately by the modules is performed in
+ other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems, and later to modules. Note that this map may have to be
+ at a level of detail below the component or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to modules x, y and z of subsystem A;
+ (rule 2) to x, p, and q of subsystem A; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems, and modules that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and modules, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems, and modules implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems and modules have been identified, or if
+ adequate detail had been provided for those subsystems and modules.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of all modules for the
+ evaluator to determine that the SFRs are completely and
+ accurately implemented; as such, the TOE design provides
+ an explanation of the implementation
+ representation.
+
+
+
+ At this level, there is no differentiation of required
+ information according to SFR-relevance.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each
+ subsystem of the TSF, supported by informal, explanatory text where
+ appropriate.
+
+
+ The design shall provide a description of the interactions among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall provide a semiformal description of each module
+ in terms of its purpose, interaction, interfaces, return values
+ from those interfaces, and called interfaces to other modules,
+ supported by informal, explanatory text where appropriate.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The developer shall provide a formal specification of the
+ TSF subsystems.
+
+
+ The developer shall provide a proof of correspondence
+ between the formal specifications of the TSF subsystems and
+ of the functional specification.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each
+ subsystem of the TSF, supported by informal, explanatory text where
+ appropriate.
+
+
+ The design shall provide a description of the interactions among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe in semiformal style each module in terms
+ of its purpose, interfaces, return values from those interfaces,
+ and called interfaces to other modules, supported by informal, explanatory
+ text where appropriate.
+
+
+ The formal specification of the TSF subsystems shall
+ describe the TSF using a formal style, supported by
+ informal, explanatory text where appropriate.
+
+
+ The mapping shall demonstrate that all behaviour described
+ in the TOE design is mapped to the TSFIs that invoke it.
+
+
+ The proof of correspondence between the formal
+ specifications of the TSF subsystems and of the functional
+ specification shall demonstrate that all behaviour described
+ in the TOE design is a correct and complete refinement of
+ the TSFI that invoked it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The guidance documents class provides the requirements for
+ guidance documentation for all user roles. For the secure
+ preparation and operation of the TOE it is necessary to
+ describe all relevant aspects for the secure handling of the
+ TOE. The class also addresses the possibility of unintended
+ incorrect configuration or handling of the TOE.
+
+ In many cases it may be appropriate that guidance is provided
+ in separate documents for preparation and operation of the
+ TOE, or even separate for different user roles as end-users,
+ administrators, application programmers using software or
+ hardware interfaces, etc.
+
+ The guidance documents class is subdivided into two families
+ which are concerned with the preparative user guidance (what
+ has to be done to transform the delivered TOE into its
+ evaluated configuration in the operational environment as
+ described in the ST) and with the operational user guidance
+ (what has to be done during the operation of the TOE in its
+ evaluated configuration).
+
+
+
+ Assurance class defines
+ requirements directed at the understandability, coverage and
+ completeness of the preparative and operational documentation
+ provided by the developer. This documentation, which provides
+ information for all user roles, is an important factor in the
+ secure preparation and operation of the TOE.
+
+
+
+ The purpose of the guidance document activity is to judge the
+ adequacy of the documentation describing how the user can
+ handle the TOE in a secure manner. Such documentation should
+ take into account the various types of users (e.g. those who
+ accept, install, administrate or operate the TOE) whose
+ incorrect actions could adversely affect the security of the
+ TOE or of their own data.
+
+ The guidance documents class is subdivided into two families
+ which are concerned firstly with the preparative user guidance
+ (all that has to be done to transform the delivered TOE into
+ its evaluated configuration in the environment as described in
+ the ST, i.e. accepting and installing the TOE) and secondly
+ with the operational user guidance (all that has to be done
+ during the operation of the TOE in its evaluated
+ configuration, i.e. operation and administration).
+
+
+
+ The guidance documents activity applies to those functions and
+ interfaces which are related to the security of the TOE. The
+ secure configuration of the TOE is described in the ST.
+
+
+
+
+ Operational user guidance refers to written material that is
+ intended to be used by all types of users of the TOE in its
+ evaluated configuration: end-users, persons responsible for
+ maintaining and administering the TOE in a correct manner
+ for maximum security, and by others (e.g. programmers) using
+ the TOE's external interfaces. Operational user guidance
+ describes the security functionality provided by the TSF,
+ provides instructions and guidelines (including warnings),
+ helps to understand the TSF and includes the
+ security-critical information, and the security-critical
+ actions required, for its secure use. Misleading and
+ unreasonable guidance should be absent from the guidance
+ documentation, and secure procedures for all modes of
+ operation should be addressed. Insecure states should be
+ easy to detect.
+
+ The operational user guidance provides a measure of
+ confidence that non-malicious users, administrators,
+ application providers and others exercising the external
+ interfaces of the TOE will understand the secure operation
+ of the TOE and will use it as intended. The evaluation of
+ the user guidance includes investigating whether the TOE can
+ be used in a manner that is insecure but that the user of
+ the TOE would reasonably believe to be secure. The objective
+ is to minimise the risk of human or other errors in
+ operation that may deactivate, disable, or fail to activate
+ security functionality, resulting in an undetected insecure
+ state.
+
+
+
+ Requirements for operational user guidance help ensure that
+ all types of users are able to operate the TOE in a secure
+ manner (e.g. the usage constraints assumed by the PP or ST
+ must be clearly explained and illustrated). It should be
+ excluded that the TOE can be used in a manner that is
+ insecure but that the user of the TOE would reasonably
+ believe to be secure. Operational user guidance is the
+ primary vehicle available to the developer for providing the
+ TOE users with the necessary background and specific
+ information on how to correctly use the TOE's protection
+ functions.
+
+ Operational user guidance must do two things. First, it
+ needs to explain what the security functionality accessible
+ by the user does and how it is to be used, so that users are
+ able to consistently and effectively protect their
+ information. Second, it needs to explain the user's role in
+ maintaining the TOE's security.
+
+
+
+ This family contains only one component.
+
+
+
+ There may be different user roles or groups that are
+ recognised by the TOE and that can interact with the
+ TSF. These user roles and groups should be taken into
+ consideration by the operational user guidance. They may be
+ roughly grouped into administrators and non-administrative
+ users, or more specifically grouped into persons responsible
+ for receiving, accepting, installing and maintaining the
+ TOE, application programmers, revisors, auditors,
+ daily-management, end-users. Each role can encompass an
+ extensive set of capabilities, or can be a single
+ one.
+
+ The requirement
+ encompasses the aspect that any warnings to the users during
+ operation of a TOE with regard to the security problem
+ definition and the security objectives for the operational
+ environment described in the PP/ST are appropriately covered
+ in the user guidance.
+
+ The concept of secure values, as employed in , has relevance where a user
+ has control over security parameters. Guidance needs to be
+ provided on secure and insecure settings for such
+ parameters.
+
+ requires that the
+ user guidance describes the appropriate reactions to all
+ security-relevant events. Although many security-relevant
+ events are the result of performing functions, this need not
+ always be the case (e.g. the audit log fills up, an
+ intrusion is detected). Furthermore, a security-relevant
+ event may happen as a result of a specific chain of
+ functions or, conversely, several security-relevant events
+ may be triggered by one function.
+
+ requires that the
+ user guidance is clear and reasonable. Misleading or
+ unreasonable guidance may result in a user of the TOE
+ believing that the TOE is secure when it is not.
+
+ An example of misleading guidance would be the description
+ of a single guidance instruction that could be parsed in
+ more than one way, one of which may result in an insecure
+ state.
+
+ An example of unreasonable guidance would be a
+ recommendation to follow a procedure that is so complicated
+ that it cannot reasonably be expected that users will follow
+ this guidance.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the user guidance describes for each user role the
+ security functionality and interfaces provided by the TSF,
+ provides instructions and guidelines for the secure use of
+ the TOE, addresses secure procedures for all modes of
+ operation, facilitates prevention and detection of
+ insecure TOE states, or whether it is misleading or
+ unreasonable.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design, if applicable;
+
+
+ the user guidance;
+
+
+
+
+ The developer shall provide operational user guidance.
+
+
+ The operational user guidance shall describe, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+
+ The operational user guidance shall describe, for each user
+ role, how to use the available interfaces provided by the
+ TOE in a secure manner.
+
+
+ The operational user guidance shall describe, for each user
+ role, the available functions and interfaces, in particular
+ all security parameters under the control of the user,
+ indicating secure values as appropriate.
+
+
+ The operational user guidance shall, for each user role,
+ clearly present each type of security-relevant event
+ relative to the user-accessible functions that need to be
+ performed, including changing the security characteristics
+ of entities under the control of the TSF.
+
+
+ The operational user guidance shall identify all possible
+ modes of operation of the TOE (including operation following
+ failure or operational error), their consequences and
+ implications for maintaining secure operation.
+
+
+ The operational user guidance shall, for each user role,
+ describe the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+
+ The operational user guidance shall be clear and reasonable.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+ The configuration of the TOE may allow different user
+ roles to have dissimilar privileges in making use of the
+ different functions of the TOE. This means that some
+ users are authorised to perform certain functions, while
+ other users may not be so authorised. These functions
+ and privileges should be described, for each user role,
+ by the user guidance.
+
+ The user guidance identifies, for each user role, the
+ functions and privileges that must be controlled, the
+ types of commands required for them, and the reasons for
+ such commands. The user guidance should contain warnings
+ regarding the use of these functions and
+ privileges. Warnings should address expected effects,
+ possible side effects, and possible interactions with
+ other functions and privileges.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the secure use of the available interfaces
+ provided by the TOE.
+
+ The user guidance should provide advice regarding
+ effective use of the TSF (e.g. reviewing password
+ composition practises, suggested frequency of user file
+ backups, discussion on the effects of changing user
+ access privileges).
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the available security functionality and
+ interfaces, in particular all security parameters under
+ the control of the user, indicating secure values as
+ appropriate.
+
+ The user guidance should contain an overview of the
+ security functionality that is visible at the user
+ interfaces.
+
+ The user guidance should identify and describe the
+ purpose, behaviour, and interrelationships of the
+ security interfaces and functionality.
+
+ For each user-accessible interface, the user guidance
+ should:
+
+
+ describe the method(s) by which the interface is
+ invoked (e.g. command-line, programming-language
+ system call, menu selection, command button);
+
+
+ describe the parameters to be set by the user, their
+ particular purposes, valid and default values, and
+ secure and insecure use settings of such parameters,
+ both individually or in combination;
+
+
+ describe the immediate TSF response, message, or
+ code returned.
+
+
+
+ The evaluator should consider the functional
+ specification and the ST to determine that the TSF
+ described in these documents is consistent to the
+ operational user guidance. The evaluator has to ensure
+ that the operational user guidance is complete to allow
+ the secure use through the TSFI available to all types
+ of human users. The evaluator may, as an aid, prepare an
+ informal mapping between the guidance and these
+ documents. Any omissions in this mapping may indicate
+ incompleteness.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, each type of security-relevant event relative to
+ the user functions that need to be performed, including
+ changing the security characteristics of entities under
+ the control of the TSF and operation following failure
+ or operational error.
+
+ All types of security-relevant events are detailed for
+ each user role, such that each user knows what events
+ may occur and what action (if any) he may have to take
+ in order to maintain security. Security-relevant events
+ that may occur during operation of the TOE (e.g. audit
+ trail overflow, system crash, updates to user records,
+ such as when a user account is removed when the user
+ leaves the organisation) are adequately defined to allow
+ user intervention to maintain secure operation.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance and other evaluation evidence to determine that
+ the guidance identifies all possible modes of operation
+ of the TOE (including, if applicable, operation
+ following failure or operational error), their
+ consequences and implications for maintaining secure
+ operation.
+
+ Other evaluation evidence, particularly the functional
+ specification, provide an information source that the
+ evaluator should use to determine that the guidance
+ contains sufficient guidance information.
+
+ If test documentation is included in the assurance
+ package, then the information provided in this evidence
+ can also be used to determine that the guidance contains
+ sufficient guidance documentation. The detail provided
+ in the test steps can be used to confirm that the
+ guidance provided is sufficient for the use and
+ administration of the TOE.
+
+ The evaluator should focus on a single human visible
+ TSFI at a time, comparing the guidance for securely
+ using the TSFI with other evaluation evidence, to
+ determine that the guidance related to the TSFI is
+ sufficient for the secure usage (i.e. consistent with
+ the SFRs) of that TSFI. The evaluator should also
+ consider the relationships between interfaces, searching
+ for potential conflicts.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+ The evaluator analyses the security objectives for the
+ operational environment in the ST and determines that
+ for each user role, the relevant security measures are
+ described appropriately in the user guidance.
+
+ The security measures described in the user guidance
+ should include all relevant external procedural,
+ physical, personnel and connectivity measures.
+
+ Note that those measures relevant for secure
+ installation of the TOE are examined in .
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is clear.
+
+ The guidance is unclear if it can reasonably be
+ misconstrued by an administrator or user, and used in a
+ way detrimental to the TOE, or to the security provided
+ by the TOE.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is reasonable.
+
+ The guidance is unreasonable if it makes demands on the
+ TOE's usage or operational environment that are
+ inconsistent with the ST or unduly onerous to maintain
+ security.
+
+
+
+
+
+
+
+ Preparative procedures are useful for ensuring that the TOE
+ has been received and installed in a secure manner as
+ intended by the developer. The requirements for preparation
+ call for a secure transition from the delivered TOE to its
+ initial operational environment. This includes investigating
+ whether the TOE can be configured or installed in a manner
+ that is insecure but that the user of the TOE would
+ reasonably believe to be secure.
+
+
+
+ Preparation requires that the delivered copy of the TOE is
+ accepted, configured and activated by the user to exhibit
+ the protection properties as needed during operation of the
+ TOE. The preparative procedures provide confidence that the
+ user will be aware of the TOE configuration parameters and
+ how they can affect the TSF.
+
+
+
+ This family contains only one component.
+
+
+
+ It is recognised that the application of these requirements
+ will vary depending on aspects such as whether the TOE is
+ delivered in an operational state, or whether it has to be
+ installed at the TOE owner's site, etc.
+
+ The first process covered by the preparative procedures is
+ the consumer's secure acceptance of the received TOE in
+ accordance with the developer's delivery procedures. If the
+ developer has not defined delivery procedures, security of
+ the acceptance has to be ensured otherwise.
+
+ Installation of the TOE includes transforming its
+ operational environment into a state that conforms to the
+ security objectives for the operational environment provided
+ in the ST.
+
+ It might also be the case that no installation is necessary,
+ for example a smart card. In this case it may be
+ inappropriate to require and analyse installation
+ procedures.
+
+ The requirements in this assurance family are presented
+ separately from those in the family, due to the infrequent, possibly
+ one-time use of the preparative procedures.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the procedures and steps for the secure preparation of the
+ TOE have been documented and result in a secure
+ configuration.
+
+
+
+ The preparative procedures refer to all acceptance and
+ installation procedures, that are necessary to progress
+ the TOE to the secure configuration as described in the
+ ST.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE including its preparative procedures;
+
+
+ the description of developer's delivery procedures, if
+ applicable;
+
+
+
+
+ The developer shall provide the TOE including its
+ preparative procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure acceptance
+ of the delivered TOE in accordance with the developer's
+ delivery procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure
+ installation of the TOE and for the secure preparation of
+ the operational environment in accordance with the security
+ objectives for the operational environment as described in
+ the ST.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+ The evaluator shall examine the provided acceptance
+ procedures to determine that they describe the steps
+ necessary for secure acceptance of the TOE in accordance
+ with the developer's delivery procedures.
+ If it is not anticipated by the developer's delivery
+ procedures that acceptance procedures will or can be
+ applied, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+ The acceptance procedures should include as a minimum,
+ that the user has to check that all parts of the TOE as
+ indicated in the ST have been delivered in the correct
+ version.
+
+ The acceptance procedures should reflect the steps the
+ user has to perform in order to accept the delivered TOE
+ that are implied by the developer's delivery
+ procedures.
+
+ The acceptance procedures should provide detailed
+ information about the following, if applicable:
+
+
+ making sure that the delivered TOE is the complete
+ evaluated instance;
+
+
+ detecting modification/masquerading of the delivered
+ TOE.
+
+
+
+
+
+
+
+ The evaluator shall examine the provided installation
+ procedures to determine that they describe the steps
+ necessary for secure installation of the TOE and the
+ secure preparation of the operational environment in
+ accordance with the security objectives in the
+ ST.
+ If it is not anticipated that installation procedures
+ will or can be applied for the TOE and the operational
+ environment (e.g. because the TOE may already be
+ delivered in an operational state and there are no
+ requirements for the environment) this work unit is not
+ applicable, and is therefore considered to be
+ satisfied.
+
+ If it is not anticipated that installation procedures
+ will or can be applied (e.g. because the TOE may already
+ be delivered in an operational state), this work unit is
+ not applicable, and is therefore considered to be
+ satisfied.
+
+ The installation procedures should provide detailed
+ information about the following, if applicable:
+
+
+ minimum system requirements for secure installation;
+
+
+ requirements for the operational environment in
+ accordance with the security objectives provided by
+ the ST;
+
+ the steps the user has to perform in order to get to an
+ operational TOE being commensurate with its evaluated
+ configuration. Such a description shall include - for each step
+ - a clear scheme for the decision on the next step depended on
+ success, failure or problems at the current step;
+
+
+ changing the installation specific security
+ characteristics of entities under the control of the
+ TSF (for example parameters, settings, passwords);
+
+
+ handling exceptions and problems.
+
+
+
+
+
+ The evaluator shall apply the preparative procedures to
+ confirm that the TOE can be prepared securely for operation.
+
+
+ The evaluator shall perform all user procedures
+ necessary to prepare the TOE to determine that the TOE
+ and its operational environment can be prepared securely
+ using only the supplied preparative user
+ guidance.
+ Preparation requires the evaluator to advance the
+ TOE from a deliverable state to the state in which it is
+ operational, including acceptance and installation of
+ the TOE, and enforcing the SFRs consistent with the
+ security objectives for the TOE specified in the
+ ST.
+
+ The evaluator should follow only the developer's
+ procedures and may perform the activities that customers
+ are usually expected to perform to accept and install
+ the TOE, using the supplied preparative guidance
+ documentation only. Any difficulties encountered during
+ such an exercise may be indicative of incomplete,
+ unclear or unreasonable guidance.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+ If it is known that the TOE will be used as a dependent
+ component for a composed TOE evaluation, then the
+ evaluator should ensure that the operational environment
+ is satisfied by the base component used in the composed
+ TOE.
+
+
+
+
+
+
+
+
+ Life-cycle support is an aspect of establishing discipline and
+ control in the processes of refinement of the TOE during its
+ development and maintenance. Confidence in the correspondence
+ between the TOE security requirements and the TOE is greater
+ if security analysis and the production of the evidence are
+ done on a regular basis as an integral part of the development
+ and maintenance activities.
+
+ In the product life-cycle it is distinguished whether the TOE
+ is under the responsibility of the developer or the user
+ rather than whether it is located in the development or user
+ environment. The point of transition is the moment where the
+ TOE is handed over to the user. This is also the point of
+ transition from the to the class.
+
+ The class consists of seven
+ families. is the high-level
+ description of the TOE life-cycle; a more detailed description of the management
+ of the configuration items.
+ requires a minimum set of configuration items to be managed in
+ the defined way. is
+ concerned with the developer's physical, procedural,
+ personnel, and other security measures; with the development tools and implementation
+ standards used by the developer; with the handling of security flaws. defines the procedures used for
+ the delivery of the TOE to the consumer. Delivery processes
+ occurring during the development of the TOE are denoted rather
+ as transportations, and are handled in the context of
+ integration and acceptance procedures in other families of
+ this class.
+
+ Throughout this class, development and related terms
+ (developer, develop) are meant in the more general sense to
+ comprise development and production, whereas
+ production specifically means the process of transforming the
+ implementation representation into the final TOE.
+
+
+
+ Assurance class defines
+ requirements for assurance through the adoption of a well
+ defined life-cycle model for all the steps of the TOE
+ development, including flaw remediation procedures and
+ policies, correct use of tools and techniques and the security
+ measures used to protect the development environment.
+
+ Configuration management (CM) helps to ensure that the
+ integrity of the TOE is preserved, by preventing unauthorised
+ modifications, additions, or deletions to the TOE, thus
+ providing assurance that the TOE and documentation used for
+ evaluation are the ones prepared for distribution.
+
+ The delivery procedures define requirements for the measures,
+ procedures, and standards concerned with secure delivery of
+ the TOE, ensuring that the security protection offered by the
+ TOE is not compromised during the transfer to the user.
+
+
+
+ The purpose of the life-cycle support activity is to determine
+ the adequacy of the security procedures that the developer
+ uses during the development and maintenance of the TOE. These
+ procedures include the life-cycle model used by the developer,
+ the configuration management, the security measures used
+ throughout TOE development, the tools used by the developer
+ throughout the life-cycle of the TOE, the handling of security
+ flaws, and the delivery activity.
+
+ Poorly controlled development and maintenance of the TOE can
+ result in vulnerabilities in the implementation. Conformance
+ to a defined life-cycle model can help to improve controls in
+ this area. A measurable life-cycle model used for the TOE can
+ remove ambiguity in assessing the development progress of the
+ TOE.
+
+ The purpose of the configuration management activity is to
+ assist the consumer in identifying the evaluated TOE, to
+ ensure that configuration items are uniquely identified, and
+ the adequacy of the procedures that are used by the developer
+ to control and track changes that are made to the TOE. This
+ includes details on what changes are tracked, how potential
+ changes are incorporated, and the degree to which automation
+ is used to reduce the scope for error.
+
+ Developer security procedures are intended to protect the TOE
+ and its associated design information from interference or
+ disclosure. Interference in the development process may allow
+ the deliberate introduction of vulnerabilities. Disclosure of
+ design information may allow vulnerabilities to be more easily
+ exploited. The adequacy of the procedures will depend on the
+ nature of the TOE and the development process.
+
+ The use of well-defined development tools and the application
+ of implementation standards by the developer and by third
+ parties involved in the development process help to ensure
+ that vulnerabilities are not inadvertently introduced during
+ refinement.
+
+ The flaw remediation activity is intended to track security
+ flaws, to identify corrective actions, and to distribute the
+ corrective action information to TOE users.
+
+ The purpose of the delivery activity is to judge the adequacy
+ of the documentation of the procedures used to ensure that the
+ TOE is delivered to the consumer without modification.
+
+
+
+
+ Configuration management (CM) is one means for increasing
+ assurance that the TOE meets the SFRs. CM establishes this
+ by requiring discipline and control in the processes of
+ refinement and modification of the TOE and the related
+ information. CM systems are put in place to ensure the
+ integrity of the portions of the TOE that they control, by
+ providing a method of tracking any changes, and by ensuring
+ that all changes are authorised.
+
+ The objective of this family is to require the developer's
+ CM system to have certain capabilities. These are meant to
+ reduce the likelihood that accidental or unauthorised
+ modifications of the configuration items will occur. The CM
+ system should ensure the integrity of the TOE from the early
+ design stages through all subsequent maintenance
+ efforts.
+
+ The objective of introducing automated CM tools is to
+ increase the effectiveness of the CM system. While both
+ automated and manual CM systems can be bypassed, ignored, or
+ proven insufficient to prevent unauthorised modification,
+ automated systems are less susceptible to human error or
+ negligence.
+
+ The objectives of this family include the following:
+
+
+ ensuring that the TOE is correct and complete before it
+ is sent to the consumer;
+
+
+ ensuring that no configuration items are missed during
+ evaluation;
+
+
+ preventing unauthorised modification, addition, or
+ deletion of TOE configuration items.
+
+
+
+
+
+ Configuration management capabilities define the
+ characteristics of the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ the CM system capabilities, the scope of the CM
+ documentation and the evidence provided by the
+ developer.
+
+
+
+ While it is desired that CM be applied from the early design
+ stages and continue into the future, this family requires
+ that CM be in place and in use prior to the end of the
+ evaluation.
+
+ In the case where the TOE is a subset of a product, the
+ requirements of this family apply only to the TOE
+ configuration items, not to the product as a whole.
+
+ For developers that have separate CM systems for different
+ life-cycle phases (for example development, production
+ and/or the final product), it is required to document all of
+ them. For evaluation purposes, the separate CM systems
+ should be regarded as parts of an overall CM system which is
+ addressed in the criteria.
+
+ Similarly, if parts of the TOE are produced by different
+ developers or at different sites, the CM systems being in
+ use at the different places should be regarded as parts of
+ an overall CM system which is addressed in the criteria. In
+ this situation, integration aspects have also to be taken
+ into account.
+
+ Several elements of this family refer to configuration
+ items. These elements identify CM requirements to be imposed
+ on all items identified in the configuration list, but leave
+ the contents of the list to the discretion of the
+ developer. can be used to
+ narrow this discretion by identifying specific items that
+ must be included in the configuration list, and hence
+ covered by CM.
+
+ introduces a
+ requirement that the CM system uniquely identify all
+ configuration items. This also requires that modifications
+ to configuration items result in a new, unique identifier
+ being assigned to the configuration item.
+
+ introduces the
+ requirement that the evidence shall demonstrate that the CM
+ system operates in accordance with the CM plan. Examples of
+ such evidence might be documentation such as screen
+ snapshots or audit trail output from the CM system, or a
+ detailed demonstration of the CM system by the
+ developer. The evaluator is responsible for determining that
+ this evidence is sufficient to show that the CM system
+ operates in accordance with the CM plan.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ support the production of the TOE. This requires that the CM
+ system provide an automated means to assist in determining
+ that the correct configuration items are used in generating
+ the TOE.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ ascertain the changes between the TOE and its preceding
+ version. If no previous version of the TOE exists, the
+ developer still needs to provide an automated means to
+ ascertain the changes between the TOE and a future version
+ of the TOE.
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the
+ TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items.
+
+
+
+ This component contains an implicit evaluator action to
+ determine that the CM system is being used. As the
+ requirements here are limited to identification of the TOE
+ and provision of a configuration list, this action is
+ already covered by, and limited to, the existing work
+ units. At the
+ requirements are expanded beyond these two items, and more
+ explicit evidence of operation is required.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+ Assurance that the CM system uniquely identifies
+ all configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items, and whether the
+ ability to modify these items is properly
+ controlled.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide measures such that only
+ authorised changes are made to the configuration items.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan to determine that they
+ are effective in preventing unauthorised access to the
+ configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan.
+ The CM plan needs not to be a connected document, but it is
+ recommended that there is a single document that describes where
+ the various parts of the CM plan can be found. If the CM plan is
+ no single document, the list in the following work unit gives
+ hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that they
+ are automated and effective in preventing unauthorised
+ access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan.
+ The CM plan does not need to be contained within a single
+ document, but it is recommended that there is a separate
+ document that describes where the various parts of the CM plan
+ can be found. If the CM plan is provided by a set of documents,
+ the list in the following work unit gives guidance regarding the
+ required content.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+ If this work unit is applied to a dependent component
+ that is going to be integrated in a composed TOE, the CM
+ plan should consider the control of base components
+ obtained by the dependent TOE developer.
+
+ When obtaining the components the evaluators are to
+ verify the following:
+
+
+ Transfer of each base component from the base
+ component developer to the integrator (dependent TOE
+ developer) was performed in accordance with the base
+ component TOE's secure delivery procedures, as
+ reported in the base component TOE certification
+ report.
+
+
+ The component received has the same identifiers as
+ those stated in the ST and Certification Report for
+ the component TOE.
+
+
+ All additional material required by a developer for
+ composition (integration) is provided. This is to
+ include the necessary extract of the component TOE's
+ functional specification.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+ Requiring that the CM system be able to identify the
+ version of the implementation representation from which
+ the TOE is generated helps to ensure that the integrity of
+ this material is preserved by the appropriate technical,
+ physical and procedural safeguards.
+
+ Providing an automated means of ascertaining changes
+ between versions of the TOE and identifying which
+ configuration items are affected by modifications to other
+ configuration items assists in determining the impact of
+ the changes between successive versions of the TOE. This
+ in turn can provide valuable information in determining
+ whether changes to the TOE result in all configuration
+ items being consistent with one another.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM documentation shall justify that the acceptance
+ procedures provide for an adequate and appropriate review of
+ changes to all configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM system shall ensure that the person responsible for
+ accepting a configuration item into CM is not the person who
+ developed it.
+
+
+ The CM system shall identify the configuration items that
+ comprise the TSF.
+
+
+ The CM system shall support the audit of all changes to the
+ TOE by automated means, including the originator, date, and
+ time in the audit trail.
+
+
+ The CM system shall provide an automated means to identify
+ all other configuration items that are affected by the
+ change of a given configuration item.
+
+
+ The CM system shall be able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the CM documentation to
+ determine that it justifies that the acceptance
+ procedures provide for an adequate and appropriate
+ review of changes to all configuration items.
+
+ The CM documentation should make it sufficiently clear
+ that by following the acceptance procedures only parts
+ of adequate quality are incorporated into the
+ TOE.
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that
+ they are automated and effective in preventing
+ unauthorised access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it ensures that the person responsible for
+ accepting a configuration item is not the person who
+ developed it.
+
+ The acceptance procedures describe who is responsible
+ for accepting a configuration item. From these
+ descriptions, the evaluator should be able to determine
+ that the person who developed a configuration item is in
+ no case responsible for its acceptance.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it identifies the configuration items that comprise
+ the TSF.
+
+ The CM documentation should describe how the CM system
+ identifies the configuration items that comprise the
+ TSF. The evaluator should select a sample of
+ configuration items covering each type of items,
+ particularly containing TSF and non-TSF items, and check
+ that they are correctly classified by the CM
+ system.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it supports the audit of all changes to the TOE by
+ automated means, including the originator, date, and
+ time in the audit trail.
+
+ The evaluator should inspect a sample of audit trails
+ and check, if they contain the minimum
+ information.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it provides an automated means to identify all
+ other configuration items that are affected by the
+ change of a given configuration item.
+
+ The CM documentation should describe how the CM system
+ identifies all other configuration items that are
+ affected by the change of a given configuration
+ item. The evaluator should select a sample of
+ configuration items, covering all types of items, and
+ exercise the automated means to determine that it
+ identifies all items that are affected by the change of
+ the selected item.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it is able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+ The CM documentation should describe how the CM system
+ identifies the version of the implementation
+ representation from which the TOE is generated. The
+ evaluator should select a sample of the parts used to
+ produce the TOE and should apply the CM system to verify
+ that it identifies the corresponding implementation
+ representation in the correct version.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check that the CM documentation provided
+ includes a CM plan.
+ The CM plan needs not to be a connected document, but it is
+ recommended that there is a single document that describes where
+ the various parts of the CM plan can be found. If the CM plan is
+ no single document, the list in the following work unit gives
+ hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include
+ change control forms, or configuration item access
+ approval forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+ The evaluator shall determine that the application of the
+ production support procedures results in a TOE as provided
+ by the developer for testing activities.
+
+
+ The evaluator shall examine the production support
+ procedures to determine that by following these
+ procedures a TOE would be produced like that one
+ provided by the developer for testing activities.
+
+ If the TOE is a small software TOE and production
+ consists of compiling and linking, the evaluator might
+ confirm the adequacy of the production support
+ procedures by reapplying them himself.
+
+ If the production process of the TOE is more complicated
+ (as for example in the case of a smart card), but has
+ already started, the evaluator should inspect the
+ application of the production support procedures during
+ a visit of the development site. He might compare a copy
+ of the TOE produced in his presence with the samples
+ used for his testing activities.
+
+ For guidance on site visits see .
+
+ Otherwise the evaluator's determination should be based
+ on the documentary evidence provided by the
+ developer.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+ The objective of this family is to identify items to be
+ included as configuration items and hence placed under the
+ CM requirements of .
+ Applying configuration management to these additional items
+ provides additional assurance that the integrity of TOE is
+ maintained.
+
+
+
+ Configuration management scope indicates the TOE items that
+ need to be controlled by the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ which of the following are required to be included as
+ configuration items: the TOE and the evaluation evidence
+ required by the SARs; the parts of the TOE; the
+ implementation representation; security flaws; and
+ development tools and related information.
+
+
+
+ While mandates a list of
+ configuration items and that each item on this list be under
+ CM, leaves the contents of
+ the configuration list to the discretion of the
+ developer. narrows this
+ discretion by identifying items that must be included in the
+ configuration list, and hence come under the CM requirements
+ of .
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself and the evaluation evidence required by the other
+ SARs in the ST under CM provides assurance that they have
+ been modified in a controlled manner with proper
+ authorisations.
+
+
+
+ introduces the
+ requirement that the TOE itself and the evaluation
+ evidence required by the other SARs in the ST be included
+ in the configuration list and hence be subject to the CM
+ requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer performs configuration management on the TOE
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; and the evaluation evidence required by the SARs.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, and the
+ evaluation evidence required by the other SARs under CM
+ provides assurance that they have been modified in a
+ controlled manner with proper authorisations.
+
+
+
+ introduces the
+ requirement that the parts that comprise the TOE (all
+ parts that are delivered to the consumer, for example
+ hardware parts or executable files) be included in the
+ configuration list and hence be subject to the CM
+ requirements of .
+
+ introduces the
+ requirement that the configuration list indicate the
+ developer of each TSF relevant configuration
+ item. ``Developer'' here does not refer to a person, but
+ to the organisation responsible for the development of the
+ item.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; and
+ the parts that comprise the TOE.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+ the TOE itself;
+
+ the parts that comprise the TOE;
+
+ the evaluation evidence required by the SARs.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+
+
+ introduces the
+ requirement that the TOE implementation representation be
+ included in the list of configuration items and hence be
+ subject to the CM requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; and the implementation
+ representation.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+
+
+ introduces the
+ requirement that security flaws be included in the
+ configuration list and hence be subject to the CM
+ requirements of . This
+ requires that information regarding previous security
+ flaws and their resolution be maintained, as well as
+ details regarding current security flaws.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; and security flaw reports and resolution
+ status.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database).
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+ Development tools play an important role in ensuring the
+ production of a quality version of the TOE. Therefore, it
+ is important to control modifications to these
+ tools.
+
+
+
+ introduces the
+ requirement that development tools and other related
+ information be included in the list of configuration items
+ and hence be subject to the CM requirements of . Examples of development tools
+ are programming languages and compilers. Information
+ pertaining to TOE generation items (such as compiler
+ options, generation options, and build options) is an
+ example of information relating to development
+ tools.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, development tools and related information,
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; security flaw reports and resolution status;
+ and development tools and related information.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database);
+
+
+ all tools (incl. test software, if applicable)
+ involved in the development and production of the
+ TOE including the names, versions, configurations
+ and roles of each development tool, and related
+ documentation.
+
+
+ For a software TOE, ``development tools'' are usually
+ programming languages and compiler and ``related documentation''
+ comprises compiler and linker options. For a hardware TOE,
+ ``development tools'' might be hardware design languages,
+ simulation and synthesis tools, compilers, and ``related
+ documentation'' might comprise compiler options again.
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ The concern of this family is the secure transfer of the
+ finished TOE from the development environment into the
+ responsibility of the user.
+
+ The requirements for delivery call for system control and
+ distribution facilities and procedures that detail the
+ measures necessary to provide assurance that the security of
+ the TOE is maintained during distribution of the TOE to the
+ user. For a valid distribution of the TOE, the procedures
+ used for the distribution of the TOE address the objectives
+ identified in the PP/ST relating to the security of the TOE
+ during delivery.
+
+
+
+ Delivery covers the procedures used to maintain security
+ during transfer of the TOE to the user, both on initial
+ delivery and as part of subsequent modification. It includes
+ special procedures or operations required to demonstrate the
+ authenticity of the delivered TOE. Such procedures and
+ measures are the basis for ensuring that the security
+ protection offered by the TOE is not compromised during
+ transfer. While compliance with the delivery requirements
+ cannot always be determined when a TOE is evaluated, it is
+ possible to evaluate the procedures that a developer has
+ developed to distribute the TOE to users.
+
+
+
+ This family contains only one component. An increasing level
+ of protection is established by requiring commensurability
+ of the delivery procedures with the assumed attack potential
+ in the family .
+
+
+
+ Transportations from subcontractors to the developer or
+ between different development sites are not considered here,
+ but in the family .
+
+ The end of the delivery phase is marked by the transfer of
+ the TOE into the responsibility of the user. This does not
+ necessarily coincide with the arrival of the TOE at the
+ user's location.
+
+ The delivery procedures should consider, if applicable,
+ issues such as:
+
+
+ ensuring that the TOE received by the consumer
+ corresponds precisely to the evaluated version of the
+ TOE;
+
+
+ avoiding or detecting any tampering with the actual
+ version of the TOE;
+
+
+ preventing submission of a false version of the TOE;
+
+
+ avoiding unwanted knowledge of distribution of the TOE
+ to the consumer: there might be cases where potential
+ attackers should not know when and how it is delivered;
+
+
+ avoiding or detecting the TOE being intercepted during
+ delivery; and
+
+
+ avoiding the TOE being delayed or stopped during
+ distribution.
+
+
+
+ The delivery procedures should include the recipient's
+ actions implied by these issues. The consistent description
+ of these implied actions is examined in the family, if present.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the delivery documentation describes all procedures used
+ to maintain security of the TOE when distributing the TOE
+ to the user.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the delivery documentation.
+
+
+
+
+ The developer shall document procedures for delivery of the
+ TOE or parts of it to the consumer.
+
+
+ The developer shall use the delivery procedures.
+
+
+ The evaluator shall examine aspects of the delivery
+ process to determine that the delivery procedures are
+ used.
+
+ The approach taken by the evaluator to check the
+ application of delivery procedures will depend on the
+ nature of the TOE, and the delivery process itself. In
+ addition to examination of the procedures themselves,
+ the evaluator seeks some assurance that they are applied
+ in practise. Some possible approaches are:
+
+
+ a visit to the distribution site(s) where practical
+ application of the procedures may be observed;
+
+
+ examination of the TOE at some stage during
+ delivery, or after the user has received it
+ (e.g. checking for tamper proof seals);
+
+
+ observing that the process is applied in practise
+ when the evaluator obtains the TOE through regular
+ channels;
+
+
+ questioning end users as to how the TOE was
+ delivered.
+
+
+
+ For guidance on site visits see .
+
+ It may be the case of a newly developed TOE that the
+ delivery procedures have yet to be exercised. In these
+ cases, the evaluator has to be satisfied that
+ appropriate procedures and facilities are in place for
+ future deliveries and that all personnel involved are
+ aware of their responsibilities. The evaluator may
+ request a ``dry run'' of a delivery if this is
+ practical. If the developer has produced other similar
+ products, then an examination of procedures in their use
+ may be useful in providing assurance.
+
+
+
+ The delivery documentation shall describe all procedures
+ that are necessary to maintain security when distributing
+ versions of the TOE to the consumer.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the delivery documentation
+ to determine that it describes all procedures that are
+ necessary to maintain security when distributing
+ versions of the TOE or parts of it to the
+ consumer.
+
+ The delivery documentation describes proper procedures
+ to maintain security of the TOE during transfer of the
+ TOE or its component parts and to determine the
+ identification of the TOE.
+
+ The delivery documentation should cover the entire TOE,
+ but may contain different procedures for different parts
+ of the TOE. The evaluation should consider the totality
+ of procedures.
+
+ The delivery procedures should be applicable across all
+ phases of delivery from the production environment to
+ the installation environment (e.g. packaging, storage
+ and distribution). Standard commercial practise for
+ packaging and delivery may be acceptable. This includes
+ shrink wrapped packaging, a security tape or a sealed
+ envelope. For the distribution, physical (e.g. public
+ mail or a private distribution service) or electronic
+ (e.g. electronic mail or downloading off the Internet)
+ procedures may be used.
+
+ Cryptographic checksums or a software signature may be
+ used by the developer to ensure that tampering or
+ masquerading can be detected. Tamper proof seals
+ additionally indicate if the confidentiality has been
+ broken. For software TOEs, confidentiality might be
+ assured by using encryption. If availability is of
+ concern, a secure transportation might be
+ required.
+
+ Interpretation of the term ``necessary to maintain
+ security'' will need to consider:
+
+
+ The nature of the TOE (e.g. whether it is software
+ or hardware).
+
+
+ The overall security level stated for the TOE by the
+ chosen level of the Vulnerability Assessment. If the
+ TOE is required to be resistant against attackers of
+ a certain potential in its intended environment,
+ this should also apply to the delivery of the
+ TOE. The evaluator should determine that a balanced
+ approach has been taken, such that delivery does not
+ present a weak point in an otherwise secure
+ development process.
+
+
+ The security objectives provided by the ST. The emphasis in the
+ delivery documentation is likely to be on measures related to
+ integrity, as integrity of the TOE is always important. However,
+ confidentiality and availability of the delivery will be of
+ concern in the delivery of some TOEs; procedures relating to
+ these aspects of the secure delivery should also be discussed in
+ the procedures.
+
+
+
+
+
+
+
+
+
+ Development security is concerned with physical, procedural,
+ personnel, and other security measures that may be used in
+ the development environment to protect the TOE and its
+ parts. It includes the physical security of the development
+ location and any procedures used to select development
+ staff.
+
+
+
+ Development security covers the physical, procedural,
+ personnel, and other security measures used in the
+ development environment. It includes physical security of
+ the development location(s) and controls on the selection
+ and hiring of development staff.
+
+
+
+ The components in this family are levelled on the basis of
+ whether justification of the sufficiency of the security
+ measures is required.
+
+
+
+ This family deals with measures to remove or reduce threats
+ existing at the developer's site.
+
+ The evaluator should visit the site(s) in order to assess
+ evidence for development security. This may include sites of
+ subcontractors involved in the TOE development and
+ production. Any decision not to visit shall be agreed with
+ the evaluation authority.
+
+ Although development security deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, the requirements specify only that the
+ development security measures be in place at the time of
+ evaluation. Furthermore,
+ does not contain any requirements related to the sponsor's
+ intention to apply the development security measures in the
+ future, after completion of the evaluation.
+
+ It is recognised that confidentiality may not always be an
+ issue for the protection of the TOE in its development
+ environment. The use of the word ``necessary'' allows for
+ the selection of appropriate safeguards.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first referring to
+ the ST for any information that may assist in the determination
+ of necessary protection.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material within and out of
+ the development environment and between
+ different development sites in accordance with
+ defined acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ The evaluator should examine whether the following is included
+ in the policies:
+
+ what information relating to the TOE development needs to be
+ kept confidential, and which members of the development
+ staff are allowed to access such material;
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the , mandating only necessary measures, are
+ dependent on the nature of the TOE, and on information
+ that may be provided in the ST. For example, the ST may
+ identify a security objective for the development
+ environment that requires the TOE to be developed by
+ staff that has security clearance. The evaluators would
+ then determine that such a policy had been applied under
+ this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised. Additionally, sufficiency of the measures
+ as applied is intended be justified.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The development security documentation shall justify that
+ the security measures provide the necessary level of
+ protection to maintain the confidentiality and integrity of
+ the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first referring to
+ the ST for any information that may assist in the determination
+ of necessary protection.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material out of the
+ development environment and between different
+ development sites in accordance with defined
+ acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by the ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in the .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that an appropriate
+ justification is given why the security measures provide
+ the necessary level of protection to maintain the
+ confidentiality and integrity of the TOE.
+
+ Since attacks on the TOE or its related information are
+ assumed in different design and production stages,
+ measures and procedures need to have an appropriate
+ level necessary to prevent those attacks or to make them
+ more difficult.
+
+ Since this level depends on the overall attack potential
+ claimed for the TOE (cf. the component chosen), the development
+ security documentation should justify the necessary
+ level of protection to maintain the confidentiality and
+ integrity of the TOE. This level has to be achieved by
+ the security measures applied.
+
+ The concept of protection measures should be consistent,
+ and the justification should include an analysis of how
+ the measures are mutually supportive. All aspects of
+ development and production on all the different sites
+ with all roles involved up to delivery of the TOE should
+ be analysed.
+
+ Justification may include an analysis of potential
+ vulnerabilities taking the applied security measures
+ into account.
+
+ There may be a convincing argument showing that e.g.
+
+
+ The technical measures and mechanisms of the
+ developer's infrastructure are sufficient for
+ keeping the appropriate security level
+ (e.g. cryptographic mechanisms as well as physical
+ protection mechanisms, properties of the CM system
+ (cf. ));
+
+ The system containing the implementation
+ representation of the TOE (including concerning
+ guidance documents) provides effective protection
+ against logical attacks e.g. by ``Trojan'' code or
+ viruses. It might be adequate, if the implementation
+ representation is kept on an isolated system where
+ only the software necessary to maintain it is
+ installed and where no additional software is
+ installed afterwards.
+
+ Data brought into this system need to be carefully considered to
+ prevent the installation of hidden functionality onto the
+ system. The effectiveness of these measures need to be tested,
+ e.g. by independently trying to get access to the machine,
+ install some additional executable (program, macro etc.) or get
+ some information out of the machine using logical
+ attacks.
+
+ The appropriate organisational (procedural and
+ personal) measures are unconditionally
+ enforced.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ The evaluator should examine whether the following is included
+ in the policies:
+
+ what information relating to the TOE development needs to be
+ kept confidential, and which members of the development
+ staff are allowed to access such material;
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the , mandating only necessary measures, are
+ dependent on the nature of the TOE, and on information
+ that may be provided in the ST. For example, the ST may
+ identify a security objective for the development
+ environment that requires the TOE to be developed by
+ staff that has security clearance. The evaluators would
+ then determine that such a policy had been applied under
+ this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ Flaw remediation requires that discovered security flaws be
+ tracked and corrected by the developer. Although future
+ compliance with flaw remediation procedures cannot be
+ determined at the time of the TOE evaluation, it is possible
+ to evaluate the policies and procedures that a developer has
+ in place to track and correct flaws, and to distribute the
+ flaw information and corrections.
+
+
+
+ Flaw remediation ensures that flaws discovered by the TOE
+ consumers will be tracked and corrected while the TOE is
+ supported by the developer. While future compliance with the
+ flaw remediation requirements cannot be determined when a
+ TOE is evaluated, it is possible to evaluate the procedures
+ and policies that a developer has in place to track and
+ repair flaws, and to distribute the repairs to
+ consumers.
+
+
+
+ The components in this family are levelled on the basis of
+ the increasing extent in scope of the flaw remediation
+ procedures and the rigour of the flaw remediation
+ policies.
+
+
+
+ This family provides assurance that the TOE will be
+ maintained and supported in the future, requiring the TOE
+ developer to track and correct flaws in the
+ TOE. Additionally, requirements are included for the
+ distribution of flaw corrections. However, this family does
+ not impose evaluation requirements beyond the current
+ evaluation.
+
+ The TOE user is considered to be the focal point in the user
+ organisation that is responsible for receiving and
+ implementing fixes to security flaws. This is not
+ necessarily an individual user, but may be an organisational
+ representative who is responsible for the handling of
+ security flaws. The use of the term TOE user recognises that
+ different organisations have different procedures for
+ handling flaw reporting, which may be done either by an
+ individual user, or by a central administrative body.
+
+ The flaw remediation procedures should describe the methods
+ for dealing with all types of flaws encountered. These flaws
+ may be reported by the developer, by users of the TOE, or by
+ other parties with familiarity with the TOE. Some flaws may
+ not be reparable immediately. There may be some occasions
+ where a flaw cannot be fixed and other (e.g. procedural)
+ measures must be taken. The documentation provided should
+ cover the procedures for providing the operational sites
+ with fixes, and providing information on flaws where fixes
+ are delayed (and what to do in the interim) or when fixes
+ are not possible.
+
+ Changes applied to a TOE after its release render it
+ unevaluated; although some information from the original
+ evaluation may still apply. The phrase ``release of the
+ TOE'' used in this family therefore refers to a version of a
+ product that is a release of a certified TOE, to which
+ changes have been applied.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE users.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation.
+
+
+
+
+ The developer shall document flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+ While these requirements do not mandate that there be a
+ publicised means for TOE users to report security flaws,
+ they do mandate that all security flaws that are
+ reported be tracked. That is, a reported security flaw
+ cannot be ignored simply because it comes from outside
+ the developer's organisation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACK DOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer. Flaw remediation guidance from the developer to
+ the TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, and for assurance that the corrections introduce no
+ new security flaws.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that they describe procedures
+ for the developer to accept reports of security flaws or
+ requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure every reported flaw is
+ corrected.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is corrected. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+
+ The procedures describe the process that is taken from
+ the point at which a security flaw is resolved to the
+ point at which the remediation procedures are
+ provided. The procedures for delivering corrective
+ actions should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer, and how to register themselves with the
+ developer so that they may receive these corrective
+ fixes. Flaw remediation guidance from the developer to the
+ TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, for assurance that the corrections introduce no new
+ security flaws, for the establishment of a point of
+ contact for each TOE user, and for the timely issue of
+ corrective actions to TOE users.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The flaw remediation procedures shall include a procedure
+ requiring timely response and the automatic distribution of
+ security flaw reports and the associated corrections to
+ registered users who might be affected by the security flaw.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users may register with the developer, to be
+ eligible to receive security flaw reports and corrections.
+
+
+ The flaw remediation guidance shall identify the specific
+ points of contact for all reports and enquiries about
+ security issues involving the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+ For TOE users who register with the developer (see work
+ unit ), the
+ passive availability of this information is not
+ sufficient. Developers must actively send the
+ information (or a notification of its availability) to
+ registered TOE users.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a means for the developer to
+ receive from TOE user reports of suspected security
+ flaws or requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a timely means of providing
+ the registered TOE users who might be affected with
+ reports about, and associated corrections to, each
+ security flaw.
+
+ The issue of timeliness applies to the issuance of both
+ security flaw reports and the associated
+ corrections. However, these need not be issued at the
+ same time. It is recognised that flaw reports should be
+ generated and issued as soon as an interim solution is
+ found, even if that solution is as drastic as turn off
+ the TOE. Likewise, when a more permanent (and less
+ drastic) solution is found, it should be issued without
+ undue delay.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done in a timely manner.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in automatic distribution of the
+ reports and associated corrections to the registered TOE
+ users who might be affected.
+
+ Automatic distribution does not mean
+ that human interaction with the distribution method is
+ not permitted. In fact, the distribution method could
+ consist entirely of manual procedures, perhaps through a
+ closely monitored procedure with prescribed escalation
+ upon the lack of issue of reports or corrections.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done automatically.
+
+
+
+
+ The evaluator shall examine the flaw remediation procedures to
+ determine that the application of these procedures would help to
+ ensure that every reported flaw is corrected.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is remediated. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+ The procedures describe the process that is taken
+ from the point at which a security flaw is resolved to
+ the point at which the remediation procedures are
+ provided. The procedures for delivering remediation
+ procedures should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it describes a means of
+ enabling the TOE users to register with the
+ developer.
+
+ Enabling the TOE users to register with the
+ developer simply means having a way for each
+ TOE user to provide the developer with a point of
+ contact; this point of contact is to be used to
+ provide the TOE user with information related to
+ security flaws that might affect that TOE user, along
+ with any corrections to the security flaw. Registering
+ the TOE user may be accomplished as part of the
+ standard procedures that TOE users undergo to identify
+ themselves to the developer, for the purposes of
+ registering a software licence, or for obtaining
+ update and other useful information.
+
+ There need not be one registered TOE user per
+ installation of the TOE; it would be sufficient if there
+ were one registered TOE user for an organisation. For
+ example, a corporate TOE user might have a centralised
+ acquisition office for all of its sites. In this case,
+ the acquisition office would be a sufficient point of
+ contact for all of that TOE user's sites, so that all of
+ the TOE user's installations of the TOE have a
+ registered point of contact.
+
+ In either case, it must be possible to associate each
+ TOE that is delivered with an organisation in order to
+ ensure that there is a registered user for each TOE. For
+ organisations that have many different addresses, this
+ assures that there will be no user who is erroneously
+ presumed to be covered by a registered TOE user.
+ It should be noted that TOE users need not
+ register; they must only be provided with a means of
+ doing so. However, users who choose to register must be
+ directly sent the information (or a notification of its
+ availability).
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it identifies specific points
+ of contact for user reports and enquiries about security
+ issues involving the TOE.
+
+ The guidance includes a means whereby registered TOE
+ users can interact with the developer to report
+ discovered security flaws in the TOE or to make
+ enquiries regarding discovered security flaws in the
+ TOE.
+
+
+
+
+
+
+
+ Poorly controlled development and maintenance of the TOE can
+ result in a TOE that does not meet all of its
+ SFRs. Therefore, it is important that a model for the
+ development and maintenance of a TOE be established as early
+ as possible in the TOE's life-cycle.
+
+ Using a model for the development and maintenance of a TOE
+ does not guarantee that the TOE meets all of its SFRs. It is
+ possible that the model chosen will be insufficient or
+ inadequate and therefore no benefits in the quality of the
+ TOE can be observed. Using a life-cycle model that has been
+ approved by a group of experts (e.g. academic experts,
+ standards bodies) improves the chances that the development
+ and maintenance models will contribute to the TOE meeting
+ its SFRs. The use of a life-cycle model including some
+ quantitative valuation adds further assurance in the overall
+ quality of the TOE development process.
+
+
+
+ Life-cycle definition establishes that the engineering
+ practises used by a developer to produce the TOE include the
+ considerations and activities identified in the development
+ process and operational support requirements. Confidence in
+ the correspondence between the requirements and the TOE is
+ greater when quality control and the production of evidence
+ are done on a regular basis as an integral part of the
+ development process and operational support activities. It
+ is not the intent of this component to dictate any specific
+ development process.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements for measurability of the life-cycle
+ model, and for compliance with that model.
+
+
+
+ A life-cycle model encompasses the procedures, tools and
+ techniques used to develop and maintain the TOE. Aspects of
+ the process that may be covered by such a model include
+ design methods, review procedures, project management
+ controls, change control procedures, test methods and
+ acceptance procedures. An effective life-cycle model will
+ address these aspects of the development and maintenance
+ process within an overall management structure that assigns
+ responsibilities and monitors progress.
+
+ There are different types of acceptance situations that are
+ dealt with at different locations in the criteria:
+ acceptance of parts delivered by subcontractors
+ (``integration'') should be treated in this family , acceptance subsequent to
+ internal transportations in , acceptance of parts into the CM system in
+ , and acceptance of the
+ delivered TOE by the consumer in . The first three types may overlap.
+
+ Although life-cycle definition deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, its evaluation adds assurance
+ through an analysis of the life-cycle information for the
+ TOE provided at the time of the evaluation.
+
+ A life-cycle model provides for the necessary control over
+ the development and maintenance of the TOE, if the model
+ enables sufficient minimisation of the danger that the TOE
+ will not meet its security requirement.
+
+ A measurable life-cycle model is a model using some
+ quantitative valuation (arithmetic parameters and/or
+ metrics) of the managed product in order to measure
+ development properties of the product. Typical metrics are
+ source code complexity metrics, defect density (errors per
+ size of code) or mean time to failure. For the security
+ evaluation all those metrics are of relevance, which are
+ used to increase quality by decreasing the probability of
+ faults and thereby in turn increasing assurance in the
+ security of the TOE.
+
+ One should take into account that there exist standardised
+ life cycle models on the one hand (like the waterfall model)
+ and standardised metrics on the other hand (like error
+ density), which may be combined. The CC does not require the
+ life cycle to follow exactly one standard defining both
+ aspects.
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented model of the
+ TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process.
+
+ The description of the life-cycle model should include:
+
+
+ information on the life-cycle phases of the TOE and
+ the boundaries between the subsequent phases;
+
+
+ information on the procedures, tools and techniques
+ used by the developer (e.g. for design, coding,
+ testing, bug-fixing);
+
+
+ overall management structure governing the
+ application of the procedures (e.g. an
+ identification and description of the individual
+ responsibilities for each of the procedures required
+ by the development and maintenance process covered
+ by the life-cycle model);
+
+
+ information on which parts of the TOE are delivered
+ by subcontractors, if subcontractors are involved.
+
+
+
+ does not require the
+ model used to conform to any standard life-cycle
+ model.
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented and measurable
+ model of the TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation;
+
+
+ information about the standard used;
+
+
+ the life-cycle output documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE, that is based
+ on a measurable life-cycle model.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The developer shall measure the TOE development using the
+ measurable life-cycle model.
+
+
+ The developer shall provide life-cycle output documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE, including the
+ details of its arithmetic parameters and/or metrics used to
+ measure the quality of the TOE and/or its development.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The life-cycle output documentation shall provide the
+ results of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process, including the
+ details of its arithmetic parameters and/or metrics used
+ to measure the TOE development.
+
+ The description of the life-cycle model includes:
+
+ information on the life-cycle phases of the TOE and the
+ boundaries between the subsequent phases;
+
+ information on the procedures, tools and techniques used by
+ the developer (e.g. for design, coding, testing,
+ bug-fixing);
+
+ overall management structure governing the application of
+ the procedures (e.g. an identification and description of
+ the individual responsibilities for each of the procedures
+ required by the development and maintenance process covered
+ by the life-cycle model);
+
+ information on which parts of the TOE are delivered by
+ subcontractors, if subcontractors are involved;
+
+ information on the parameters/metrics that are used to
+ measure the TOE development. Metrics standards typically
+ include guides for measuring and producing reliable products
+ and cover the aspects reliability, quality, performance,
+ complexity and cost. For the evaluation all those metrics
+ are of relevance, which are used to increase quality by
+ decreasing the probability of faults and thereby in turn
+ increase assurance in the security of the TOE.
+
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+ For the metrics/measurements used in the life-cycle
+ model, evidence has to be provided that shows how those
+ metrics/measurements usefully contribute to the
+ minimisation of the likelihood of flaws. This can be
+ viewed as the overall goal for measurement in an context. As a consequence the
+ metrics/measurements have to be selected based on their
+ capability to achieve that overall goal or contribute to
+ that. In the first place a metric/measure is suitable
+ with respect to if a
+ correlation between the metric/measure and the number of
+ flaws can be stated with a certain degree of
+ reliability. But also a metric/measure useful for
+ management purposes as for planning and monitoring the
+ TOE development are helpful since badly managed projects
+ are endangered to produce bad quality and to introduce
+ flaws.
+
+ It may be possible to use metrics for quality
+ improvement, for which this use is not obvious. For
+ example a metric to estimate the expected cost of a
+ product development may help quality, if the developer
+ can show that this is used to provide an adequate budget
+ for development projects and that this helps to avoid
+ quality problems arising from resource shortages.
+
+ It is not required that every single step in the life
+ cycle of the TOE is measurable. However the evaluator
+ should see from the description of the measures and
+ procedures that the metrics are appropriate to control
+ the overall quality of the TOE and to minimise possible
+ security flaws by this.
+
+
+
+
+ The evaluator shall examine the life-cycle output
+ documentation to determine that it provides the results
+ of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+ The output documentation not only includes numeric values of the
+ metrics but also documents actions taken as a result of the
+ measurements and in accordance with the model. For example there
+ may be a requirement that a certain design phase needs to be
+ repeated, if some error rates measured during testing are
+ outside of a defined threshold. In this case the documentation
+ should show that such action was taken, if indeed the thresholds
+ were not met.
+
+ The output documentation should not only include numeric
+ values of the metrics but should also document actions
+ taken as a result of the measurements and in accordance
+ with the model. For example there may be a requirement
+ that a certain design phase needs to be repeated, if
+ some error rates measured during testing are outside of
+ a defined threshold. In this case the documentation
+ should show that such action was taken, if indeed the
+ thresholds were not met.
+
+ If the evaluation is conducted in parallel with the
+ development of the TOE it may be possible that quality
+ measurements have not been used in the past. In this
+ case the evaluator should use the documentation of the
+ planned procedures in order to gain confidence that
+ corrective actions are defined if results of quality
+ measurements deviate from some threshold.
+
+
+
+
+
+
+
+ Tools and techniques is an aspect of selecting tools that
+ are used to develop, analyse and implement the TOE. It
+ includes requirements to prevent ill-defined, inconsistent
+ or incorrect development tools from being used to develop
+ the TOE. This includes, but is not limited to, programming
+ languages, documentation, implementation standards, and
+ other parts of the TOE such as supporting runtime
+ libraries.
+
+
+
+ Tools and techniques addresses the need to define the
+ development tools being used to analyse and implement the
+ TOE. It includes requirements concerning the development
+ tools and implementation dependent options of those
+ tools.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements on the description and scope of the
+ implementation standards and the documentation of
+ implementation-dependent options.
+
+
+
+ There is a requirement for well-defined development
+ tools. These are tools that are clearly and completely
+ described. For example, programming languages and computer
+ aided design (CAD) systems that are based on a standard
+ published by standards bodies are considered to be
+ well-defined. Self-made tools would need further
+ investigation to clarify whether they are
+ well-defined.
+
+ The requirement in is
+ especially applicable to programming languages so as to
+ ensure that all statements in the source code have an
+ unambiguous meaning.
+
+ In and , implementation guidelines may be accepted
+ as an implementation standard if they have been approved by
+ some group of experts (e.g. academic experts, standards
+ bodies). Implementation standards are normally public, well
+ accepted and common practise in a specific industry, but
+ developer-specific implementation guidelines may also be
+ accepted as a standard; the emphasis is on the
+ expertise.
+ Tools and techniques distinguishes between the
+ implementation standards applied by the developer () and the implementation
+ standards for ``all parts of the TOE'' () which include third party software,
+ hardware, or firmware. The configuration list introduced in
+ requires that for each TSF
+ relevant configuration item to indicate if it has been
+ generated by the TOE developer or by third party
+ developers.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable
+ results.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the subset of the implementation representation.
+
+
+
+
+ The developer shall identify each development tool being
+ used for the TOE.
+
+
+ The developer shall document the selected
+ implementation-dependent options of each development tool.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tools is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable results,
+ and whether implementation standards have been
+ applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall identify each development tool being
+ used for the TOE.
+
+
+ The developer shall document the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe the implementation standards
+ that are being applied by the developer.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is not required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, but only those parts
+ that are developed by the TOE developer himself. The
+ evaluator may consult the configuration list required by
+ the to get the
+ information which parts are developed by the TOE
+ developer, and which by third party developers.
+
+ If the referenced implementation standards are not
+ applied for at least parts of the provided implementation representation,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer and his subcontractors have used
+ well-defined development tools (e.g. programming languages
+ or computer-aided design (CAD) systems) that yield
+ consistent and predictable results, and whether
+ implementation standards have been applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall identify each development tool being
+ used for the TOE.
+
+
+ The developer shall document the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe the implementation standards
+ that are being applied by the developer and by any
+ third-party providers for all parts of the TOE.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, including third party
+ contributions. This may require the evaluator to visit
+ the sites of contributors. The evaluator may consult the
+ configuration list required by the to see who has developed which part of
+ the TOE.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more other PPs or on packages, that the PP is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ writing an ST or another PP.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an PP to demonstrate that
+ the PP is sound and internally consistent, and, if the PP is
+ based on one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of a PP. The
+ requirements and methodology for PP evaluation are identical
+ for each PP evaluation, regardless of the EAL (or other set of
+ assurance requirements) that is claimed in the PP. The
+ evaluation methodology in this Clause is based on the
+ requirements on the PP as specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The PP is the description of a TOE type. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ an ST or another PP.
+
+
+
+
+ While evaluating a PP that is based on one or more certified
+ PPs, it may be possible to re-use the fact that these PPs were
+ certified. The potential for re-use of the result of a certified
+ PP is greater if the PP under evaluation does not add threats,
+ OSPs, security objectives and/or security requirements to those
+ of the PP that conformance is being claimed to. If the PP under
+ evaluation contains much more than the certified PP, re-use may
+ not be useful at all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP that conformance is being
+ claimed to contains a set of security requirements, and these
+ were determined to be internally consistent during its
+ evaluation. If the PP under evaluation uses the exact same
+ requirements, the consistency analysis does not have to be
+ repeated during the PP evaluation. If the PP under evaluation
+ adds one or more requirements, or performs operations on these
+ requirements, the analysis will have to be repeated. However, it
+ may be possible to save work in this consistency analysis by
+ using the fact that the original requirements are internally
+ consistent. If the original requirements are internally
+ consistent, the evaluator only has to determine that:
+
+ the set of all new and/or changed requirements is internally
+ consistent, and
+
+ the set of all new and/or changed requirements is consistent
+ with the original requirements.
+
+ The evaluator notes in the ETR each case where analyses
+ are not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way.
+
+ Evaluation of the PP introduction is required to demonstrate
+ that the PP is correctly identified, and that the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The PP introduction describes the TOE in a narrative
+ way.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the PP is correctly identified, and whether the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a PP introduction.
+
+
+ The PP introduction shall contain a PP reference and a TOE
+ overview.
+
+
+ The PP reference shall uniquely identify the PP.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware available to the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the PP introduction
+ contains a PP reference and a TOE overview.
+
+
+
+
+ The evaluator shall examine the PP reference to
+ determine that it uniquely identifies the PP.
+
+ The evaluator determines that the PP reference
+ identifies the PP itself, so that it may be easily
+ distinguished from other PPs, and that it also uniquely
+ identifies each version of the PP, e.g. by including a
+ version number and/or a date of publication.
+
+ The PP should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features expected of the TOE. The TOE overview should
+ enable consumers and potential TOE developers to quickly
+ determine whether the PP is of interest to them.
+
+ The evaluator determines that the overview is clear
+ enough for TOE developers and consumers, and sufficient
+ to give them a general understanding of the intended
+ usage and major security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware available to the TOE.
+
+ While some TOEs may run stand-alone, other TOEs (notably
+ software TOEs) need additional hardware, software or
+ firmware to operate. In this subclause of the PP, the PP
+ author lists all hardware, software, and/or firmware
+ that will be available for the TOE to run on.
+
+ This identification should be detailed enough for
+ potential consumers and TOE developers to determine
+ whether their TOE may operate with the listed hardware,
+ software and firmware.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs and other PPs are to claim conformance with the
+ PP.
+
+
+
+ Conformance claims describes how the Protection Profile
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the PP conforms to the CC, other PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP;
+
+
+ the PP(s) that the PP claims conformance to;
+
+
+ the package(s) that the PP claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The developer shall provide a conformance statement.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the PP claims
+ conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the PP claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ PP to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance statement shall describe the conformance
+ required of any PPs/STs to the PP as strict-PP or
+ demonstrable-PP conformance.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the PP claims
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this PP. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the PP.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the PP.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the PP claims conformance.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+ The evaluator determines that any referenced PPs
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the PP claims conformance.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The relation between the types may be simple: a firewall
+ PP claiming conformance to another firewall PP, or more
+ complex: a smart card PP claiming conformance to a number
+ of other PPs at the same time: a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the PP under evaluation does not claim conformance
+ with another PP, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If the PP to which conformance is being claimed does not
+ have a statement of security problem definition, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether
+
+
+ the threats in the PP under evaluation are a
+ superset of or identical to the threats in the PP to
+ which conformance is being claimed;
+
+
+ the OSPs in the PP under evaluation are a superset
+ of or identical to the OSPs in the PP to which
+ conformance is being claimed;
+
+
+ the assumptions in the PP under evaluation are
+ identical to the assumptions in the PP to which conformance
+ is being claimed;
+
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ problem definition of the PP under evaluation is
+ equivalent or more restrictive than the statement of
+ security problem definition in the PP to which
+ conformance is being claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PPs, with the statement of security
+ objectives in the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether:
+
+ The PP under evaluation contains all security
+ objectives for the TOE of the PP to which
+ conformance is being claimed. Note that it is
+ allowed for the PP under evaluation to have
+ additional security objectives for the TOE;
+ The PP under evaluation contains exactly all
+ security objectives for the operational environment
+ (with one exception in the next bullet). Note that
+ it is not allowed for the PP under evaluation to
+ have additional security objectives for the
+ operational environment;
+ The PP under evaluation may specify that certain
+ objectives for the operational environment in the PP
+ that conformance is being claimed to are security
+ objectives for the TOE in the PP under
+ evaluation. This is a valid exception to the
+ previous bullet.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ objectives in the PP to which conformance is being
+ claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+
+
+ The evaluator shall examine the PP to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the PP
+ under evaluation is a superset of or identical to the
+ statement of security requirements in the PP to which
+ conformance is being claimed (for strict
+ conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ requirements in the PP to which conformance is being
+ claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+
+
+
+ The evaluator shall check that the PP conformance
+ statement states a claim of strict-PP or demonstrable-PP
+ conformance.
+
+
+
+
+
+
+
+ This part of the PP defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or its operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and/or threats only, OSPs need not be present in the
+ PP. In this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition and that
+ the division of this problem between the TOE and its
+ operational environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat, the evaluator action
+ related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP, the evaluator action
+ related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ If no security objectives for the operational environment trace back to the assumption,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author. This family is used to determine that these extended
+ components are defined similarly to the existing CC Part 2
+ or CC Part 3 components.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the PP.
+
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the PP, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the PP defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+
+ a member of a new class defined in the PP.
+
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ PP, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the PP author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the PP does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations,
+ the evaluator determines that the extended functional
+ component is consistent with CC Part 1 .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the PP does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the PP does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance
+ component is consistent with CC Part 1 .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the PP does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the PP does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance to
+ this requirement.
+
+
+
+ The evaluator shall confirm that no extended component may
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component may
+ not be clearly expressed using existing
+ components.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the PP, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is, or whether the SFRs are derived from
+ security objectives for the TOE.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.Guidance on the
+ correct performance of operations may be found in CC
+ Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it justifies that the SFRs are suitable to
+ meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the TOE,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ If the SFRs that trace back to a security objective for
+ the TOE have any uncompleted assignments, or uncompleted
+ or restricted selections, the evaluator determines that
+ for every conceivable completion or combination of
+ completions of these operations, the security objective
+ is still met.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+ The evaluator is reminded that any explanation is
+ correct, as long as it is coherent and neither the SARs
+ nor the explanation have obvious inconsistencies with
+ the remainder of the PP.
+ An example of an obvious inconsistency between the
+ SARs and the remainder of the PP would be to have threat
+ agents that are very capable, but an SAR that does not protect against these
+ threat agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an ST, to demonstrate that
+ the ST is sound and internally consistent, and, if the ST is
+ based on one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of an ST. The ST
+ evaluation should be started prior to any TOE evaluation
+ sub-activities since the ST provides the basis and context to
+ perform these sub-activities. The evaluation methodology in
+ this subclause is based on the requirements on the ST as
+ specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The ST describes the security features of a TOE. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+
+
+
+ While evaluating an ST that is based on one or more
+ certified PPs, it may be possible to re-use the fact that
+ these PPs were certified. The potential for re-use of the
+ result of a certified PP is greater if the ST does not add
+ threats, OSPs, assumptions, security objectives and/or
+ security requirements to those of the PP. If the ST
+ contains much more than the certified PP, re-use may not be
+ useful at all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP contains a set of security
+ requirements, and these were determined to be internally
+ consistent during the PP evaluation. If the ST uses the
+ exact same requirements, the consistency analysis does not
+ have to be repeated during the ST evaluation. If the ST adds
+ one or more requirements, or performs operations on these
+ requirements, the analysis will have to be
+ repeated. However, it may be possible to save work in this
+ consistency analysis by using the fact that the original
+ requirements are internally consistent. If the original
+ requirements are internally consistent, the evaluator only
+ has to determine that:
+
+
+ the set of all new and/or changed requirements is
+ internally consistent, and
+
+
+ the set of all new and/or changed requirements is
+ consistent with the original requirements.
+
+
+ The evaluator notes in the ETR each case where analyses are
+ not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way on three levels of abstraction: TOE reference,
+ TOE overview and TOE description.
+
+ Evaluation of the ST introduction is required to demonstrate
+ that the ST and the TOE are correctly identified, that the
+ TOE is correctly described at three levels of abstraction
+ and that these three descriptions are consistent with each
+ other.
+
+
+
+ The ST introduction describes the TOE in a narrative way on
+ three levels of abstraction: TOE reference, TOE overview and
+ TOE description.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the ST and the TOE are correctly identified, whether the
+ TOE is correctly described in a narrative way at three
+ levels of abstraction (TOE reference, TOE overview and TOE
+ description), and whether these three descriptions are
+ consistent with each other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide an ST introduction.
+
+
+ The ST introduction shall contain an ST reference, a TOE
+ reference, a TOE overview and a TOE description.
+
+
+ The ST reference shall uniquely identify the ST.
+
+
+ The TOE reference shall identify the TOE.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware required by the TOE.
+
+
+ The TOE description shall describe the physical scope of the
+ TOE.
+
+
+ The TOE description shall describe the logical scope of the
+ TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the ST introduction
+ contains an ST reference, a TOE reference, a TOE
+ overview and a TOE description.
+
+
+
+
+ The evaluator shall examine the ST reference to
+ determine that it uniquely identifies the ST.
+
+ The evaluator determines that the ST reference
+ identifies the ST itself, so that it may be easily
+ distinguished from other STs, and that it also uniquely
+ identifies each version of the ST, e.g. by including a
+ version number and/or a date of publication.
+
+ In evaluations where a CM system is provided, the
+ evaluator may validate the uniqueness of the reference
+ by checking the configuration list. In the other cases,
+ the ST should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it identifies the TOE.
+
+ The evaluator determines that the TOE reference
+ identifies the TOE, so that it is clear to which TOE the
+ ST refers, and that it also identifies the version of
+ the TOE, e.g. by including a version/release/build
+ number, or a date of release.
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it is not misleading.
+
+ If the TOE is related to one or more well-known
+ products, it is allowed to reflect this in the TOE
+ reference. However, this should not be used to mislead
+ consumers: situations where only a small part of a
+ product is evaluated, yet the TOE reference does not
+ reflect this, are not allowed.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features of the TOE. The TOE overview should enable
+ potential consumers to quickly determine whether the TOE
+ may be suitable for their security needs.
+
+ The TOE overview in an ST for a composed TOE should
+ describe the usage and major security feature of the
+ composed TOE, rather than those of the individual
+ component TOEs.
+
+ The evaluator determines that the overview is clear
+ enough for consumers, and sufficient to give them a
+ general understanding of the intended usage and major
+ security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that the TOE type is not misleading.
+
+ There are situations where the general consumer would
+ expect certain functionality of the TOE because of its
+ TOE type. If this functionality is absent in the TOE,
+ the evaluator determines that the TOE overview
+ adequately discusses this absence.
+
+ There are also TOEs where the general consumer would
+ expect that the TOE should be able to operate in a
+ certain operational environment because of its TOE
+ type. If the TOE is unable to operate in such an
+ operational environment, the evaluator determines that
+ the TOE overview adequately discusses this.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware required by the TOE.
+
+ While some TOEs are able to run stand-alone, other TOEs
+ (notably software TOEs) need additional hardware,
+ software or firmware to operate. If the TOE does not
+ require any hardware, software or firmware, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the TOE overview
+ identifies any additional hardware, software and
+ firmware needed by the TOE to operate. This
+ identification does not have to be exhaustive, but
+ detailed enough for potential consumers of the TOE to
+ determine whether their current hardware, software and
+ firmware support use of the TOE, and, if this is not the
+ case, which additional hardware, software and/or
+ firmware is needed.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the physical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description lists
+ the hardware, firmware, software and guidance parts that
+ constitute the TOE and describes them at a level of
+ detail that is sufficient to give the reader a general
+ understanding of those parts.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any hardware, firmware,
+ software or guidance part is part of the TOE or
+ not.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the logical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description
+ discusses the logical security features offered by the
+ TOE at a level of detail that is sufficient to give the
+ reader a general understanding of those features.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any logical security
+ feature is offered by the TOE or not.
+
+ An ST for a composed TOE may refer out to the
+ description of the logical scope of the component TOEs,
+ provided in the component TOE STs to provide the
+ majority of this description for the composed TOE.
+ However, the evaluator determines that the composed TOE
+ ST clearly discusses which features of the individual
+ components are not within the composed TOE, and
+ therefore not a feature of the composed TOE.
+
+
+
+ The evaluator shall confirm that the TOE reference, the TOE
+ overview, and the TOE description are consistent with each
+ other.
+
+
+ The evaluator shall examine the TOE reference, TOE
+ overview and TOE description to determine that they are
+ consistent with each other.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs are to claim conformance with the PP.
+
+
+
+ Conformance claims describes how the Security Target
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the ST and the TOE conform to the CC and how the ST
+ conforms to PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the PP(s) that the ST claims conformance to;
+
+
+ the package(s) that the ST claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the ST and
+ the TOE claim conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the ST claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ ST to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the ST and the TOE claim
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this ST. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+ For a composed TOE, the evaluator will consider any
+ differences between the version of the CC claimed for a
+ component and the version of the CC claimed for the
+ composed TOE. If the versions differ the evaluator will
+ assess whether the differences between the versions will
+ lead to conflicting claims.
+
+ For instances where the CC conformance claims for the
+ base TOE and dependent TOE are for different major
+ releases of the CC (e.g. one component TOE conformance
+ claim is CC v2.x and the other component TOE conformance
+ claim is CC v3.x), the conformance claim for the
+ composed TOE will be the earlier release of the CC, as
+ the CC is developed with an aim to provide backwards
+ compatibility (although this may not be achieved in the
+ strictest sense, it is understood to be achieved in
+ principle).
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the ST.
+
+ For a composed TOE, the evaluator will consider whether
+ this claim is consistent not only with the CC Part 2,
+ but also with the claims of conformance to CC Part 2 by
+ each of the component TOEs. I.e. if one or more
+ component TOEs claims to be CC Part 2 extended, then the
+ composed TOE should also claim to be CC Part 2
+ extended.
+
+ The CC conformance claim for the composed TOE may be CC
+ Part 2 extended, even though the component TOEs are Part
+ 2 conformant, in the event that additional SFRs are
+ claimed for the base TOE (see composed TOE guidance for
+ )
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the ST.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the ST claims conformance.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that any referenced PPs are
+ unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted. Therefore,
+ conformance to a PP requiring a composite solution may
+ be claimed in an ST for a composed TOE. Conformance to
+ such a PP would not have been possible during the
+ evaluation of the component TOEs, as these components
+ would not have satisfied the composed solution. This is
+ only possible in the instances where the ``composite'' PP
+ permits use of the composition evaluation approach (use
+ of components).
+
+ The ST for a composed TOE will identify the STs of the
+ component TOEs from which the composed ST is comprised.
+ The composed TOE is essentially claiming conformance to
+ the STs of the component TOEs.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the ST claims conformance.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator determines that the component TOE STs from
+ which the composed TOE is derived are also unambiguously
+ identified.
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the ST
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package then the ST
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The relation between the types may be simple: a firewall
+ ST claiming conformance to a firewall PP, or more
+ complex: a smart card ST claiming conformance to a number
+ of PPs at the same time (a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card).
+
+ For a composed TOE, the evaluator will determine whether
+ the conformance claim rationale demonstrates that the
+ TOE types of the component TOEs are consistent with the
+ composed TOE type. This does not mean that both the
+ component and the composed TOE types have to be the
+ same, but rather that the component TOEs are suitable
+ for integration to provide the composed TOE. It should be made clear in the composed TOE ST which SFRs are only included as a result of composition, and were not examined as SFRs in the base and dependent TOE (e.g. EALx) evaluation.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the ST does not claim conformance with a PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the PP does not have a statement of security problem
+ definition, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether:
+
+
+ the threats in the ST are a superset of or identical
+ to the threats in the PP to which conformance is
+ being claimed;
+
+
+ the OSPs in the ST are a superset of or identical to
+ the OSPs in the PP to which conformance is being
+ claimed;
+
+ the assumptions in the ST are identical to the
+ assumptions in the PP to which conformance is being
+ claimed;
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security problem definition of the ST is equivalent or
+ more restrictive than the statement of security problem
+ definition in the PP to which conformance is being
+ claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+ For a composed TOE, the evaluator will consider whether
+ the security problem definition of the composed TOE is
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ Threat statements and OSPs in the composed TOE ST do
+ not contradict those from the component STs.
+
+ Any assumptions made in the component STs are upheld
+ in the composed TOE ST. That is, either the
+ assumption should also be present in the composed
+ ST, or the assumption should be positively addressed
+ in the composed ST. The assumption may be
+ positively addressed through specification of
+ requirements in the composed TOE to provide
+ functionality fulfilling the concern captured in the
+ assumption.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PP, with the statement of security
+ objectives in the PPs to which conformance is being claimed.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP, no
+ conformance claim rationale is required. Instead, the
+ evaluator determines whether:
+
+ The ST contains all security objectives for the
+ TOE of the PP to which conformance is being
+ claimed. Note that it is allowed for the ST under
+ evaluation to have additional security objectives
+ for the TOE;
+ The ST contains exactly all security objectives
+ for the operational environment (with one exception
+ in the next bullet). Note that it is not allowed for
+ the ST under evaluation to have additional security
+ objectives for the operational environment;
+ The ST may specify that certain objectives for
+ the operational environment in the PP that
+ conformance is being claimed to are security
+ objectives for the TOE in the ST. This is a valid
+ exception to the previous bullet.
+
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the ST is equivalent or more restrictive
+ than the statement of security objectives in the PP to
+ which conformance is being claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+ For a composed TOE, the evaluator will consider whether
+ the security objectives of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment are consistent with the
+ statement of security objectives for the TOE in the
+ base TOE ST. It is not expected that the statement
+ of security objectives for the environment within in
+ the dependent TOE ST will cover all aspects of the
+ statement of security objectives for the TOE in the
+ base TOE ST.
+
+ The statement of security objectives in the composed
+ ST is consistent with the statements of security
+ objectives in the STs for the component TOEs.
+
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security objectives of the ST is at least equivalent to
+ the statement of security objectives in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+ The evaluator shall examine the ST to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the ST
+ is a superset of or identical to the statement of
+ security requirements in the PP to which conformance is
+ being claimed (for strict conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is equivalent or more restrictive
+ than the statement of security requirements in the PP to
+ which conformance is being claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+ For a composed TOE, the evaluator will consider whether
+ the security requirements of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance rationale to determine that:
+
+
+ The statement of security requirements in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security requirements for the
+ environment within in the dependent TOE ST will
+ cover all aspects of the statement of security
+ requirements for the TOE in the base TOE ST, as
+ some SFRs may need to be added to the statement of
+ security requirements in the composed TOE ST.
+ However, the statement of security requirements in
+ the base should support the operation of the dependent
+ component.
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security objectives for the environment
+ within in the dependent TOE ST will cover all
+ aspects of the statement of security requirements
+ for the TOE in the base TOE ST.
+
+ The statement of security requirements in the
+ composed is consistent with the statements of
+ security requirements in the STs for the component
+ TOEs.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is at least equivalent to the
+ statement of security requirements in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+
+
+
+ This part of the ST defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and threats only, OSPs need not be present in the ST. In
+ this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition, that the
+ division of this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ if no security objectives for the operational environment trace back to the assumption,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the ST
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended components are defined wherever it is impossible to
+ clearly express requirements using only components from CC
+ Part 2 and/or CC Part 3.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the ST.
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the ST, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the ST defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+ a member of a new class defined in the ST.
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ ST, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the ST author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the ST does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations,
+ the evaluator determines that the extended functional
+ component is consistent with CC Part 1 .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the ST does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the ST does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance
+ component is consistent with CC Part 1 Subclause .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the ST does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the ST does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance
+ with this requirement.
+
+
+
+ The evaluator shall confirm that no extended component can
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component can
+ not be clearly expressed using existing
+ components.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the ST, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and canonical
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that a
+ security requirements rationale is provided which justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+ All subjects, objects,
+ operations, security attributes, external entities and other
+ terms that are used in the SFRs and the SARs shall be
+ defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFRs is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that all SARs are identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be
+ found in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it demonstrates that the SFRs are suitable
+ to meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the TOE,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+
+ The evaluator is reminded that any explanation is correct, as
+ long as it is coherent and neither the SARs nor the explanation
+ have obvious inconsistencies with the remainder of the ST.
+
+ An example of an obvious inconsistency between the SARs and the
+ remainder of the ST would be to have threat agents that are very
+ capable, but an SAR that does not
+ protect against these threat agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended assurance requirement
+ specifying an open source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+ The TOE summary specification enables evaluators and
+ potential consumers to gain a general understanding of how
+ the TOE is implemented.
+
+ Evaluation of the TOE summary specification is necessary to
+ determine whether it is adequately described how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass. and whether the TOE
+ summary specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The TOE Summary specification allows evaluators and
+ potential consumers of the TOE to gain a general
+ understanding of how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass.
+
+
+
+ The components in this family are levelled on whether the
+ TOE summary specification only needs to describe how the TOE
+ meets the SFRs, or whether the TOE summary specification
+ also needs to describe how the TOE protects itself against
+ logical tampering and bypass. This additional description
+ may be used in special circumstances where there might be a
+ specific concern regarding the TOE security architecture.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, and
+ whether the TOE summary specification is consistent with
+ other narrative descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ satisfy each SFR and that the descriptions therefore
+ should not be overly detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, whether
+ the TOE summary specification addresses interference,
+ logical tampering and bypass, and whether the TOE summary
+ specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against interference and logical tampering.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against bypass.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ satisfy each SFR and that the descriptions therefore
+ should not be overly detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against interference and logical
+ tampering.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against interference and logical
+ tampering and that the descriptions therefore should not
+ be overly detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against bypass.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against bypass and that the
+ descriptions therefore should not be overly
+ detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+ The class ``Tests'' encompasses four families: , ,
+ (i.e. functional testing
+ performed by evaluators), and . Testing provides assurance that the TSF
+ behaves as described (in the functional specification, TOE
+ design, and implementation representation).
+
+ The emphasis in this class is on confirmation that the TSF
+ operates according to its design descriptions. This class does
+ not address penetration testing, which is based upon an
+ analysis of the TSF that specifically seeks to identify
+ vulnerabilities in the design and implementation of the
+ TSF. Penetration testing is addressed separately as an aspect
+ of vulnerability assessment in the class.
+
+ The class separates testing into
+ developer testing and evaluator testing. The and families address the completeness of developer
+ testing. addresses the rigour
+ with which the functional specification is tested; addresses whether testing against
+ other design descriptions (security architecture, TOE design,
+ implementation representation) is required.
+
+ addresses the performing of
+ the tests by the developer and how this testing should be
+ documented. Finally, then
+ addresses evaluator testing: whether the evaluator should
+ repeat part or all of the developer testing and how much
+ independent testing the evaluator should do.
+
+
+
+ Assurance class states testing
+ requirements that demonstrate that the TOE matches its design
+ descriptions as provided in the
+ class.
+
+
+
+ The goal of this activity is to determine whether the TOE
+ behaves as described in the ST and as specified in the
+ evaluation evidence (described in the class). This determination is achieved through
+ some combination of the developer's own functional testing of
+ the TSF () and independent
+ testing the TSF by the evaluator (). At the lowest level of assurance, there is no
+ requirement for developer involvement, so the only testing is
+ conducted by the evaluator, using the limited available
+ information about the TOE. Additional assurance is gained as
+ the developer becomes increasingly involved both in testing
+ and in providing additional information about the TOE, and as
+ the evaluator increases the independent testing
+ activities.
+
+
+
+ Testing of the TSF is conducted by the evaluator and, in most
+ cases, by the developer. The evaluator's testing efforts
+ consist not only of creating and running original tests, but
+ also of assessing the adequacy of the developer's tests and
+ re-running a subset of them.
+
+ The evaluator analyses the developer's tests to determine the
+ extent to which they are sufficient to demonstrate that TSFI
+ (see ) perform as specified,
+ and to understand the developer's approach to
+ testing. Similarly, the evaluator analyses the developer's
+ tests to determine the extent to which they are sufficient to
+ demonstrate the internal behaviour and properties of the
+ TSF.
+ The evaluator also executes a subset of the developer's
+ tests as documented to gain confidence in the developer's test
+ results: the evaluator will use the results of this analysis
+ as an input to independently testing a subset of the TSF. With
+ respect to this subset, the evaluator takes a testing approach
+ that is different from that of the developer, particularly if
+ the developer's tests have shortcomings.
+
+ To determine the adequacy of developer's test documentation or
+ to create new tests, the evaluator needs to understand the
+ desired expected behaviour of the TSF, both internally and as
+ seen at the TSFI, in the context of the SFRs it is to
+ satisfy. The evaluator may choose to divide the TSF and TSFI
+ into subsets according to functional areas of the ST (audit
+ subsystem, audit-related TSFI, authentication module,
+ authentication-related TSFI, etc.) if they were not already
+ divided in the ST, and focus on one subset of the TSF and TSFI
+ at a time, examining the ST requirement and the relevant parts
+ of the development and guidance documentation to gain an
+ understanding of the way the TOE is expected to behave. This
+ reliance upon the development documentation underscores the need
+ for the dependencies on by and .
+
+ The CC has separated coverage and depth from functional tests
+ to increase the flexibility when applying the components of
+ the families. However, the requirements of the families are
+ intended to be applied together to confirm that the TSF
+ operates according to its specification. This tight coupling
+ of families has led to some duplication of evaluator work
+ units across sub-activities. These application notes are used
+ to minimise duplication of text between sub-activities.
+
+
+ Before the adequacy of test documentation can be accurately
+ evaluated, or before new tests can be created, the evaluator
+ has to understand the desired expected behaviour of a
+ security function in the context of the requirements it is
+ to satisfy.
+
+ As mentioned earlier, the evaluator may choose to subset the
+ TSF and TSFI according to SFRs (audit, authentication, etc.)
+ in the ST and focus on one subset at a time. The evaluator
+ examines each ST requirement and the relevant parts of the
+ functional specification and guidance documentation to gain
+ an understanding of the way the related TSFI is expected to
+ behave. Similarly, the evaluator examines the relevant parts
+ of the TOE design and security architecture documentation to
+ gain an understanding of the way the related modules or
+ subsystems of the TSF are expected to behave.
+
+ With an understanding of the expected behaviour, the
+ evaluator examines the test plan to gain an understanding of
+ the testing approach. In most cases, the testing approach
+ will entail a TSFI being stimulated and its responses
+ observed. Externally-visible functionality can be tested
+ directly; however, in cases where functionality is not
+ visible external to the TOE (for example, testing the
+ residual information protection functionality), other means
+ will need to be employed.
+
+
+
+ In cases where it is impractical or inadequate to test
+ specific functionality (where it provides no
+ externally-visible TSFI), the test plan should identify the
+ alternate approach to verify expected behaviour. It is the
+ evaluator's responsibility to determine the suitability of
+ the alternate approach. However, the following should be
+ considered when assessing the suitability of alternate
+ approaches:
+
+
+ an analysis of the implementation representation to
+ determine that the required behaviour should be
+ exhibited by the TOE is an acceptable alternate
+ approach. This could mean a code inspection for a
+ software TOE or perhaps a chip mask inspection for a
+ hardware TOE.
+
+
+ it is acceptable to use evidence of developer
+ integration or module testing, even if the claimed
+ assurance requirements do not include availability of
+ lower level descriptions of the TOE modules (e.g. ) or implementation (). If evidence of developer
+ integration or module testing is used in verifying the
+ expected behaviour of a security functionality, care
+ should be given to confirm that the testing evidence
+ reflects the current implementation of the TOE. If the
+ subsystems or modules have been changed since testing
+ occurred, evidence that the changes were tracked and
+ addressed by analysis or further testing will usually be
+ required.
+
+
+
+ It should be emphasised that supplementing the testing
+ effort with alternate approaches should only be undertaken
+ when both the developer and evaluator determine that there
+ exists no other practical means to test the expected
+ behaviour.
+
+
+
+ Test pre-requisites are necessary to establish the required
+ initial conditions for the test. They may be expressed in
+ terms of parameters that must be set or in terms of test
+ ordering in cases where the completion of one test
+ establishes the necessary pre-requisites for another
+ test. The evaluator must determine that the pre-requisites
+ are complete and appropriate in that they will not bias the
+ observed test results towards the expected test
+ results.
+
+ The test steps and expected results specify the actions and
+ parameters to be applied to the TSFI as well as how the
+ expected results should be verified and what they are. The
+ evaluator must determine that the test steps and expected
+ results are consistent with the descriptions of the TSFI in
+ the functional specification. This means that each
+ characteristic of the TSFI behaviour explicitly described in
+ the functional specification should have tests and expected
+ results to verify that behaviour.
+
+ The overall aim of this testing activity is to determine
+ that each subsystem, module, and TSFI has been sufficiently
+ tested against the behavioural claims in the functional
+ specification, TOE design, and architecture description. At
+ the higher assurance levels, testing also includes bounds
+ testing and negative testing. The test procedures will
+ provide insight as to how the TSFIs, modules, and subsystems
+ have been exercised by the developer during testing. The
+ evaluator uses this information when developing additional
+ tests to independently test the TSF.
+
+
+
+
+
+ This family establishes that the TSF has been tested against
+ its functional specification. This is achieved through an
+ examination of developer evidence of correspondence.
+
+
+
+ Coverage deals with the completeness of the functional tests
+ performed by the developer on the TOE. It addresses the
+ extent to which the TSF is tested.
+
+
+
+ The components in this family are levelled on the basis of
+ specification.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to establish that some
+ of the TSFIs have been tested.
+
+
+
+ In this component the developer shows how tests in the
+ test documentation correspond to TSFIs in the functional
+ specification. This can be achieved by a statement of
+ correspondence, perhaps using a table.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+ The coverage analysis provided by the developer is
+ required to show the correspondence between the tests
+ provided as evaluation evidence and the functional
+ specification. However, the coverage analysis need not
+ demonstrate that all TSFI have been tested, or that all
+ externally-visible interfaces to the TOE have been
+ tested. Such shortcomings are considered by the evaluator
+ during the independent testing () sub-activity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage evidence.
+
+
+
+
+ The developer shall provide evidence of the test coverage.
+
+
+ The evidence of the test coverage shall show the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage evidence
+ to determine that the correspondence between the tests
+ identified in the test documentation and the TSFIs
+ described in the functional specification is
+ accurate.
+
+ Correspondence may take the form of a table or
+ matrix. The coverage evidence required for this
+ component will reveal the extent of coverage, rather
+ than to show complete coverage. In cases where coverage
+ is shown to be poor the evaluator should increase the
+ level of independent testing to compensate.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to confirm that all of
+ the TSFIs have been tested.
+
+
+
+ In this component the developer confirms that tests in the
+ test documentation correspond to all of the TSFIs in the
+ functional specification. This can be achieved by a
+ statement of correspondence, perhaps using a table, but
+ the developer also provides an analysis of the test
+ coverage.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested all of the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage analysis.
+
+
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the tests
+ in the test documentation and the interfaces in the
+ functional specification is accurate.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ interfaces presented in the test coverage analysis has
+ to be unambiguous.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the testing approach for each interface
+ demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that the test prerequisites, test steps and
+ expected result(s) adequately test each
+ interface.
+
+ Guidance on this work units, as it pertains to the
+ functional specification, can be found in:
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the
+ interfaces in the functional specification and the tests
+ in the test documentation is complete.
+
+ All TSFIs that are described in the functional
+ specification have to be present in the test coverage
+ analysis and mapped to tests in order for completeness
+ to be claimed, although exhaustive specification testing
+ of interfaces is not required. Incomplete coverage would
+ be evident if an interface was identified in the
+ functional specification and no test was mapped to
+ it.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to confirm that the
+ developer performed exhaustive tests of all interfaces in
+ the functional specification.
+
+ The objective of this component is to confirm that all
+ parameters of all of the TSFIs have been tested.
+
+
+
+ In this component the developer is required to show how
+ tests in the test documentation correspond to all of the
+ TSFIs in the functional specification. This can be
+ achieved by a statement of correspondence, perhaps using a
+ table, but in addition the developer is required to
+ demonstrate that the tests exercise all of the parameters
+ of all TSFIs. This additional requirement includes bounds
+ testing (i.e. verifying that errors are generated when
+ stated limits are exceeded) and negative testing
+ (e.g. when access is given to User A, verifying not only
+ that User A now has access, but also that User B did not
+ suddenly gain access). This kind of testing is not,
+ strictly speaking, exhaustive because not
+ every possible value of the parameters is expected to be
+ checked.
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been completely
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The components in this family deal with the level of detail
+ to which the TSF is tested by the developer. Testing of the
+ TSF is based upon increasing depth of information derived
+ from additional design representations and descriptions (TOE
+ design, implementation representation, and security
+ architecture description).
+
+ The objective is to counter the risk of missing an error in
+ the development of the TOE. Testing that exercises specific
+ internal interfaces can provide assurance not only that the
+ TSF exhibits the desired external security behaviour, but
+ also that this behaviour stems from correctly operating
+ internal functionality.
+
+
+
+ Depth deals with the level of detail to which the developer
+ tests the TSF. Testing is based upon increasing depth of
+ information derived from analysis of the TSF
+ representations.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing detail provided in the TSF representations, from
+ the TOE design to the implementation representation. This
+ levelling reflects the TSF representations presented in the
+ class.
+
+
+
+ The TOE design describes the internal components
+ (e.g. subsystems) and, perhaps, modules of the TSF, together
+ with a description of the interfaces among these components and
+ modules. Evidence of testing of this TOE design must show that
+ the internal interfaces have been exercised and seen to behave
+ as described. This may be achieved through testing via the
+ external interfaces of the TSF, or by testing of the TOE
+ subsystem or module interfaces in isolation, perhaps employing a
+ test harness. In cases where some aspects of an internal
+ interface cannot be tested via the external interfaces, there
+ should either be justification that these aspects need not be
+ tested, or the internal interface needs to be tested
+ directly. In the latter case the TOE design needs to be
+ sufficiently detailed in order to facilitate direct
+ testing.
+
+ In cases where the description of the TSF's architectural
+ soundness (in ) cites
+ specific mechanisms, the tests performed by the developer
+ must show that the mechanisms have been exercised and seen
+ to behave as described.
+
+ At the highest component of this family, the testing is
+ performed not only against the TOE design, but also against
+ the implementation representation.
+
+
+
+
+
+
+
+ The subsystem descriptions of the TSF provide a high-level
+ description of the internal workings of the TSF. Testing
+ at the level of the TOE subsystems provides assurance that
+ the TSF subsystems behave and interact as described in the
+ TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSF subsystems against the
+ TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the descriptions of the
+ behaviour of TSF subsystems and of their interactions is
+ included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to subsystem interfaces
+ in the TOE design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the SFR-enforcing
+ modules, of the TSF. Testing at this level of TOE
+ description provides assurance that the TSF subsystems and
+ SFR-enforcing modules behave and interact as described in
+ the TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has tested all the TSF subsystems and SFR-enforcing
+ modules against the TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation and
+ the TSF subsystems and SFR-enforcing modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the SFR-enforcing modules in the TOE design have been
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of
+ SFR-enforcing modules are included within the test
+ documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms at the modular
+ level, this work unit also verifies the correspondence
+ between the tests and the descriptions of the behaviour
+ of such mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test prerequisites,
+ test steps and expected result(s) to determine that the testing
+ approach for each SFR-enforcing module interface demonstrates
+ the expected behaviour of that interface.
+
+ While work unit addresses
+ expected behaviour of subsystems, this work unit addresses
+ expected behaviour of the SFR-enforcing module interfaces that
+ are covered by .
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to subsystem interfaces
+ in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all interfaces of SFR-enforcing modules
+ are tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of SFR-enforcing modules that are provided in the TOE
+ design have to be tested. Incomplete depth of testing
+ would be evident if any interface of any SFR-enforcing
+ modules was identified in the TOE design and no tests
+ could be attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of an SFR-enforcing module in the TOE
+ design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description.
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has tested the all the TSF subsystems and modules
+ against the TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that all
+ TSF modules in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are provided, the behaviour
+ of those subsystems may be performed directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ If TSF subsystem interfaces are provided, the
+ interactions with other subsystems may be performed
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of TSF modules
+ are included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for each TSF module
+ interface demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to subsystem interfaces
+ in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to determine
+ that all interfaces of all TSF modules are tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of TSF modules that are provided in the TOE design have
+ to be tested. Incomplete depth of testing would be
+ evident if any interface of any TSF module was
+ identified in the TOE design and no tests could be
+ attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of a TSF module in the TOE design.
+
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description, and in accordance with the
+ implementation representation.
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all modules in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the TSF operates in accordance with its implementation
+ representation.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ Functional testing performed by the developer provides
+ assurance that the tests in the test documentation are
+ performed and documented correctly. The correspondence of
+ these tests to the design descriptions of the TSF is
+ achieved through the and
+ families.
+
+ This family contributes to providing assurance that the
+ likelihood of undiscovered flaws is relatively small.
+
+ The families , and are used in combination to define the evidence
+ of testing to be supplied by a developer. Independent
+ functional testing by the evaluator is specified by .
+
+
+
+ Functional testing establishes that the tests performed by
+ the developer are performed and documented correctly.
+
+
+
+ This family contains two components, the higher requiring
+ that ordering dependencies are analysed.
+
+
+
+ Procedures for performing tests are expected to provide
+ instructions for using test programs and test suites,
+ including the test environment, test conditions, test data
+ parameters and values. The test procedures should also show
+ how the test results are derived from the test
+ inputs.
+
+ Ordering dependencies are relevant when the successful
+ execution of a particular test depends upon the existence of
+ a particular state. For example, this might require that
+ test A be executed immediately before test B, since the
+ state resulting from the successful execution of test A is a
+ prerequisite for the successful execution of test B. Thus,
+ failure of test B could be related to a problem with the
+ ordering dependencies. In the above example, test B could
+ fail because test C (rather than test A) was executed
+ immediately before it, or the failure of test B could be
+ related to a failure of test A.
+
+
+
+
+
+ The objective is for the developer to demonstrate that the
+ tests in the test documentation are performed and
+ documented correctly.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented the tests
+ in the test documentation.
+
+
+
+ The extent to which the test documentation is required to
+ cover the TSF is dependent upon the coverage assurance
+ component.
+
+ For the developer tests provided, the evaluator determines
+ whether the tests are repeatable, and the extent to which
+ the developer's tests can be used for the evaluator's
+ independent testing effort. Any TSFI for which the
+ developer's test results indicate that it might not
+ perform as specified should be tested independently by the
+ evaluator to determine whether or not it does.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation.
+
+
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the test documentation
+ includes test plans, expected test results and actual
+ test results.
+
+ The evaluator checks that test plans, expected tests
+ results and actual test results are included in the test
+ documentation.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that it describes the scenarios for performing each
+ test.
+
+ The evaluator determines that the test plan provides
+ information about the test configuration being used:
+ both on the configuration of the TOE and on any test
+ equipment being used. This information should be
+ detailed enough to ensure that the test configuration is
+ reproducible.
+
+ The evaluator also determines that the test plan
+ provides information about how to execute the test: any
+ necessary automated set-up procedures (and whether they
+ require privilege to run), inputs to be applied, how
+ these inputs are applied, how output is obtained, any
+ automated clean-up procedures (and whether they require
+ privilege to run), etc. This information should be
+ detailed enough to ensure that the test is
+ reproducible.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the TOE test configuration is consistent with the
+ ST.
+
+ The TOE referred to in the developer's test plan should
+ have the same unique reference as established by the
+ sub-activities and
+ identified in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The evaluator verifies
+ that all test configurations identified in the developer
+ test documentation are consistent with the ST. For
+ example, the ST might define configuration options that
+ must be set, which could have an impact upon what
+ constitutes the TOE by including or excluding additional
+ portions. The evaluator verifies that all such
+ variations of the TOE are considered.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+ If this work unit is applied to a component TOE that
+ might be used/integrated in a composed TOE (see ), the following will apply. In
+ the instances that the component TOE under evaluation
+ depends on other components in the operational
+ environment to support their operation, the developer
+ may wish to consider using the other component(s) that
+ will be used in the composed TOE to fulfil the
+ requirements of the operational environment as one of
+ the test configurations. This will reduce the amount an
+ additional testing that will be required for the
+ composed TOE evaluation.
+
+
+
+
+ The evaluator shall examine the test plans to determine
+ that sufficient instructions are provided for any
+ ordering dependencies.
+
+ Some steps may have to be performed to establish initial
+ conditions. For example, user accounts need to be added
+ before they can be deleted. An example of ordering
+ dependencies on the results of other tests is the need
+ to perform actions in a test that will result in the
+ generation of audit records, before performing a test to
+ consider the searching and sorting of those audit
+ records. Another example of an ordering dependency
+ would be where one test case generates a file of data to
+ be used as input for another test case.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that all expected tests results are
+ included.
+
+ The expected test results are needed to determine
+ whether or not a test has been successfully
+ performed. Expected test results are sufficient if they
+ are unambiguous and consistent with expected behaviour
+ given the testing approach.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall check that the actual test results
+ in the test documentation are consistent with the
+ expected test results in the test documentation.
+
+ A comparison of the actual and expected test results
+ provided by the developer will reveal any
+ inconsistencies between the results. It may be that a
+ direct comparison of actual results cannot be made until
+ some data reduction or synthesis has been first
+ performed. In such cases, the developer's test
+ documentation should describe the process to reduce or
+ synthesise the actual data.
+
+ For example, the developer may need to test the contents
+ of a message buffer after a network connection has
+ occurred to determine the contents of the buffer. The
+ message buffer will contain a binary number. This binary
+ number would have to be converted to another form of
+ data representation in order to make the test more
+ meaningful. The conversion of this binary representation
+ of data into a higher-level representation will have to
+ be described by the developer in enough detail to allow
+ an evaluator to perform the conversion process
+ (i.e. synchronous or asynchronous transmission, number
+ of stop bits, parity, etc.).
+
+ It should be noted that the description of the process
+ used to reduce or synthesise the actual data is used by
+ the evaluator not to actually perform the necessary
+ modification but to assess whether this process is
+ correct. It is up to the developer to transform the
+ expected test results into a format that allows an easy
+ comparison with the actual test results.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall report the developer testing effort,
+ outlining the testing approach, configuration, depth and
+ results.
+
+ The developer testing information recorded in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing of the TOE by the developer. The intent
+ of providing this information is to give a meaningful overview
+ of the developer testing effort. It is not intended that the
+ information regarding developer testing in the ETR be an exact
+ reproduction of specific test steps or results of individual
+ tests. The intention is to provide enough detail to allow other
+ evaluators and evaluation authorities to gain some insight about the
+ developer's testing approach, amount of testing performed, TOE
+ test configurations, and the overall results of the developer
+ testing.
+
+ Information that would typically be found in the ETR
+ subclause regarding the developer testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested,
+ including whether any privileged code was required
+ to set up the test or clean up afterwards;
+
+
+ testing approach. An account of the overall
+ developer testing strategy employed;
+
+
+ testing results. A description of the overall
+ developer testing results.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ developer testing effort.
+
+
+
+
+
+
+
+
+ The objectives are for the developer to demonstrate that
+ the tests in the test documentation are performed and
+ documented correctly, and to ensure that testing is
+ structured such as to avoid circular arguments about the
+ correctness of the interfaces being tested.
+
+
+
+ Although the test procedures may state pre-requisite
+ initial test conditions in terms of ordering of tests,
+ they may not provide a rationale for the ordering. An
+ analysis of test ordering is an important factor in
+ determining the adequacy of testing, as there is a
+ possibility of faults being concealed by the ordering of
+ tests.
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The test documentation shall include an analysis of the test
+ procedure ordering dependencies.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The objectives of this family are built upon the assurances
+ achieved in the , , and
+ families by verifying the developer testing and performing
+ additional tests by the evaluator.
+
+
+
+ Independent testing specifies the degree to which the
+ testing of the TSF must be performed by a party other than
+ the developer (e.g. a third party). This family adds value
+ by the introduction of tests that are not part of the
+ developer's tests.
+
+
+
+ Levelling is based upon the amount of developer test
+ documentation and test support and the amount of evaluator
+ testing.
+
+
+
+ This family deals with the degree to which there is
+ independent functional testing of the TSF. Independent
+ functional testing may take the form of repeating the
+ developer's functional tests (in whole or in part) or of
+ extending the scope or the depth of the developer's
+ tests. These activities are complementary, and an
+ appropriate mix must be planned for each TOE, which takes
+ into account the availability and coverage of test results,
+ and the functional complexity of the TSF.
+
+ Sampling of developer tests is intended to provide
+ confirmation that the developer has carried out his planned
+ test programme on the TSF, and has correctly recorded the
+ results. The size of sample selected will be influenced by
+ the detail and quality of the developer's functional test
+ results. The evaluator will also need to consider the scope
+ for devising additional tests, and the relative benefit that
+ may be gained from effort in these two areas. It is
+ recognised that repetition of all developer tests may be
+ feasible and desirable in some cases, but may be very
+ arduous and less productive in others. The highest component
+ in this family should therefore be used with
+ caution. Sampling will address the whole range of test
+ results available, including those supplied to meet the
+ requirements of both and
+ .
+
+ There is also a need to consider the different
+ configurations of the TOE that are included within the
+ evaluation. The evaluator will need to assess the
+ applicability of the results provided, and to plan his own
+ testing accordingly.
+
+ The suitability of the TOE for testing is based on the
+ access to the TOE, and the supporting documentation and
+ information required (including any test software or tools)
+ to run tests. The need for such support is addressed by the
+ dependencies to other assurance families.
+
+ Additionally, suitability of the TOE for testing may be
+ based on other considerations. For example, the version of
+ the TOE submitted by the developer may not be the final
+ version.
+
+ The term interfaces refers to interfaces
+ described in the functional specification and TOE design,
+ and parameters passed through invocations identified in the
+ implementation representation. The exact set of interfaces
+ to be used is selected through and the
+ components.
+
+ References to a subset of the interfaces are intended to
+ allow the evaluator to design an appropriate set of tests
+ which is consistent with the objectives of the evaluation
+ being conducted.
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents.
+
+
+
+ This component does not address the use of developer test
+ results. It is applicable where such results are not
+ available, and also in cases where the developer's testing
+ is accepted without validation. The evaluator is required
+ to devise and conduct tests with the objective of
+ confirming that the TOE operates in accordance with its
+ design representations, including but not limited to the
+ functional specification. The approach is to gain
+ confidence in correct operation through representative
+ testing, rather than to conduct every possible test. The
+ extent of testing to be planned for this purpose is a
+ methodology issue, and needs to be considered in the
+ context of a particular TOE and the balance of other
+ evaluation activities.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSFI, whether the
+ TOE behaves as specified in the functional specification
+ and guidance documentation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer should have the same
+ unique reference as established by the sub-activities and identified
+ in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state.
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall test a subset of the TSF to confirm that
+ the TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of the
+ interfaces. In other cases this may not be
+ cost-effective, and sampling is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of the interface. Complex interfaces may
+ require complex tests that impose onerous
+ requirements on the developer or evaluator, which
+ may not be conducive to cost-effective
+ evaluations. Conversely, they are a likely area to
+ find errors and are good candidates for the
+ subset. The evaluator will need to strike a balance
+ between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST and the functional specification, the
+ evaluator has to determine the most feasible way to test
+ the interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection, if the
+ implementation representation is available);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the behaviour of the
+ interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing activity during the evaluation. The
+ intent of providing this information is to give a meaningful
+ overview of the testing effort. It is not intended that the
+ information regarding testing in the ETR be an exact
+ reproduction of specific test instructions or results of
+ individual tests. The intention is to provide enough detail to
+ allow other evaluators and evaluation authorities to gain some insight about
+ the testing approach chosen, amount of testing performed, TOE
+ test configurations, and the overall results of the testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested;
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size;
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset;
+
+
+ interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset;
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ confirms that the developer performed some tests of some
+ interfaces in the functional specification.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ This component contains a requirement that the evaluator
+ has available test results from the developer to
+ supplement the programme of testing. The evaluator will
+ repeat a sample of the developer's tests to gain
+ confidence in the results obtained. Having established
+ such confidence the evaluator will build upon the
+ developer's testing by conducting additional tests that
+ exercise the TOE in a different manner. By using a
+ platform of validated developer test results the evaluator
+ is able to gain confidence that the TOE operates correctly
+ in a wider range of conditions than would be possible
+ purely using the developer's own efforts, given a fixed
+ level of resource. Having gained confidence that the
+ developer has tested the TOE, the evaluator will also have
+ more freedom, where appropriate, to concentrate testing in
+ areas where examination of documentation or specialist
+ knowledge has raised particular concerns.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSF, whether the TOE
+ behaves as specified in the design documentation, and to
+ gain confidence in the developer's test results by
+ performing a sample of the developer's tests.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design description;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the configuration management documentation;
+
+
+ the test documentation;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the developer
+ to functionally test the TSF
+
+ The set of resource used by the developer is documented
+ in the developer test plan, as considered in the family. The resource set may
+ include laboratory access and special test equipment,
+ among others. Resources that are not identical to those
+ used by the developer need to be equivalent in terms of
+ any impact they may have on test results.
+
+
+
+ The evaluator shall execute a sample of tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall conduct testing using a sample of
+ tests found in the developer test plan and
+ procedures.
+
+ The overall aim of this work unit is to perform a
+ sufficient number of the developer tests to confirm the
+ validity of the developer's test results. The evaluator
+ has to decide on the size of the sample, and the
+ developer tests that will compose the sample (see ).
+
+ All the developer tests can be traced back to specific
+ interfaces. Therefore, the factors to consider in the
+ selection of the tests to compose the sample are similar
+ to those listed for subset selection in work-unit . Additionally, the
+ evaluator may wish to employ a random sampling method to
+ select developer tests to include in the sample.
+
+
+
+ The evaluator shall check that all the actual test
+ results are consistent with the expected test
+ results.
+
+ Inconsistencies between the developer's expected test
+ results and actual test results will compel the
+ evaluator to resolve the discrepancies. Inconsistencies
+ encountered by the evaluator could be resolved by a
+ valid explanation and resolution of the inconsistencies
+ by the developer.
+
+ If a satisfactory explanation or resolution can not be
+ reached, the evaluator's confidence in the developer's
+ test results may be lessened and it may be necessary for
+ the evaluator to increase the sample size to the extent
+ that the subset identified in work unit is adequately tested:
+ deficiencies with the developer's tests need to result
+ in either corrective action to the developer's tests or
+ in the production of new tests by the evaluator.
+
+
+
+ The evaluator shall test a subset of the TSF to confirm that the
+ TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The developer test evidence. The developer test
+ evidence consists of: the test documentation, the
+ available test coverage analysis, and the available
+ depth of testing analysis. The developer test
+ evidence will provide insight as to how the TSF has
+ been exercised by the developer during testing. The
+ evaluator applies this information when developing
+ new tests to independently test the
+ TOE. Specifically the evaluator should consider:
+
+
+ augmentation of developer testing for
+ interfaces. The evaluator may wish to perform
+ more of the same type of tests by varying
+ parameters to more rigorously test the
+ interface.
+
+
+ supplementation of developer testing strategy
+ for interfaces. The evaluator may wish to vary
+ the testing approach of a specific interface by
+ testing it using another test strategy.
+
+
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of them. In other
+ cases this may not be cost-effective, and sampling
+ is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Rigour of developer testing of the interfaces. Those
+ interfaces that the evaluator determines require
+ additional testing should be included in the test
+ subset.
+
+
+ Developer test results. If the results of developer
+ tests cause the evaluator to doubt that an interface
+ is not properly implemented, then the evaluator
+ should include such interfaces in the test subset.
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of interfaces. Interfaces that require
+ complex implementation may require complex tests
+ that impose onerous requirements on the developer or
+ evaluator, which may not be conducive to
+ cost-effective evaluations. Conversely, they are a
+ likely area to find errors and are good candidates
+ for the subset. The evaluator will need to strike a
+ balance between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST, the functional specification, and the
+ TOE design description, the evaluator has to determine
+ the most feasible way to test the
+ interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour of that interface.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing activity during the evaluation. The
+ intent of providing this information is to give a meaningful
+ overview of the testing effort. It is not intended that the
+ information regarding testing in the ETR be an exact
+ reproduction of specific test instructions or results of
+ individual tests. The intention is to provide enough detail to
+ allow other evaluators and evaluation authorities to gain some insight about
+ the testing approach chosen, amount of evaluator testing
+ performed, amount of developer tests performed, TOE test
+ configurations, and the overall results of the testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested.
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size.
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset.
+
+
+ Interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset.
+
+
+ developer tests performed. The amount of developer
+ tests performed and a brief description of the
+ criteria used to select the tests.
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate
+ that the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ includes repeating all of the developer tests.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ In this component the evaluator must repeat all of the
+ developer's tests as part of the programme of testing. As
+ in the previous component the evaluator will also conduct
+ tests that aim to exercise the TSF in a different manner
+ from that achieved by the developer. In cases where
+ developer testing has been exhaustive, there may remain
+ little scope for this.
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall execute all tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall test the TSF to confirm that the entire
+ TSF operates as specified.
+
+
+
+
+
+
+
+ The class addresses the
+ possibility of exploitable vulnerabilities introduced in the
+ development or the operation of the TOE.
+
+
+
+ Assurance class defines
+ requirements directed at the identification of exploitable
+ vulnerabilities. Specifically, it addresses those
+ vulnerabilities introduced in the development, operation,
+ misuse, or incorrect configuration of the TOE.
+
+
+
+ Generally, the vulnerability assessment activity covers various
+ vulnerabilities in the development and operation of the
+ TOE. Development vulnerabilities take advantage of some property
+ of the TOE which was introduced during its development,
+ e.g. defeating the TSF self protection through tampering, direct
+ attack or monitoring of the TSF, defeating the TSF domain
+ separation through monitoring or direct attack the TSF, or
+ defeating non-bypassability through circumventing (bypassing)
+ the TSF. Operational vulnerabilities take advantage of
+ weaknesses in non-technical countermeasures to violate the TOE
+ SFRs, e.g. misuse or incorrect configuration. Misuse
+ investigates whether the TOE can be configured or used in a
+ manner that is insecure, but that an administrator or user of
+ the TOE would reasonably believe to be secure.
+
+ Assessment of development vulnerabilities is covered by the
+ assurance family . Basically,
+ all development vulnerabilities can be considered in the
+ context of due to the fact,
+ that this family allows application of a wide range of
+ assessment methodologies being unspecific to the kind of an
+ attack scenario. These unspecific assessment methodologies
+ comprise, among other, also the specific methodologies for
+ those TSF where covert channels are to be considered (a
+ channel capacity estimation can be done using informal
+ engineering measurements, as well as actual test measurements)
+ or can be overcome by the use of sufficient resources in the
+ form of a direct attack (underlying technical concept of those
+ TSF is based on probabilistic or permutational mechanisms; a
+ qualification of their security behaviour and the effort
+ required to overcome them can be made using a quantitative or
+ statistical analysis).
+
+ If there are security objectives specified in the ST to either
+ to prevent one user of the TOE from observing activity
+ associated with another user of the TOE, or to ensure that
+ information flows cannot be used to achieve enforced illicit
+ data signals, covert channel analysis should be considered
+ during the conduct of the vulnerability analysis. This is often
+ reflected by the inclusion of
+ and multilevel access control policies specified through and/or requirements in the ST.
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the exploitability of flaws or weaknesses in the TOE
+ in the operational environment. This determination is based
+ upon analysis of the evaluation evidence and a search of
+ publicly available material by the evaluator and is supported
+ by evaluator penetration testing.
+
+
+
+
+ Vulnerability analysis is an assessment to determine whether
+ potential vulnerabilities identified, during the evaluation
+ of the development and anticipated operation of the TOE or
+ by other methods (e.g. by flaw hypotheses or quantitative or
+ statistical analysis of the security behaviour of the
+ underlying security mechanisms), could allow attackers to
+ violate the SFRs.
+
+ Vulnerability analysis deals with the threats that an
+ attacker will be able to discover flaws that will allow
+ unauthorised access to data and functionality, allow the
+ ability to interfere with or alter the TSF, or interfere
+ with the authorised capabilities of other users.
+
+
+
+ Vulnerability analysis consists of the identification of
+ flaws potentially introduced in the different refinement
+ steps of the development (development vulnerabilities) or
+ through the application of the guidance in operation of the
+ TOE (operational vulnerabilities). It results in the
+ definition of penetration tests through the collection of
+ the necessary information concerning: (1) the completeness
+ of the TSF (does the TSF counter all the postulated
+ threats?), (2) the dependencies between all SFRs and (3)
+ whether any of the SFRs can be undermined through unexpected
+ behaviour of the TOE. These potential vulnerabilities are
+ assessed through penetration testing to determine whether
+ they could, in practise, be exploitable to compromise the
+ security of the TOE.
+
+ The characteristics of different levels of attack potential
+ are discussed in CEM .
+
+
+
+ Levelling is based on an increasing rigour of vulnerability
+ analysis by the evaluator and increased levels of attack
+ potential required by an attacker to identify and exploit
+ the potential vulnerabilities.
+
+
+
+
+
+
+
+ A vulnerability survey of information available in the
+ public domain is performed by the evaluator to ascertain
+ potential vulnerabilities that may be easily found by an
+ attacker.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has easily
+ identifiable exploitable vulnerabilities.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during the conduct of other parts of the
+ evaluation.
+
+ The use of the term guidance in this sub-activity refers
+ to the operational guidance and the preparative
+ guidance.
+
+ Potential vulnerabilities may be in information that is
+ publicly available, or not, and may require skill to
+ exploit, or not. These two aspects are related, but are
+ distinct. It should not be assumed that, simply because a
+ potential vulnerability is identifiable from information
+ that is publicly available, it can be easily
+ exploited.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the guidance documentation;
+
+
+ the TOE suitable for testing;
+
+
+ information publicly available to support the
+ identification of potential vulnerabilities.
+
+
+
+ Other input for this sub-activity is:
+
+
+ current information regarding potential
+ vulnerabilities (e.g. from an evaluation authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information, which
+ should be considered, e.g. mailing lists and security
+ forums on the world wide web that report known
+ vulnerabilities in specified technologies.
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks effectively operates to substantially
+ enhance the attack potential of a given attacker. The
+ accessibility of vulnerability information and
+ sophisticated attack tools on the Internet makes it more
+ likely that this information will be used in attempts to
+ identify potential vulnerabilities in the TOE and
+ exploit them. Modern search tools make such information
+ easily available to the evaluator, and the determination
+ of resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the information
+ publicly available. However, in this type of search, the
+ evaluator may not be able to describe the steps in
+ identifying potential vulnerabilities before the outset
+ of the examination, as the approach may evolve as a
+ result of findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses;
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing Basic
+ attack potential.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during other parts of the evaluation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the TOE using the guidance documentation,
+ functional specification, TOE design and security
+ architecture description to identify potential
+ vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a search of ST, guidance
+ documentation, functional specification, TOE design and
+ security architecture description evidence to identify
+ possible potential vulnerabilities in the TOE.
+
+ A search of the evidence should be completed whereby
+ specifications and documentation for the TOE are
+ analysed and then potential vulnerabilities in the TOE
+ are hypothesised, or speculated. The list of
+ hypothesised potential vulnerabilities is then
+ prioritised on the basis of the estimated probability
+ that a potential vulnerability exists and, assuming an
+ exploitable vulnerability does exist the attack
+ potential required to exploit it, and on the extent of
+ control or compromise it would provide. The prioritised
+ list of potential vulnerabilities is used to direct
+ penetration testing against the TOE.
+
+ The security architecture description provides the
+ developer vulnerability analysis, as it documents how
+ the TSF protects itself from interference from untrusted
+ subjects and prevents the bypass of security enforcement
+ functionality. Therefore, the evaluator should use this
+ description of the protection of the TSF as a basis for
+ the search for possible ways to undermine the
+ TSF.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the security
+ architecture description in the search for vulnerabilities (as
+ detailed in ), testing should
+ be performed to confirm the architectural properties. This is
+ likely to require negative tests attempting to disprove the
+ properties of the security architecture. In developing the
+ strategy for penetration testing, the evaluator will ensure that
+ each of the major characteristics of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ Basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Enhanced-Basic, Moderate or
+ High attack potential do not result in a failure of this
+ evaluator action. Where analysis supports the
+ hypothesis, these need not be considered further as an
+ input to penetration testing. However, such
+ vulnerabilities are reported in the ETR as residual
+ vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic attack potential and
+ resulting in a violation of the security objectives
+ should be the highest priority potential vulnerabilities
+ comprising the list used to direct penetration testing
+ against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than an Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Enhanced-Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Enhanced-Basic attack potential.
+
+
+
+ During the conduct of evaluation activities the evaluator
+ may also identify areas of concern. These are specific
+ portions of the TOE evidence that the evaluator has some
+ reservation about, although the evidence meets the
+ requirements for the activity with which the evidence is
+ associated. For example, a particular interface
+ specification looks particularly complex, and therefore
+ may be prone to error either in the development of the TOE
+ or in the operation of the TOE. There is no potential
+ vulnerability apparent at this stage, further
+ investigation is required. This is beyond the bounds of
+ encountered, as further investigation is required.
+
+ The focused approach to the identification of potential
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. Further
+ guidance on focused vulnerability analysis can be found in
+ Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation subset selected;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the TOE using the guidance documentation,
+ functional specification, TOE design, security architecture
+ description and implementation representation to identify
+ potential vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a focused search of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ A flaw hypothesis methodology needs to be used whereby
+ specifications and development and guidance evidence are
+ analysed and then potential vulnerabilities in the TOE are
+ hypothesised, or speculated.
+
+ The evaluator uses the knowledge of the TOE design and operation
+ gained from the TOE deliverables to conduct a flaw hypothesis to
+ identify potential flaws in the development of the TOE and
+ potential errors in the specified method of operation of the
+ TOE.
+
+ The security architecture description provides the developer
+ vulnerability analysis, as it documents how the TSF protects
+ itself from interference from untrusted subjects and prevents
+ the bypass of security enforcement functionality. Therefore, the
+ evaluator should build upon the understanding of the TSF
+ protection gained from the analysis of this evidence and then
+ develop this in the knowledge gained from other development
+ evidence.
+
+
+ The approach taken is directed by areas of concern
+ identified during examination of the evidence during the
+ conduct of evaluation activities and ensuring a
+ representative sample of the development and guidance
+ evidence provided for the evaluation is searched.
+
+ For guidance on sampling see Annex . This guidance
+ should be considered when selecting the subset, giving
+ reasons for:
+
+
+ the approach used in selection;
+
+
+ qualification that the evidence to be examined
+ supports that approach.
+
+
+
+ The areas of concern may relate to the sufficiency of
+ specific protection features detailed in the security
+ architecture description.
+
+ The evidence to be considered during the vulnerability analysis
+ may be linked to the evidence the attacker is assumed to be able
+ to obtain. For example, the developer may protect the TOE design
+ and implementation representations, so the only information
+ assumed to be available to an attacker is the functional
+ specification and guidance (publicly available). So, although
+ the objectives for assurance in the TOE ensure the TOE design
+ and implementation representation requirements are met, these
+ design representations may only be searched to further
+ investigate areas of concerns.
+
+ On the other hand, if the source is publicly available it would
+ be reasonable to assume that the attacker has access to the
+ source and can use this in attempts to attack the
+ TOE. Therefore, the source should be considered in the focused
+ examination approach.
+
+ The following indicates examples for the selection of
+ the subset of evidence to be considered:
+
+
+ For an evaluation where all levels of design
+ abstraction from functional specification to
+ implementation representation are provided,
+ examination of information in the functional
+ specification and the implementation representation
+ may be selected, as the functional specification
+ provides detail of interfaces available to an
+ attacker, and the implementation representation
+ incorporates the design decisions made at all other
+ design abstractions. Therefore, the TOE design
+ information will be considered as part of the
+ implementation representation.
+
+
+ Examination of a particular subset of information in
+ each of the design representations provided for the
+ evaluation.
+
+
+ Coverage of particular SFRs through each of the
+ design representations provided for the evaluation.
+
+
+ Examination of each of the design representations
+ provided for the evaluation, considering different
+ SFRs within each design representations.
+
+
+ Examination of aspects of the evidence provided for
+ the evaluation relating to current potential
+ vulnerability information the evaluator has received
+ (e.g. from a scheme).
+
+
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach; applying a system to the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered and the
+ hypothesis that is to be created.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be searched to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examine in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Enhanced-Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the security
+ architecture description in the search for vulnerabilities (as
+ detailed in ), testing should
+ be performed to confirm the architectural properties. If
+ requirements from are included in
+ the SARs, the developer testing evidence will include testing
+ performed to confirm the correct implementation of any specific
+ mechanisms detailed in the security architecture
+ description. However, the developer testing will not necessarily
+ include testing of all aspects of the architectural properties
+ that protect the TSF, as much of this testing will be negative
+ testing in nature, attempting to disprove the properties. In
+ developing the strategy for penetration testing, the evaluator
+ will ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ It will probably be practical to carry out penetration
+ test using a series of test cases, where each test case
+ will test for a specific potential vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Moderate or High attack
+ potential do not result in a failure of this evaluator
+ action. Where analysis supports the hypothesis, these
+ need not be considered further as an input to
+ penetration testing. However, such vulnerabilities are
+ reported in the ETR as residual vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic or Enhanced-Basic attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which an Enhanced-Basic attack potential is
+ required to effect an attack. However, as a result of
+ evaluation expertise, the evaluator may discover a
+ potential vulnerability that is exploitable only by an
+ attacker with greater than Enhanced-Basic attack
+ potential. Such vulnerabilities are to be reported in
+ the ETR as residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming an Enhanced-Basic attack
+ potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing an Enhanced-Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Moderate attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Moderate.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Moderate.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Moderate attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will describe the approach to be taken to
+ identify potential vulnerabilities in the publicly
+ available material, detailing the search to be
+ performed. This may be driven by factors such as areas
+ of concern identified by the evaluator, linked to the
+ evidence the attacker is assumed to be able to obtain.
+ However, it is recognised that in this type of search
+ the approach may further evolve as a result of findings
+ during the search. Therefore, the evaluator will also
+ report any actions taken in addition to those described
+ in the approach to further investigate issues thought to
+ lead to potential vulnerabilities, and will report the
+ evidence examined in completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct a methodical analysis of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ Guidance on methodical vulnerability analysis is
+ provided in Annex .
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach. A system is to be applied in the
+ examination. The evaluator is to describe the method to
+ be used in terms of the manner in which this information
+ is to be considered and the hypothesis that is to be
+ created.
+
+ A flaw hypothesis methodology needs to be used whereby the ST,
+ development (functional specification, TOE design and
+ implementation representation) and guidance evidence are
+ analysed and then vulnerabilities in the TOE are hypothesised,
+ or speculated.
+
+ The evaluator uses the knowledge of the TOE design and operation
+ gained from the TOE deliverables to conduct a flaw hypothesis to
+ identify potential flaws in the development of the TOE and
+ potential errors in the specified method of operation of the
+ TOE.
+
+ The security architecture description provides the developer
+ vulnerability analysis, as it documents how the TSF protects
+ itself from interference from untrusted subjects and prevents
+ the bypass of security enforcement functionality. Therefore, the
+ evaluator should build upon the understanding of the TSF
+ protection gained from the analysis of this evidence and then
+ develop this in the knowledge gained from other development
+ evidence.
+
+ The approach taken to the methodical search for vulnerabilities
+ is to consider any areas of concern identified in the results of
+ the evaluator's assessment of the development and guidance
+ evidence. However, the evaluator should also consider each
+ aspect of the security architecture analysis to search for any
+ ways in which the protection of the TSF can be undermined. It
+ may be helpful to structure the methodical analysis on the basis
+ of the material presented in the security architecture
+ description, introducing concerns from other evidence as appropriate. The analysis can then be
+ further developed to ensure all other material from the evidence is considered.
+
+ The following provide some examples of hypotheses that
+ may be created when examining the evidence:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that 'all interface
+ specifications in the evidence provided will be searched
+ to hypothesise potential vulnerabilities' and go on to
+ explain the methods used in the hypothesis.
+
+ In addition, areas of concern the evaluator has identified
+ during examination of the evidence during the conduct of
+ evaluation activities. Areas of concern may also be identified
+ during the conduct of other work units associated with this
+ component, in particular ,
+ and where the development and conduct of penetration
+ tests may identify further areas of concerns for investigation,
+ or potential vulnerabilities.
+
+ However, examination of only a subset of the development
+ and guidance evidence or their contents is not permitted
+ in this level of rigour. The approach description should
+ provide a demonstration that the methodical approach
+ used is complete, providing confidence that the approach
+ used to search the deliverables has considered all of
+ the information provided in those deliverables.
+
+ This approach to identification of potential vulnerabilities is
+ to take an ordered and planned approach; applying a system to
+ the examination. The evaluator is to describe the method to be
+ used in terms of how the evidence will be considered; the manner
+ in which this information is to be considered and the hypothesis
+ that is to be created. This approach should be agreed with the
+ evaluation authority, and the evaluation authority may
+ provide detail of any additional approaches the evaluator should
+ take to the vulnerability analysis and identify any additional
+ information that should be considered by the evaluator.
+
+ Although a system to identifying potential
+ vulnerabilities is predefined, the identification
+ process may still be iterative, where the identification
+ of one potential vulnerability may lead to identifying
+ another area of concern that requires further
+ investigation.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing Moderate attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the
+ security architecture description in the search for
+ vulnerabilities (as detailed in ), testing should be performed to confirm the
+ architectural properties. If requirements from are included in the SARs, the
+ developer testing evidence will include testing
+ performed to confirm the correct implementation of any
+ specific mechanisms detailed in the security
+ architecture description. However, the developer testing
+ will not necessarily include testing of all aspects of
+ the architectural properties that protect the TSF, as
+ much of this testing will be negative testing in nature,
+ attempting to disprove the properties. In developing the
+ strategy for penetration testing, the evaluator will
+ ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Moderate (or less) attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Moderate attack potential is required
+ to effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Moderate attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI;
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Moderate attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than a High attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than High.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of High.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing High
+ attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+ If the TOE SFRs include and
+ requirements such that
+ actions and data of one subject cannot be observed and
+ linked with another subject, the evaluator should consider
+ performing a covert channel analysis. This will build
+ upon the design evidence provided by the developer in
+ satisfaction of and requirements. The design evidence
+ will include details of how the TOE architecture prevents
+ observation by subjects of actions performed by other
+ subjects. the evaluator should seek guidance from the
+ evaluation authority on the conduct of such a covert
+ channel analysis.
+
+ The analysis of the guidance documentation is to include
+ consideration of whether it is possible to unknowingly
+ configure the TOE insecurely. Therefore, the analysis will
+ consider warning prompts provided by the TOE when
+ configuration options are selected by the user that may
+ render the TOE in an insecure state, not just in the
+ guidance but also in the use of the TOE. An example may be
+ when access control rules are amended from a remote
+ administration console, which will not take effect until
+ the TOE has been restarted. The evaluator will determine
+ whether the TOE issues a suitable warning when the changes
+ are made to ensure the user is aware that a restart must
+ be completed before the changes take effect.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing High attack potential.
+
+
+
+
+
+
+
+ EAL1 is applicable where some confidence in correct operation
+ is required, but the threats to security are not viewed as
+ serious. It will be of value where independent assurance is
+ required to support the contention that due care has been
+ exercised with respect to the protection of personal or
+ similar information.
+
+ EAL1 requires only a limited security target. It is sufficient
+ to simply state the SFRs that the TOE must meet, rather than
+ deriving them from threats, OSPs and assumptions through
+ security objectives.
+
+ EAL1 provides an evaluation of the TOE as made available to
+ the customer, including independent testing against a
+ specification, and an examination of the guidance
+ documentation provided. It is intended that an EAL1 evaluation
+ could be successfully conducted without assistance from the
+ developer of the TOE, and for minimal outlay.
+
+ An evaluation at this level should provide evidence that the
+ TOE functions in a manner consistent with its
+ documentation.
+
+
+
+ EAL1 provides a basic level of assurance by a limited security
+ target and an analysis of the SFRs in that ST using a
+ functional and interface specification and guidance
+ documentation, to understand the security behaviour.
+
+ The analysis is supported by a search for potential
+ vulnerabilities in the public domain and independent testing
+ (functional and penetration) of the TSF.
+
+ EAL1 also provides assurance through unique identification of
+ the TOE and of the relevant evaluation documents.
+
+ This EAL provides a meaningful increase in assurance over
+ unevaluated IT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL2 requires the co-operation of the developer in terms of
+ the delivery of design information and test results, but
+ should not demand more effort on the part of the developer
+ than is consistent with good commercial practise. As such it
+ should not require a substantially increased investment of
+ cost or time.
+
+ EAL2 is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record. Such a
+ situation may arise when securing legacy systems, or where
+ access to the developer may be limited.
+
+
+
+ EAL2 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation and a basic
+ description of the architecture of the TOE, to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, selective independent confirmation of the
+ developer test results, and a vulnerability analysis (based
+ upon the functional specification, TOE design, security architecture
+ description and guidance evidence provided) demonstrating
+ resistance to penetration attackers with a basic attack
+ potential.
+
+ EAL2 also provides assurance through use of a configuration
+ management system and evidence of secure delivery
+ procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL1 by requiring developer testing, a vulnerability analysis
+ (in addition to the search of the public domain), and
+ independent testing based upon more detailed TOE
+ specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL3 permits a conscientious developer to gain maximum
+ assurance from positive security engineering at the design
+ stage without substantial alteration of existing sound
+ development practises.
+
+ EAL3 is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the TOE and
+ its development without substantial re-engineering.
+
+
+
+ EAL3 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation, and an
+ architectural description of the design of the TOE, to
+ understand the security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent
+ confirmation of the developer test results, and a
+ vulnerability analysis (based upon the functional
+ specification, TOE design, security architecture description and guidance
+ evidence provided) demonstrating resistance to penetration
+ attackers with a basic attack potential.
+
+ EAL3 also provides assurance through the use of development
+ environment controls, TOE configuration management, and
+ evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL2 by requiring more complete testing coverage of the
+ security functionality and mechanisms and/or procedures that
+ provide some confidence that the TOE will not be tampered with
+ during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL4 permits a developer to gain maximum assurance from
+ positive security engineering based on good commercial
+ development practises which, though rigorous, do not require
+ substantial specialist knowledge, skills, and other
+ resources. EAL4 is the highest level at which it is likely to
+ be economically feasible to retrofit to an existing product
+ line.
+
+ EAL4 is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity TOEs
+ and are prepared to incur additional security-specific
+ engineering costs.
+
+
+
+ EAL4 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the basic modular design of the TOE, and a
+ subset of the implementation, to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent confirmation
+ of the developer test results, and a vulnerability analysis
+ (based upon the functional specification, TOE design,
+ implementation representation, architectural design and guidance
+ evidence provided) demonstrating resistance to penetration
+ attackers with an Enhanced-Basic attack potential.
+
+ EAL4 also provides assurance through the use of development
+ environment controls and additional TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from EAL3
+ by requiring more design description, the implementation
+ representation for the entire TSF, and improved mechanisms
+ and/or procedures that provide confidence that the TOE will not
+ be tampered with during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL5 permits a developer to gain maximum assurance from
+ security engineering based upon rigorous commercial
+ development practises supported by moderate application of
+ specialist security engineering techniques. Such a TOE will
+ probably be designed and developed with the intent of
+ achieving EAL5 assurance. It is likely that the additional
+ costs attributable to the EAL5 requirements, relative to
+ rigorous development without the application of specialised
+ techniques, will not be large.
+
+ EAL5 is therefore applicable in those circumstances where
+ developers or users require a high level of independently
+ assured security in a planned development and require a
+ rigorous development approach without incurring unreasonable
+ costs attributable to specialist security engineering
+ techniques.
+
+
+
+ EAL5 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the design of the TOE, and the implementation,
+ to understand the security behaviour. A modular TSF design is
+ also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a moderate attack potential.
+
+ EAL5 also provides assurance through the use of a development
+ environment controls, and comprehensive TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from EAL4
+ by requiring semiformal design descriptions, a more structured
+ (and hence analysable) architecture, and improved mechanisms
+ and/or procedures that provide confidence that the TOE will not
+ be tampered with during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL6 permits developers to gain high assurance from
+ application of security engineering techniques to a rigorous
+ development environment in order to produce a premium TOE for
+ protecting high value assets against significant risks.
+
+ EAL6 is therefore applicable to the development of security
+ TOEs for application in high risk situations where the value
+ of the protected assets justifies the additional costs.
+
+
+
+ EAL6 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and the implementation to understand the
+ security behaviour. Assurance is additionally gained through a
+ formal model of select TOE security policies and a semiformal
+ presentation of the functional specification and TOE design. A
+ modular and layered TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a high attack potential.
+
+ EAL6 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL5 by requiring more comprehensive analysis, a structured
+ representation of the implementation, more architectural
+ structure (e.g. layering), more comprehensive independent
+ vulnerability analysis, and improved configuration management
+ and development environment controls.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL7 is applicable to the development of security TOEs for
+ application in extremely high risk situations and/or where the
+ high value of the assets justifies the higher costs. Practical
+ application of EAL7 is currently limited to TOEs with tightly
+ focused security functionality that is amenable to extensive
+ formal analysis.
+
+
+
+ EAL7 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and a structured presentation of the
+ implementation to understand the security behaviour. Assurance
+ is additionally gained through a formal model of select TOE
+ security policies and a semiformal presentation of the
+ functional specification and TOE design. A modular, layered
+ and simple TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design and implementation representation,
+ complete independent confirmation of the developer test
+ results, and an independent vulnerability analysis
+ demonstrating resistance to penetration attackers with a high
+ attack potential.
+
+ EAL7 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL6 by requiring more comprehensive analysis using formal
+ representations and formal correspondence, and comprehensive
+ testing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-A is applicable when a composed TOE is integrated and
+ confidence in the correct security operation of the resulting
+ composite is required. This requires the cooperation of the
+ developer of the dependent component in terms of delivery of
+ design information and test results from the dependent
+ component certification, without requiring the involvement of
+ the base component developer.
+
+ CAP-A is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record.
+
+
+
+ CAP-A provides assurance by analysis of a security target for
+ the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation) and a
+ specification for the interfaces between the component TOEs in
+ the composed TOE to understand the security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information,
+ evidence of developer testing based on the reliance
+ information, development information and composition
+ rationale, and selective independent confirmation of the
+ developer test results. The analysis is also supported by a
+ vulnerability review of the composed TOE by the
+ evaluator.
+
+ CAP-A also provides assurance through unique identification of
+ the composed TOE (i.e. IT TOE and guidance
+ documentation).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-B permits a conscientious developer to gain maximum
+ assurance from understanding, at a subsystem level, the
+ affects of interactions between component TOEs integrated in
+ the composed TOE, whilst minimising the demand of involvement
+ of the base component developer.
+
+ CAP-B is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the composed
+ TOE and its development without substantial
+ re-engineering.
+
+
+
+ CAP-B provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF subsystems) contained in
+ the composed development information to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now also including TOE design), evidence of developer testing
+ based on the reliance information, development information and
+ composition rationale, and selective independent confirmation
+ of the developer test results. The analysis is also supported
+ by a vulnerability analysis of the composed TOE by the
+ evaluator demonstrating resistance to attackers with basic
+ attack potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-A by requiring more complete testing coverage of the
+ security functionality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-C permits a developer to gain maximum assurance from
+ positive analysis of the interactions between the components
+ of the composed TOE, which, though rigorous, do not require
+ full access to all evaluation evidence of the base
+ component.
+
+ CAP-C is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity
+ composed TOEs and are prepared to incur additional
+ security-specific engineering costs.
+
+
+
+ CAP-C provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF modules) contained in the
+ composed development information to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now including TOE design), evidence of developer testing based
+ on the reliance information, development information and
+ composition rationale, and selective independent confirmation of
+ the developer test results. The analysis is also supported by a
+ vulnerability analysis of the composed TOE by the evaluator
+ demonstrating resistance to attackers with Enhanced-Basic attack
+ potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-B by requiring more design description and demonstration
+ of resistance to a higher attack potential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/c5dec/assets/database/SecurityControls/cc3R3.xml b/c5dec/assets/database/SecurityControls/cc3R3.xml
new file mode 100644
index 0000000..7a9fd93
--- /dev/null
+++ b/c5dec/assets/database/SecurityControls/cc3R3.xml
@@ -0,0 +1,53805 @@
+
+
+
+
+
+
+ For the purposes of this document, the terms, definitions,
+ symbols and abbreviated terms given in CC Part 1 apply.
+
+
+
+ Security assurance components, as defined in this CC Part 3, are
+ the basis for the security assurance requirements expressed in a
+ Protection Profile (PP) or a Security Target (ST).
+
+ These requirements establish a standard way of expressing the
+ assurance requirements for TOEs. This CC Part 3 catalogues the
+ set of assurance components, families and classes. This CC Part
+ 3 also defines evaluation criteria for PPs and STs and presents
+ evaluation assurance levels that define the predefined CC scale
+ for rating assurance for TOEs, which is called the Evaluation
+ Assurance Levels (EALs).
+
+ The audience for this CC Part 3 includes consumers, developers,
+ and evaluators of secure IT products. CC Part 1 Clause provides additional information
+ on the target audience of the CC, and on the use of the CC by
+ the groups that comprise the target audience. These groups may
+ use this part of the CC as follows:
+
+
+ Consumers, who use this CC Part 3 when selecting components
+ to express assurance requirements to satisfy the security
+ objectives expressed in a PP or ST, determining required
+ levels of security assurance of the TOE.
+
+
+ Developers, who respond to actual or perceived consumer
+ security requirements in constructing a TOE, reference this
+ CC Part 3 when interpreting statements of assurance
+ requirements and determining assurance approaches of TOEs.
+
+
+ Evaluators, who use the assurance requirements defined in
+ this part of the CC as mandatory statement of evaluation
+ criteria when determining the assurance of TOEs and when
+ evaluating PPs and STs.
+
+
+
+
+
+
+ Clause describes the paradigm
+ used in the security assurance requirements of CC Part
+ 3.
+
+ Clause describes the
+ presentation structure of the assurance classes, families,
+ components, evaluation assurance levels along with their
+ relationships, and the structure of the composed assurance
+ packages. It also characterises the assurance classes and
+ families found in Clauses through
+ .
+
+ Clause provides detailed
+ definitions of the EALs.
+
+ Clause provides detailed
+ definitions of the CAPs.
+
+ Clauses through provide the detailed definitions of the CC Part 3
+ assurance classes.
+
+ provides further
+ explanations and examples of the concepts behind the
+ Development class.
+
+ provides an explanation of
+ the concepts behind composed TOE evaluations and the
+ Composition class.
+
+ provides
+ a summary of the dependencies between the assurance
+ components.
+
+ provides a cross
+ reference between PPs and the families and components of the
+ class.
+
+ provides a cross reference
+ between the EALs and the assurance components.
+
+ provides a cross reference
+ between the CAPs and the assurance components.
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CC-1
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 1: Introduction and general model.
+
+
+
+ CC-2
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 2: Functional security components.
+
+
+
+
+
+ This CC Part 3 defines the assurance requirements of the CC. It
+ includes the evaluation assurance levels (EALs) that define a
+ scale for measuring assurance for component TOEs, the composed
+ assurance packages (CAPs) that define a scale for measuring
+ assurance for composed TOEs, the individual assurance components
+ from which the assurance levels and packages are composed, and
+ the criteria for evaluation of PPs and STs.
+
+
+
+ The goal of this annex is to explain the concepts behind
+ composition evaluations and the
+ criteria. This annex does not define the criteria; this definition can be found in clause
+ .
+
+
+ The IT market is, on the whole, made up of vendors offering a
+ particular type of product/technology. Although there is some
+ overlap, where a PC hardware vendor may also offer application
+ software and/or operating systems or a chip manufacturer may
+ also develop a dedicated operating system for their own
+ chipset, it is often the case that an IT solution is
+ implemented by a variety of vendors.
+
+ There is sometimes a need for assurance in the combination
+ (composition) of components in addition to the assurance of
+ the individual components. Although there is cooperation
+ between these vendors, in the dissemination of certain
+ material required for the technical integration of the
+ components, the agreements rarely stretch to the extent of
+ providing detailed design information and development
+ process/procedure evidence. This lack of information from the
+ developer of a component on which another component relies
+ means that the dependent component developer does not have
+ access to the type of information necessary to perform an
+ evaluation of both the dependent and base components at EAL2
+ or above. Therefore, while an evaluation of the dependent
+ component can still be performed at any assurance level, to
+ compose components with assurance at EAL2 or above it is
+ necessary to reuse the evaluation evidence and results of
+ evaluations performed for the component developer.
+
+ It is intended that the criteria
+ are applicable in the situation where one IT entity is
+ dependent on another for the provision of security
+ services. The entity providing the services is termed the
+ ``base component'', and that receiving the services is termed
+ the ``dependent component''. This relationship may exist in a
+ number of contexts. For example, an application (dependent
+ component) may use services provided by an operating system
+ (base component). Alternatively, the relationship may be
+ peer-to-peer, in the sense of two linked applications, either
+ running in a common operating system environment, or on
+ separate hardware platforms. If there is a dominant peer
+ providing the services to the minor peer, the dominant peer is
+ considered to be the base component and the minor peer the
+ dependent component. If the peers provide services to each
+ other in a mutual manner, each peer will be considered to be
+ the base component for the services offered and dependent
+ component for the services required. This will require
+ iterations of the components
+ applying all requirements to each type of component
+ peer.
+
+ The criteria are also intended to be more broadly applicable,
+ stepwise (where a composed TOE comprised of a dependent
+ component and a base component itself becomes the base
+ component of another composed TOE), in more complex
+ relationships, but this may require further
+ interpretation.
+
+ It is still required for composed TOE evaluations that the
+ individual components are evaluated independently, as the
+ composition evaluation builds on the results of the individual
+ component evaluations. The evaluation of the dependent
+ component may still be in progress when the composed TOE
+ evaluation commences. However, the dependent component
+ evaluation must complete before the composed TOE evaluation
+ completes.
+
+ The composed evaluation activities may take place at the same
+ time as the dependent component evaluation. This is due to two
+ factors:
+
+
+ Economic/business drivers - the dependent component
+ developer will either be sponsoring the composition
+ evaluation activities or supporting these activities as
+ the evaluation deliverables from the dependent component
+ evaluation are required for composed evaluation
+ activities.
+
+ Technical drivers - the components consider whether the
+ requisite assurance is provided by the base component
+ (e.g. considering the changes to the base component since
+ completion of the component evaluation) with the
+ understanding that the dependent component has recently
+ undergone (is undergoing) component evaluation and all
+ evaluation deliverables associated with the evaluation are
+ available. Therefore, there are no activities during
+ composition requesting the dependent component evaluation
+ activities to be re-verified. Also, it is verified that
+ the base component forms (one of) the test configurations
+ for the testing of the dependent component during the
+ dependent component evaluation, leaving to consider the base component in this
+ configuration.
+
+ The evaluation evidence from the evaluation of the dependent
+ component is required input into the composed TOE evaluation
+ activities. The only evaluation material from the evaluation
+ of the base component that is required as input into the
+ composed TOE evaluation activities:
+
+
+ Residual vulnerabilities in the base component, as
+ reported during the base component evaluation. This is
+ required for the
+ activities.
+
+ No other evaluation evidence from the base component
+ activities should be required for the composed TOE evaluation,
+ as the evaluation results from the component evaluation of the
+ base component should be reused. Additional information about
+ the base component may be required if the composed TOE TSF
+ includes more of the base component than was considered to be
+ TSF during component evaluation of the base component.
+
+ The component evaluation of the base and dependent components
+ are assumed to be complete by the time final verdicts are
+ assigned for the components.
+
+ The components only consider
+ resistance against an attacker with an attack potential up to
+ Enhanced-Basic. This is due to the level of design information
+ that can be provided of how the base component provides the
+ services on which the dependent component relies through
+ application of the
+ activities. Therefore, the confidence arising from composed TOE
+ evaluations using CAPs is limited to a level similar to that
+ obtained from EAL4 component TOE evaluations. Although
+ assurance in the components that comprise the composed TOE may
+ be higher than EAL4.
+
+
+
+ An ST will be submitted by the developer for the evaluation of
+ the composed (base component + dependent component) TOE. This
+ ST will identify the assurance package to be applied to the
+ composed TOE, providing assurance in the composed entity by
+ drawing upon the assurance gained in the component
+ evaluations.
+
+ The purpose of considering the composition of components
+ within an ST is to validate the compatibility of the
+ components from the point of view of both the environment and
+ the requirements, and also to assess that the composed TOE ST
+ is consistent with the component STs and the security policies
+ expressed within them. This includes determining that the
+ component STs and the security policies expressed within them
+ are compatible.
+
+ The composed TOE ST may refer out to the content of the
+ component STs, or the ST author may chose to reiterate the
+ material of the component STs within the composed TOE ST
+ providing a rationale of how the component STs are represented
+ in the composed TOE ST.
+
+ During the conduct of the
+ evaluation activities for a composed TOE ST the evaluator
+ determines that the component STs are accurately represented
+ in the composed TOE ST. This is achieved through determining
+ that the composed TOE ST demonstrably conforms to the
+ component TOE STs. Also, the evaluator will need to determine
+ that the dependencies of the dependent component on the
+ operational environment are adequately fulfilled in the
+ composed TOE.
+
+ The composed TOE description will describe the composed
+ solution. The logical and physical scope and boundary of the
+ composed solution will be described, and the logical
+ boundary(ies) between the components will also be
+ identified. The description will identify the security
+ functionality to be provided by each component.
+
+ The statement of SFRs for the composed TOE will identify which
+ component is to satisfy an SFR. If an SFR is met by both
+ components, then the statement will identify which component
+ meets the different aspects of the SFR. Similarly the composed
+ TOE Summary Specification will identify which component
+ provides the security functionality described.
+
+ The package of requirements
+ applied to the composed TOE ST should be consistent with the
+ package of requirements used in
+ the component evaluations.
+
+ Reuse of evaluation results from the evaluation of component
+ STs can be made in the instances that the composed TOE ST
+ directly refers to the component STs. e.g. if the composed TOE
+ ST refers to a component ST for part of its statement of SFRs,
+ the evaluator can understand that the requirement for the
+ completion of all assignment and selection operations (as
+ stated in .*.3C has been
+ satisfied in the component evaluations.
+
+
+
+ The TSF of the base component is often defined without
+ knowledge of the dependencies of the possible applications
+ with which it may by composed. The TSF of this base component
+ is defined to include all parts of the base component that
+ have to be relied upon for enforcement of the base component
+ SFRs. This will include all parts of the base component
+ required to implement the base component SFRs.
+
+ The TSFI of this base component represents the interfaces
+ provided by the TSF to the external entities defined in the
+ statement of SFRs to invoke a service of the TSF. This
+ includes interfaces to the human user and also interfaces to
+ external IT entities. However, the TSFI only includes those
+ interfaces to the TSF, and therefore is not necessarily an
+ exhaustive interface specification of all possible interfaces
+ available between an external entity and the base
+ component. The base component may present interfaces to
+ services that were not considered security-relevant, either
+ because of the inherent purpose of the service (e.g., adjust
+ type font) or because associated CC SFRs are not being claimed
+ in the base component's ST (e.g. the login interface when no
+ SFRs are claimed).
+
+ The functional interfaces provided by the base component are
+ in addition to the security interfaces (TSFIs), and are not
+ required to be considered during the base component
+ evaluation. These often include interfaces that are used by a
+ dependent component to invoke a service provided by the base
+ component.
+
+ The base component may include some indirect interfaces
+ through which TSFIs may be called, e.g. APIs that can be used
+ to invoke a service of the TSF, which were not considered
+ during the evaluation of the base component.
+
+
+ The dependent component, which relies on the base component,
+ is similarly defined: interfaces to external entities defined
+ in the SFRs of the component ST are categorised as TSFI and
+ are examined in .
+
+ Any call out from the dependent TSF to the environment in
+ support of an SFR will indicate that the dependent TSF
+ requires some service from the environment in order to satisfy
+ the enforcement of the stated dependent component SFRs. Such a
+ service is outside the dependent component boundary and the
+ base component is unlikely to be defined in the dependent ST
+ as an external entity. Hence, the calls for services made out
+ by the dependent TSF to its underlying platform (the base
+ component) will not be analysed as part of the activities. These dependencies on
+ the base component are expressed in the dependent component ST
+ as security objectives for the environment.
+
+ This abstraction of the dependent component and the interfaces
+ is shown in Figure
+ below.
+
+
+ When considering the composition of the base component and the
+ dependent component, if the dependent component's TSF requires
+ services from the base component to support the implementation
+ of the SFR, the interface to the service will need to be
+ defined. If that service is provided by the base component's
+ TSF, then that interface should be a TSFI of the base
+ component and will therefore already be defined within the
+ functional specification of the base component.
+
+ If, however, the service called by the dependent component's
+ TSF is not provided by the TSF of the base component (i.e., it
+ is implemented in the non-TSF portion of the base component or
+ possibly even in the non-TOE portion of the base component
+ (not illustrated in Figure ), there is unlikely to be a TSFI of the base
+ component relating to the service, unless the service is
+ mediated by the TSF of the base component. The interfaces to
+ these services from the dependent component to the operational
+ environment are considered in the family .
+
+ The non-TSF portion of the base component is drawn into the
+ TSF of the composed TOE due to the dependencies the dependent
+ component has on the base component to support the SFRs of the
+ dependent component. Therefore, in such cases, the TSF of the
+ composed TOE would be larger than simply the sum of the
+ components' TSFs.
+
+
+ It may be the case that the base component TSFI is being
+ called in a manner that was unforeseen in the base component
+ evaluation. Hence there would be a requirement for further
+ testing of the base component TSFI.
+
+ The possible interfaces are further described in the following
+ diagram (Figure ) and
+ supporting text.
+
+
+
+
+ Arrows going into 'dependent component-a'
+ (A and B) = where the component expects the environment to
+ respond to a service request (responding to calls out from
+ dependent component to the environment);
+
+ Arrows coming out of 'base component-b'
+ (C and D) = interfaces of services provided by the base
+ component to the environment;
+
+ Broken lines between components = types of communication
+ between pairs of interfaces;
+
+ The other (grey) arrows = interfaces that are described by
+ the given criteria.
+
+ The following is a simplification, but explains the
+ considerations that need to be made.
+
+ There are components a ('dependent component-a') and b ('base
+ component-b'): the arrows coming out of TSF-a
+ are services provided by TSF-a and are therefore TSFIs(a);
+ likewise, the arrows coming out of TSF-b
+ (``C'') are TSFIs(b). These are each detailed in their
+ respective functional specs. component-a is such that it
+ requires services from its environment: those needed by the
+ TSF(a) are labelled ``A''; the other (not related to TSF-a)
+ services are labelled ``B''.
+
+ When component-a and component-b are combined, there are four
+ possible combinations of {services needed by component-a} and
+ {services provided by component-b}, shown as broken lines
+ (types of communication between pairs of interfaces). Any set
+ of these might exist for a particular composition:
+
+
+ TSF-a needs those services that are provided by TSF-b ("A" is connected to "C"):
+ this is straightforward: the details about "C" are in the FSP for component-b.
+ In this instance the interfaces should all be defined in the functional specifications for
+ the component-b.
+
+
+ Non-TSF-a needs those services that are provided by TSF-b
+ (``B'' is connected to ``C''): this is straightforward
+ (again, the details about ``C'' are in the FSP for
+ component-b), but unimportant: security-wise.
+
+ Non-TSF-a needs those services that are provided by
+ non-TSF-b (``B'' is connected to ``D''): we have no
+ details about D, but there are no security implications
+ about the use of these interfaces, so they do not need to
+ be considered in the evaluation, although they are likely
+ to be an integration issue for the developer.
+
+ TSF-a needs those services that are provided by non-TSF-b
+ (``A'' is connected to ``D''): this would arise when
+ component-a and component-b have different senses of what
+ a ``security service'' is. Perhaps component-b is making
+ no claims about I&A (has no
+ SFRs in its ST), but component-a needs authentication
+ provided by its environment. There are no details about
+ the ``D'' interfaces available (they are not TSFI (b), so
+ they are not in component-b's FSP).
+
+ Note: if the kind of interaction described in case d above
+ exists, then the TSF of the composed TOE would be TSF-a + TSF-b
+ + Non-TSF-b. Otherwise, the TSF of the composed TOE would be
+ TSF-a + TSF-b.
+
+ Interfaces types 2 and 4 of Figure are not directly relevant to the evaluation of
+ the composed TOE. Interfaces 1 and 3 will be considered during
+ the application of different families:
+
+
+ (for component-b) will
+ describe the C interfaces.
+
+ will describe the A
+ interfaces.
+
+ will describe the C
+ interfaces for connection type 1 and the D interfaces for
+ connection type 3.
+
+ A typical example where composition may be applied is a
+ database management system (DBMS) that relies upon its
+ underlying operating system (OS). During the evaluation of
+ the DBMS component, there will be an assessment made of the
+ security properties of that DBMS (to whatever degree of rigour
+ is dictated by the assurance components used in the
+ evaluation): its TSF boundary will be identified, its
+ functional specification will be assessed to determine whether
+ it describes the interfaces to the security services provided
+ by the TSF, perhaps additional information about the TSF (its
+ design, architecture, internal structure) will be provided,
+ the TSF will be tested, aspects of its life-cycle and its
+ guidance documentation will be assessed, etc.
+
+ However, the DBMS evaluation will not call for any evidence
+ concerning the dependency the DBMS has on the OS. The ST of
+ the DBMS will most likely state assumptions about the OS in
+ its Assumptions subclause and state security objectives for the
+ OS in its Environment subclause. The DBMS ST may even
+ instantiate those objectives for the environment in terms of
+ SFRs for the OS. However, there will be no specification for
+ the OS that mirrors the detail in the functional
+ specification, architecture description, or other evidence as for the DBMS. will fulfil that need.
+
+ describes the interfaces of
+ the dependent TOE that make the calls to the base component
+ for the provision of services. These are the interfaces to
+ which the base component is to respond. The interface
+ descriptions are provided from the dependent component's
+ viewpoint.
+
+ describes the interfaces
+ provided by the base component, which respond to the dependent
+ component service requests. These interfaces are mapped to the
+ relevant dependent component interfaces that are identified in
+ the reliance information. (The completeness of this mapping,
+ whether the base component interfaces described represent all
+ dependent component interfaces, is not verified here, but in
+ ). At the higher levels of
+ the subsystems providing the
+ interfaces are described.
+
+ Any interfaces required by the dependent component that have
+ not been described for the base component are reported in the
+ rationale for . The rationale
+ also reports whether the interfaces of the base component on
+ which the dependent component relies were considered within
+ the base component evaluation. For any interfaces that were
+ not considered in the base component evaluation, a rationale
+ is provided of the impact of using the interface on the base
+ component TSF.
+
+
+
+
+ This annex contains ancillary material to further explain and
+ provide additional examples for the topics brought up in
+ families of the class.
+
+
+ A security architecture is a set of properties that the TSF
+ exhibits; these properties include self-protection, domain
+ separation, and non-bypassability. Having these properties
+ provides a basis of confidence that the TSF is providing its
+ security services. This annex provides additional material on
+ these properties, as well as discussion on contents of a
+ security architecture description.
+
+ The remainder of this subclause first explains these properties,
+ then discusses the kinds of information that are needed to
+ describe how the TSF exhibits those properties.
+
+ Self-protection refers to the ability of
+ the TSF to protect itself from manipulation from external
+ entities that may result in changes to the TSF. Without these
+ properties, the TSF might be disabled from performing its
+ security services.
+
+ It is oftentimes the case that a TOE uses services or
+ resources supplied by other IT entities in order to perform
+ its functions (e.g. an application that relies upon its
+ underlying operating system). In these cases, the TSF does
+ not protect itself entirely on its own, because it depends
+ on the other IT entities to protect the services it
+ uses.
+ Domain separation is a property whereby the TSF
+ creates separate security domains for each
+ untrusted active entity to operate on its resources, and then
+ keeps those domains separated from one another so that no entity
+ can run in the domain of any other. For example, an operating
+ system TOE supplies a domain (address space, per-process
+ environment variables) for each process associated with
+ untrusted entities.
+
+ For some TOEs such domains do not exist because all of the
+ actions of the untrusted entities are brokered by the TSF. A
+ packet-filter firewall is an example of such a TOE, where
+ there are no untrusted entity domains; there are only data
+ structures maintained by the TSF. The existence of domains,
+ then, is dependant upon 1) the type of TOE and 2) the SFRs
+ levied on the TOE. In the cases where the TOE does provide
+ domains for untrusted entities, this family requires that
+ those domains are isolated from one another such that
+ untrusted entities in one domain are prevented from
+ tampering (affecting without brokering by the TSF) from
+ another untrusted entity's domain.
+
+ Non-bypassability is a property that the
+ security functionality of the TSF (as specified by the SFRs)
+ is always invoked and cannot be circumvented when
+ appropriate for that specific mechanism. For example, if
+ access control to files is specified as a capability of the
+ TSF via an SFR, there must be no interfaces through which
+ files can be accessed without invoking the TSF's access
+ control mechanism (an interface through which a raw disk
+ access takes place might be an example of such an
+ interface).
+
+ As is the case with self-protection, the very nature of some
+ TOEs might depend upon their environments to play a role in
+ non-bypassability of the TSF. For example, a security
+ application TOE requires that it be invoked by the
+ underlying operating system. Similarly, a firewall depends
+ upon the fact that there are no direct connections between
+ the internal and external networks and that all traffic
+ between them must go through the firewall.
+
+
+ The security architecture description explains how the
+ properties described above are exhibited by the TSF. It
+ describes how domains are defined and how the TSF keeps them
+ separate. It describes what prevents untrusted processes
+ from getting to the TSF and modifying it. It describes what
+ ensures that all resources under the TSF's control are
+ adequately protected and that all actions related to the
+ SFRs are mediated by the TSF. It explains any role the
+ environment plays in any of these (e.g. presuming it gets
+ correctly invoked by its underlying environment, how are its
+ security functions invoked?).
+
+ The security architecture description presents the TSF's
+ properties of self-protection, domain separation, and
+ non-bypassability in terms of the decomposition descriptions.
+ The level of this description is commensurate with the TSF
+ description required by the ,
+ and requirements that are being claimed. For example, if
+ is the only TSF description
+ available, it would be difficult to provide any meaningful
+ security architecture description because none of the details of
+ any internal workings of the TSF would be available.
+
+ However, if the TOE design were also available, even at the most
+ basic level (), there would be
+ some information available concerning the subsystems that make
+ up the TSF, and there would be a description of how they work to
+ implement self-protection, domain separation, and
+ non-bypassability. For example, perhaps all user interaction
+ with the TOE is constrained through a process that acts on that
+ user's behalf, adopting all of the user's security attributes;
+ the security architecture description would describe how such a
+ process comes into being, how the process's behaviour is
+ constrained by the TSF (so it cannot corrupt the TSF), how all
+ actions of that process are mediated by the TSF (thereby
+ explaining why the TSF cannot be bypassed), etc.
+
+ If the available TOE design is more detailed (e.g. at the
+ modular level), or the implementation representation is also
+ available, then the security architecture description would be
+ correspondingly more detailed, explaining how the user's process
+ communicate with the TSF processes, how different requests are
+ processed by the TSF, what parameters are passed, what
+ programmatic protections (buffer overflow prevention, parameter
+ bounds checking, time of check/time of use checking, etc.) are
+ in place. Similarly, a TOE whose ST claimed the component would go into
+ implementation-specific detail.
+
+ The explanations provided in the security architecture
+ description are expected to be of sufficient detail that one
+ would be able to test their accuracy. That is, simple
+ assertions (e.g. "The TSF keeps domains separate'') provide
+ no useful information to convince the reader that the TSF
+ does indeed create and separate domains.
+
+ In cases where the TOE exhibits domain separation entirely on
+ its own, there would be a straightforward description of how
+ this is attained. The security architecture description would
+ explain the different kinds of domains that are defined by the
+ TSF, how they are defined (i.e. what resources are allocated
+ to each domain), how no resources are left unprotected, and
+ how the domains are kept separated so that active entities in
+ one domain cannot tamper with resources in another
+ domain.
+ For cases where the TOE depends upon other IT entities to play
+ a role in domain separation, that sharing of roles must be made
+ clear. For example, a TOE that is solely application software
+ relies upon the underlying operating system to correctly
+ instantiate the domains that the TOE defines; if the TOE
+ defines separate processing space, memory space, etc, for each
+ domain, it depends upon the underlying operating system to
+ operate correctly and benignly (e.g. allow the process to
+ execute only in the execution space that is requested by the
+ TOE software).
+ For example, mechanisms that implement domain separation
+ (e.g., memory management, protected processing modes provided
+ by the hardware, etc.) would be identified and described. Or,
+ the TSF might implement software protection constructs or
+ coding conventions that contribute to implementing separation
+ of software domains, perhaps by delineating user address space
+ from system address space.
+ The vulnerability analysis and testing (see ) activities will likely include attempts to defeat
+ the described TSF domain separation through the use of
+ monitoring or direct attack the TSF.
+
+
+ In cases where the TOE exhibits self-protection entirely
+ on its own, there would be a straightforward description
+ of how this self-protection is attained. Mechanisms that
+ provide domain separation to define a TSF domain that is
+ protected from other (user) domains would be identified
+ and described.
+
+ For cases where the TOE depends upon other IT entities to
+ play a role in protecting itself, that sharing of roles
+ must be made clear. For example, a TOE that is solely
+ application software relies upon the underlying operating
+ system to operate correctly and benignly; the application
+ cannot protect itself against a malicious operating system
+ that subverts it (for example, by overwriting its
+ executable code or TSF data).
+
+ The security architecture description also covers how user input
+ is handled by the TSF in such a way that the TSF does not
+ subject itself to being corrupted by that user input. For
+ example, the TSF might implement the notion of privilege and
+ protect itself by using privileged-mode routines to handle user
+ data. The TSF might make use of processor-based separation
+ mechanisms (e.g. privilege levels or rings) to separate TSF
+ code and data from user code and data. The TSF might implement
+ software protection constructs or coding conventions that
+ contribute to implementing separation of software, perhaps by
+ delineating user address space from system address space.
+
+ For TOEs that start up in a low-function mode (for
+ example, a single-user mode accessible only to installers
+ or administrators) and then transition to the evaluated
+ secure configuration (a mode whereby untrusted users are
+ able to login and use the services and resources of the
+ TOE), the security architecture description also includes
+ an explanation of how the TSF is protected against this
+ initialisation code that does not run in the evaluated
+ configuration. For such TOEs, the security architecture
+ description would explain what prevents those services
+ that should be available only during initialisation
+ (e.g. direct access to resources) from being accessible in
+ the evaluated configuration. It would also explain what
+ prevents initialisation code from running while the TOE is
+ in the evaluated configuration.
+
+ There must also be an explanation of how the trusted
+ initialisation code will maintain the integrity of the TSF
+ (and of its initialisation process) such that the
+ initialisation process is able to detect any modification
+ that would result in the TSF being spoofed into believe it
+ was in an initial secure state.
+
+ The vulnerability analysis and testing (see ) activities will likely include
+ attempts to defeat the described TSF self protection
+ through the use of tampering, direct attack, or monitoring
+ of the TSF.
+
+
+ The property of non-bypassability is concerned with
+ interfaces that permit the bypass of the enforcement
+ mechanisms. In most cases this is a consequence of the
+ implementation, where if a programmer is writing an
+ interface that accesses or manipulates an object, it is
+ that programmer's responsibility to use interfaces that
+ are part of the SFR enforcement mechanism for the object
+ and not to try to circumvent those interfaces. For the
+ description pertaining to non-bypassability, then, there
+ are two broad areas that have to be covered.
+
+ The first consists of those interfaces to the SFR-enforcement.
+ The property for these interfaces is that they contain no
+ operations or modes that allow them to be used to bypass the
+ TSF. It is likely that the evidence for and can be used in
+ large part to make this determination. Because non-bypassability
+ is the concern, if only certain operations available through
+ these TSFIs are documented (because they are SFR-enforcing) and
+ others are not, the developer should consider whether additional
+ information (to that presented in
+ and ) is necessary to make a
+ determination that the
+ SFR-supporting and SFR-non-interfering
+ operations of the TSFI do not afford an
+ untrusted entity the ability to bypass the policy being
+ enforced. If such information is necessary, it is included
+ in the security architecture description.
+
+ The second area of non-bypassability is concerned with
+ those interfaces whose interactions are not associated
+ with SFR-enforcement. Depending on the and components
+ claimed, some information about these interfaces may or
+ may not exist in the functional specification and TOE
+ design documentation. The information presented for such
+ interfaces (or groups of interfaces) should be sufficient
+ so that a reader can make a determination (at the level of
+ detail commensurate with the rest of the evidence supplied
+ in the class) that the
+ enforcement mechanisms cannot be bypassed.
+
+ The property that the security functionality cannot be
+ bypassed applies to all security functionality
+ equally. That is, the design description should cover
+ objects that are protected under the SFRs (e.g. _* components) and functionality
+ (e.g., audit) that is provided by the TSF. The description
+ should also identify the interfaces that are associated
+ with security functionality; this might make use of the
+ information in the functional specification. This
+ description should also describe any design constructs,
+ such as object managers, and their method of use. For
+ instance, if routines are to use a standard macro to
+ produce an audit record, this convention is a part of the
+ design that contributes to the non-bypassability of the
+ audit mechanism. It is important to note that
+ non-bypassability in this context is not an
+ attempt to answer the question ``could a part of the TSF
+ implementation, if malicious, bypass the security
+ functionality'', but rather to document how the
+ implementation does not bypass the security
+ functionality.
+
+ The vulnerability analysis and testing (see ) activities will likely include
+ attempts to defeat the described non-bypassability by
+ circumventing the TSF.
+
+
+
+
+ The purpose in specifying the TSFIs is to provide the
+ necessary information to conduct testing; without knowing the
+ possible means interact with the TSF, one cannot adequately
+ test the behaviour of the TSF.
+
+ There are two parts to specifying the TSFIs: identifying them
+ and describing them. Because of the diversity of possible
+ TOEs, and of different TSFs therein, there is no standard set
+ of interfaces that constitute ``TSFIs''. This annex provides
+ guidance on the factors that determine which interfaces are
+ TSFIs.
+
+
+ In order to identify the interfaces to the TSF, the parts of the
+ TOE that make up the TSF must first be identified. This
+ identification is actually a part of the analysis, but is also performed implicitly
+ (through identification and description of the TSFI) by the
+ developer in cases where is not
+ included in the assurance package. In this analysis, a portion
+ of the TOE must be considered to be in the TSF if it contributes
+ to the satisfaction of an SFR in the ST (in whole or in
+ part). This includes, for example, everything in the TOE that
+ contributes to TSF run-time initialisation, such as software
+ that runs prior to the TSF being able to protect itself because
+ enforcement of the SFRs has not yet begun (e.g., while booting
+ up). Also included in the TSF are all parts of the TOE that
+ contribute to the architectural principles of TSF
+ self-protection, domain separation, and non-bypassability (see
+ ).
+
+ Once the TSF has been defined, the TSFI are identified.
+ The TSFI consists of all means by which external entities (or
+ subjects in the TOE but outside of the TSF) supply data to the TSF,
+ receive data from the TSF and invoke services from the TSF.
+ These service invocations and responses are the means of crossing
+ the TSF boundary. While many of these are readily apparent, others
+ might not be as obvious. The question that should be asked when
+ determining the TSFIs is: ``How can a potential attacker interact
+ with the TSF in an attempt to subvert the SFRs?'' The following
+ discussions illustrate the application of the TSFI definition in
+ different contexts.
+
+
+ In TOEs such as smart cards, where the adversary has not
+ only logical access to the TOE, but also complete physical
+ access to the TOE, the TSF boundary is the physical
+ boundary. Therefore, the exposed electrical interfaces
+ are considered TSFI because their manipulation could
+ affect the behaviour of the TSF. As such, all these
+ interfaces (electrical contacts) need to be described:
+ various voltages that might be applied, etc.
+
+
+
+ The TSFIs of a TOE that performs protocol processing would
+ be those protocol layers to which a potential attacker has
+ direct access. This need not be the entire protocol stack,
+ but it might be.
+
+ For example, if the TOE were some sort of a network
+ appliance that allowed potential attackers to affect every
+ level of the protocol stack (i.e. to send arbitrary
+ signals, arbitrary voltages, arbitrary packets, arbitrary
+ datagrams, etc.), then the TSF boundary exists at each
+ layer of the stack. Therefore, the functional
+ specification would have to address every protocol at
+ every layer of the stack.
+
+ If, however, the TOE were a firewall that protects an
+ internal network from the Internet, a potential attacker
+ would have no means of directly manipulating the voltages
+ that enter the TOE; any extreme voltages would simply not
+ be passed though the Internet. That is, the attacker would
+ have access only to those protocols at the Internet layer
+ or above. The TSF boundary exists at each layer of the
+ stack. Therefore, the functional specification would have
+ to address only those protocols at or above the Internet
+ layer: it would describe each of the different
+ communication layers at which the firewall is exposed in
+ terms of what constitutes well-formed input for what might
+ appear on the line, and the result of both well-formed and
+ malformed inputs. For example, the description of the
+ Internet protocol layer would describe what constitutes a
+ well-formed IP packet and what happens when both
+ correctly-formed and malformed packets are
+ received. Likewise, the description of the TCP layer would
+ describe a successful TCP connection and what happens both
+ when successful connections are established and when
+ connections cannot be established or are inadvertently
+ dropped. Presuming the firewall's purpose is to filter
+ application-level commands (like FTP or telnet), the
+ description of the application layer would describe the
+ application-level commands that are recognised and
+ filtered by the firewall, as well as the results of
+ encountering unknown commands.
+
+ The descriptions of these layers would likely reference
+ published communication standards (telnet, FTP, TCP, etc.)
+ that are used, noting which user-defined options are
+ chosen.
+
+
+
+
+
+
+ ``Wrappers'' translate complex series of interactions into
+ simplified common services, such as when Operating Systems
+ create APIs for use by applications (as shown in Figure
+ ). Whether the TSFIs
+ would be the system calls or the APIs depends upon what is
+ available to the application: if the application can use
+ the system calls directly, then the system calls are the
+ TSFIs. If, however, there were something that prohibits
+ their direct use and requires all communication through
+ the APIs, then the APIs would be the TSFIs.
+
+ A Graphical User interface is similar: it translates
+ between machine-understandable commands and user-friendly
+ graphics. Similarly, the TSFIs would be the commands if
+ users have access to them, or the graphics (pull-down
+ menus, check-boxes, text fields) if the users are
+ constrained to using them.
+
+ It is worth noting that, in both of these examples, if the
+ user is prohibited from using the more primitive
+ interfaces (i.e. the system calls or the commands), the
+ description of this restriction and of its enforcement
+ would be included in the Security Architecture Description
+ (see ). Also, the wrapper would be
+ part of the TSF.
+
+
+
+ For a given TOE, not all of the interfaces may be
+ accessible. That is, the security
+ objectives for the operational environment (in the
+ Security Target) may prevent access to these interfaces or
+ limit access in such a way that they are practically
+ inaccessible. Such interfaces would not be considered
+ TSFIs. Some examples:
+
+ If the security objectives for the operational
+ environment for the stand-alone firewall state that
+ ``the firewall will be operational in a server room
+ environment to which only trusted and trained
+ personnel will have access, and which will be equipped
+ with an interruptible power supply (against power
+ failure)'', physical and power interfaces will not be
+ accessible, since trusted and trained personnel will
+ not attempt to dismantle the firewall and/or disable
+ its power supply. If the security
+ objectives for the operational environment for the
+ software firewall (application) state that ``the OS
+ and the hardware will provide a security domain for
+ the application free from tampering by other
+ programs'', the interfaces through which the firewall
+ can be accessed by other applications on the OS
+ (e.g. deleting or modifying the firewall executable,
+ direct reading or writing to the memory space of the
+ firewall) will not be accessible, since the
+ OS/hardware part of the operational environment makes
+ this interface inaccessible.If the
+ security objectives for the operational environment
+ for the software firewall additionally state that the
+ OS and hardware will faithfully execute the commands
+ of the TOE, and will not tamper with the TOE in any
+ manner, interfaces through which the firewall obtains
+ primitive functionality from the OS and hardware
+ (executing machine code instructions, OS APIs, such as
+ creating, reading, writing or deleting files,
+ graphical APIs etc.) will not be accessible, since the
+ OS/hardware are the only entities that can access that
+ interface, and they are completely
+ trusted. For all of these examples,
+ these inaccessible interfaces would not be
+ TSFIs.
+
+
+
+ Figure
+ illustrates a complex TOE: a database management system that
+ relies on hardware and software that is outside the TOE
+ boundary (referred to as the IT environment
+ in the rest of this discussion). To simplify this example,
+ the TOE is identical to the TSF. The
+ shaded boxes represent the TSF, while the unshaded boxes
+ represent IT entities in the environment. The TSF comprises
+ the database engine and management GUIs (represented by the
+ box labelled DB) and a kernel module that
+ runs as part of the OS that performs some security function
+ (represented by the box labelled PLG). The
+ TSF kernel module has entry points defined by the OS
+ specification that the OS will call to invoke some function
+ (this could be a device driver, or an authentication module,
+ etc.). The key is that this pluggable kernel module is
+ providing security services specified by functional
+ requirements in the ST.
+
+
+
+
+ The IT environment consists of the operating system itself
+ (represented by the box labelled OS), as
+ well as an external server (labelled SRV).
+ This external server, like the OS, provides a service that
+ the TSF depends on, and thus needs to be in the IT
+ environment. Interfaces in the figure are labelled
+ Ax for TSFI, and Bx for
+ other interfaces that would be documented in . Each of these groups of interfaces is now
+ discussed.
+
+ Interface group A1 represents the most obvious set of TSFI.
+ These are interfaces used by users to directly access the
+ database and its security functionality and
+ resources.
+
+ Interface group A2 represent the TSFI that the OS invokes to
+ obtain the functionality provided by the pluggable module.
+ These are contrasted with interface group B3, which
+ represent calls that the pluggable module makes to obtain
+ services from the IT environment.
+
+ Interface group A3 represent TSFI that pass through the IT
+ environment. In this case, the DBMS communicates over the
+ network using a proprietary application-level
+ protocol. While the IT environment is responsible for
+ providing various supporting protocols (e.g., Ethernet, IP,
+ TCP), the application layer protocol that is used to obtain
+ services from the DBMS is a TSFI and must be documented as
+ such. The dotted line indicates return values/services from
+ the TSF over the network connection.
+
+ The interfaces labelled Bx represent
+ interfaces to functionality in the IT Environment. These
+ interfaces are not TSFI and need only be discussed and
+ analysed when the TOE is being used in a composite
+ evaluation as part of the activities associated with the
+ class.
+
+
+
+ The Example firewall is used between an internal network and
+ an external network. It verifies the source address of data
+ received (to ensure that external data is not attempting to
+ masquerade as originating from the internal data); if it
+ detects any such attempts, it saves the offending attempt to
+ the audit log. The administrator connects to the firewall by
+ establishing a telnet connection to the firewall from the
+ internal network. Administrator actions consist of
+ authenticating, changing passwords, reviewing the audit log,
+ and setting or changing the addresses of the internal and
+ external networks.
+
+ The Example firewall presents the following interfaces to
+ the internal network:
+
+ IP datagrams
+ Administrator Commands and the
+ following interfaces to the external network:
+
+ IP datagrams
+ Interfaces Descriptions: IP
+ Datagrams
+ The datagrams are in the format specified by RFC 791.
+
+ Purpose - to transmit blocks of data (``datagrams'')
+ from source hosts to destination hosts identified by
+ fixed length addresses; also provides for fragmentation
+ and reassembly of long datagrams, if necessary, for
+ transmission through small-packet networks.
+ Method of Use - they arrive from the lower-level
+ (e.g. data link) protocol.
+ Parameters - the following fields of the IP datagram
+ header: source address, destination address,
+ don't-fragment flag.
+ Parameter description - [As defined by RFC 791,
+ subclause 3.1 (``Internet Header Format'')]
+ Actions - Transmits datagrams that are not
+ masquerading; fragments large datagrams if necessary;
+ reassembles fragments into datagrams.
+ Error messages - (none). No reliability guaranteed
+ (reliability to be provided by upper-level protocols)
+ Undeliverable datagrams (e.g. must be fragmented for
+ transmission, but don't-fragment flag is set)
+ dropped.
+ Interfaces Descriptions: Administrator
+ Commands
+ The administrator commands provide a means for the
+ administrator to interact with the firewall. These commands
+ and responses ride atop a telnet (RFC 854) connection
+ established from any host on the internal network. Available
+ commands are:
+
+ Passwd
+
+ Purpose - sets administrator password
+ Method of Use - Passwd
+ <password>
+ Parameters - password
+ Parameter description - value of new
+ password
+ Actions - changes password to new value
+ supplied. There are no restrictions.
+ Error messages - none.
+
+ Readaudit
+
+ Purpose - presents the audit log to the
+ administrator
+ Method of Use - Readaudit
+ Parameters - none
+ Parameter description - none
+ Actions - provides the text of the audit
+ log
+ Error messages - none.
+
+ Setintaddr
+
+ Purpose - sets the address of the internal
+ address.
+ Method of Use - Setintaddr
+ <address>
+ Parameters - address
+ Parameter description - first three fields of an
+ IP address (as defined in RFC 791). For example:
+ 123.123.123.
+ Actions - changes the internal value of the
+ variable defining the internal network, the value of
+ which is used to judge attempted masquerades.
+ Error messages - ``address in use'': indicates
+ the identified internal network is the same as the
+ external network.
+
+ Setextaddr
+
+ Purpose - sets the address of the external address
+ Method of Use - Setextaddr
+ <address>
+ Parameters - address
+ Parameter description - first three fields of an
+ IP address (as defined in RFC 791). For example:
+ 123.123.123.
+ Actions - changes the internal value of the
+ variable defining the external network.
+ Error messages - ``address in use'': indicates
+ the identified external network is the same as the
+ internal network.
+
+
+
+
+
+
+ The wide variety of TOEs makes it impossible to codify
+ anything more specific than ``well-structured'' or ``minimum
+ complexity''. Judgements on structure and complexity are
+ expected to be derived from the specific technologies used in
+ the TOE. For example, software is likely to be considered
+ well-structured if it exhibits the characteristics cited in
+ the software engineering disciplines.
+
+ This annex provides supplementary material on assessing the
+ structure and complexity of procedure-based software portions
+ of the TSF. This material is based on information readily
+ available in software engineering literature. For other kinds
+ of internals (e.g. hardware, non-procedural software such as
+ object-oriented code, etc.), corresponding literature on good
+ practises should be consulted.
+
+
+ The structure of procedural software is traditionally
+ assessed according to its
+ modularity. Software written with a modular
+ design aids in achieving understandability by clarifying
+ what dependencies a module has on other modules
+ (coupling) and by including in a module
+ only tasks that are strongly related to each other
+ (cohesion). The use of modular design
+ reduces the interdependence between elements of the TSF and
+ thus reduces the risk that a change or error in one module
+ will have effects throughout the TOE. Its use enhances
+ clarity of design and provides for increased assurance that
+ unexpected effects do not occur. Additional desirable
+ properties of modular decomposition are a reduction in the
+ amount of redundant or unneeded code.
+
+ Minimising the amount of functionality in the TSF allows the
+ evaluator as well as the developer to focus only on that
+ functionality which is necessary for SFR enforcement,
+ contributing further to understandability and further
+ lowering the likelihood of design or implementation
+ errors.
+
+ The incorporation of modular decomposition, layering and
+ minimisation into the design and implementation process must
+ be accompanied by sound software engineering
+ considerations. A practical, useful software system will
+ usually entail some undesirable coupling among modules, some
+ modules that include loosely-related functions, and some
+ subtlety or complexity in a module's design. These
+ deviations from the ideals of modular decomposition are
+ often deemed necessary to achieve some goal or constraint,
+ be it related to performance, compatibility, future planned
+ functionality, or some other factors, and may be acceptable,
+ based on the developer's justification for them. In applying
+ the requirements of this class, due consideration must be
+ given to sound software engineering principles; however, the
+ overall objective of achieving understandability must be
+ achieved.
+
+
+ Cohesion is the manner and degree to which the tasks
+ performed by a single software module are related to one
+ another; types of cohesion include coincidental,
+ communicational, functional, logical, sequential, and
+ temporal. These types of cohesion are characterised below,
+ listed in the order of decreasing desirability.
+
+ functional cohesion - a module
+ with functional cohesion performs activities related
+ to a single purpose. A functionally cohesive module
+ transforms a single type of input into a single type
+ of output, such as a stack manager or a queue
+ manager.
+ sequential cohesion - a module
+ with sequential cohesion contains functions each of
+ whose output is input for the following function in
+ the module. An example of a sequentially cohesive
+ module is one that contains the functions to write
+ audit records and to maintain a running count of the
+ accumulated number of audit violations of a specified
+ type.
+ communicational cohesion - a
+ module with communicational cohesion contains
+ functions that produce output for, or use output from,
+ other functions within the module. An example of a
+ communicationally cohesive module is an access check
+ module that includes mandatory, discretionary, and
+ capability checks.
+ temporal cohesion - a module
+ with temporal cohesion contains functions that need to
+ be executed at about the same time. Examples of
+ temporally cohesive modules include initialisation,
+ recovery, and shutdown modules.
+ logical (or
+ procedural) cohesion - a module with
+ logical cohesion performs similar activities on
+ different data structures. A module exhibits logical
+ cohesion if its functions perform related, but
+ different, operations on different inputs.
+ coincidental cohesion - a
+ module with coincidental cohesion performs unrelated,
+ or loosely related, activities.
+
+
+
+ Coupling is the manner and degree of interdependence
+ between software modules; types of coupling include call,
+ common and content coupling. These types of coupling are
+ characterised below, listed in the order of decreasing
+ desirability:
+
+ call: two modules are call coupled if they
+ communicate strictly through the use of their
+ documented function calls; examples of call coupling
+ are data, stamp, and control, which are defined below.
+
+ data: two modules are data
+ coupled if they communicate strictly through the
+ use of call parameters that represent single data
+ items.
+ stamp: two modules are stamp
+ coupled if they communicate through the use of
+ call parameters that comprise multiple fields or
+ that have meaningful internal structures.
+ control: two modules are
+ control coupled if one passes information that is
+ intended to influence the internal logic of the
+ other.
+
+ common: two modules are common
+ coupled if they share a common data area or a common
+ system resource. Global variables indicate that
+ modules using those global variables are common
+ coupled. Common coupling through global variables is
+ generally allowed, but only to a limited degree. For
+ example, variables that are placed into a global area,
+ but are used by only a single module, are
+ inappropriately placed, and should be removed. Other
+ factors that need to be considered in assessing the
+ suitability of global variables are:
+
+ The number of modules that modify a global
+ variable: In general, only a single module should
+ be allocated the responsibility for controlling
+ the contents of a global variable, but there may
+ be situations in which a second module may share
+ that responsibility; in such a case, sufficient
+ justification must be provided. It is unacceptable
+ for this responsibility to be shared by more than
+ two modules. (In making this assessment, care
+ should be given to determining the module actually
+ responsible for the contents of the variable; for
+ example, if a single routine is used to modify the
+ variable, but that routine simply performs the
+ modification requested by its caller, it is the
+ calling module that is responsible, and there may
+ be more than one such module). Further, as part
+ of the complexity determination, if two modules
+ are responsible for the contents of a global
+ variable, there should be clear indications of how
+ the modifications are coordinated between
+ them.
+ The number of modules that reference a global
+ variable: Although there is generally no limit on
+ the number of modules that reference a global
+ variable, cases in which many modules make such a
+ reference should be examined for validity and
+ necessity.
+
+ content: two modules are content
+ coupled if one can make direct reference to the
+ internals of the other (e.g. modifying code of, or
+ referencing labels internal to, the other module).
+ The result is that some or all of the content of one
+ module are effectively included in the other. Content
+ coupling can be thought of as using unadvertised
+ module interfaces; this is in contrast to call
+ coupling, which uses only advertised module
+ interfaces.
+
+
+
+
+ Complexity is the measure of the decision points and logical
+ paths of execution that code takes. Software engineering
+ literature cites complexity as a negative characteristic of
+ software because it impedes understanding of the logic and
+ flow of the code. Another impediment to the understanding of
+ code is the presence of code that is unnecessary, in that it
+ is unused or redundant.
+
+ The use of layering to separate levels of abstraction and
+ minimise circular dependencies further enables a better
+ understanding of the TSF, providing more assurance that the
+ TOE security functional requirements are accurately and
+ completely instantiated in the implementation.
+
+ Reducing complexity also includes reducing or eliminating
+ mutual dependencies, which pertains both to modules in a
+ single layer and to those in separate layers. Modules that
+ are mutually dependent may rely on one another to formulate
+ a single result, which could result in a deadlock condition,
+ or worse yet, a race condition (e.g., time of check vs. time
+ of use concern), where the ultimate conclusion could be
+ indeterminate and subject to the computing environment at
+ the given instant in time.
+
+ Design complexity minimisation is a key characteristic of a
+ reference validation mechanism, the purpose of which is to
+ arrive at a TSF that is easily understood so that it can be
+ completely analysed. (There are other important
+ characteristics of a reference validation mechanism, such as
+ TSF self-protection and non-bypassability; these other
+ characteristics are covered by requirements in the family.)
+
+
+
+
+ This Subclause provides additional guidance on the TDS family,
+ and its use of the terms ``subsystem'' and ``module''. This is
+ followed by a discussion of how, as more-detailed becomes
+ available, the requirement for the less-detailed is
+ reduced.
+
+ Figure
+ shows that, depending on the complexity of the TSF, the
+ design may be described in terms of subsystems
+ and modules (where subsystems are at a
+ higher level of abstraction than modules); or it may just be
+ described in terms of one level of abstraction (e.g.,
+ subsystems at lower assurance levels,
+ modules at higher levels). In cases where a
+ lower level of abstraction (modules) is presented,
+ requirements levied on higher-level abstractions
+ (subsystems) are essentially met by default. This concept is
+ further elaborated in the discussion on subsystems and
+ modules below.
+
+
+ The developer is expected to describe the design of the TOE
+ in terms of subsystems. The term
+ ``subsystem'' was chosen to be specifically vague so that it
+ could refer to units appropriate to the TOE (e.g.,
+ subsystems, modules). subsystems can even be uneven in
+ scope, as long as the requirements for description of
+ subsystems are met.
+
+ The first use of subsystems is to distinguish the TSF boundary;
+ that is, the portions of the TOE that comprise the TSF. In
+ general, a subsystem is part of the TSF if it has the capability
+ (whether by design or implementation) to affect the correct
+ operation of any of the SFRs. For example, for software that
+ depends on different hardware execution modes to provide domain
+ separation (see ) where
+ SFR-enforcing code is executed in one domain, then all
+ subsystems that execute in that domain would be considered part
+ of the TSF. Likewise, if a server outside that domain
+ implemented an SFR (e.g. enforced an access control policy over
+ objects it managed), then it too would be considered part of the
+ TSF.
+
+ The second use of subsystems is to provide a structure for
+ describing the TSF at a level of description that, while
+ describing how the TSF works, does not necessarily contain
+ low-level implementation detail found in module descriptions
+ (discussed later). subsystems are described at either a high
+ level (lacking an abundance of implementation detail) or a
+ detailed level (providing more insight into the
+ implementation). The level of description provided for a
+ subsystem is determined by the degree to which that
+ subsystem is responsible for implementing an SFR.
+
+ An SFR-enforcing subsystem is a subsystem
+ that provides mechanisms for enforcing an element of any SFR,
+ or directly supports a subsystem that is responsible
+ for enforcing an SFR. If a subsystem provides (implements)
+ an SFR-enforcing TSFI, then the subsystem is
+ SFR-enforcing.
+
+ Subsystems can also be identified as
+ SFR-supporting and
+ SFR-non-interfering. An SFR-supporting
+ subsystem is one that is depended on by an SFR-enforcing
+ subsystem in order to implement an SFR, but does not play as
+ direct a role as an SFR-enforcing subsystem. An
+ SFR-non-interfering subsystem is one that is not depended
+ upon, in either a supporting or enforcing role, to implement
+ an SFR.
+
+
+
+ A module is generally a relatively small architectural unit
+ that can be characterised in terms of the properties
+ discussed in . When both
+ (or above) requirements
+ and requirements are
+ present in a PP or ST, a ``module'' in terms of the requirements refers to the same
+ entity as a ``module'' for the requirements. Unlike subsystems, modules
+ describe the implementation in a level of detail that can
+ serve as a guide to reviewing the implementation
+ representation.
+
+ It is important to note that, depending on the TOE, modules
+ and subsystems may refer to the same abstraction. For and (which do not require description at the
+ module level) the subsystem description provides the lowest
+ level detail available about the TSF. For (which require module
+ descriptions) these descriptions provide the lowest level of
+ detail, while the subsystem descriptions (if they exist as
+ separate entities) merely serve to put to the module
+ descriptions in context. That is, it is not necessary to
+ provide detailed subsystem descriptions if module
+ descriptions exist. In TOEs that are sufficiently simple, a
+ separate ``subsystem description'' is not necessary; the
+ requirements can be met through documentation provided by
+ modules. For complex TOEs, the purpose of the subsystem
+ description (with respect to the TSF) is to provide the
+ reader context so they can focus their analysis
+ appropriately. This difference is illustrated in Figure
+ .
+
+ An SFR-enforcing module is a module that completely or partially implements
+ a security functional requirement (SFR) in the ST. Such modules may
+ implement an SFR-enforcing TSFI, but some functionality expressed in an SFR (for example,
+ audit and object re-use functionality) may not be directly tied to a single TSFI. As was
+ the case with subsystems, SFR-supporting modules are those modules that are depended upon by
+ an SFR-enforcing module, but are not responsible for directly implementing an SFR.
+ SFR-non-interfering modules are those modules that do not deal, directly or indirectly,
+ with the enforcement of SFRs.
+
+ It is important to note that the determination of what
+ ``directly implements'' means is somewhat subjective. In the
+ narrowest sense of the term, it could be interpreted to mean
+ the one or two lines of code that actually perform a
+ comparison, zeroing operation, etc. that implements a
+ requirement. A broader interpretation might be that it
+ includes the module that is invoked in response to a
+ SFR-enforcing TSFI, and all modules that may be invoked in
+ turn by that module (and so on until the completion of the
+ call). Neither of these interpretations is particularly
+ satisfying, since the narrowness of the first interpretation
+ may lead to important modules being incorrectly categorised
+ as SFR supporting, while the second leads to modules that
+ are actually not SFR-enforcing being classified as
+ such.
+
+ A description of a module should be such that one could create an implementation of the
+ module from the description, and the resulting implementation would be 1) identical to
+ the actual TSF implementation in terms of the interfaces presented, 2) identical in the
+ use of interfaces that are mentioned in the design, and 3) functionally equivalent to the
+ description of the purpose of the TSF module. For instance, RFC 793
+ provides a high-level description of the TCP protocol. It is necessarily implementation
+ independent. While it provides a wealth of detail, it is
+ not
+ a suitable design description because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC, and implementation choices
+ (for example, the use of global data vs. local data in various parts of the implementation)
+ may have an impact on the analysis that is performed. The design description of the TCP
+ module would list the interfaces presented by the implementation (rather than just those
+ defined in RFC 793), as well as an algorithm description of the processing associated with
+ the modules implementing TCP (assuming they were part of the TSF).
+
+ In the design, modules are described in detail in terms
+ of the function they provide (the purpose); the interfaces
+ they present (when required by the criteria); the return
+ values from such interfaces; the interfaces (presented by other modules)
+ they use (provided those interfaces are required to be also described);
+ and a description of how they provide their functionality using a
+ technique appropriate to the method used to implement the module.
+
+ The purpose of a module should be described indicating what
+ function the module is providing. It should be sufficient so
+ that the reader could get a general idea of what the
+ module's function is in the architecture.
+
+ The interfaces presented by a module are those interfaces used by
+ other modules to invoke the functionality provided. Interfaces include both
+ explicit interfaces (e.g., a calling sequence invoked by
+ other modules) as well as implicit interfaces (e.g., global
+ data manipulated by the module). Interfaces are described in terms of how
+ they are invoked, and any values that are returned. This description would
+ include a list of parameters, and descriptions of these parameters. If a parameter
+ were expected to take on a set of values (e.g., a ``flag'' parameter), the complete set
+ of values the parameter could take on that would have an effect on module processing
+ would be specified. Likewise, parameters representing data structures are described
+ such that each field of the data structure is identified and described.
+ Global data should be described to the extent required to understand their purpose.
+ The level of description required for a global data structure needs to be identical
+ to the one for module interfaces, where the input parameter and return values correspond
+ to the individual fields and their possible values in the data structure. Global data
+ structures may be described separate from the modules that manipulate or read them as
+ long as the design of the modules contain sufficient information about the global data
+ structures updated or the information extracted from global data structures.
+
+ Note that different programming languages may have
+ additional ``interfaces'' that would be non-obvious; an
+ example would be operator/function overloading in C++. This
+ ``implicit interface'' in the class description would also
+ be described as part of the module design. Note that
+ although a module could present only one interface, it is
+ more common that a module presents a small set of related
+ interfaces.
+
+ When it is required to describe the interfaces used by a module, it must be
+ clear from either the design description of the module or the purpose of the
+ module called, what service is expected from the module called. For example if
+ Module A is being described, and it uses Module B's bubble sort routine, the
+ description of the interaction between modules must allow to identify why
+ Module B's bubble sort routine is called and what this call contributes to the
+ implementation of the SFRs. The interface and purpose of Module B's bubble sort
+ routine must be described as part of the interfaces of Module B (provided the
+ level of ADV_TDS and the classification of Module B require a description its
+ interfaces) and so Module A just needs to identify what data it needs to have
+ sorted using this routine. An adequate description would be: "Module A invokes
+ Module B's interface double_bubble() to sort the usernames in
+ alphabetical order".
+ Note that if this sorting of the user names is not important for the enforcement of
+ any SFR (e. g. it is just done to speed up things and an algorithmically identical
+ implementation of Module A could also avoid to have the usernames sorted), the use of
+ Module B's bubble sort routine is not SFR-enforcing and it is suffcient to explain in
+ the description of Module A that the usernames are sorted in alphabetical order to
+ enhance performance. Module B may be classified as "SFR-supporting" only and the level
+ of ADV_TDS chosen indicates if the interfaces of SFR-supporting modules need to be
+ described or if its is sufficient to just describe the purpose of Module B.
+
+ As discussed previously, the algorithmic description of the
+ module should describe in an algorithmic fashion the
+ implementation of the module. This can be done in
+ pseudo-code, through flow charts, or (at ) informal text. It discusses
+ how the module inputs and called functions are used to
+ accomplish the module's function. It notes changes to global
+ data, system state, and return values produced by the
+ module. It is at the level of detail that an implementation
+ could be derived that would be very similar to the actual
+ implementation of the TOE.
+
+ It should be noted that source code does not meet the module
+ documentation requirements. Although the module design
+ describes the implementation, it is not the
+ implementation. The comments surrounding the source code
+ might be sufficient documentation if they provide an
+ explanation of the intent of the source code. In-line
+ comments that merely state what each line of code is doing
+ are useless because they provide no explanation of what the
+ module is meant to accomplish.
+
+ In the elements below, the labels (SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering) discussed for
+ subsystems and modules are used to describe the amount and
+ type of information that needs to be made available by the
+ developer. The elements have been structured so that there
+ is no expectation that the developer provide
+ only the information specified. That is, if
+ the developer's documentation of the TSF provides the
+ information in the requirements below, there is no
+ expectation that the developer update their documentation
+ and label subsystems and modules as SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering. The primary purpose
+ of this labelling is to allow developers with less mature
+ development methodologies (and associated artifacts, such as
+ detailed interface and design documentation) to provide the
+ necessary evidence without undue cost.
+
+
+
+ Because there is subjectivity in determining what is
+ SFR-enforcing vs. SFR-supporting (and in some cases, even
+ determining what is SFR-non-interfering) the following
+ paradigm has been adopted in this family. In early
+ components of the family, the developer makes a
+ determination about the classification of the subsystems
+ into SFR-enforcing, etc., supplying the appropriate
+ information, and there is little additional evidence for the
+ evaluator to examine to support this claim. As the level of
+ desired assurance increases, while the developer still makes
+ a classification determination, the evaluator obtains more
+ and more evidence that is used to confirm the developer's
+ classification.
+
+ In order to focus the evaluator's analysis on the SFR-related
+ portions of the TOE, especially at lower levels of assurance,
+ the components of the family are levelled such that initially
+ detailed information is required only for SFR-enforcing
+ architectural entities. As the level of assurance increases,
+ more information is required for SFR-supporting and (eventually)
+ SFR-non-interfering entities. It should be noted that even when
+ complete information is required, it is not required that all of
+ this information be analysed in the same level of detail. The
+ focus should be in all cases on whether the
+ necessary information has been provided and
+ analysed.
+
+ Table summarises the
+ information required at each of the family components for the
+ architectural entities to be described.
+
+
+
+
+
+ TSF subsystem
+ TSF Module
+
+
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+
+
+
+
+
+ (informal
+ presentation)
+
+ structure, summary of SFR-Enf. behaviour, interactions
+
+ designation support
+ designation support means that
+ only documentation sufficient to support the
+ classification of the subsystem / module is
+ needed.
+
+ designation support
+
+
+
+
+
+
+ (informal
+ presentation)
+
+ structure, detailed description of SFR-Enf. behaviour,
+ summary of other behaviour, interactions
+
+
+ structure, summary of other behaviour, interactions
+
+ designation support, interactions
+
+
+
+
+
+
+
+ (informal
+ presentation)description,
+ interactionsdescription, interactions
+ description, interactions
+
+ purpose, SFR interfacesSFR interfaces means that the module description contains,
+ for each SFR-related interface, the returned values and the called interfaces
+ to other modules.
+ interaction, purpose
+ interaction, purpose
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, SFR interfaces
+
+
+ purpose, SFR interfaces
+
+ interaction, purpose
+
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, all interfacesAll interfaces means that the module description contains,
+ for each interface, the returned values and the called interfaces to other
+ modules.
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+
+
+ (semiformal
+ presentation; additional formal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+
+
+ Description Detail Levelling
+
+
+
+
+
+ Formal methods provide a mathematical representation of the
+ TSF and its behaviour and are required by the , , and
+ components. There are two aspects of formal methods: the
+ specification language that is used for
+ formal expression, and the theorem prover
+ that mathematically proves the completeness and correctness of
+ the formal specification.
+
+ A formal specification is expressed within a formal system
+ based upon well-established mathematical concepts. These
+ mathematical concepts are used to define well-defined
+ semantics, syntax and rules of inference. A formal system is
+ an abstract system of identities and relations that can be
+ described by specifying a formal alphabet, a formal language
+ over that alphabet which is based on a formal syntax, and a
+ set of formal rules of inference for constructing derivations
+ of sentences in the formal language.
+
+ The evaluator should examine the identified formal systems to
+ make sure that:
+
+ The semantics, syntax and inference rules of the
+ formal system are defined or a definition is
+ referenced.
+ Each formal system is accompanied by explanatory text
+ that provides defined semantics so that:
+
+ the explanatory text provides defined meanings of
+ terms, abbreviations and acronyms that are used in a
+ context other than that accepted by normal
+ usage,
+ the use of a formal system and semiformal notation
+ use is accompanied by supporting explanatory text in
+ informal style appropriate for unambiguous
+ meaning,
+ the formal system is able to express rules and
+ characteristics of applicable SFPs,
+ security functionality and interfaces (providing
+ details of effects, exceptions and error messages) of
+ TSF, their subsystems or modules to be specified for
+ the assurance family for which the notations are
+ used.
+ the notation provides rules to determine the
+ meaning of syntactical valid constructs.
+
+ Each formal system uses a formal syntax that provides
+ rules to unambiguously recognise constructs.
+ Each formal system provides proof rules which
+
+ support logical reasoning of well-established
+ mathematical concepts,
+ help to prevent derivation of
+ contradictions
+
+ If the developer uses a formal system which is already accepted
+ by the evaluation authority the evaluator can rely on the level
+ of formality and strength of the system and focus on the
+ instantiation of the formal system to the TOE specifications and
+ correspondence proofs.
+
+ The formal style supports mathematical proofs of the security
+ properties based on the security features, the consistency of
+ refinements and the correspondence of the representations.
+ Formal tool support seems adequate whenever manual derivations
+ would otherwise become long winded and
+ incomprehensible. Formal tools are also apt to reduce the
+ error probability inherent in manual derivations.
+
+ Examples of formal systems:
+
+ The Z specification language is highly
+ expressive, and supports many different methods or styles
+ of formal specification. The use of Z has been
+ predominantly for model-oriented specification, using
+ schemas to formally specify
+ operations. See for more
+ information.
+ ACL2 is an open-source formal system
+ comprising a LISP-based specification language and a
+ theorem prover. See for
+ further information.
+ Isabelle is a popular generic theorem
+ proving environment that allows mathematical formulae to
+ be expressed in a formal language and provides tools for
+ proving those formulae within a logical calculus (see
+ e.g. for
+ additional information)
+ The B method is a formal system based
+ on the propositional calculus, the first order predicate
+ calculus with inference rules and set theory (see
+ e.g. for further
+ information).
+
+
+
+
+ The dependencies documented in the components of Clauses and - are the direct dependencies between the
+ assurance components.
+
+ The following dependency tables for assurance components show
+ their direct, indirect and optional dependencies. Each of the
+ components that is a dependency of some assurance component is
+ allocated a column. Each assurance component is allocated a
+ row. The value in the table cell indicate whether the column
+ label component is directly required (indicated by a cross
+ ``X'') or indirectly required (indicated by a dash ``-''), by
+ the row label component. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+ The purpose of this Clause is to document the philosophy that
+ underpins the CC approach to assurance. An understanding of this
+ Clause will permit the reader to understand the rationale behind
+ the CC Part 3 assurance requirements.
+
+
+ The CC philosophy is that the threats to security and
+ organisational security policy commitments should be clearly
+ articulated and the proposed security measures be demonstrably
+ sufficient for their intended purpose.
+
+ Furthermore, measures should be adopted that reduce the
+ likelihood of vulnerabilities, the ability to exercise
+ (i.e. intentionally exploit or unintentionally trigger) a
+ vulnerability, and the extent of the damage that could occur
+ from a vulnerability being exercised. Additionally, measures
+ should be adopted that facilitate the subsequent
+ identification of vulnerabilities and the elimination,
+ mitigation, and/or notification that a vulnerability has been
+ exploited or triggered.
+
+
+
+ The CC philosophy is to provide assurance based upon an
+ evaluation (active investigation) of the IT product that is to
+ be trusted. Evaluation has been the traditional means of
+ providing assurance and is the basis for prior evaluation
+ criteria documents. In aligning the existing approaches, the
+ CC adopts the same philosophy. The CC proposes measuring the
+ validity of the documentation and of the resulting IT product
+ by expert evaluators with increasing emphasis on scope, depth,
+ and rigour.
+
+ The CC does not exclude, nor does it comment upon, the
+ relative merits of other means of gaining assurance. Research
+ continues with respect to alternative ways of gaining
+ assurance. As mature alternative approaches emerge from these
+ research activities, they will be considered for inclusion in
+ the CC, which is so structured as to allow their future
+ introduction.
+
+
+ It is assumed that there are threat agents that will
+ actively seek to exploit opportunities to violate security
+ policies both for illicit gains and for well-intentioned,
+ but nonetheless insecure actions. Threat agents may also
+ accidentally trigger security vulnerabilities, causing harm
+ to the organisation. Due to the need to process sensitive
+ information and the lack of availability of sufficiently
+ trusted products, there is significant risk due to failures
+ of IT. It is, therefore, likely that IT security breaches
+ could lead to significant loss.
+
+ IT security breaches arise through the intentional
+ exploitation or the unintentional triggering of
+ vulnerabilities in the application of IT within business
+ concerns.
+
+ Steps should be taken to prevent vulnerabilities arising in
+ IT products. To the extent feasible, vulnerabilities should
+ be:
+
+
+ eliminated -- that is, active steps should be taken to
+ expose, and remove or neutralise, all exercisable
+ vulnerabilities;
+
+
+ minimised -- that is, active steps should be taken to
+ reduce, to an acceptable residual level, the potential
+ impact of any exercise of a vulnerability;
+
+
+ monitored -- that is, active steps should be taken to
+ ensure that any attempt to exercise a residual
+ vulnerability will be detected so that steps can be
+ taken to limit the damage.
+
+
+
+
+
+ Vulnerabilities can arise through failures in:
+
+
+ requirements -- that is, an IT product may possess all
+ the functions and features required of it and still
+ contain vulnerabilities that render it unsuitable or
+ ineffective with respect to security;
+
+
+ development -- that is, an IT product does not meet its
+ specifications and/or vulnerabilities have been
+ introduced as a result of poor development standards or
+ incorrect design choices;
+
+
+ operation -- that is, an IT product has been constructed
+ correctly to a correct specification but vulnerabilities
+ have been introduced as a result of inadequate controls
+ upon the operation.
+
+
+
+
+
+ Assurance is grounds for confidence that an IT product meets
+ its security objectives. Assurance can be derived from
+ reference to sources such as unsubstantiated assertions,
+ prior relevant experience, or specific experience. However,
+ the CC provides assurance through active
+ investigation. Active investigation is an evaluation of the
+ IT product in order to determine its security
+ properties.
+
+
+
+ Evaluation has been the traditional means of gaining
+ assurance, and is the basis of the CC approach. Evaluation
+ techniques can include, but are not limited to:
+
+
+ analysis and checking of process(es) and procedure(s);
+
+
+ checking that process(es) and procedure(s) are being
+ applied;
+
+
+ analysis of the correspondence between TOE design
+ representations;
+
+
+ analysis of the TOE design representation against the
+ requirements;
+
+
+ verification of proofs;
+
+
+ analysis of guidance documents;
+
+
+ analysis of functional tests developed and the results
+ provided;
+
+
+ independent functional testing;
+
+
+ analysis for vulnerabilities (including flaw
+ hypothesis);
+
+
+ penetration testing.
+
+
+
+
+
+
+ The CC philosophy asserts that greater assurance results from
+ the application of greater evaluation effort, and that the
+ goal is to apply the minimum effort required to provide the
+ necessary level of assurance. The increasing level of effort
+ is based upon:
+
+
+ scope -- that is, the effort is greater because a larger
+ portion of the IT product is included;
+
+
+ depth -- that is, the effort is greater because it is
+ deployed to a finer level of design and implementation
+ detail;
+
+
+ rigour -- that is, the effort is greater because it is
+ applied in a more structured, formal manner.
+
+
+
+
+
+
+ This annex provides an explanation of the criteria and examples of their application. This
+ annex does not define the criteria;
+ this definition can be found in CC Part 3 Section .
+
+ This annex consists of 2 major parts:
+
+
+ Guidance for completing an independent vulnerability
+ analysis. This is summarised in section , and described in more
+ detail in section
+ . These sections describe how an evaluator should approach
+ the construction of an independent Vulnerability Analysis.
+
+
+ How to characterise and use assumed Attack Potential of an
+ attacker. This is described in sections to . These sections provide an example of describe
+ how an attack potential can be characterised and should be
+ used, and provide examples.
+
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the existence and exploitability of flaws or
+ weaknesses in the TOE in the operational environment. This
+ determination is based upon analysis performed by the
+ evaluator, and is supported by evaluator testing.
+
+ At the lowest levels of the
+ evaluator simply performs a search of publicly available
+ information to identify any known weaknesses in the TOE, while
+ at the higher levels the evaluator performs a structured
+ analysis of the TOE evaluation evidence.
+
+ There are three main factors in performing a vulnerability
+ analysis, namely:
+
+ the identification of potential vulnerabilities;
+
+ assessment to determine whether the identified potential
+ vulnerabilities could allow an attacker with the relevant
+ attack potential to violate the SFRs.
+
+ penetration testing to determine whether the identified
+ potential vulnerabilities are exploitable in the operational
+ environment of the TOE.
+
+
+ The identification of vulnerabilities can be further
+ decomposed into the evidence to be searched and how hard to
+ search that evidence to identify potential vulnerabilities. In
+ a similar manner, the penetration testing can be further
+ decomposed into analysis of the potential vulnerability to
+ identify attack methods and the demonstration of the attack
+ methods.
+
+ These main factors are iterative in nature, i.e. penetration
+ testing of potential vulnerabilities may lead to the
+ identification of further potential vulnerabilities. Hence,
+ these are performed as a single vulnerability analysis
+ activity.
+
+
+
+ The evaluator vulnerability analysis is to determine that the
+ TOE is resistant to penetration attacks performed by an
+ attacker possessing a Basic (for and ),
+ Enhanced-Basic (for ),
+ Moderate (for ) or High (for
+ ) attack potential. The
+ evaluator first assesses the exploitability of all identified
+ potential vulnerabilities. This is accomplished by conducting
+ penetration testing. The evaluator should assume the role of
+ an attacker with a Basic (for
+ and ), Enhanced-Basic (for
+ ), Moderate (for ) or High (for ) attack potential when attempting to penetrate the
+ TOE.
+
+ The evaluator considers potential vulnerabilities encountered
+ by the evaluator during the conduct of other evaluation
+ activities. The evaluator penetration testing determining TOE
+ resistance to these potential vulnerabilities should be
+ performed assuming the role of an attacker with a Basic (for
+ and ), Enhanced-Basic (for ), Moderate (for )
+ or High (for ) attack
+ potential.
+
+ However, vulnerability analysis should not be performed as an
+ isolated activity. It is closely linked with and . The evaluator
+ performs these other evaluation activities with a focus on
+ identifying potential vulnerabilities or ``areas of
+ concern''. Therefore, evaluator familiarity with the generic
+ vulnerability guidance (provided in Section ) is required.
+
+
+ The following five categories provide discussion of generic
+ vulnerabilities.
+
+
+ Bypassing includes any means by which an attacker could
+ avoid security enforcement, by:
+
+
+ exploiting the capabilities of interfaces to the TOE,
+ or of utilities which can interact with the TOE;
+
+
+ inheriting privileges or other capabilities that
+ should otherwise be denied;
+
+
+ (where confidentiality is a concern) reading sensitive
+ data stored or copied to inadequately protected areas.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on exploiting the capabilities of
+ interfaces or utilities generally take advantage of
+ the absence of the required security enforcement on
+ those interfaces. For example, gaining access to
+ functionality that is implemented at a lower level
+ than that at which access control is
+ enforced. Relevant items include:
+
+
+ changing the predefined sequence of invocation of
+ TSFI;
+
+
+ invoking an additional TSFI;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using implementation detail introduced in less
+ abstract representations;
+
+
+ using the delay between time of access check and
+ time of use.
+
+
+
+
+ Changing the predefined sequence of invocation of
+ components should be considered where there is an
+ expected order in which interfaces to the TOE
+ (e.g. user commands) are called to invoke a TSFI
+ (e.g. opening a file for access and then reading data
+ from it). If a TSFI is invoked through one of the TOE
+ interfaces (e.g. an access control check), the
+ evaluator should consider whether it is possible to
+ bypass the control by performing the call at a later
+ point in the sequence or by missing it out altogether.
+
+
+ Executing an additional component (in the predefined
+ sequence) is a similar form of attack to the one
+ described above, but involves the calling of some
+ other TOE interface at some point in the sequence. It
+ can also involve attacks based on interception of
+ sensitive data passed over a network by use of network
+ traffic analysers (the additional component here being
+ the network traffic analyser).
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes using an unrelated TOE
+ interface to bypass the TSF by using it to achieve a
+ purpose that it was not designed or intended to
+ achieve. Covert channels are an example of this type
+ of attack (see for further discussion of covert
+ channels). The use of undocumented interfaces, which
+ may be insecure, also falls into this category. Such
+ interfaces may include undocumented support and help
+ facilities.
+
+
+ Using implementation detail introduced in lower
+ representations may allow an attacker to take
+ advantage of additional functions, resources or
+ attributes that are introduced to the TOE as a
+ consequence of the refinement process. Additional
+ functionality may include test harness code contained
+ in software modules and back-doors introduced during
+ the implementation process.
+
+
+ Using the delay between time of check and time of use
+ includes scenarios where an access control check is
+ made and access granted, and an attacker is
+ subsequently able to create conditions in which, had
+ they applied at the time the access check was made,
+ would have caused the check to fail. An example would
+ be a user creating a background process to read and
+ send highly sensitive data to the user's terminal, and
+ then logging out and logging back in again at a lower
+ sensitivity level. If the background process is not
+ terminated when the user logs off, the MAC checks
+ would have been effectively bypassed.
+
+
+ Attacks based on inheriting privileges are generally
+ based on illicitly acquiring the privileges or
+ capabilities of some privileged component, usually by
+ exiting from it in an uncontrolled or unexpected
+ manner. Relevant items include:
+
+
+ executing data not intended to be executable, or
+ making it executable;
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Executing data not intended to be executable, or
+ making it executable includes attacks involving
+ viruses (e.g. putting executable code or commands in a
+ file which are automatically executed when the file is
+ edited or accessed, thus inheriting any privileges the
+ owner of the file has).
+
+
+ Generating unexpected input for a component can have
+ unexpected effects which an attacker could take
+ advantage of. For example, if the TSF could be
+ bypassed if a user gains access to the underlying
+ operating system, it may be possible to gain such
+ access following the login sequence by exploring the
+ effect of hitting various control or escape sequences
+ whilst a password is being authenticated.
+
+
+ Invalidating assumptions and properties on which lower
+ level components rely includes attacks based on
+ breaking out of the constraints of an application to
+ gain access to an underlying operating system in order
+ to bypass the TSF of an application. In this case the
+ assumption being invalidated is that it is not
+ possible for a user of the application to gain such
+ access. A similar attack can be envisaged against an
+ application on an underlying database management
+ system: again the TSF could be bypassed if an attacker
+ can break out of the constraints of the application.
+
+
+ Attacks based on reading sensitive data stored in
+ inadequately protected areas (applicable where
+ confidentiality is a concern) include the following
+ issues which should be considered as possible means of
+ gaining access to sensitive data:
+
+
+ disk scavenging;
+
+
+ access to unprotected memory;
+
+
+ exploiting access to shared writable files or
+ other shared resources (e.g. swap files);
+
+
+ Activating error recovery to determine what access
+ users can obtain. For example, after a crash an
+ automatic file recovery system may employ a lost
+ and found directory for headerless files, which
+ are on disk without labels. If the TOE implements
+ mandatory access controls, it is important to
+ investigate at what security level this directory
+ is kept (e.g. at system high), and who has access
+ to this directory.
+
+
+
+
+
+ There are a number of different methods through which an
+ evaluator may identify a back-door, including two main
+ techniques. Firstly, by the evaluator inadvertently
+ identifying during testing an interface that can be
+ misused. Secondly, through testing each external
+ interface of the TSF in a debugging mode to identify any
+ modules that are not called as a part of testing the
+ documented interfaces and then inspecting the code that is
+ not called to consider whether it is a back-door.
+
+ For a software TOE where and or
+ higher components are included in the assurance package,
+ the evaluator may consider during their analysis of the
+ tools the libraries and packages that are linked by the
+ compiler at compilation stage to determine that back-doors
+ are not introduced at this stage.
+
+
+
+ Tampering includes any attack based on an attacker
+ attempting to influence the behaviour of the TSF
+ (i.e. corruption or de-activation), for example by:
+
+
+ accessing data on whose confidentiality or integrity
+ the TSF relies;
+
+
+ forcing the TOE to cope with unusual or unexpected
+ circumstances;
+
+
+ disabling or delaying security enforcement;
+
+
+ physical modification the TOE.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on accessing data, whose confidentiality
+ or integrity are protected, include:
+
+
+ reading, writing or modifying internal data
+ directly or indirectly;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using interfaces between components that are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Reading, writing or modifying internal data directly
+ or indirectly includes the following types of attack
+ which should be considered:
+
+
+ reading ``secrets'' stored internally, such as
+ user passwords;
+
+
+ spoofing internal data that security enforcing
+ mechanisms rely upon;
+
+
+ modifying environment variables (e.g. logical
+ names), or data in configuration files or
+ temporary files.
+
+
+
+ It may be possible to deceive a trusted process into
+ modifying a protected file that it wouldn't normally
+ access.
+
+
+ The evaluator should also consider the following
+ ``dangerous features'':
+
+
+ source code resident on the TOE along with a
+ compiler (for instance, it may be possible to
+ modify the login source code);
+
+
+ an interactive debugger and patch facility (for
+ instance, it may be possible to modify the
+ executable image);
+
+
+ the possibility of making changes at device
+ controller level, where file protection does not
+ exist;
+
+
+ diagnostic code which exists in the source code
+ and that may be optionally included;
+
+
+ developer's tools left in the TOE.
+
+
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes (for example), where the
+ TOE is an application built upon an operating system,
+ users exploiting knowledge of a word processor package
+ or other editor to modify their own command file
+ (e.g. to acquire greater privileges).
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction includes
+ attacks exploiting shared access to resources, where
+ modification of a resource by one component can
+ influence the behaviour of another (trusted)
+ component, e.g. at source code level, through the use
+ of global data or indirect mechanisms such as shared
+ memory or semaphores.
+
+
+ Attacks based on forcing the TOE to cope with unusual
+ or unexpected circumstances should always be
+ considered. Relevant items include:
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Generating unexpected input for a component includes
+ investigating the behaviour of the TOE when:
+
+
+ command input buffers overflow (possibly
+ ``crashing the stack'' or overwriting other
+ storage, which an attacker may be able to take
+ advantage of, or forcing a crash dump that may
+ contain sensitive information such as clear-text
+ passwords);
+
+
+ invalid commands or parameters are entered
+ (including supplying a read-only parameter to an
+ interface which expects to return data via that
+ parameter and supplying improperly formatted input
+ that should fail parsing such as SQL-injection,
+ format strings);
+
+
+ an end-of-file marker (e.g. CTRL-Z or CTRL-D) or
+ null character is inserted in an audit trail.
+
+
+
+
+ Invalidating assumptions and properties on which
+ lower-level components rely includes attacks taking
+ advantage of errors in the source code where the code
+ assumes (explicitly or implicitly) that security
+ relevant data is in a particular format or has a
+ particular range of values. In these cases the
+ evaluator should determine whether they can invalidate
+ such assumptions by causing the data to be in a
+ different format or to have different values, and if
+ so whether this could confer advantage to an attacker.
+
+
+ The correct behaviour of the TSF may be dependent on
+ assumptions that are invalidated under extreme
+ circumstances where resource limits are reached or
+ parameters reach their maximum value. The evaluator
+ should consider (where practical) the behaviour of the
+ TOE when these limits are reached, for example:
+
+
+ changing dates (e.g. examining how the TOE behaves
+ when a critical date threshold is passed);
+
+
+ filling disks;
+
+
+ exceeding the maximum number of users;
+
+
+ filling the audit log;
+
+
+ saturating security alarm queues at a console;
+
+
+ overloading various parts of a multi-user TOE
+ which relies heavily upon communications
+ components;
+
+
+ swamping a network, or individual hosts, with
+ traffic;
+
+
+ filling buffers or fields.
+
+
+
+
+ Attacks based on disabling or delaying security
+ enforcement include the following items:
+
+
+ using interrupts or scheduling functions to
+ disrupt sequencing;
+
+
+ disrupting concurrence;
+
+
+ using interfaces between components which are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Using interrupts or scheduling functions to disrupt
+ sequencing includes investigating the behaviour of the
+ TOE when:
+
+
+ a command is interrupted (with CTRL-C, CTRL-Y,
+ etc.);
+
+
+ a second interrupt is issued before the first is
+ acknowledged.
+
+
+
+
+ The effects of terminating security critical processes
+ (e.g. an audit daemon) should be explored. Similarly,
+ it may be possible to delay the logging of audit
+ records or the issuing or receipt of alarms such that
+ it is of no use to an administrator (since the attack
+ may already have succeeded).
+
+
+ Disrupting concurrence includes investigating the
+ behaviour of the TOE when two or more subjects attempt
+ simultaneous access. It may be that the TOE can cope
+ with the interlocking required when two subjects
+ attempt simultaneous access, but that the behaviour
+ becomes less well defined in the presence of further
+ subjects. For example, a critical security process
+ could be put into a resource-wait state if two other
+ processes are accessing a resource which it requires.
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction may provide a
+ means of delaying a time-critical trusted process.
+
+
+ Physical attacks can be categorised into physical
+ probing, physical manipulation, physical modification,
+ and substitution.
+
+
+ Physical probing by penetrating the TOE targeting
+ internals of the TOE, e.g. reading at internal
+ communication interfaces, lines or memories.
+
+
+ Physical manipulation can be with the TOE
+ internals aiming at internal modifications of the
+ TOE (e.g. by using optical fault induction as an
+ interaction process), at the external interfaces
+ of the TOE (e.g. by power or clock glitches) and
+ at the TOE environment (e.g. by modifying
+ temperature).
+
+
+ Physical modification of TOE internal security
+ enforcing attributes to inherit privileges or
+ other capabilities that should be denied in
+ regular operation. Such modifications can be
+ caused, e.g., by optical fault induction. Attacks
+ based on physical modification may also yield a
+ modification of the TSF itself, e.g. by causing
+ faults at TOE internal program data transfers
+ before execution. Note, that such kind of
+ bypassing by modifying the TSF itself can
+ jeopardise every TSF unless there are other
+ measures (possibly environmental measures) that
+ prevent an attacker from gaining physical access
+ to the TOE.
+
+
+ Physical substitution to replace the TOE with
+ another IT entity, during delivery or operation of
+ the TOE. Substitution during delivery of the TOE
+ from the development environment to the user
+ should be prevented through application of secure
+ delivery procedures (such as those considered
+ under ). Substitution of the TOE during
+ operation may be considered through a combination
+ of user guidance and the operational environment,
+ such that the user is able to be confident that
+ they are interacting with the TOE.
+
+
+
+
+
+
+
+ Direct attack includes the identification of any
+ penetration tests necessary to test the strength of
+ permutational or probabilistic mechanism and other
+ mechanisms to ensure they withstand direct attack.
+
+ For example, it may be a flawed assumption that a
+ particular implementation of a pseudo-random number
+ generator will possess the required entropy necessary to
+ seed the security mechanism.
+
+ Where a probabilistic or permutational mechanism relies on
+ selection of security attribute value (e.g. selection of
+ password length) or entry of data by a human user
+ (e.g. choice of password), the assumptions made should
+ reflect the worst case.
+
+ Probabilistic or permutational mechanisms should be
+ identified during examination of evaluation evidence
+ required as input to this sub-activity (security target,
+ functional specification, TOE design and implementation
+ representation subset) and any other TOE (e.g. guidance)
+ documentation may identify additional probabilistic or
+ permutational mechanisms.
+
+ Where the design evidence or guidance includes assertions
+ or assumptions (e.g. about how many authentication
+ attempts are possible per minute), the evaluator should
+ independently confirm that these are correct. This may be
+ achieved through testing or through independent
+ analysis.
+
+ Direct attacks reliant upon a weakness in a cryptographic
+ algorithm should not be considered under , as this is outside the scope
+ of the CC. Correctness of the implementation of the
+ cryptographic algorithm is considered during the and
+ activities.
+
+
+
+ Information is an abstract view on relation between the
+ properties of entities, i.e. a signal contains information
+ for a system, if the TOE is able to react to this
+ signal. The TOE resources processes and stores information
+ represented by user data. Therefore:
+
+
+ information may flow with the user data between
+ subjects by internal TOE transfer or export from the TOE;
+
+
+ information may be generated and passed to other user
+ data;
+
+
+ information may be gained through monitoring the
+ operations on data representing the information.
+
+
+
+ The information represented by user data may be
+ characterised by security attributes like ``classification
+ level'' having values, for example unclassified,
+ confidential, secret, top secret, to control operations to
+ the data. This information and therefore the security
+ attributes may be changed by operations e.g. may describe decrease of the
+ level by ``sanitarisation'' or increase of level by
+ combination of data. This is one aspects of an information
+ flow analysis focused on controlled operations of
+ controlled subjects on controlled objects.
+
+ The other aspect is the analysis of illicit
+ information flow. This aspect is more
+ general than the direct access to objects containing user
+ data addressed by the
+ family. An unenforced
+ signalling channel carrying information under control of
+ the information flow control policy can also be caused by
+ monitoring of the processing of any object containing or
+ related to this information (e.g. side channels). An
+ enforced signalling channels
+ may be identified in terms of the subjects manipulating
+ resources and the subject or user that observe such
+ manipulation. Classically, covert channels have been
+ identified as timing or storage channels, according to the
+ resource being modified or modulated. As for other
+ monitoring attacks, the use of the TOE is in accordance
+ with the SFRs.
+
+ Covert channels are normally applicable in the case when
+ the TOE has unobservability AND multi-level separation
+ policy requirements. Covert channels may be routinely
+ spotted during vulnerability analysis and design
+ activities, and should therefore be tested. However,
+ generally such monitoring attacks are only identified
+ through specialised analysis techniques commonly referred
+ to as ``covert channel analysis''. These techniques have
+ been the subject of much research and there are many
+ papers published on this subject. Guidance for the
+ conduct of covert channel analysis should be sought from
+ the evaluation authority.
+
+ Unenforced information flow monitoring
+ attacks include passive analysis techniques aiming at
+ disclosure of sensitive internal data of the TOE by
+ operating the TOE in the way that corresponds to the
+ guidance documents.
+
+ Side Channel Analysis includes crypt analytical techniques
+ based on physical leakage of the TOE. Physical leakage can
+ occur by timing information, power consumption or power
+ emanation during computation of a TSF. Timing information
+ can be collected also by a remote-attacker (having network
+ access to the TOE), power based information channels
+ requires that the attacker is in the near-by environment
+ of the TOE.
+
+ Eavesdropping techniques include interception of all forms
+ of energy, e.g., electromagnetic or optical emanation of
+ computer displays, not necessarily in the near-field of
+ the TOE.
+
+ Monitoring also includes exploits of protocol flaws, e.g.,
+ an attack on SSL implementation.
+
+
+
+ Misuse may arise from:
+
+
+ incomplete guidance documentation;
+
+
+ unreasonable guidance;
+
+
+ unintended misconfiguration of the TOE;
+
+
+ forced exception behaviour of the TOE.
+
+
+
+ If the guidance documentation is incomplete the user may
+ not know how to operate the TOE in accordance with the
+ SFRs. The evaluator should apply familiarity with the TOE
+ gained from performing other evaluation activities to
+ determine that the guidance is complete. In particular,
+ the evaluator should consider the functional
+ specification. The TSF described in this document should
+ be described in the guidance as required to permit secure
+ administration and use through the TSFI available to human
+ users. In addition, the different modes of operation
+ should be considered to ensure that guidance is provided
+ for all modes of operation.
+
+ The evaluator may, as an aid, prepare an informal mapping
+ between the guidance and these documents. Any omissions in
+ this mapping may indicate incompleteness.
+
+ The guidance is considered to be unreasonable if it makes
+ demands on the TOE's usage or operational environment that
+ are inconsistent with the ST or unduly onerous to maintain
+ security.
+
+ A TOE may use a variety of ways to assist the consumer in
+ effectively using that TOE in accordance with the SFRs and
+ prevent unintentional misconfiguration. A TOE may employ
+ functionality (features) to alert the consumer when the
+ TOE is in a state that is inconsistent with the SFRs,
+ whilst other TOEs may be delivered with enhanced guidance
+ containing suggestions, hints, procedures, etc. on using
+ the existing security features most effectively; for
+ instance, guidance on using the audit feature as an aid
+ for detecting when the SFRs are being compromised; namely
+ insecure.
+
+ The evaluator considers the TOE's functionality, its
+ purpose and security objectives for the operational
+ environment to arrive at a conclusion of whether or not
+ there is reasonable expectation that use of the guidance
+ would permit transition into an insecure state to be
+ detected in a timely manner.
+
+ The potential for the TOE to enter into insecure states
+ may be determined using the evaluation deliverables, such
+ as the ST, the functional specification and any other
+ design representations provided as evidence for components
+ included in the assurance package for the TOE (e.g. the
+ TOE/TSF design specification if a component from is included).
+
+ Instances of forced exception behaviour of the TSF could
+ include, but are not limited to, the following:
+
+
+ behaviour of the TOE when start-up, close-down or error
+ recovery is activated;
+
+
+ behaviour of the TOE under extreme circumstances
+ (sometimes termed overload or asymptotic behaviour),
+ particularly where this could lead to the
+ de-activation or disabling of parts of the TSF;
+
+
+ any potential for unintentional misconfiguration or
+ insecure use arising from attacks noted in the section
+ on tampering above.
+
+
+
+
+
+
+ Potential vulnerabilities may be identified by the evaluator
+ during different activities. They may become apparent during
+ an evaluation activity or they may be identified as a result
+ of analysis of evidence to search for
+ vulnerabilities.
+
+
+ The encountered identification of vulnerabilities is where
+ potential vulnerabilities are identified by the evaluator
+ during the conduct of evaluation activities, i.e. the
+ evidence are not being analysed with the express aim of
+ identifying potential vulnerabilities.
+
+ The encountered method of identification is dependent on the
+ evaluator's experience and knowledge; which is monitored and
+ controlled by the evaluation authority. It is not reproducible
+ in approach, but will be documented to ensure repeatability of
+ the conclusions from the reported potential
+ vulnerabilities.
+
+ There are no formal analysis criteria required for this
+ method. Potential vulnerabilities are identified from the
+ evidence provided as a result of knowledge and
+ experience. However, this method of identification is not
+ constrained to any particular subset of evidence.
+
+ Evaluator is assumed to have knowledge of the TOE-type
+ technology and known security flaws as documented in the
+ public domain. The level of knowledge assumed is that
+ which can be gained from a security e-mail list relevant
+ to the TOE type, the regular bulletins (bug, vulnerability
+ and security flaw lists) published by those organisations
+ researching security issues in products and technologies
+ in widespread use. This knowledge is not expected to
+ extend to specific conference proceedings or detailed
+ theses produced by university research for or . However, to ensure the knowledge applied is
+ up to date, the evaluator may need to perform a search of
+ public domain material.
+
+ For to the search of publicly
+ available information is expected to include conference
+ proceeding and theses produced during research activities
+ by universities and other relevant organisations.
+
+ Examples of how these may arise (how the evaluator may
+ encounter potential vulnerabilities):
+
+
+ while the evaluator is examining some evidence, it
+ sparks a memory of a potential vulnerability
+ identified in a similar product type, that the
+ evaluator believes to also be present in the TOE under
+ evaluation;
+
+
+ while examining some evidence, the evaluator spots a
+ flaw in the specification of an interface, that
+ reflects a potential vulnerability.
+
+
+ This may include becoming aware of a potential
+ vulnerability in a TOE through reading about generic
+ vulnerabilities in a particular product type in an IT
+ security publication or on a security e-mail list to which
+ the evaluator is subscribed.
+
+ Attack methods can be developed directly from these
+ potential vulnerabilities. Therefore, the encountered
+ potential vulnerabilities are collated at the time of
+ producing penetration tests based on the evaluator's
+ vulnerability analysis. There is no explicit action for
+ the evaluator to encounter potential
+ vulnerabilities. Therefore, the evaluator is directed
+ through an implicit action specified in and .*.4E.
+
+ Current information regarding public domain
+ vulnerabilities and attacks may be provided to the
+ evaluator by, for example, an evaluation authority. This
+ information is to be taken into account by the evaluator
+ when collating encountered vulnerabilities and attack
+ methods when developing penetration tests.
+
+
+
+ The following types of analysis are presented in terms of
+ the evaluator actions.
+
+
+ The unstructured analysis to be performed by the
+ evaluator (for )
+ permits the evaluator to consider the generic
+ vulnerabilities (as discussed in ). The evaluator will also apply their
+ experience and knowledge of flaws in similar technology
+ types.
+
+
+
+ During the conduct of evaluation activities the
+ evaluator may also identify areas of concern. These are
+ specific portions of the TOE evidence that the evaluator
+ has some reservation about, although the evidence meets
+ the requirements for the activity with which the
+ evidence is associated. For example, a particular
+ interface specification looks particularly complex, and
+ therefore may be prone to error either in the
+ development of the TOE or in the operation of the
+ TOE. There is no potential vulnerability apparent at
+ this stage, further investigation is required. This is
+ beyond the bounds of encountered, as further
+ investigation is required.
+
+ Difference between potential vulnerability and area of
+ concern:
+
+
+ Potential vulnerability - The evaluator knows a
+ method of attack that can be used to exploit the
+ weakness or the evaluator knows of vulnerability
+ information that is relevant to the TOE.
+
+
+ Area of concern - The evaluator may be able to
+ discount concern as a potential vulnerability based
+ on information provided elsewhere. While reading
+ interface specification, the evaluator identifies
+ that due to the extreme (unnecessary) complexity of
+ an interface a potential vulnerability may lay
+ within that area, although it is not apparent
+ through this initial examination.
+
+
+ The focused approach to the identification of
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. This
+ approach to the identification of potential
+ vulnerabilities can be used during the independent
+ vulnerability analysis required by .
+
+ This analysis can be achieved through different
+ approaches, that will lead to commensurate levels of
+ confidence. None of the approaches have a rigid format
+ for the examination of evidence to be performed.
+
+ The approach taken is directed by the results of the
+ evaluator's assessment of the evidence to determine it
+ meets the requirements of the /
+ sub-activities. Therefore, the investigation of the
+ evidence for the existence of potential vulnerabilities
+ may be directed by any of the following:
+
+
+ areas of concern identified during examination of
+ the evidence during the conduct of evaluation
+ activities;
+
+
+ reliance on particular functionality to provide
+ separation, identified during the analysis of the
+ architectural design (as in ), requiring further analysis to
+ determine it cannot be bypassed;
+
+
+ representative examination of the evidence to
+ hypothesise potential vulnerabilities in the
+ TOE.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, the evaluator may not be able to
+ describe the steps in identifying potential
+ vulnerabilities before the outset of the
+ examination. The approach will evolve as a result of the
+ outcome of evaluation activities.
+
+ The areas of concern may arise from examination of any
+ of the evidence provided to satisfy the SARs specified
+ for the TOE evaluation. The information publicly
+ accessible is also considered.
+
+ The activities performed by the evaluator can be
+ repeated and the same conclusions, in terms of the level
+ of assurance in the TOE, can be reached although the
+ steps taken to achieve those conclusions may vary. As
+ the evaluator is documenting the form the analysis took,
+ the actual steps taken to achieve those conclusions are
+ also reproducible.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the
+ focused identification method). The method is specified
+ in terms of the information that will be considered and
+ how/why it will be considered. This approach to the
+ identification of potential vulnerabilities can be used
+ during the independent vulnerability analysis required
+ by and .
+
+ This analysis of the evidence is deliberate and
+ pre-planned in approach, considering all evidence
+ identified as an input into the analysis.
+
+ All evidence provided to satisfy the () assurance requirements specified in the
+ assurance package are used as input to the potential
+ vulnerability identification activity.
+
+ The ``methodical'' descriptor for this analysis has been
+ used in an attempt to capture the characterisation that
+ this identification of potential vulnerabilities is to
+ take an ordered and planned approach. A ``method'' or
+ ``system'' is to be applied in the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered; and the
+ hypothesis that is to be generated.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a security mechanism, such as domain
+ separation, hypothesising internal buffer overflows
+ leading to degradation of separation;
+
+
+ analysis to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine the SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the analysis that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be analysed to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ This identification method will provide a plan of attack
+ of the TOE, that would be performed by an evaluator
+ completing penetration testing of potential
+ vulnerabilities in the TOE. The rationale for the method
+ of identification would provide the evidence for the
+ coverage and depth of exploitation determination that
+ would be performed on the TOE.
+
+
+
+
+
+
+
+ Attack potential is used by a PP/ST author during the
+ development of the PP/ST, in consideration of the threat
+ environment and the selection of assurance components. This
+ may simply be a determination that the attack potential
+ possessed by the assumed attackers of the TOE is generically
+ characterised as Basic, Enhanced-Basic, Moderate or
+ High. Alternatively, the PP/ST may wish to specify
+ particular levels of individual factors assumed to be
+ possessed by attackers. (e.g. the attackers are assumed to
+ be experts in the TOE technology type, with access to
+ specialised equipment.)
+
+ The PP/ST author considers the threat profile developed during a
+ risk assessment (outside the scope of the CC, but used as an
+ input into the development of the PP/ST in terms of the Security
+ Problem Definition or in the case of low assurance STs, the
+ requirements statement). Consideration of this threat profile in
+ terms of one of the approaches discussed in the following
+ sections will permit the specification of the attack potential
+ the TOE is to resist.
+
+
+
+ Attack potential is especially considered by the evaluator
+ in two distinct ways during the ST evaluation and the
+ vulnerability assessment activities.
+
+ Attack potential is used by an evaluator during the conduct
+ of the vulnerability analysis sub-activity to determine
+ whether or not the TOE is resistant to attacks assuming a
+ specific attack potential of an attacker. If the evaluator
+ determines that a potential vulnerability is exploitable in
+ the TOE, they have to confirm that it is exploitable
+ considering all aspects of the intended environment,
+ including the attack potential assumed by an
+ attacker.
+
+ Therefore, using the information provided in the threat
+ statement of the Security Target, the evaluator determines
+ the minimum attack potential required by an attacker to
+ effect an attack, and arrives at some conclusion about the
+ TOE's resistance to attacks. Table demonstrates the relationship between this
+ analysis and attack potential.
+
+
+
+
+ Vulnerability Component
+ TOE resistant to attacker with
+ attack potential of:
+ Residual vulnerabilities only
+ exploitable by attacker with attack potential
+ of:
+
+
+
+
+ VAN.5
+ High
+ Beyond High
+
+
+ VAN.4
+ Moderate
+ High
+
+
+ VAN.3
+ Enhanced-Basic
+ Moderate
+
+
+ VAN.2
+ Basic
+ Enhanced-Basic
+
+
+ VAN.1
+ Basic
+ Enhanced-Basic
+
+
+
+ Vulnerability testing and attack potential
+
+
+ The ``beyond high'' entry in the residual vulnerabilities
+ column of the above table represents those potential
+ vulnerabilities that would require an attacker to have an
+ attack potential greater than that of ``high'' in order to
+ exploit the potential vulnerability. A vulnerability
+ classified as residual in this instance reflects the fact
+ that a known weakness exists in the TOE, but in the current
+ operational environment, with the assumed attack potential,
+ the weakness cannot be exploited.
+
+ At any level of attack potential a potential vulnerability
+ may be deemed ``infeasible'' due to a countermeasure in the
+ operational environment that prevents the vulnerability from
+ being exploited.
+
+ A vulnerability analysis applies to all TSFI, including ones
+ that access probabilistic or permutational mechanisms. No
+ assumptions are made regarding the correctness of the design
+ and implementation of the TSFI; nor are constraints placed
+ on the attack method or the attacker's interaction with the
+ TOE - if an attack is possible, then it is to be considered
+ during the vulnerability analysis. As shown in Table , successful evaluation
+ against a vulnerability assurance component reflects that
+ the TSF is designed and implemented to protect against the
+ required level of threat.
+
+ It is not necessary for an evaluator to perform an attack
+ potential calculation for each potential vulnerability. In
+ some cases it is apparent when developing the attack method
+ whether or not the attack potential required to develop and
+ run the attack method is commensurate with that assumed of
+ the attacker in the operational environment. For any
+ vulnerabilities for which an exploitation is determined, the
+ evaluator performs an attack potential calculation to
+ determine that the exploitation is appropriate to the level
+ of attack potential assumed for the attacker.
+
+ The approach described below is to be applied whenever it is
+ necessary to calculate attack potential, unless the evaluation
+ authority provides mandatory guidance that an alternative
+ approach is to be applied. The values given in Tables and
+ below are not mathematically proven. Therefore, the values given
+ in these example tables may need to be adjusted according to the
+ technology type and specific environments. The evaluator should
+ seek guidance from the evaluation authority.
+
+
+
+
+
+ Attack potential is a function of expertise, resources and
+ motivation. There are multiple methods of representing and
+ quantifying these factors. Also, there may be other factors
+ that are applicable for particular TOE types.
+
+
+ Motivation is an attack potential factor that can be used
+ to describe several aspects related to the attacker and
+ the assets the attacker desires. Firstly, motivation can
+ imply the likelihood of an attack - one can infer from a
+ threat described as highly motivated that an attack is
+ imminent, or that no attack is anticipated from an
+ un-motivated threat. However, except for the two extreme
+ levels of motivation, it is difficult to derive a
+ probability of an attack occurring from motivation.
+
+ Secondly, motivation can imply the value of the asset,
+ monetarily or otherwise, to either the attacker or the
+ asset holder. An asset of very high value is more likely
+ to motivate an attack compared to an asset of little
+ value. However, other than in a very general way, it is
+ difficult to relate asset value to motivation because the
+ value of an asset is subjective - it depends largely upon
+ the value an asset holder places on it.
+
+ Thirdly, motivation can imply the expertise and resources
+ with which an attacker is willing to effect an attack. One
+ can infer that a highly motivated attacker is likely to
+ acquire sufficient expertise and resources to defeat the
+ measures protecting an asset. Conversely, one can infer
+ that an attacker with significant expertise and resources
+ is not willing to effect an attack using them if the
+ attacker's motivation is low.
+
+ During the course of preparing for and conducting an
+ evaluation, all three aspects of motivation are at some
+ point considered. The first aspect, likelihood of attack,
+ is what may inspire a developer to pursue an
+ evaluation. If the developer believes that the attackers
+ are sufficiently motivated to mount an attack, then an
+ evaluation can provide assurance of the ability of the TOE
+ to thwart the attacker's efforts. Where the operational
+ environment is well defined, for example in a system
+ evaluation, the level of motivation for an attack may be
+ known, and will influence the selection of
+ countermeasures.
+
+ Considering the second aspect, an asset holder may believe
+ that the value of the assets (however measured) is
+ sufficient to motivate attack against them. Once an
+ evaluation is deemed necessary, the attacker's motivation
+ is considered to determine the methods of attack that may
+ be attempted, as well as the expertise and resources used
+ in those attacks. Once examined, the developer is able to
+ choose the appropriate assurance level, in particular the
+ requirement components,
+ commensurate with the attack potential for the
+ threats. During the course of the evaluation, and in
+ particular as a result of completing the vulnerability
+ assessment activity, the evaluator determines whether or
+ not the TOE, operating in its operational environment, is
+ sufficient to thwart attackers with the identified
+ expertise and resources.
+
+ It may be possible for a PP author to quantify the
+ motivation of an attacker, as the PP author has greater
+ knowledge of the operational environment in which the TOE
+ (conforming to the requirements of the PP) is to be
+ placed. Therefore, the motivation could form an explicit
+ part of the expression of the attack potential in the PP,
+ along with the necessary methods and measures to quantify
+ the motivation.
+
+
+
+
+ This section examines the factors that determine attack
+ potential, and provides some guidelines to help remove some
+ of the subjectivity from this aspect of the evaluation
+ process.
+
+
+ The determination of the attack potential for an attack
+ corresponds to the identification of the effort required to
+ create the attack, and to demonstrate that it can be
+ successfully applied to the TOE (including setting up or
+ building any necessary test equipment), thereby exploiting the
+ vulnerability in the TOE. The demonstration that the attack can
+ be successfully applied needs to consider any difficulties in
+ expanding a result shown in the laboratory to create a useful
+ attack. For example, where an experiment reveals some bits or
+ bytes of a confidential data item (such as a key), it is
+ necessary to consider how the remainder of the data item would
+ be obtained (in this example some bits might be measured
+ directly by further experiments, while others might be found by
+ a different technique such as exhaustive search). It may not be
+ necessary to carry out all of the experiments to identify the
+ full attack, provided it is clear that the attack actually
+ proves that access has been gained to a TOE asset, and that the
+ complete attack could realistically be carried out in
+ exploitation according to the
+ component targeted. In some cases the only way to prove that an
+ attack can realistically be carried out in exploitation
+ according to the component
+ targeted is to perform completely the attack and
+ then rate it based upon the resources actually required.
+ One of the outputs from the identification of a potential
+ vulnerability is assumed to be a script that gives a
+ step-by-step description of how to carry out the attack that can
+ be used in the exploitation of the vulnerability on another
+ instance of the TOE.
+
+ In many cases, the evaluators will estimate the parameters
+ for exploitation, rather than carry out the full
+ exploitation. The estimates and their rationale will be
+ documented in the ETR.
+
+
+
+ The following factors should be considered during analysis
+ of the attack potential required to exploit a
+ vulnerability:
+
+
+ Time taken to identify and exploit (
+ Elapsed Time);
+
+
+ Specialist technical expertise required (
+ Specialist Expertise);
+
+
+ Knowledge of the TOE design and operation (
+ Knowledge of the TOE);
+
+
+
+ Window of opportunity;
+
+
+
+ IT hardware/software or other
+ equipment required for
+ exploitation.
+
+
+
+ In many cases these factors are not independent, but may be
+ substituted for each other in varying degrees. For example,
+ expertise or hardware/software may be a substitute for time. A
+ discussion of these factors follows. (The levels of each factor
+ are discussed in increasing order of magnitude.) When it is the
+ case, the less ``expensive'' combination is considered in the
+ exploitation phase.
+ Elapsed time is the total amount
+ of time taken by an attacker to identify that a particular
+ potential vulnerability may exist in the TOE, to develop an
+ attack method and to sustain effort required to mount the attack
+ against the TOE. When considering this factor, the worst case
+ scenario is used to estimate the amount of time required. The
+ identified amount of time is as follows:
+ less than one day;between one day and one week;between one week and two weeks;between two weeks and one month;each additional month up to 6 months leads to an
+ increased value;more than 6 months.
+
+ Specialist expertise refers
+ to the level of generic knowledge of the underlying
+ principles, product type or attack methods (e.g. Internet
+ protocols, Unix operating systems, buffer overflows). The
+ identified levels are as follows:
+
+
+ Laymen are unknowledgeable compared to experts or
+ proficient persons, with no particular expertise;
+
+
+ Proficient persons are knowledgeable in that they are
+ familiar with the security behaviour of the product or
+ system type;
+
+
+ Experts are familiar with the underlying algorithms,
+ protocols, hardware, structures, security behaviour,
+ principles and concepts of security employed,
+ techniques and tools for the definition of new
+ attacks, cryptography, classical attacks for the
+ product type, attack methods, etc. implemented in the
+ product or system type.
+
+
+ The level ``Multiple Expert'' is introduced to allow for
+ a situation, where different fields of expertise are
+ required at an Expert level for distinct steps of an
+ attack.
+
+ It may occur that several types of expertise are
+ required. By default, the higher of the different
+ expertises factors is chosen. In very specific cases, the
+ ``multiple expert'' level could be used but it should be
+ noted that the expertise must concern fields that are
+ strictly different like for example HW manipulation and
+ cryptography.
+
+
+ Knowledge of the TOE refers to
+ specific expertise in relation to the TOE. This is
+ distinct from generic expertise, but not unrelated to
+ it. Identified levels are as follows:
+
+
+ Public information concerning the TOE (e.g. as gained
+ from the Internet);
+
+
+ Restricted information concerning the TOE
+ (e.g. knowledge that is controlled within the
+ developer organisation and shared with other
+ organisations under a non-disclosure agreement)
+
+
+ Sensitive information about the TOE (e.g. knowledge
+ that is shared between discreet teams within the
+ developer organisation, access to which is constrained
+ only to members of the specified teams);
+
+
+ Critical information about the TOE (e.g. knowledge
+ that is known by only a few individuals, access to
+ which is very tightly controlled on a strict need to
+ know basis and individual undertaking).
+
+
+
+ The knowledge of the TOE may graduate according to design
+ abstraction, although this can only be done on a TOE by
+ TOE basis. Some TOE designs may be public source (or
+ heavily based on public source) and therefore even the
+ design representation would be classified as public or at
+ most restricted, while the implementation representation
+ for other TOEs is very closely controlled as it would give
+ an attacker information that would aid an attack and is
+ therefore considered to be sensitive or even
+ critical.
+
+ It may occur that several types of knowledge are
+ required. In such cases, the higher of the different
+ knowledge factors is chosen.
+
+
+ Window of opportunity
+
+ (Opportunity) is also an important consideration, and has
+ a relationship to the Elapsed Time
+ factor. Identification or exploitation of a
+ vulnerability may require considerable amounts of access
+ to a TOE that may increase the likelihood of
+ detection. Some attack methods may require considerable
+ effort off-line, and only brief access to the TOE to
+ exploit. Access may also need to be continuous, or over a
+ number of sessions.
+
+ For some TOEs the Window of
+ opportunity may equate to the number of
+ samples of the TOE that the attacker can obtain. This is
+ particularly relevant where attempts to penetrate the
+ TOE and undermine the SFRs may result in the destruction
+ of the TOE preventing use of that TOE sample for further
+ testing, e.g. hardware devices. Often in these cases
+ distribution of the TOE is controlled and so the
+ attacker must apply effort to obtain further samples of
+ the TOE.
+
+ For the purposes of this discussion:
+
+
+ unnecessary/unlimited access means that the attack
+ doesn't need any kind of opportunity to be realised
+ because there is no risk of being detected during
+ access to the TOE and it is no problem to access the
+ number of TOE samples for the attack;
+
+ easy means that access is required for less than a day
+ and that the number of TOE samples required to perform
+ the attack is less than ten;
+
+ moderate means that access is required for less than a
+ month and that the number of TOE samples required to
+ perform the attack is less than one hundred;
+
+ difficult means that access is required for at least a
+ month or that the number of TOE samples required to
+ perform the attack is at least one hundred;
+
+ none means that the opportunity window is not
+ sufficient to perform the attack (the length for which
+ the asset to be exploited is available or is sensitive
+ is less than the opportunity length needed to perform
+ the attack - for example, if the asset key is changed
+ each week and the attack needs two weeks); another
+ case is, that a sufficient number of TOE samples
+ needed to perform the attack is not accessible to the
+ attacker - for example if the TOE is a hardware and
+ the probability to destroy the TOE during the attack
+ instead of being successful is very high and the
+ attacker has only access to one sample of the
+ TOE.
+
+ Consideration of this factor may result in determining
+ that it is not possible to complete the exploit, due to
+ requirements for time availability that are greater than
+ the opportunity time.
+
+
+ IT hardware/software or other equipment
+ refers to the equipment required to identify
+ or exploit a vulnerability.
+
+
+ Standard equipment is readily available to the
+ attacker, either for the identification of a
+ vulnerability or for an attack. This equipment may be
+ a part of the TOE itself (e.g. a debugger in an
+ operating system), or can be readily obtained
+ (e.g. Internet downloads, protocol analyser or simple
+ attack scripts).
+
+
+ Specialised equipment is not readily available to the attacker,
+ but could be acquired without undue effort. This could include
+ purchase of moderate amounts of equipment (e.g. power analysis
+ tools, use of hundreds of PCs linked across the Internet would
+ fall into this category), or development of more extensive
+ attack scripts or programs. If clearly different test benches
+ consisting of specialised equipment are required for distinct
+ steps of an attack this would be rated as bespoke.
+
+
+ Bespoke equipment is not readily available to the
+ public as it may need to be specially produced
+ (e.g. very sophisticated software), or because the
+ equipment is so specialised that its distribution is
+ controlled, possibly even restricted. Alternatively,
+ the equipment may be very expensive.
+
+ The level ``Multiple Bespoke'' is introduced to allow
+ for a situation, where different types of bespoke
+ equipment are required for distinct steps of an
+ attack.
+
+ Specialist expertise and Knowledge of the
+ TOE are concerned with the information
+ required for persons to be able to attack a TOE. There
+ is an implicit relationship between an attacker's
+ expertise (where the attacker may be one or more persons
+ with complementary areas of knowledge) and the ability
+ to effectively make use of equipment in an attack. The
+ weaker the attacker's expertise, the lower the potential
+ to use equipment (IT hardware/software or other
+ equipment). Likewise, the greater the expertise, the
+ greater the potential for equipment to be used in the
+ attack. Although implicit, this relationship between
+ expertise and the use of equipment does not always
+ apply, for instance, when environmental measures prevent
+ an expert attacker's use of equipment, or when, through
+ the efforts of others, attack tools requiring little
+ expertise to be effectively used are created and freely
+ distributed (e.g. via the Internet).
+
+
+
+ Table identifies the
+ factors discussed in the previous section and associates
+ numeric values with the total value of each factor.
+
+ Where a factor falls close to the boundary of a range the
+ evaluator should consider use of an intermediate value to those
+ in the table. For example, if twenty samples are required to
+ perform the attack then a value between one and four may be
+ selected for that factor, or if the design is based on a
+ publicly available design but the developer has made some
+ alterations then a value between zero and three should be
+ selected according to the evaluator's view of the impact of
+ those design changes. The table is intended as a guide.
+
+ The ``**'' specification in the table in considering
+ Window of Opportunity is not
+ to be seen as a natural progression from the timescales
+ specified in the preceding ranges associated with this
+ factor. This specification identifies that for a
+ particular reason the potential vulnerability cannot be
+ exploited in the TOE in its intended operational
+ environment. For example, access to the TOE may be
+ detected after a certain amount of time in a TOE with a
+ known environment (i.e. in the case of a system) where
+ regular patrols are completed, and the attacker could not
+ gain access to the TOE for the required two weeks
+ undetected. However, this would not be applicable to a TOE
+ connected to the network where remote access is possible,
+ or where the physical environment of the TOE is
+ unknown.
+
+
+
+
+
+ Factor
+
+
+ Value
+
+
+
+
+
+
+ Elapsed Time
+
+
+
+
+
+ <= one day
+
+ 0
+
+
+
+ <= one week
+
+ 1
+
+
+
+ <= two weeks
+
+ 2
+
+
+
+ <= one month
+
+ 4
+
+
+
+ <= two months
+
+ 7
+
+
+
+ <= three months
+
+ 10
+
+
+
+ <= four months
+
+ 13
+
+
+
+ <= five months
+
+ 15
+
+
+
+ <= six months
+
+ 17
+
+
+
+ > six months
+
+ 19
+
+
+
+ Expertise
+
+
+
+
+
+ Layman
+
+ 0
+
+
+
+ Proficient
+
+
+ 3*When several proficient persons are
+ required to complete the attack path, the
+ resulting level of expertise still remains
+ ``proficient'' (which leads to a 3
+ rating).
+
+
+
+ Expert
+
+ 6
+
+
+
+ Multiple experts
+
+ 8
+
+
+
+ Knowledge of TOE
+
+
+
+
+
+ Public
+
+ 0
+
+
+
+ Restricted
+
+ 3
+
+
+
+ Sensitive
+
+ 7
+
+
+
+ Critical
+
+ 11
+
+
+
+ Window of Opportunity
+
+
+
+
+
+ Unnecessary / unlimited access
+
+ 0
+
+
+
+ Easy
+
+ 1
+
+
+
+ Moderate
+
+ 4
+
+
+
+ Difficult
+
+ 10
+
+
+
+ None
+
+
+ **Indicates that the attack path is not
+ exploitable due to other measures in the
+ intended operational environment of the
+ TOE.
+
+
+
+
+ Equipment
+
+
+
+
+
+ Standard
+
+ 0
+
+
+
+ Specialised
+
+ 4If clearly different test benches
+ consisting of specialised equipment are required
+ for distinct steps of an attack, this should be
+ rated as bespoke.
+
+
+
+ Bespoke
+
+ 7
+
+
+
+ Multiple bespoke
+
+ 9
+
+
+
+
+ Calculation of attack potential
+
+
+ To determine the resistance of the TOE to the potential
+ vulnerabilities identified the following steps should be
+ applied:
+
+
+ Define the possible attack scenarios {AS1, AS2, ...,
+ ASn} for the TOE in the operational
+ environment.
+
+ For each attack scenario, perform a theoretical
+ analysis and calculate the relevant attack potential
+ using Table .
+
+ For each attack scenario, if necessary, perform
+ penetration tests in order to confirm or to disprove
+ the theoretical analysis.
+
+ Divide all attack scenarios {AS1, AS2, ..., ASn} into
+ two groups:
+
+
+ the attack scenarios having been successful
+ (i.e. those that have been used to successfully
+ undermine the SFRs), and
+
+ the attack scenarios that have been demonstrated
+ to be unsuccessful.
+
+
+
+ For each successful attack scenario, apply Table and determine, whether
+ there is a contradiction between the resistance of the
+ TOE and the chosen
+ assurance component, see the last column of Table .
+
+ Should one contradiction be found, the vulnerability
+ assessment will fail, e.g. the author of the ST chose
+ the component and an
+ attack scenario with an attack potential of 21 points
+ (high) has broken the security of the TOE. In this
+ case the TOE is resistant to attacker with attack
+ potential 'Moderate', this contradicts to , hence, the vulnerability
+ assessment fails.
+
+ The ``Values'' column of Table indicates the range of attack potential values
+ (calculated using Table ) of an
+ attack scenario that results in the SFRs being
+ undermined.
+
+
+ An approach such as this cannot take account of every
+ circumstance or factor, but should give a better
+ indication of the level of resistance to attack required
+ to achieve the standard ratings. Other factors, such as
+ the reliance on unlikely chance occurrences are not
+ included in the basic model, but can be used by an
+ evaluator as justification for a rating other than those
+ that the basic model might indicate.
+
+ It should be noted that whereas a number of
+ vulnerabilities rated individually may indicate high
+ resistance to attack, collectively the combination of
+ vulnerabilities may indicate that overall a lower rating
+ is applicable. The presence of one vulnerability may make
+ another easier to exploit.
+
+ If a PP/ST author wants to use the attack potential table for
+ the determination of the level of attack the TOE should
+ withstand (selection of Vulnerability analysis () component), he should proceed as
+ follows: For all different attack scenarios (i.e. for all
+ different types of attacker and/or different types of attack the
+ author has in mind) which must not violate the SFRs, several
+ passes through Table should be
+ made to determine the different values of attack potential
+ assumed for each such unsuccessful attack scenario. The PP/ST
+ author then chooses the highest value of them in order to
+ determine the level of the TOE resistance to be claimed from
+ Table : the TOE resistance must
+ be at least equal to this highest value determined. For
+ example, the highest value of attack potentials of all attack
+ scenarios, which must not undermine the TOE security policy,
+ determined in such a way is Moderate; hence, the TOE resistance
+ shall be at least Moderate (i.e. Moderate or High); therefore,
+ the PP/ST author can choose either (for Moderate) or
+ (for High) as the appropriate assurance component.
+
+
+
+
+
+
+
+ Mechanisms subject to direct attack are often vital for system
+ security and developers often strengthen these mechanisms. As
+ an example, a TOE might use a simple pass number
+ authentication mechanism that can be overcome by an attacker
+ who has the opportunity to repeatedly guess another user's
+ pass number. The system can strengthen this mechanism by
+ restricting pass numbers and their use in various ways. During
+ the course of the evaluation an analysis of this direct attack
+ could proceed as follows:
+
+ Information gleaned from the ST and design evidence reveals
+ that identification and authentication provides the basis upon
+ which to control access to network resources from widely
+ distributed terminals. Physical access to the terminals is not
+ controlled by any effective means. The duration of access to a
+ terminal is not controlled by any effective means. Authorised
+ users of the system choose their own pass numbers when
+ initially authorised to use the system, and thereafter upon
+ user request. The system places the following restrictions on
+ the pass numbers selected by the user:
+
+
+ the pass number must be at least four and no greater than
+ six digits long;
+
+
+ consecutive numerical sequences are disallowed (such as
+ 7,6,5,4,3);
+
+
+ repeating digits is disallowed (each digit must be
+ unique).
+
+
+
+ Guidance provided to the users at the time of pass number
+ selection is that pass numbers should be as random as possible
+ and should not be affiliated with the user in some way - a
+ date of birth, for instance.
+
+ The pass number space is calculated as follows:
+
+
+ Patterns of human usage are important considerations that
+ can influence the approach to searching a password
+ space. Assuming the worst case scenario and the user
+ chooses a number comprising only four digits, the number
+ of pass number permutations assuming that each digit must
+ be unique is:
+
+
+ The number of possible increasing sequences is seven, as
+ is the number of decreasing sequences. The pass number
+ space after disallowing sequences is:
+
+
+
+ Based on further information gleaned from the design evidence,
+ the pass number mechanism is designed with a terminal locking
+ feature. Upon the sixth failed authentication attempt the
+ terminal is locked for one hour. The failed authentication
+ count is reset after five minutes so that an attacker can at
+ best attempt five pass number entries every five minutes, or
+ 60 pass number entries every hour.
+
+ On average, an attacker would have to enter 2513 pass numbers,
+ over 2513 minutes, before entering the correct pass number. The
+ average successful attack would, as a result, occur in slightly
+ less than:
+
+ Using the approach to calculate the attack potential, described
+ in the previous section, identifies that it is possible that a
+ layman can defeat the mechanism within days (given easy access
+ to the TOE), with the use of standard equipment, and with no
+ knowledge of the TOE, giving a value of 1. Given the resulting
+ sum, 1, the attack potential required to effect a successful
+ attack is not rated, as it falls below that considered to be
+ Basic.
+
+
+
+
+ Table describes the
+ relationship between the composition assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Composed Assurance Packages (CAPs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance for
+ composed TOEs.
+
+ It is important to note that there are only a small number of
+ families and components from CC Part 3 included in the
+ CAPs. This is due to their nature of building upon evaluation
+ results of previously evaluated entities (base components and
+ dependent components), and is not to say that these do not
+ provide meaningful and desirable assurances.
+
+
+ CAPs are to be applied to composed TOEs, which are comprised
+ of components that have been (are going through) component TOE
+ evaluation (see ). The
+ individual components will have been certified to an EAL or
+ another assurance package specified in the ST. It is expected
+ that a basic level of assurance in a composed TOE will be
+ gained through application of EAL1, which can be achieved with
+ information about the components that is generally available
+ in the public domain. (EAL1 can be applied as specified
+ within to both component and composed TOEs.) CAPs provide an
+ alternative approach to obtaining higher levels of assurance
+ for a composed TOE than application of the EALs above
+ EAL1.
+
+ While a dependent component can be evaluated using a
+ previously evaluated and certified base component to satisfy
+ the IT platform requirements in the environment, this does not
+ provide any formal assurance of the interactions between the
+ components or the possible introduction of vulnerabilities
+ resulting from the composition. Composed assurance packages
+ consider these interactions and, at higher levels of
+ assurance, ensure that the interface between the components
+ has itself been the subject of testing. A vulnerability
+ analysis of the composed TOE is also performed to consider the
+ possible introduction of vulnerabilities as a result of
+ composing the components.
+
+ Table represents a summary
+ of the CAPs. The columns represent a hierarchically ordered
+ set of CAPs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, three hierarchically
+ ordered composed assurance packages are defined in the CC for
+ the rating of a composed TOE's assurance. They are
+ hierarchically ordered inasmuch as each CAP represents more
+ assurance than all lower CAPs. The increase in assurance from
+ CAP to CAP is accomplished by substitution of a hierarchically
+ higher assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements). These increases result in
+ greater analysis of the composition to identify the impact on
+ the evaluation results gained for the individual component
+ TOEs.
+
+ These CAPs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each CAP includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ The CAPs only consider resistance against an attacker with an
+ attack potential up to Enhanced-Basic. This is due to the level
+ of design information that can be provided through the , limiting some of the factors
+ associated with attack potential (knowledge of the composed TOE)
+ and subsequently affecting the rigour of vulnerability analysis
+ that can be performed by the evaluator. Therefore, the level of
+ assurance in the composed TOE is limited, although the assurance
+ in the individual components within the composed TOE may be much
+ higher.
+
+
+
+
+ The following Subclauses provide definitions of the CAPs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ Unlike the CC, where each element maintains the last digit of
+ its identifying symbol for all components within the family,
+ the CEM may introduce new work units when a CC evaluator
+ action element changes from sub-activity to sub-activity; as a
+ result, the last digit of the work unit's identifying symbol
+ may change although the work unit remains unchanged.
+
+ Any methodology-specific evaluation work required that is not
+ derived directly from CC requirements is termed
+ task or sub-task.
+
+
+
+ All work unit and sub-task verbs are preceded by the auxiliary
+ verb shall and by presenting both the verb
+ and the shall in
+
+ bold italic type face. The
+ auxiliary verb shall is used only when the
+ provided text is mandatory and therefore only within the work
+ units and sub-tasks. The work units and sub-tasks contain
+ mandatory activities that the evaluator must perform in order
+ to assign verdicts.
+
+ Guidance text accompanying work units and sub-tasks gives
+ further explanation on how to apply the CC words in an
+ evaluation. The verb usage is in accordance with ISO
+ definitions for these verbs. The auxiliary verb
+ should is used when the described method is
+ strongly preferred. All other auxiliary verbs, including
+ may, are used where the described method(s)
+ is allowed but is neither recommended nor strongly preferred;
+ it is merely explanation.
+
+ The verbs check, examine,
+ report and record are used
+ with a precise meaning within this part of the CEM and the
+ Clause should be
+ referenced for their definitions.
+
+
+
+ Material that has applicability to more than one sub-activity
+ is collected in one place. Guidance whose applicability is
+ widespread (across activities and EALs) has been collected
+ into . Guidance that
+ pertains to multiple sub-activities within a single activity
+ has been provided in the introduction to that activity. If
+ guidance pertains to only a single sub-activity, it is
+ presented within that sub-activity.
+
+
+
+ There are direct relationships between the CC structure
+ (i.e. class, family, component and element) and the structure
+ of the CEM. Figure illustrates the correspondence
+ between the CC constructs of class, family and evaluator
+ action elements and CEM activities, sub-activities and
+ actions. However, several CEM work units may result from the
+ requirements noted in CC developer action and content and
+ presentation elements.
+
+
+
+ For the purposes of this document, the following terms and
+ definitions apply.
+ Terms which are presented in bold-faced type are themselves
+ defined in this Subclause.
+ action
+
+ evaluator action element of the CC Part 3
+
+ These actions are either explicitly stated as evaluator
+ actions or implicitly derived from developer actions (implied
+ evaluator actions) within the CC Part 3 assurance components.
+
+ activity
+
+ application of an assurance class of the CC Part 3
+
+ check
+
+ generate a verdict by a simple comparison
+
+ Evaluator expertise is not required. The statement
+ that uses this verb describes what is mapped.
+
+ evaluation deliverable
+
+ any resource required from the sponsor or developer by the
+ evaluator or evaluation authority to perform one or more evaluation or
+ evaluation oversight activities
+
+ evaluation evidence
+ tangible evaluation deliverable
+ evaluation technical report
+
+ report that documents the overall verdict and its
+ justification, produced by the evaluator and submitted to an
+ evaluation authority
+ examine
+
+ generate a verdict by analysis using
+ evaluator expertise
+
+ The statement that uses this verb identifies what is analysed
+ and the properties for which it is analysed.
+
+ interpretation
+ clarification or amplification of a CC, CEM or
+ scheme requirement
+ methodology
+
+ system of principles, procedures and processes applied to IT
+ security evaluations
+
+ observation report
+
+ report written by the evaluator requesting a clarification
+ or identifying a problem during the evaluation
+
+ overall verdict
+ pass or fail statement issued by an
+ evaluator with respect to the result of an
+ evaluation
+
+ oversight verdict
+
+ statement issued by an evaluation authority confirming or
+ rejecting an overall verdict based on the
+ results of evaluation oversight activities
+
+ record
+
+ retain a written description of procedures, events,
+ observations, insights and results in sufficient detail to
+ enable the work performed during the evaluation to be
+ reconstructed at a later time
+
+ report
+
+ include evaluation results and supporting material in the
+ Evaluation Technical Report or an
+ Observation Report
+ scheme
+
+ set of rules, established by an evaluation authority,
+ defining the evaluation environment, including criteria and
+ methodology required to conduct IT security
+ evaluations
+
+ sub-activity
+
+ application of an assurance component of the CC Part 3
+
+ Assurance families are not explicitly addressed in the CEM
+ because evaluations are conducted on a single assurance
+ component from an assurance family.
+
+ tracing
+
+ simple directional relation between two sets of
+ entities, which shows which entities in the first set
+ correspond to which entities in the second
+
+ verdict
+ pass, fail or inconclusive statement issued
+ by an evaluator with respect to a CC evaluator action element,
+ assurance component, or class
+
+ Also see overall verdict.
+
+ work unit
+
+ most granular level of evaluation work
+
+ Each CEM action comprises one or more work units, which are
+ grouped within the CEM action by CC content and presentation
+ of evidence or developer action element. The work units are
+ presented in the CEM in the same order as the CC elements
+ from which they are derived. Work units are identified in
+ the left margin by a symbol such as . In this symbol, the
+ string
+ indicates the CC component (i.e. the CEM sub-activity), and
+ the final digit (2) indicates that this is
+ the second work unit in the
+ sub-activity.
+
+
+
+ The target audience for the Common Methodology for Information
+ Technology Security Evaluation (CEM) is primarily evaluators
+ applying the CC and certifiers confirming evaluator actions;
+ evaluation sponsors, developers, PP/ST authors and other parties
+ interested in IT security may be a secondary audience.
+
+ The CEM recognises that not all questions concerning IT security
+ evaluation will be answered herein and that further
+ interpretations will be needed. Individual schemes will
+ determine how to handle such interpretations, although these may
+ be subject to mutual recognition agreements. A list of
+ methodology-related activities that may be handled by individual
+ schemes can be found in .
+
+
+
+
+ Clause defines the
+ conventions used in the CEM.
+
+ Clause
+ describes general evaluation tasks with no verdicts associated
+ with them as they do not map to CC evaluator action
+ elements.
+
+ Clause addresses the work
+ necessary for reaching an evaluation result on a PP.
+
+ Clauses to define the evaluation activities, organised by
+ Assurance Classes.
+
+ covers the basic
+ evaluation techniques used to provide technical evidence of
+ evaluation results.
+
+ provides an explanation
+ of the Vulnerability Analysis criteria and examples of their
+ application
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CC
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+
+
+
+
+ The Common Methodology for Information Technology Security
+ Evaluation (CEM) is a companion document to the Common Criteria
+ for Information Technology Security Evaluation (CC). The CEM
+ defines the minimum actions to be performed by an evaluator in
+ order to conduct a CC evaluation, using the criteria and
+ evaluation evidence defined in the CC.
+ The CEM does not define evaluator actions for certain high
+ assurance CC components, where there is as yet no generally
+ agreed guidance.
+
+
+
+ CEM
+
+ Common Methodology for Information Technology Security
+ Evaluation
+
+
+
+ ETR
+
+ Evaluation Technical Report
+
+
+
+ OR
+
+ Observation Report
+
+
+
+
+
+
+ Table describes the
+ relationship between the evaluation assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Evaluation Assurance Levels (EALs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance. The
+ CC approach identifies the separate concepts of assurance in a
+ TOE at the end of the evaluation, and of maintenance of that
+ assurance during the operational use of the TOE.
+
+ It is important to note that not all families and components
+ from CC Part 3 are included in the EALs. This is not to say that
+ these do not provide meaningful and desirable
+ assurances. Instead, it is expected that these families and
+ components will be considered for augmentation of an EAL in
+ those PPs and STs for which they provide utility.
+
+
+ Table represents a summary
+ of the EALs. The columns represent a hierarchically ordered
+ set of EALs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, seven hierarchically
+ ordered evaluation assurance levels are defined in the CC for
+ the rating of a TOE's assurance. They are hierarchically
+ ordered inasmuch as each EAL represents more assurance than
+ all lower EALs. The increase in assurance from EAL to EAL is
+ accomplished by substitution of a hierarchically higher
+ assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements).
+
+ These EALs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each EAL includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ While the EALs are defined in the CC, it is possible to
+ represent other combinations of assurance. Specifically, the
+ notion of ``augmentation'' allows the addition of assurance
+ components (from assurance families not already included in
+ the EAL) or the substitution of assurance components (with
+ another hierarchically higher assurance component in the same
+ assurance family) to an EAL. Of the assurance constructs
+ defined in the CC, only EALs may be augmented. The notion of
+ an ``EAL minus a constituent assurance component'' is not
+ recognised by the standard as a valid claim. Augmentation
+ carries with it the obligation on the part of the claimant to
+ justify the utility and added value of the added assurance
+ component to the EAL. An EAL may also be augmented with
+ extended assurance requirements.
+
+
+
+
+ The following Subclauses provide definitions of the EALs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ The objective of this clause is to cover general guidance
+ used to provide technical evidence of evaluation results. The
+ use of such general guidance helps in achieving objectivity,
+ repeatability and reproducibility of the work performed by the
+ evaluator.
+
+
+
+ This Subclause provides general guidance on sampling. Specific
+ and detailed information is given in those work units under
+ the specific evaluator action elements where sampling has to
+ be performed.
+
+ Sampling is a defined procedure of an evaluator whereby some
+ subset of a required set of evaluation evidence is examined
+ and assumed to be representative for the entire set. It allows
+ the evaluator to gain enough confidence in the correctness of
+ particular evaluation evidence without analysing the whole
+ evidence. The reason for sampling is to conserve resources
+ while maintaining an adequate level of assurance. Sampling of
+ the evidence can provide two possible outcomes:
+
+
+ The subset reveals no errors, allowing the evaluator to
+ have some confidence that the entire set is correct.
+
+
+ The subset reveals errors and therefore the validity of
+ the entire set is called into question. Even the
+ resolution of all errors that were found may be
+ insufficient to provide the evaluator the necessary
+ confidence and as a result the evaluator may have to
+ increase the size of the subset, or stop using sampling
+ for this particular evidence.
+
+
+
+ Sampling is a technique which can be used to reach a reliable
+ conclusion if a set of evidence is relatively homogeneous in
+ nature, e.g. if the evidence has been produced during a well
+ defined process.
+
+ Sampling in the cases identified in the CC, and in cases
+ specifically covered in CEM work items, is recognised as a
+ cost-effective approach to performing evaluator
+ actions. Sampling in other areas is permitted only in
+ exceptional cases, where performance of a particular activity
+ in its entirety would require effort disproportionate to the
+ other evaluation activities, and where this would not add
+ correspondingly to assurance. In such cases a rationale for
+ the use of sampling in that area will need to be made. Neither
+ the fact that the TOE is large and complex, nor that it has
+ many security functional requirements, is sufficient
+ justification, since evaluations of large, complex TOEs can be
+ expected to require more effort. Rather it is intended that
+ this exception be limited to cases such as that where the TOE
+ development approach yields large quantities of material for a
+ particular CC requirement that would normally all need to be
+ checked or examined, and where such an action would not be
+ expected to raise assurance correspondingly.
+
+ Sampling needs to be justified taking into account the
+ possible impact on the security objectives and threats of the
+ TOE. The impact depends on what might be missed as a result of
+ sampling. Consideration also needs to be given to the nature
+ of the evidence to be sampled, and the requirement not to
+ diminish or ignore any security functions.
+
+ It should be recognised that sampling of evidence directly
+ related to the implementation of the TOE (e.g. developer test
+ results) requires a different approach to sampling, then
+ sampling related to the determination of whether a process is
+ being followed. In many cases the evaluator is required to
+ determine that a process is being followed, and a sampling
+ strategy is recommended. The approach for sampling a
+ developer's test results will differ. This is because the
+ former case is concerned with ensuring that a process is in
+ place, and the latter deals with determining correct
+ implementation of the TOE. Typically, larger sample sizes
+ should be analysed in cases related to the correct
+ implementation of the TOE than would be necessary to ensure
+ that a process is in place.
+
+ In certain cases it may be appropriate for the evaluator to
+ give greater emphasis to the repetition of developer
+ testing. For example if the independent tests left for the
+ evaluator to perform would be only superficially different
+ from those included in an extensive developer test set
+ (possibly because the developer has performed more testing
+ than necessary to satisfy the
+ and criteria) then it would
+ be appropriate for the evaluator to give greater focus to the
+ repetition of developer tests. Note that this does not
+ necessarily imply a requirement for a high percentage sample
+ for repetition of developer tests; indeed, given an extensive
+ developer test set, the evaluator may be able to justify a low
+ percentage sample.
+
+ Where the developer has used an automated test suite to
+ perform functional testing, it will usually be easier for the
+ evaluator to re-run the entire test suite rather than repeat
+ only a sample of developer tests. However the evaluator does
+ have an obligation to check that the automatic testing does
+ not give misrepresentative results. The implication is thus
+ that this check must be performed for a sample of the
+ automatic test suite, with the principles for selecting some
+ tests in preference to others and ensuring a sufficient sample
+ size applying equally in this case.
+
+ The following principles should be followed whenever sampling
+ is performed:
+
+
+ Sampling should not be random, rather it should be chosen
+ such that it is representative of all of the evidence. The
+ sample size and composition must always be justified.
+
+
+ When sampling relates to the correct implementation of the
+ TOE, the sample should be representative of all aspects
+ relevant to the areas that are sampled. In particular, the
+ selection should cover a variety of components,
+ interfaces, developer and operational sites (if more than
+ one is involved) and hardware platform types (if more than
+ one is involved). The sample size should be commensurate
+ with the cost effectiveness of the evaluation and will
+ depend on a number of TOE dependent factors (e.g. the size
+ and complexity of the TOE, the amount of documentation).
+
+
+ Also, when sampling relates to specifically gaining
+ evidence that the developer testing is repeatable and
+ reproducible the sample used must be sufficient to
+ represent all distinct aspects of developer testing, such
+ as different test regimes. The sample used must be
+ sufficient to detect any systematic problem in the
+ developer's functional testing process. The evaluator
+ contribution resulting from the combination of repeating
+ developer tests and performing independent tests must be
+ sufficient to address the major points of concern for the
+ TOE.
+
+
+ Where sampling relates to gaining evidence that a process
+ (e.g. visitor control or design review) the evaluator
+ should sample sufficient information to gain reasonable
+ confidence that the procedure is being followed.
+
+
+ The sponsor and developer should not be informed in
+ advance of the exact composition of the sample, subject to
+ ensuring timely delivery of the sample and supporting
+ deliverable, e.g. test harnesses and equipment to the
+ evaluator in accordance with the evaluation schedule.
+
+
+ The choice of the sample should be free from bias to the
+ degree possible (one should not always choose the first or
+ last item). Ideally the sample selection should be done by
+ someone other than the evaluator.
+
+
+
+ Errors found in the sample can be categorised as being either
+ systematic or sporadic. If the error is systematic, the
+ problem should be corrected and a complete new sample
+ taken. If properly explained, sporadic errors might be solved
+ without the need for a new sample, although the explanation
+ should be confirmed. The evaluator should use judgement in
+ determining whether to increase the sample size or use a
+ different sample.
+
+
+
+ In general it is possible to perform the required evaluation
+ activities, sub-activities, and actions in any order or in
+ parallel. However, there are different kinds of dependencies
+ which have to be considered by the evaluator. This Subclause
+ provides general guidance on dependencies between different
+ activities, sub-activities, and actions.
+
+
+ For some cases the different assurance classes may recommend
+ or even require a sequence for the related activities. A
+ specific instance is the ST activity. The ST evaluation
+ activity is started prior to any TOE evaluation activities
+ since the ST provides the basis and context to perform
+ them. However, a final verdict on the ST evaluation may not
+ be possible until the TOE evaluation is complete, since
+ changes to the ST may result from activity findings during
+ the TOE evaluation.
+
+
+
+ Dependencies identified between components in CC Part 3 have
+ to be considered by the evaluator. Most dependencies are
+ one way, e.g. claims a
+ dependency on and . There are also instances of
+ mutual dependencies, where both components depend on each
+ other. An example of this is and .
+
+ A sub-activity can be assigned a pass verdict normally only
+ if all those sub-activities are successfully completed on
+ which it has a one-way dependency. For example, a pass
+ verdict on can normally
+ only be assigned if the sub-activities related to and are assigned a pass verdict too. In the case
+ of mutual dependency the ordering of these components is
+ down to the evaluator deciding which sub-activity to perform
+ first. Note this indicates that pass verdicts can normally
+ only be assigned once both sub-activities have been
+ successful.
+
+ So when determining whether a sub-activity will impact
+ another sub-activity, the evaluator should consider whether
+ this activity depends on potential evaluation results from
+ any dependent sub-activities. Indeed, it may be the case
+ that a dependent sub-activity will impact this sub-activity,
+ requiring previously completed evaluator actions to be
+ performed again.
+
+ A significant dependency effect occurs in the case of
+ evaluator-detected flaws. If a flaw is identified as a
+ result of conducting one sub-activity, the assignment of a
+ pass verdict to a dependent sub-activity may not be possible
+ until all flaws related to the sub-activity upon which it
+ depends are resolved.
+
+
+
+ It may be the case, that results which are generated by the
+ evaluator during one action are used for performing another
+ action. For example, actions for completeness and
+ consistency cannot be completed until the checks for content
+ and presentation have been completed. This means for example
+ that the evaluator is recommended to evaluate the PP/ST
+ rationale after evaluating the constituent parts of the
+ PP/ST.
+
+
+
+
+
+ The assurance class includes
+ requirements for
+
+
+ the application of configuration management, ensuring
+ that the integrity of the TOE is preserved;
+
+
+ measures, procedures, and standards concerned with
+ secure delivery of the TOE, ensuring that the security
+ protection offered by the TOE is not compromised during
+ the transfer to the user,
+
+
+ security measures, used to protect the development
+ environment.
+
+
+
+ A development site visit is a useful means whereby the
+ evaluator determines whether procedures are being followed
+ in a manner consistent with that described in the
+ documentation.
+
+ Reasons for visiting sites include:
+
+
+ to observe the use of the CM system as described in the
+ CM plan;
+
+
+ to observe the practical application of delivery
+ procedures as described in the delivery documentation;
+
+
+ to observe the application of security measures during
+ development and maintenance of the TOE as described in
+ the development security documentation.
+
+
+
+ Specific and detailed information is given in work units for
+ those activities where site visits are performed:
+
+
+ .n with n>=3
+ (especially work unit = = );
+
+
+ (especially work unit
+ );
+
+
+ (especially work unit
+ = ).
+
+
+
+
+
+ During an evaluation it is often necessary that the
+ evaluator will meet the developer more than once and it is a
+ question of good planning to combine the site visit with
+ another meeting to reduce costs. For example one might
+ combine the site visits for configuration management, for
+ the developer's security and for delivery. It may also be
+ necessary to perform more than one site visit to the same
+ site to allow the checking of all development phases. It
+ should be considered that development could occur at
+ multiple facilities within a single building, multiple
+ buildings at the same site, or at multiple sites.
+
+ The first site visit should be scheduled early during the
+ evaluation. In the case of an evaluation which starts during
+ the development phase of the TOE, this will allow corrective
+ actions to be taken, if necessary. In the case of an
+ evaluation which starts after the development of the TOE, an
+ early site visit could allow corrective measures to be put
+ in place if serious deficiencies in the applied procedures
+ emerge. This avoids unnecessary evaluation effort.
+
+ Interviews are also a useful means of determining whether the
+ written procedures reflect what is done. In conducting such
+ interviews, the evaluator aims to gain a deeper understanding of
+ the analysed procedures at the development site, how they are
+ used in practise and whether they are being applied as described
+ in the provided evaluation evidence. Such interviews complement
+ but do not replace the examination of evaluation
+ evidence.
+
+ As a first step preparing the site visits the evaluators
+ should perform the evaluator work units concerning the
+ assurance class excluding the
+ aspects describing the results of the site visit. Based on
+ the information provided by the relevant developer
+ documentation and the remaining open questions which were
+ not answered by the documentation the evaluators compile a
+ check list of the questions which are to be resolved by the
+ site visits.
+
+ The first version of the evaluation report concerning the
+ class and the check list serves
+ as input for the consultation with the evaluation authority
+ concerning the site visits.
+
+ The check list serve as a guide line for the site visits,
+ which questions are to be answered by inspection of the
+ relevant measures, their application and results, and by
+ interviews. Where appropriate, sampling is used for gaining
+ the required level of confidence (see Subclause ).
+
+ The results of the site visits are recorded and serve as
+ input for the final version of the evaluation report
+ concerning the assurance class .
+
+ Other approaches to gain confidence should be considered
+ that provide an equivalent level of assurance (e.g. to
+ analyse evaluation evidence). Any decision not to make a
+ visit should be determined in consultation with the
+ evaluation authority. Appropriate security criteria and a
+ methodology should be based on other standards of the
+ Information Security Management Systems area.
+
+
+
+ In the following some keywords are provided, which topics
+ should be checked during an audit.
+
+ Basic
+
+
+ Items of the configuration list, including TOE, source
+ code, run time libraries, design documentation,
+ development tools ().
+
+
+ Tracking of design documentation, source code, user
+ guidance to different versions of the TOE.
+
+
+ Integration of the configuration system in the design
+ and development process, test planning, test analysis
+ and quality management procedures.
+
+
+
+ Test analysis
+
+
+ Tracking of test plans and results to specific
+ configurations and versions of the TOE.
+
+
+
+ Access control to development systems
+
+
+ Policies for access control and logging.
+
+
+ Policies for project specific assignment and changing
+ of access rights.
+
+
+
+ Clearance
+
+
+ Policies for clearance of the TOE and user guidance to
+ the customer.
+
+
+ Policies for testing and approving of components and
+ the TOE before deployment.
+
+
+
+
+
+ Infrastructure
+
+
+ Security measures for physical access control to the
+ development site and rationale for the effectiveness
+ of these measures.
+
+
+
+ Organisational measures
+
+
+ Organisational structure of the company in respect of
+ the security of the development environment.
+
+
+ Organisational separation between development,
+ production, testing and quality assurance.
+
+
+
+ Personal measures
+
+
+ Measures for education of the personnel in respect of
+ development security.
+
+
+ Measures and legal agreements of non disclosure of
+ internal information.
+
+
+
+ Access control
+
+
+ Assignment of secured objects (for instance TOE,
+ source code, run time libraries, design documentation,
+ development tools, user guidance) and security
+ policies.
+
+
+ Policies and responsibilities concerning the access
+ control and the handling of authentication
+ information.
+
+
+ Policies for logging of any kind access to the
+ development site and protection of the logging data.
+
+
+
+ Input, processing and output of data
+
+
+ Security measures for protection of output and output
+ devices (printer, plotter and displays).
+
+
+ Securing of local networks and communication
+ connections.
+
+
+
+ Storage, transfer and destruction of documents and data
+ media.
+
+
+ Policies for handling of documents and data media.
+
+
+ Policies and responsibilities for destruction of
+ sorted out documents and logging of these events.
+
+
+
+ Data protection
+
+
+ Policies and responsibilities for data and information
+ protection (e.g. for performing backups).
+
+
+
+ Contingency plan
+
+
+ Practises in case of emergency and responsibilities.
+
+
+ Documentation of the contingency measures concerning
+ access control.
+
+
+ Information of the personnel about applicable
+ practises in extreme cases. protection (e.g. for
+ performing backups).
+
+
+
+
+
+
+ The examples of checklists for site visits consist in tables
+ for the preparation of an audit and for the presentation of
+ the results of an audit.
+
+ The checklist structure given in the following is
+ preliminary. Dependent on the concrete contents of the new
+ guideline, changes might become necessary.
+ The checklist is divided into three subclauses according
+ to the subjects indicated in the introduction (Subclause ).
+
+
+ Configuration management system.
+
+
+ Delivery procedures.
+
+
+ Security measures during development.
+
+
+ These subclauses correspond to the actual CC class , especially the families .n with n>=3, and .
+ The subclauses are subdivided further into rows
+ corresponding to the relevant work units of the CEM.
+
+ The columns of the checklist contain in turn
+
+
+ a consecutive number,
+
+
+ the referenced work unit,
+
+
+ the references to the corresponding developer
+ documentation,
+
+
+ the explicit reproduction of the developer measures,
+
+
+ special remarks and questions to be clarified on the
+ visit (beyond the standard evaluator task to verify the
+ application of the indicated measures),
+
+
+ the result of the examinations during the visit.
+
+
+ If it is decided to have separate checklists for
+ preparation and reporting of the audit, the result column is
+ omitted in the preparation list and the remarks and
+ questions column is omitted in the reporting list. The
+ remaining columns should be identical in both lists.
+
+
+ Example of a checklist at EAL 4 (extract)
+
+
+
+
+
+ A. Examination of the CM system ( and )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ A.1
+
+
+ ,
+
+
+
+ ``Configuration Management System'', ch. ...
+
+
+ The system automatically managing the source code
+ files is capable of administering user profiles and
+ graded access rights, and of checking identification
+ and authentication of users.
+
+
+ Does reading or updating of a source code file
+ require a user authentication?
+
+
+ If a user has not the right to access a confidential
+ document, it is not even displayed to him in the
+ file list.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ B. Examination of the Delivery Procedures ()
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ B.1
+
+
+ ,
+
+
+
+ ``Delivery of the TOE'', ch. ...
+
+
+ The software is transmitted PGP-signed and encrypted
+ to the customer.
+
+
+ ---
+
+
+ The evaluators have checked the process and found it
+ as described, additionally a checksum is
+ transmitted.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ C. Examination of the organisational and
+ infrastructural developer security
+ (,
+ ,
+ )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ C.1
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Premises)
+
+
+ The premises are protected by security fencing.
+
+
+ Is the fencing sufficiently strong and high to
+ prevent an easy intrusion into the premises?
+
+
+ The evaluators considered the fencing to be
+ sufficiently strong and high.
+
+
+
+
+ C.2
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Building)
+
+
+ The building has the following access possibilities:
+ The main entrance which is surveyed by the reception
+ and is closed if the reception is not manned. And an
+ access in the goods reception which is secured by
+ two roller shutters.
+
+
+ Is the listing of the access possibilities complete?
+
+
+ Beyond the indicated access possibilities, there is
+ an emergency exit that cannot be opened from the
+ outside. The roller shutters mentioned before can be
+ operated only from inside.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+
+ This CEM describes the minimum technical work that evaluations
+ conducted under oversight (scheme) bodies must
+ perform. However, it also recognises (both explicitly and
+ implicitly) that there are activities or methods upon which
+ mutual recognition of evaluation results do not rely. For the
+ purposes of thoroughness and clarity, and to better delineate
+ where the CEM ends and an individual scheme's methodology
+ begins, the following matters are left up to the discretion of
+ the schemes. Schemes may choose to provide the following,
+ although they may choose to leave some unspecified. (Every
+ effort has been made to ensure this list is complete;
+ evaluators encountering a subject neither listed here nor
+ addressed in the CEM should consult with their evaluation
+ schemes to determine under whose auspices the subject
+ falls.)
+
+ The matters that schemes may choose to specify include:
+
+
+ what is required in ensuring that an evaluation was done
+ sufficiently - every scheme has a means of verifying the
+ technical competence, understanding of work and the work
+ of its evaluators, whether by requiring the evaluators to
+ present their findings to the oversight body, by requiring
+ the oversight body to redo the evaluator's work, or by
+ some other means that assures the scheme that all
+ evaluation bodies are adequate and comparable;
+
+
+ process for disposing of evaluation evidence upon
+ completion of an evaluation;
+
+
+ any requirements for confidentiality (on the part of the
+ evaluator and the non-disclosure of information obtained
+ during evaluation);
+
+
+ the course of action to be taken if a problem is
+ encountered during the evaluation (whether the evaluation
+ continues once the problem is remedied, or the evaluation
+ ends immediately and the remedied product must be
+ re-submitted for evaluation);
+
+
+ any specific (natural) language in which documentation
+ must be provided;
+
+
+ any recorded evidence that must be submitted in the ETR -
+ this CEM specifies the minimum to be reported in an ETR;
+ however, individual schemes may require additional
+ information to be included;
+
+
+ any additional reports (other than the ETR) required from
+ the evaluators -for example, testing reports;
+
+
+ any specific ORs that may be required by the scheme,
+ including the structure, recipients, etc. of any such ORs;
+
+
+ any specific content structure of any written report as a
+ result from an ST evaluation - a scheme may have a
+ specific format for all of its reports detailing results
+ of an evaluation, be it the evaluation of a TOE or of an
+ ST;
+
+
+ any additional PP/ST identification information required;
+
+
+ any activities to determine the suitability of
+ explicitly-stated requirements in an ST;
+
+
+ any requirements for provision of evaluator evidence to
+ support re-evaluation and re-use of evidence;
+
+
+ any specific handling of scheme identifiers, logos,
+ trademarks, etc.;
+
+
+ any specific guidance in dealing with cryptography;
+
+
+ handling and application of scheme, national and
+ international interpretations;
+
+
+ a list or characterisations of suitable alternative
+ approaches to testing where testing is infeasible;
+
+
+ the mechanism by which an evaluation authority can determine what
+ steps an evaluator took while testing;
+
+
+ preferred test approach (if any): at internal interface or
+ at external interface;
+
+
+ a list or characterisation of acceptable means of
+ conducting the evaluator's vulnerability analysis
+ (e.g. flaw hypothesis methodology);
+
+
+ information regarding any vulnerabilities and weaknesses
+ to be considered.
+
+
+
+
+
+
+
+ The following annexes through provide the application notes for the functional
+ classes defined in the main body of this part of the CC.
+
+
+ For the purposes of this document, the terms, definitions,
+ symbols and abbreviated terms given in CC Part 1 apply.
+
+
+ Security functional components, as defined in this CC Part 2, are
+ the basis for the security functional requirements expressed in a
+ Protection Profile (PP) or a Security Target (ST). These
+ requirements describe the desired security behaviour expected of a
+ Target of Evaluation (TOE) and are intended to meet the security
+ objectives as stated in a PP or an ST. These requirements describe
+ security properties that users can detect by direct interaction
+ (i.e. inputs, outputs) with the IT or by the IT response to
+ stimulus.
+
+ Security functional components express security requirements
+ intended to counter threats in the assumed operating environment
+ of the TOE and/or cover any identified organisational security
+ policies and assumptions.
+
+ The audience for this CC Part 2 includes consumers, developers,
+ and evaluators of secure IT products. CC Part 1
+ Chapter provides additional
+ information on the target audience of the CC, and on the use of
+ the CC by the groups that comprise the target audience. These
+ groups may use this part of the CC as follows:
+
+
+ Consumers, who use this CC Part 2 when selecting components to
+ express functional requirements to satisfy the security
+ objectives expressed in a PP or ST. CC Part 1 Section provides more detailed
+ information on the relationship between security objectives
+ and security requirements.
+
+
+ Developers, who respond to actual or perceived consumer
+ security requirements in constructing a TOE, may find a
+ standardised method to understand those requirements in this
+ part of the CC. They can also use the contents of this part of
+ the CC as a basis for further defining the TOE security
+ functionality and mechanisms that comply with those
+ requirements.
+
+
+ Evaluators, who use the functional requirements defined in
+ this part of the CC in verifying that the TOE functional
+ requirements expressed in the PP or ST satisfy the IT security
+ objectives and that all dependencies are accounted for and
+ shown to be satisfied. Evaluators also should use this part of
+ the CC to assist in determining whether a given TOE satisfies
+ stated requirements.
+
+
+
+
+
+ The CC and the associated security functional requirements
+ described herein are not meant to be a definitive answer to all
+ the problems of IT security. Rather, the CC offers a set of well
+ understood security functional requirements that can be used to
+ create trusted products reflecting the needs of the market. These
+ security functional requirements are presented as the current
+ state of the art in requirements specification and
+ evaluation.
+
+ This part of the CC does not presume to include all possible
+ security functional requirements but rather contains those that
+ are known and agreed to be of value by the CC Part 2 authors at
+ the time of release.
+
+ Since the understanding and needs of consumers may change, the
+ functional requirements in this part of the CC will need to be
+ maintained. It is envisioned that some PP/ST authors may have
+ security needs not (yet) covered by the functional requirement
+ components in CC Part 2. In those cases the PP/ST author may
+ choose to consider using functional requirements not taken from
+ the CC (referred to as extensibility), as explained in annexes
+ and
+ of
+ CC Part 1.
+
+
+
+ Clause
+ describes the paradigm used in the security functional
+ requirements of CC Part 2.
+
+ Clause
+ introduces the catalogue of CC Part 2 functional components
+ while clauses through describe the functional classes.
+
+ provides explanatory information for potential
+ users of the functional components including a complete cross
+ reference table of the functional component dependencies.
+
+ through provide the explanatory information for the
+ functional classes. This material must be seen as normative
+ instructions on how to apply relevant operations and select
+ appropriate audit or documentation information; the use of the
+ auxiliary verb should means that the instruction is strongly
+ preferred, but others may be justifiable. Where different
+ options are given, the choice is left to the PP/ST
+ author.
+
+ Those who author PPs or STs should refer to clause 2 of CC Part
+ 1 for relevant structures, rules, and guidance:
+
+
+ CC Part 1, clause
+ defines the terms used in the CC.
+
+
+ CC Part 1, annex defines the
+ structure for STs.
+
+
+ CC Part 1, annex defines the
+ structure for PPs.
+
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest edition
+ of the referenced document (including any amendments) applies.CC
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 1: Introduction and general model.
+
+
+ This part of the CC defines the required structure and content
+ of security functional components for the purpose of security
+ evaluation. It includes a catalogue of functional components
+ that will meet the common security functionality requirements
+ of many IT products.
+
+
+ This chapter describes the paradigm used in the security
+ functional requirements of this part of the CC. Key concepts
+ discussed are highlighted in bold/italics. This section is not
+ intended to replace or supersede any of the terms found in CC Part
+ 1, chapter .
+
+ This part of the CC is a catalogue of security functional
+ components that can be specified for a Target of
+ Evaluation (TOE). A TOE is a set of software, firmware
+ and/or hardware possibly accompanied by user and administrator
+ guidance documentation. A TOE may contain resources such as
+ electronic storage media (e.g. main memory, disk space),
+ peripheral devices (e.g. printers), and computing capacity (e.g.
+ CPU time) that can be used for processing and storing
+ information and is the subject of an evaluation.
+
+ TOE evaluation is concerned primarily with ensuring that a defined
+ set of security functional requirements (SFRs) is
+ enforced over the TOE resources. The SFRs define the rules by
+ which the TOE governs access to and use of its resources, and thus
+ information and services controlled by the TOE.
+
+ The SFRs may define multiple Security Function Policies
+ (SFPs) to represent the rules that the TOE must enforce. Each such SFP
+ must specify its scope of control, by defining the subjects,
+ objects, resources or information, and operations to which it applies. All
+ SFPs are implemented by the TSF (see below), whose mechanisms enforce the
+ rules defined in the SFRs and provide necessary capabilities.
+
+ Those portions of a TOE that must be relied on for the correct
+ enforcement of the SFRs are collectively referred to as the
+ TOE Security Functionality (TSF). The TSF consists of
+ all hardware, software, and firmware of a TOE that is either
+ directly or indirectly relied upon for security enforcement.
+
+ The TOE may be a monolithic product containing hardware, firmware,
+ and software.
+
+ Alternatively a TOE may be a distributed product that consists
+ internally of multiple separated parts. Each of these parts of the
+ TOE provides a particular service for the TOE, and is connected to
+ the other parts of the TOE through an internal communication
+ channel. This channel can be as small as a processor bus,
+ or may encompass a network internal to the TOE.
+
+ When the TOE consists of multiple parts, each part of the TOE may
+ have its own part of the TSF which exchanges user and TSF data
+ over internal communication channels with other parts of the
+ TSF. This interaction is called internal TOE
+ transfer. In this case the separate parts of the TSF
+ abstractly form the composite TSF, which enforces the SFRs.
+
+ TOE interfaces may be localised to the particular TOE, or they may
+ allow interaction with other IT products over external
+ communication channels. These external interactions with
+ other IT products may take two forms:
+
+
+ The SFRs of the other ``trusted IT product'' and the SFRs of
+ the TOE have been administratively coordinated and the other
+ trusted IT product is assumed to enforce its SFRs correctly
+ (e. g. by being separately evaluated). Exchanges of
+ information in this situation are called inter-TSF
+ transfers, as they are between the TSFs of distinct
+ trusted products.
+
+
+ The other IT product may not be trusted, it may be called an
+ ``untrusted IT product''. Therefore its SFRs are either
+ unknown or their implementation is not viewed as
+ trustworthy. TSF mediated exchanges of information in this
+ situation are called transfers outside of the
+ TOE, as there is no TSF (or its policy characteristics
+ are unknown) on the other IT product.
+
+
+ The set of interfaces, whether interactive (man-machine
+ interface) or programmatic (application programming interface),
+ through which resources are accessed that are mediated by the TSF,
+ or information is obtained from the TSF, is referred to as the
+ TSF Interface (TSFI). The TSFI defines the boundaries
+ of the TOE functionality that provide for the enforcement of the
+ SFRs.
+
+ Users are outside of the TOE. However, in order to request that
+ services be performed by the TOE that are subject to rules
+ defined in the SFRs, users interact with the TOE through the
+ TSFIs. There are two types of users of interest to CC Part 2:
+ human users and external IT
+ entities. Human users may further be differentiated as
+ local human users, meaning they interact directly
+ with the TOE via TOE devices (e.g. workstations), or
+ remote human users, meaning they interact
+ indirectly with the TOE through another IT product.
+
+ A period of interaction between users and the TSF is referred to
+ as a user session. Establishment of user sessions can
+ be controlled based on a variety of considerations, for example:
+ user authentication, time of day, method of accessing the TOE, and
+ number of allowed concurrent sessions (per user or in total).
+
+ This part of the CC uses the term authorised to
+ signify a user who possesses the rights and/or privileges
+ necessary to perform an operation. The term authorised
+ user, therefore, indicates that it is allowable for a user
+ to perform a specific operation or a set of operations as defined
+ by the SFRs.
+
+ To express requirements that call for the separation of
+ administrator duties, the relevant security functional
+ components (from family )
+ explicitly state that administrative roles are
+ required. A role is a pre-defined set of rules establishing the
+ allowed interactions between a user operating in that role and
+ the TOE. A TOE may support the definition of any number of
+ roles. For example, roles related to the secure operation of a
+ TOE may include ``Audit Administrator'' and ``User Accounts
+ Administrator''.
+
+ TOEs contain resources that may be used for the
+ processing and storing of information. The primary goal of the TSF
+ is the complete and correct enforcement of the SFRs over the
+ resources and information that the TOE controls.
+
+ TOE resources can be structured and utilised in many different
+ ways. However, CC Part 2 makes a specific distinction that allows
+ for the specification of desired security properties. All entities
+ that can be created from resources can be characterised in one of
+ two ways. The entities may be active, meaning that they are the
+ cause of actions that occur internal to the TOE and cause
+ operations to be performed on information. Alternatively, the
+ entities may be passive, meaning that they are either the
+ container from which information originates or to which
+ information is stored.
+
+ Active entities in the TOE that perform operations on objects are
+ referred to as subjects. Several types of subjects
+ may exist within a TOE:
+
+
+ those acting on behalf of an authorised user (e.g. UNIX
+ processes);
+
+
+ those acting as a specific functional process that may in turn
+ act on behalf of multiple users (e.g. functions as might be
+ found in client/server architectures); or
+
+
+ those acting as part of the TOE itself (e.g. processes not
+ acting on behalf of a user).
+
+
+
+ CC Part 2 addresses the enforcement of the SFRs over types of
+ subjects as those listed above.
+
+ Passive entities in the TOE that contain or receive information
+ and upon which subjects perform operations are called
+ objects. In the case where a subject (an active
+ entity) is the target of an operation (e.g. interprocess
+ communication), a subject may also be acted on as an object.
+
+ Objects can contain information. This concept is
+ required to specify information flow control policies as addressed
+ in the FDP class.
+
+ Users, subjects, information, objects, sessions and resources
+ controlled by rules in the SFRs may possess certain
+ attributes that contain information that is used by
+ the TOE for its correct operation. Some attributes, such as file
+ names, may be intended to be informational or may be used to
+ identify individual resources while others, such as access control
+ information, may exist specifically for the enforcement of the
+ SFRs. These latter attributes are generally referred to as
+ ``security attributes''. The word attribute will be
+ used as a shorthand in some places of this part of the CC for the
+ word ``security attribute''. However, no matter what the intended
+ purpose of the attribute information, it may be necessary to have
+ controls on attributes as dictated by the SFRs.
+
+ Data in a TOE is categorised as either user data or TSF
+ data. Figure depicts this
+ relationship. User Data is information stored in TOE
+ resources that can be operated upon by users in accordance with
+ the SFRs and upon which the TSF places no special meaning. For
+ example, the content of an electronic mail message is user
+ data. TSF Data is information used by the TSF in making decisions
+ as required by the SFRs. TSF Data may be influenced
+ by users if allowed by the SFRs. Security attributes,
+ authentication data, TSF internal status variables used by the
+ rules defined in the SFRs or used for the protection of the TSF
+ and access control list entries are examples of TSF data.
+
+ There are several SFPs that apply to data protection such as
+ access control SFPs and information flow
+ control SFPs. The mechanisms that implement access control
+ SFPs base their policy decisions on attributes of the users,
+ resources, subjects, objects, sessions, TSF status data and
+ operations within the scope of control. These attributes are used
+ in the set of rules that govern operations that subjects may
+ perform on objects.
+
+ The mechanisms that implement information flow control SFPs base
+ their policy decisions on the attributes of the subjects and
+ information within the scope of control and the set of rules that
+ govern the operations by subjects on information. The attributes
+ of the information, which may be associated with the attributes of
+ the container or may be derived from the data in the container,
+ stay with the information as it is processed by the TSF.
+
+
+ Two specific types of TSF data addressed by CC Part 2 can be, but
+ are not necessarily, the same. These are authentication
+ data and secrets.
+
+ Authentication data is used to verify the claimed identity of a
+ user requesting services from a TOE. The most common form of
+ authentication data is the password, which depends on being kept
+ secret in order to be an effective security mechanism. However,
+ not all forms of authentication data need to be kept
+ secret. Biometric authentication devices (e.g. fingerprint
+ readers, retinal scanners) do not rely on the fact that the data
+ is kept secret, but rather that the data is something that only
+ one user possesses and that cannot be forged.
+
+ The term secrets, as used in CC Part 2, while applicable to
+ authentication data, is intended to also be applicable to other
+ types of data that must be kept secret in order to enforce a
+ specific SFP. For example, a trusted channel mechanism that
+ relies on cryptography to preserve the confidentiality of
+ information being transmitted via the channel can only be as
+ strong as the method used to keep the cryptographic keys secret
+ from unauthorised disclosure.
+
+ Therefore, some, but not all, authentication data needs to be kept
+ secret and some, but not all, secrets are used as authentication
+ data. Figure shows this relationship
+ between secrets and authentication data. In the Figure the types
+ of data typically encountered in the authentication data and the
+ secrets sections are indicated.
+
+
+
+
+
+ This clause provides an overview of the evaluation process
+ and defines the tasks an evaluator is intended to perform when
+ conducting an evaluation.
+
+ Each evaluation, whether of a PP or TOE (including ST),
+ follows the same process, and has four evaluator tasks in
+ common: the input task, the output task, the evaluation
+ sub-activities, and the demonstration of the technical
+ competence to the evaluation authority task.
+
+ The input task and the output tasks, which are related to
+ management of evaluation evidence and to report generation,
+ are entirely described in this clause. Each task has
+ associated sub-tasks that apply to, and are normative for all
+ CC evaluations (evaluation of a PP or a TOE).
+
+ The evaluation sub-activities are only introduced in this
+ clause, and fully described in the following clauses.
+
+ In contrast to the evaluation sub-activities, input and output
+ tasks have no verdicts associated with them as they do not map
+ to CC evaluator action elements; they are performed in order
+ to ensure conformance with the universal principles and to
+ comply with the CEM.
+
+ The demonstration of the technical competence to the
+ evaluation authority task may be fulfilled by the evaluation
+ authority analysis of the output tasks results, or may include
+ the demonstration by the evaluators of their understanding of
+ the inputs for the evaluation sub-activities. This task has no
+ associated evaluator verdict, but has an evaluator authority
+ verdict. The detailed criteria to pass this task are left to
+ the discretion of the evaluation authority, as noted in Annex
+ .
+
+
+
+
+ This subclause presents the general model of the methodology
+ and identifies:
+
+
+ roles and responsibilities of the parties involved in
+ the evaluation process;
+
+
+ the general evaluation model.
+
+
+
+
+
+ The general model defines the following roles: sponsor,
+ developer, evaluator and evaluation authority.
+
+ The sponsor is responsible for requesting and supporting an
+ evaluation. This means that the sponsor establishes the
+ different agreements for the evaluation (e.g. commissioning
+ the evaluation). Moreover, the sponsor is responsible for
+ ensuring that the evaluator is provided with the evaluation
+ evidence.
+
+ The developer produces the TOE and is responsible for
+ providing the evidence required for the evaluation
+ (e.g. training, design information), on behalf of the
+ sponsor.
+
+ The evaluator performs the evaluation tasks required in the
+ context of an evaluation: the evaluator receives the
+ evaluation evidence from the developer on behalf of the
+ sponsor or directly from the sponsor, performs the
+ evaluation sub-activities and provides the results of the
+ evaluation assessment to the evaluation authority.
+
+ The evaluation authority establishes and maintains the
+ scheme, monitors the evaluation conducted by the evaluator,
+ and issues certification/validation reports as well as
+ certificates based on the evaluation results provided by the
+ evaluator.
+
+
+
+ To prevent undue influence from improperly affecting an
+ evaluation, some separation of roles is required. This
+ implies that the roles described above are fulfilled by
+ different entities, except that the roles of developer and
+ sponsor may be satisfied by a single entity.
+
+ Moreover, some evaluations (e.g. EAL1 evaluation) may not
+ require the developer to be involved in the project. In this
+ case, it is the sponsor who provides the TOE to the
+ evaluator and who generates the evaluation evidence.
+
+
+
+ The evaluation process consists of the evaluator performing
+ the evaluation input task, the evaluation output task and
+ the evaluation sub-activities. Figure provides an overview of
+ the relationship between these tasks and
+ sub-activities.
+
+
+ The evaluation process may be preceded by a preparation
+ phase where initial contact is made between the sponsor and
+ the evaluator. The work that is performed and the
+ involvement of the different roles during this phase may
+ vary. It is typically during this step that the evaluator
+ performs a feasibility analysis to assess the likelihood of
+ a successful evaluation.
+
+
+
+ The evaluator assigns verdicts to the requirements of the CC
+ and not to those of the CEM. The most granular CC structure
+ to which a verdict is assigned is the evaluator action
+ element (explicit or implied). A verdict is assigned to an
+ applicable CC evaluator action element as a result of
+ performing the corresponding CEM action and its constituent
+ work units. Finally, an evaluation result is assigned, as
+ described in CC Part 1, Clause .
+
+
+ The CEM recognises three mutually exclusive verdict states:
+
+
+ Conditions for a pass verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST or TOE under evaluation are met. The
+ conditions for passing the element are defined as:
+
+
+ the constituent work units of the related CEM
+ action, and;
+
+
+ all evaluation evidence required for performing
+ these work units is coherent, that is it can be
+ fully and completely understood by the evaluator,
+ and
+
+
+ all evaluation evidence required for performing
+ these work units does not have any obvious internal
+ inconsistencies or inconsistencies with other
+ evaluation evidence. Note that obvious means here
+ that the evaluator discovers this inconsistency
+ while performing the work units: the evaluator
+ should not undertake a full consistency analysis
+ across the entire evaluation evidence every time a
+ work unit is performed.
+
+
+
+
+ Conditions for a fail verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST, or TOE under evaluation are not met, or
+ that the evidence is incoherent, or an obvious
+ inconsistency in the evaluation evidence has been found;
+
+
+ All verdicts are initially inconclusive
+ and remain so until either a pass or
+ fail verdict is assigned.
+
+
+
+ The overall verdict is pass if and only if
+ all the constituent verdicts are also
+ pass. In the example illustrated in Figure
+ , if the verdict for one
+ evaluator action element is fail then the
+ verdicts for the corresponding assurance component,
+ assurance class, and overall verdict are also
+ fail.
+
+
+
+
+
+ The objective of this task is to ensure that the evaluator
+ has available the correct version of the evaluation evidence
+ necessary for the evaluation and that it is adequately
+ protected. Otherwise, the technical accuracy of the
+ evaluation cannot be assured, nor can it be assured that the
+ evaluation is being conducted in a way to provide repeatable
+ and reproducible results.
+
+
+
+ The responsibility to provide all the required evaluation
+ evidence lies with the sponsor. However, most of the
+ evaluation evidence is likely to be produced and supplied by
+ the developer, on behalf of the sponsor.
+
+ Since the assurance requirements apply to the entire TOE,
+ all evaluation evidence pertaining to all parts of the TOE
+ is to be made available to the evaluator. The scope and
+ required content of such evaluation evidence is independent
+ of the level of control that the developer has over each of
+ the parts of the TOE. For example, if design is required,
+ then the requirements will
+ apply to all subsystems that are part of the TSF. In
+ addition, assurance requirements that call for procedures to
+ be in place (for example,
+ and ) will also apply to the
+ entire TOE (including any part produced by another
+ developer).
+
+ It is recommended that the evaluator, in conjunction with
+ the sponsor, produce an index to required evaluation
+ evidence. This index may be a set of references to the
+ documentation. This index should contain enough information
+ (e.g. a brief summary of each document, or at least an
+ explicit title, indication of the subclauses of interest) to
+ help the evaluator to find easily the required
+ evidence.
+
+ It is the information contained in the evaluation evidence
+ that is required, not any particular document
+ structure. Evaluation evidence for a sub-activity may be
+ provided by separate documents, or a single document may
+ satisfy several of the input requirements of a
+ sub-activity.
+
+ The evaluator requires stable and formally-issued versions
+ of evaluation evidence. However, draft evaluation evidence
+ may be provided during an evaluation, for example, to help
+ an evaluator make an early, informal assessment, but is not
+ used as the basis for verdicts. It may be helpful for the
+ evaluator to see draft versions of particular appropriate
+ evaluation evidence, such as:
+
+
+ test documentation, to allow the evaluator to make an
+ early assessment of tests and test procedures;
+
+
+ design documents, to provide the evaluator with
+ background for understanding the TOE design;
+
+
+ source code or hardware drawings, to allow the evaluator
+ to assess the application of the developer's standards.
+
+
+
+ Draft evaluation evidence is more likely to be encountered
+ where the evaluation of a TOE is performed concurrently with
+ its development. However, it may also be encountered during
+ the evaluation of an already-developed TOE where the
+ developer has had to perform additional work to address a
+ problem identified by the evaluator (e.g. to correct an
+ error in design or implementation) or to provide evaluation
+ evidence of security that is not provided in the existing
+ documentation (e.g. in the case of a TOE not originally
+ developed to meet the requirements of the CC).
+
+
+
+
+ The evaluator shall perform configuration control of the
+ evaluation evidence.
+
+ The CC implies that the evaluator is able to identify and
+ locate each item of evaluation evidence after it has been
+ received and is able to determine whether a specific
+ version of a document is in the evaluator's
+ possession.
+
+ The evaluator shall protect the evaluation evidence from
+ alteration or loss while it is in the evaluator's
+ possession.
+
+
+
+ Schemes may wish to control the disposal of evaluation
+ evidence at the conclusion of an evaluation. The disposal
+ of the evaluation evidence should be achieved by one or
+ more of:
+
+
+ returning the evaluation evidence;
+
+
+ archiving the evaluation evidence;
+
+
+ destroying the evaluation evidence.
+
+
+
+
+
+ An evaluator may have access to sponsor and developer
+ commercially-sensitive information (e.g. TOE design
+ information, specialist tools), and may have access to
+ nationally-sensitive information during the course of an
+ evaluation. Schemes may wish to impose requirements for
+ the evaluator to maintain the confidentiality of the
+ evaluation evidence. The sponsor and evaluator may
+ mutually agree to additional requirements as long as these
+ are consistent with the scheme.
+
+ Confidentiality requirements affect many aspects of
+ evaluation work, including the receipt, handling, storage
+ and disposal of evaluation evidence.
+
+
+
+
+
+ The evaluation sub-activities vary depending whether it is a
+ PP or a TOE evaluation. Moreover, in the case of a TOE
+ evaluation, the sub-activities depend upon the selected
+ assurance requirements.
+
+
+
+
+ The objective of this Subclause is to describe the Observation
+ Report (OR) and the Evaluation Technical Report
+ (ETR). Schemes may require additional evaluator reports such
+ as reports on individual units of work, or may require
+ additional information to be contained in the OR and the
+ ETR. The CEM does not preclude the addition of information
+ into these reports as the CEM specifies only the minimum
+ information content.
+
+ Consistent reporting of evaluation results facilitates the
+ achievement of the universal principle of repeatability and
+ reproducibility of results. The consistency covers the type and
+ the amount of information reported in the ETR and OR. ETR and OR
+ consistency among different evaluations is the responsibility of
+ the evaluation authority.
+
+ The evaluator performs the two following sub-tasks in order
+ to achieve the CEM requirements for the information content
+ of reports:
+
+
+ write OR sub-task (if needed in the context of the
+ evaluation);
+
+
+ write ETR sub-task.
+
+
+
+
+
+ The evaluator delivers the ETR to the evaluation authority,
+ as well as any ORs as they become available. Requirements
+ for controls on handling the ETR and ORs are established by
+ the scheme which may include delivery to the sponsor or
+ developer. The ETR and ORs may include sensitive or
+ proprietary information and may need to be sanitised before
+ they are given to the sponsor.
+
+
+
+ In this version of the CEM, the requirements for the
+ provision of evaluator evidence to support re-evaluation and
+ re-use have not been explicitly stated. Where information
+ for re-evaluation or re-use is required by the sponsor, the
+ scheme under which the evaluation is being performed should
+ be consulted.
+
+
+
+ ORs provide the evaluator with a mechanism to request a
+ clarification (e.g. from the evaluation authority on the application of a
+ requirement) or to identify a problem with an aspect of the
+ evaluation.
+
+ In the case of a fail verdict, the evaluator shall provide
+ an OR to reflect the evaluation result. Otherwise, the
+ evaluator may use ORs as one way of expressing clarification
+ needs.
+
+ For each OR, the evaluator shall report the following:
+
+
+ the identifier of the PP or TOE evaluated;
+
+
+ the evaluation task/sub-activity during which the
+ observation was generated;
+
+
+ the observation;
+
+
+ the assessment of its severity (e.g. implies a fail
+ verdict, holds up progress on the evaluation, requires a
+ resolution prior to evaluation being completed);
+
+
+ the identification of the organisation responsible for
+ resolving the issue;
+
+
+ the recommended timetable for resolution;
+
+
+ the assessment of the impact on the evaluation of
+ failure to resolve the observation.
+
+
+
+ The intended audience of an OR and procedures for handling the
+ report depend on the nature of the report's content and on the
+ scheme. Schemes may distinguish different types of ORs or define
+ additional types, with associated differences in required
+ information and distribution (e.g. evaluation ORs to evaluation authorities
+ and sponsors).
+
+
+
+
+ The evaluator shall provide an ETR to present technical
+ justification of the verdicts.
+
+ The CEM defines the ETR's minimum content requirement;
+ however, schemes may specify additional content and
+ specific presentational and structural requirements. For
+ instance, schemes may require that certain introductory
+ material (e.g. disclaimers and copyright Clauses) be
+ reported in the ETR.
+
+ The reader of the ETR is assumed to be familiar with
+ general concepts of information security, the CC, the CEM,
+ evaluation approaches and IT.
+
+ The ETR supports the evaluation authority to confirm that
+ the evaluation was done to the required standard, but it
+ is anticipated that the documented results may not provide
+ all of the necessary information, so additional
+ information specifically requested by the scheme may be
+ necessary. This aspect is outside the scope of the
+ CEM.
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a PP evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report PP configuration control
+ identifiers.
+
+ PP configuration control identifiers (e.g. name, date and
+ version number) are required to identify what is being evaluated
+ in order for the evaluation authority to verify that the verdicts have been
+ assigned correctly by the evaluator.
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the PP developer is required to identify
+ the party responsible for producing the PP.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator references the evaluation criteria,
+ methodology and interpretations used to evaluate the
+ PP.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the handling of evaluation
+ results and assumptions made during the evaluation that
+ have an impact on the evaluation results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ The evaluator shall report a verdict and a supporting
+ rationale for each assurance component that constitutes
+ an activity, as a result of
+ performing the corresponding CEM action and its
+ constituent work units.
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, in particular the overall verdict as defined
+ in CC Part 1 Clause , and determined by application
+ of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be useful for
+ the evaluation authority. These recommendations may include shortcomings of
+ the PP discovered during the evaluation or mention of features
+ which are particularly useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a TOE evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report ST and TOE configuration
+ control identifiers.
+
+ ST and TOE configuration control identifiers identify
+ what is being evaluated in order for the evaluation authority to
+ verify that the verdicts have been assigned correctly by
+ the evaluator.
+
+ If the ST claims that the TOE conforms to the
+ requirements of one or more PPs, the ETR shall report
+ the reference of the corresponding PPs.
+
+ The PPs reference contains information that uniquely
+ identifies the PPs (e.g. title, date, and version
+ number).
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the TOE developer is required to
+ identify the party responsible for producing the
+ TOE.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report a high level description of
+ the TOE and its major components based on the evaluation
+ evidence described in the CC assurance family entitled
+ , where
+ applicable.
+
+ The intent of this Subclause is to characterise the degree
+ of architectural separation of the major components. If
+ there is no requirement
+ in the ST, this is not applicable and is considered to
+ be satisfied.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator may reference the evaluation criteria,
+ methodology and interpretations used to evaluate the TOE
+ or the devices used to perform the tests.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the distribution of
+ evaluation results and assumptions made during the
+ evaluation that have an impact on the evaluation
+ results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ For each activity on which the TOE is evaluated, the
+ evaluator shall report:
+
+
+ the title of the activity considered;
+
+
+ a verdict and a supporting rationale for each
+ assurance component that constitutes this activity,
+ as a result of performing the corresponding CEM
+ action and its constituent work units.
+
+
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+ The evaluator shall report all information specifically
+ required by a work unit.
+
+ For the and activities, work units that identify
+ information to be reported in the ETR have been
+ defined.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, which will relate to whether the TOE has
+ satisfied its associated ST, in particular the overall
+ verdict as defined in CC Part 1 Clause , and determined by
+ application of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be useful for
+ the evaluation authority. These recommendations may include shortcomings of
+ the IT product discovered during the evaluation or mention of
+ features which are particularly useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+
+
+ The CC permits comparability between the results of independent
+ security evaluations. The CC does so by providing a common set
+ of requirements for the security functionality of IT products
+ and for assurance measures applied to these IT products during a
+ security evaluation. These IT products may be implemented in
+ hardware, firmware or software.
+ The evaluation process establishes a level of confidence that
+ the security functionality of these IT products and the
+ assurance measures applied to these IT products meet these
+ requirements. The evaluation results may help consumers to
+ determine whether these IT products fulfil their security needs.
+ The CC is useful as a guide for the development, evaluation
+ and/or procurement of IT products with security functionality.
+ The CC is intentionally flexible, enabling a range of evaluation
+ methods to be applied to a range of security properties of a
+ range of IT products. Therefore users of the standard are
+ cautioned to exercise care that this flexibility is not
+ misused. For example, using the CC in conjunction with
+ unsuitable evaluation methods, irrelevant security properties,
+ or inappropriate IT products, may result in meaningless
+ evaluation results.
+ Consequently, the fact that an IT product has been evaluated has
+ meaning only in the context of the security properties that were
+ evaluated and the evaluation methods that were used. Evaluation
+ authorities are advised to carefully check the products,
+ properties and methods to determine that an evaluation will
+ provide meaningful results. Additionally, purchasers of
+ evaluated products are advised to carefully consider this
+ context to determine whether the evaluated product is useful and
+ applicable to their specific situation and needs.
+ The CC addresses protection of assets from unauthorised
+ disclosure, modification, or loss of use. The categories of
+ protection relating to these three types of failure of security
+ are commonly called confidentiality, integrity, and
+ availability, respectively. The CC may also be applicable
+ to aspects of IT security outside of these three. The CC
+ is applicable to risks arising from human activities (malicious
+ or otherwise) and to risks arising from non-human
+ activities. Apart from IT security, the CC may be applied
+ in other areas of IT, but makes no claim of applicability in
+ these areas.
+ Certain topics, because they involve specialised techniques or
+ because they are somewhat peripheral to IT security, are
+ considered to be outside the scope of the CC. Some of these are
+ identified below.
+
+ The CC does not contain security evaluation criteria
+ pertaining to administrative security measures not related
+ directly to the IT security functionality. However, it is
+ recognised that significant security can often be achieved
+ through or supported by administrative measures such as
+ organisational, personnel, physical, and procedural
+ controls.
+
+ The evaluation of some technical physical aspects of IT
+ security such as electromagnetic emanation control is not
+ specifically covered, although many of the concepts
+ addressed will be applicable to that area.
+
+ The CC does not address the evaluation methodology
+ under which the criteria should be applied. This methodology
+ is given in the CEM.
+
+ The CC does not address the administrative and legal
+ framework under which the criteria may be applied by
+ evaluation authorities. However, it is expected that the CC
+ will be used for evaluation purposes in the context of such
+ a framework.
+
+ The procedures for use of evaluation results in
+ accreditation are outside the scope of the CC. Accreditation
+ is the administrative process whereby authority is granted
+ for the operation of an IT product (or collection thereof)
+ in its full operational environment including all of its
+ non-IT parts. The results of the evaluation process are an
+ input to the accreditation process. However, as other
+ techniques are more appropriate for the assessments of
+ non-IT related properties and their relationship to the IT
+ security parts, accreditors should make separate provisions
+ for those aspects.
+
+ The subject of criteria for the assessment of the inherent
+ qualities of cryptographic algorithms is not covered in the
+ CC. Should independent assessment of mathematical properties
+ of cryptography be required, the evaluation scheme under
+ which the CC is applied must make provision for such
+ assessments.
+
+ ISO terminology, such as "can", "informative", "may",
+ "normative", "shall" and "should" used throughout the document
+ are defined in the ISO/IEC Directives, Part 2. Note that the
+ term "should" has an additional meaning applicable when using
+ this standard. See the note below. The following definition is
+ given for the use of ``should'' in the CC.
+ should
+
+ within normative text, ``should'' indicates ``that among
+ several possibilities one is recommended as particularly
+ suitable, without mentioning or excluding others, or that a
+ certain course of action is preferred but not necessarily
+ required.'' (ISO/IEC Directives, Part 2).
+
+ The CC interprets ``not necessarily required'' to mean
+ that the choice of another possibility requires a justification
+ of why the preferred option was not chosen.
+
+ This part of the CC establishes the general concepts and
+ principles of IT security evaluation and specifies the general
+ model of evaluation given by various parts of the standard which
+ in its entirety is meant to be used as the basis for evaluation
+ of security properties of IT products.
+ Part one provides an overview of all parts of the CC
+ standard. It describes the various parts of the standard;
+ defines the terms and abbreviations to be used in all parts of
+ the standard; establishes the core concept of a Target of
+ Evaluation (TOE); the evaluation context and describes the
+ audience to which the evaluation criteria are addressed. An
+ introduction to the basic security concepts necessary for
+ evaluation of IT products is given.
+ It defines the various operations by which the functional and
+ assurance components given in CC Part 2 and CC Part 3 may be
+ tailored through the use of permitted operations.
+ The key concepts of protection profiles (PP), packages of
+ security requirements and the topic of conformance are specified
+ and the consequences of evaluation, evaluation results are
+ described. This part of the CC gives guidelines for the
+ specification of Security Targets (ST) and provides a
+ description of the organization of components throughout the
+ model. General information about the evaluation methodology are
+ given in the CEM and the scope of evaluation schemes is
+ provided.
+ The following referenced documents are indispensable for the
+ application of this CC part 1. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.CC-2
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 2: Functional security components.
+ CC-3
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 3: Assurance security components.
+ CEM
+ Common Methodology for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+ For the purpose of the CC, the following terms and definitions
+ apply.
+ This Clause contains only
+ those terms which are used in a specialised way throughout the
+ CC. Some combinations of common terms used in the CC, while not
+ meriting inclusion in this Clause , are explained for clarity in the context
+ where they are used.
+ adverse actions
+
+ actions performed by a threat agent on an asset
+
+ assets
+
+ entities that the owner of the TOE presumably places value upon
+
+ assignment
+
+ the specification of an identified parameter in a component
+ (of the CC) or requirement
+
+ assurance
+
+ grounds for confidence that a TOE meets the SFRs
+
+ attack potential
+
+ measure of the effort to be expended in attacking a TOE,
+ expressed in terms of an attacker's expertise, resources and
+ motivation
+
+ augmentation
+
+ addition of one or more requirement(s) to a package
+
+ authentication data
+
+ information used to verify the claimed identity of a user
+
+ authorised user
+
+ TOE user who may, in accordance with the SFRs, perform an operation
+
+ class
+
+ set of CC families that share a common focus
+
+ coherent
+
+ logically ordered and having discernible meaning
+
+ For documentation, this addresses both the actual text and
+ the structure of the document, in terms of whether it is
+ understandable by its target audience.
+
+ complete
+
+ property where all necessary parts of an entity have been provided
+
+ In terms of documentation, this means that all relevant
+ information is covered in the documentation, at such a level
+ of detail that no further explanation is required at that
+ level of abstraction.
+
+ component
+
+ smallest selectable set of elements on which requirements
+ may be based
+
+ composed assurance package
+
+ assurance package consisting of requirements drawn from
+ CC Part 3 (predominately from the class), representing a point on the CC
+ predefined composition assurance scale
+
+ confirm
+
+ declare that something has been reviewed in detail with an
+ independent determination of sufficiency
+
+ The level of rigour required depends on the nature of the subject
+ matter. This term is only applied to evaluator actions.
+
+ connectivity
+
+ property of the TOE allowing interaction with IT entities
+ external to the TOE
+
+ This includes exchange of data by wire or by wireless means,
+ over any distance in any environment or configuration.
+
+ consistent
+
+ relationship between two or more entities such that there
+ are no apparent contradictions between these entities
+
+ counter, verb
+
+ meet an attack where the impact of a particular threat is
+ mitigated but not necessarily eradicated
+
+ demonstrable conformance
+
+ relation between an ST and a PP, where the ST provides a
+ solution which solves the generic security problem in the PP
+
+ The PP and the ST may contain entirely different statements
+ that discuss different entities, use different concepts
+ etc. Demonstrable conformance is also suitable for a TOE
+ type where several similar PPs already exist, thus allowing
+ the ST author to claim conformance to these PPs
+ simultaneously, thereby saving work.
+
+ demonstrate
+
+ provide a conclusion gained by an analysis which is less
+ rigorous than a ``proof''
+
+ dependency
+
+ relationship between components such that if a requirement
+ based on the depending component is included in a PP, ST or
+ package, a requirement based on the component that is
+ depended upon must normally also be included in the PP, ST
+ or package
+
+ describe
+
+ provide specific details of an entity
+
+ determine
+
+ affirm a particular conclusion based on independent analysis
+ with the objective of reaching a particular conclusion
+
+ The usage of this term implies a truly independent analysis,
+ usually in the absence of any previous analysis having been
+ performed. Compare with the terms ``confirm'' or
+ ``verify'' which imply that an analysis has already been
+ performed which needs to be reviewed
+
+ development environment
+
+ environment in which the TOE is developed
+
+ element
+
+ indivisible statement of a security need
+
+ ensure
+
+ guarantee a strong causal relationship between an action and
+ its consequences
+
+ When this term is preceded by the word ``help'' it indicates
+ that the consequence is not fully certain, on the basis of
+ that action alone.
+
+ evaluation
+
+ assessment of a PP, an ST or a TOE, against defined criteria
+
+ evaluation assurance level
+
+ set of assurance requirements drawn from CC Part 3,
+ representing a point on the CC predefined assurance scale,
+ that form an assurance package
+
+ evaluation authority
+
+ body that sets the standards and monitors the quality of
+ evaluations conducted by bodies within a specific community
+ and implements the CC for that community by means of an
+ evaluation scheme
+
+ evaluation scheme
+
+ administrative and regulatory framework under which the CC
+ is applied by an evaluation authority within a specific
+ community
+
+ exhaustive
+
+ characteristic of a methodical approach taken to perform an
+ analysis or activity according to an unambiguous plan
+
+ This term is used in the CC with respect to conducting an
+ analysis or other activity. It is related to ``systematic''
+ but is considerably stronger, in that it indicates not only
+ that a methodical approach has been taken to perform the
+ analysis or activity according to an unambiguous plan, but
+ that the plan that was followed is sufficient to ensure that
+ all possible avenues have been exercised.
+
+ explain
+
+ give argument accounting for the reason for taking a course
+ of action
+
+ This term differs from both ``describe'' and
+ ``demonstrate''. It is intended to answer the question
+ ``Why?'' without actually attempting to argue that the
+ course of action that was taken was necessarily optimal.
+
+ extension
+
+ addition to an ST or PP of functional requirements not
+ contained in CC Part 2 and/or assurance requirements not
+ contained in CC Part 3
+
+ external entity
+
+ human or IT entity possibly interacting with the TOE from
+ outside of the TOE boundary
+
+ family
+
+ set of components that share a similar goal but differ in
+ emphasis or rigour
+
+ formal
+
+ expressed in a restricted syntax language with defined
+ semantics based on well-established mathematical concepts
+
+ guidance documentation
+
+ documentation that describes the delivery, preparation,
+ operation, management and/or use of the TOE
+
+ identity
+
+ representation uniquely identifying entities (e.g. a user, a
+ process or a disk) within the context of the TOE
+
+ An example of such a representation is a string. For a human
+ user, the representation can be the full or abbreviated name
+ or a (still unique) pseudonym.
+
+ informal
+
+ expressed in natural language
+
+ inter TSF transfers
+
+ communicating data between the TOE and the security
+ functionality of other trusted IT products
+
+ internal communication channel
+
+ communication channel between separated parts of the TOE
+
+ internal TOE transfer
+
+ communicating data between separated parts of the TOE
+
+ internally consistent
+
+ no apparent contradictions exist between any aspects of an
+ entity
+
+ In terms of documentation, this means that there can be no
+ statements within the documentation that can be taken to
+ contradict each other.
+
+ iteration
+
+ use of the same component to express two or more distinct
+ requirements
+
+ justification
+
+ analysis leading to a conclusion
+
+ ``Justification'' is more rigorous than a
+ demonstration. This term requires significant rigour in
+ terms of very carefully and thoroughly explaining every step
+ of a logical argument.
+
+ object
+
+ passive entity in the TOE, that contains or receives
+ information, and upon which subjects perform operations
+
+ operation (on a component of the CC)
+
+ modification or repetition of a component
+
+ Allowed operations on components are assignment, iteration,
+ refinement and selection.
+
+ operation (on an object)
+
+ specific type of action performed by a subject on an object
+
+ operational environment
+
+ environment in which the TOE is operated
+
+ organisational security policy
+
+ set of security rules, procedures, or guidelines for an
+ organisation
+
+ A policy may pertain to a specific operational environment.
+
+ package
+
+ named set of either security functional or security
+ assurance requirements
+
+ An example of a package is ``EAL 3''.
+
+ Protection Profile evaluation
+
+ assessment of a PP against defined criteria
+
+ Protection Profile
+
+ implementation-independent statement of security needs for a
+ TOE type
+
+ prove
+
+ show correspondence by formal analysis in its mathematical
+ sense
+
+ It is completely rigorous in all ways. Typically, ``prove''
+ is used when there is a desire to show correspondence
+ between two TSF representations at a high level of rigour.
+
+ refinement
+
+ addition of details to a component
+
+ role
+
+ predefined set of rules establishing the allowed
+ interactions between a user and the TOE
+
+ secret
+
+ information that must be known only to authorised users
+ and/or the TSF in order to enforce a specific SFP
+
+ secure state
+
+ state in which the TSF data are consistent and the TSF
+ continues correct enforcement of the SFRs
+
+ security attribute
+
+ property of subjects, users (including external IT
+ products), objects, information, sessions and/or resources
+ that is used in defining the SFRs and whose values are used
+ in enforcing the SFRs
+
+ security function policy
+
+ set of rules describing specific security behaviour enforced
+ by the TSF and expressible as a set of SFRs
+
+ security objective
+
+ statement of an intent to counter identified threats and/or
+ satisfy identified organisation security policies and/or
+ assumptions
+
+ security problem
+
+ statement which in a formal manner defines the nature and
+ scope of the security that the TOE is intended to address
+
+ This statement consists of a combination of:
+
+ threats to be countered by the TOE,
+
+ the OSPs enforced by the TOE, and
+
+ the assumptions that are upheld for the TOE and its
+ operational environment.
+
+ security requirement
+
+ requirement, stated in a standardised language, which is
+ meant to contribute to achieving the security objectives for
+ a TOE
+
+ Security Target
+
+ implementation-dependent statement of security needs for a
+ specific identified TOE
+
+ selection
+
+ specification of one or more items from a list in a component
+
+ semiformal
+
+ expressed in a restricted syntax language with defined semantics
+
+ specify
+
+ provide specific details about an entity in a rigorous and precise manner
+
+ strict conformance
+
+ hierarchical relationship between a PP and an ST where all
+ the requirements in the PP also exist in the ST
+
+ This relation can be roughly defined as ``the ST shall
+ contain all statements that are in the PP, but may contain
+ more''. Strict conformance is expected to be used for
+ stringent requirements that are to be adhered to in a single
+ manner.
+
+ ST evaluation
+
+ assessment of an ST against defined criteria
+
+ subject
+
+ active entity in the TOE that performs operations on objects
+
+ target of evaluation
+
+ set of software, firmware and/or hardware possibly
+ accompanied by guidance
+
+ threat agent
+
+ entity that can adversely act on assets
+
+ TOE evaluation
+
+ assessment of a TOE against defined criteria
+
+ TOE resource
+
+ anything useable or consumable in the TOE
+
+ TOE security functionality
+
+ combined functionality of all hardware, software, and
+ firmware of a TOE that must be relied upon for the correct
+ enforcement of the SFRs
+
+ trace, verb
+
+ perform an informal correspondence analysis between two
+ entities with only a minimal level of rigour
+
+ transfers outside of the TOE
+
+ TSF mediated communication of data to entities not under the
+ control of the TSF
+
+ translation
+
+ describes the process of describing security requirements in
+ a standardised language.
+
+ use of the term translation in this context is not literal
+ and does not imply that every SFR expressed in standardised
+ language can also be translated back to the security
+ objectives.
+
+ trusted channel
+
+ a means by which a TSF and another trusted IT product can
+ communicate with necessary confidence
+
+ trusted IT product
+
+ IT product, other than the TOE, which has its security
+ functional requirements administratively coordinated with
+ the TOE and which is assumed to enforce its security
+ functional requirements correctly
+
+ An example of a trusted IT product would be one that has
+ been separately evaluated.
+
+ trusted path
+
+ means by which a user and a TSF can communicate with the
+ necessary confidence
+
+ TSF data
+
+ data for the operation of the TOE upon which the enforcement
+ of the SFR relies
+
+ TSF interface
+
+ means by which external entities (or subjects in the TOE but
+ outside of the TSF) supply data to the TSF, receive data
+ from the TSF and invoke services from the TSF
+
+ user
+
+ see external entity
+
+ user data
+
+ data for the user, that does not affect the operation of the TSF
+
+ verify
+
+ rigorously review in detail with an independent
+ determination of sufficiency
+
+ Also see ``confirm''. This term has more rigorous
+ connotations. The term ``verify'' is used in the context
+ of evaluator actions where an independent effort is required
+ of the evaluator.
+
+ The following terms are used in the requirements for software
+ internal structuring. Some of these are derived from the
+ IEEE Std 610.12-1990,
+ Standard glossary of software engineering terminology,
+ Institute of Electrical and Electronics Engineers.
+ administrator
+
+ entity that has a level of trust with respect to all
+ policies implemented by the TSF
+
+ Not all PPs or STs assume the same level of trust for
+ administrators. Typically administrators are assumed to
+ adhere at all times to the policies in the ST of the
+ TOE. Some of these policies may be related to the
+ functionality of the TOE, others may be related to the
+ operational environment.
+
+ call tree
+
+ identifies the modules in a system in diagrammatic form
+ showing which modules call one another
+
+ Adapted from
+ cohesion
+
+ module strength
+
+ manner and degree to which the tasks performed by a single
+ software module are related to one another
+
+ Types of cohesion include coincidental, communicational,
+ functional, logical, sequential, and temporal. These types
+ of cohesion are described by the relevant term entry.
+
+ coincidental cohesion
+
+ module with the characteristic of performing unrelated, or
+ loosely related, activities
+
+ See ``cohesion''.
+
+ communicational cohesion
+
+ module containing functions that produce output for, or use
+ output from, other functions within the module
+
+ See ``cohesion''.
+ An example of a communicationally cohesive module is an
+ access check module that includes mandatory,
+ discretionary, and capability checks.
+ complexity
+
+ measure of how difficult software is to understand, and thus
+ to analyse, test, and maintain
+
+ Reducing complexity is the ultimate goal for using modular
+ decomposition, layering and minimisation. Controlling
+ coupling and cohesion contributes significantly to this
+ goal.
+ A good deal of effort in the software engineering field
+ has been expended in attempting to develop metrics to
+ measure the complexity of source code. Most of these
+ metrics use easily computed properties of the source code,
+ such as the number of operators and operands, the
+ complexity of the control flow graph (cyclomatic
+ complexity), the number of lines of source code, the ratio
+ of comments to executable code, and similar
+ measures. Coding standards have been found to be a useful
+ tool in generating code that is more readily understood.
+ The family calls for a complexity
+ analysis in all components. It is expected that the
+ developer will provide support for the claims that there
+ has been a sufficient reduction in complexity. This
+ support could include the developer's programming
+ standards, and an indication that all modules meet the
+ standard (or that there are some exceptions that are
+ justified by software engineering arguments). It could
+ include the results of tools used to measure some of the
+ properties of the source code, or it could include other
+ support that the developer finds appropriate.
+ coupling
+
+ manner and degree of interdependence between software modules
+
+ Types of coupling include call, common and content
+ coupling. These are characterised below:
+
+ call coupling
+
+ relationship between two modules
+
+ Examples of call coupling are data, stamp, and control:
+
+ call coupling (data)
+
+ relationship between two modules communicating strictly
+ through the use of call parameters that represent single
+ data items.
+
+ See ``call coupling''
+
+ call coupling (stamp)
+
+ relationship between two modules through the use of call
+ parameters that comprise multiple fields or that have
+ meaningful internal structures.
+
+ See ``call coupling''
+
+ call coupling (control)
+
+ relationship between two modules if one passes information
+ that is intended to influence the internal logic of the
+ other.
+
+ See ``call coupling''
+
+ common coupling
+
+ relationship between two modules sharing a common data area
+ or other common system resource
+
+ Global variables indicate that modules using those global
+ variables are common coupled. Common coupling through global
+ variables is generally allowed, but only to a limited
+ degree.
+ For example, variables that are placed into a global area,
+ but are used by only a single module, are inappropriately
+ placed, and should be removed. Other factors that need to
+ be considered in assessing the suitability of global
+ variables are:
+
+ The number of modules that modify a global variable:
+ In general, only a single module should be allocated
+ the responsibility for controlling the contents of a
+ global variable, but there may be situations in which
+ a second module may share that responsibility; in such
+ a case, sufficient justification must be provided. It
+ is unacceptable for this responsibility to be shared
+ by more than two modules. (In making this assessment,
+ care should be given to determining the module
+ actually responsible for the contents of the variable;
+ for example, if a single routine is used to modify the
+ variable, but that routine simply performs the
+ modification requested by its caller, it is the
+ calling module that is responsible, and there may be
+ more than one such module). Further, as part of the
+ complexity determination, if two modules are
+ responsible for the contents of a global variable,
+ there should be clear indications of how the
+ modifications are coordinated between them.
+
+ The number of modules that reference a global
+ variable: Although there is generally no limit on the
+ number of modules that reference a global variable,
+ cases in which many modules make such a reference
+ should be examined for validity and necessity.
+
+ content coupling
+
+ relationship between two modules where one makes direct
+ reference to the internals of the other
+
+ Examples include modifying code of, or referencing labels
+ internal to, the other module. The result is that some or
+ all of the content of one module are effectively included in
+ the other. Content coupling can be thought of as using
+ unadvertised module interfaces; this is in contrast to call
+ coupling, which uses only advertised module interfaces.
+
+ domain separation
+
+ security architecture property whereby the TSF defines
+ separate security domains for each user and for the TSF and
+ ensures that no user process can affect the contents of a
+ security domain of another user or of the TSF
+
+ functional cohesion
+
+ functional property of a module which performs activities
+ related to a single purpose
+
+ A functionally cohesive module transforms a single type of
+ input into a single type of output, such as a stack manager or
+ a queue manager. See also ``cohesion''.
+
+ interaction
+
+ general communication-based activity between entities
+
+ interface
+
+ means of interaction with a component or module
+
+ layering
+
+ design technique where separate groups of modules (the
+ layers) are hierarchically organised to have separate
+ responsibilities such that one layer depends only on layers
+ below it in the hierarchy for services, and provides its
+ services only to the layers above it
+
+ Strict layering adds the constraint that each layer receives
+ services only from the layer immediately beneath it, and
+ provides services only to the layer immediately above it.
+
+ logical cohesion
+
+ procedural cohesion
+
+ characteristics of a module performing similar activities on
+ different data structures
+
+ A module exhibits logical cohesion if its functions perform
+ related, but different, operations on different inputs. See
+ also ``cohesion''.
+
+ modular decomposition
+
+ process of breaking a system into components to facilitate
+ design, development and evaluation
+
+ non-bypassability (of the TSF)
+
+ security architecture property whereby all SFR-related
+ actions are mediated by the TSF
+
+ procedural cohesion
+
+ See ``logical cohesion''
+
+ security domain
+
+ collection of resources to which an active entity has access
+ privileges
+
+ sequential cohesion
+
+ module containing functions each of whose output is input
+ for the following function in the module
+
+ An example of a sequentially cohesive module is one that
+ contains the functions to write audit records and to
+ maintain a running count of the accumulated number of audit
+ violations of a specified type.
+
+ software engineering
+
+ application of a systematic, disciplined, quantifiable
+ approach to the development and maintenance of software;
+ that is, the application of engineering to software
+
+ As with engineering practices in general, some amount of
+ judgement must be used in applying engineering
+ principles. Many factors affect choices, not just the
+ application of measures of modular decomposition, layering,
+ and minimisation. For example, a developer may design a
+ system with future applications in mind that will not be
+ implemented initially. The developer may choose to include
+ some logic to handle these future applications without fully
+ implementing them; further, the developer may include some
+ calls to as-yet unimplemented modules, leaving call
+ stubs. The developer's justification for such deviations
+ from well-structured programs will have to be assessed using
+ judgement, as well as the application of good software
+ engineering discipline.
+
+ temporal cohesion
+
+ characteristics of a module containing functions that need
+ to be executed at about the same time
+
+ Adapted from . Examples of temporally
+ cohesive modules include initialisation, recovery, and
+ shutdown modules.
+
+ TSF self-protection
+
+ security architecture property whereby the TSF cannot be
+ corrupted by non-TSF code or entities
+
+ installation
+
+ procedure performed by a human user embedding the TOE in its
+ operational environment and putting it into an operational
+ state
+
+ This operation is performed normally only once, after
+ receipt and acceptance of the TOE. The TOE is expected to be
+ progressed to a configuration allowed by the ST. If similar
+ processes have to be performed by the developer they are
+ denoted as ``generation'' throughout . If
+ the TOE requires an initial start-up that does not need to
+ be repeated regularly, this process would be classified as
+ installation.
+
+ operation
+
+ usage phase of the TOE including ``normal usage'',
+ administration and maintenance of the TOE after delivery and
+ preparation
+
+ preparation
+
+ activity in the life-cycle phase of a product, comprising
+ the customer's acceptance of the delivered TOE and its
+ installation which may include such things as booting,
+ initialisation, start-up and progressing the TOE to a state
+ ready for operation
+
+ acceptance criteria
+
+ criteria to be applied when performing the acceptance
+ procedures (e.g. successful document review, or successful
+ testing in the case of software, firmware or hardware)
+
+ acceptance procedures
+
+ procedures followed in order to accept newly created or
+ modified configuration items as part of the TOE, or to move
+ them to the next step of the life-cycle
+
+ These procedures identify the roles or individuals
+ responsible for the acceptance and the criteria to be
+ applied in order to decide on the acceptance.
+ There are several types of acceptance situations some of
+ which may overlap:
+
+ acceptance of an item into the configuration
+ management system for the first time, in particular
+ inclusion of software, firmware and hardware
+ components from other manufacturers into the TOE
+ (``integration'');
+
+ progression of configuration items to the next
+ life-cycle phase at each stage of the construction of
+ the TOE (e.g. module, subsystem, quality control of
+ the finished TOE);
+
+ subsequent to transports of configuration items (for
+ example parts of the TOE or preliminary products)
+ between different development sites;
+
+ subsequent to the delivery of the TOE to the consumer.
+
+ configuration management
+
+ discipline applying technical and administrative direction
+ and surveillance to: identify and document the functional
+ and physical characteristics of a configuration item,
+ control changes to those characteristics, record and report
+ change processing and implementation status, and verify
+ compliance with specified requirements.
+
+ CM documentation
+
+ all CM documentation including CM output, CM list
+ (configuration list), CM system records, CM plan and CM
+ usage documentation
+
+ configuration management evidence
+
+ everything that may be used to establish confidence in the
+ correct operation of the CM system
+
+ For example, CM output, rationales provided by the
+ developer, observations, experiments or interviews made by
+ the evaluator during a site visit.
+
+ configuration item
+
+ object managed by the CM system during the TOE development
+
+ These may be either parts of the TOE or objects related to
+ the development of the TOE like evaluation documents or
+ development tools. CM items may be stored in the CM system
+ directly (for example files) or by reference (for example
+ hardware parts) together with their version.
+
+ configuration list
+
+ configuration management output document listing all
+ configuration items for a specific product together with the
+ exact version of each configuration management item relevant
+ for a specific version of the complete product
+
+ This list allows distinguishing the items belonging to the
+ evaluated version of the product from other versions of
+ these items belonging to other versions of the product. The
+ final configuration management list is a specific document
+ for a specific version of a specific product. (Of course the
+ list can be an electronic document inside of a configuration
+ management tool. In that case it can be seen as a specific
+ view into the system or a part of the system rather than an
+ output of the system. However, for the practical use in an
+ evaluation the configuration list will probably be delivered
+ as a part of the evaluation documentation.) The
+ configuration list defines the items that are under the
+ configuration management requirements of .
+
+ configuration management output
+
+ results, related to configuration management, produced or
+ enforced by the configuration management system
+
+ These configuration management related results could occur
+ as documents (for example filled paper forms, configuration
+ management system records, logging data, hard-copies and
+ electronic output data) as well as actions (for example
+ manual measures to fulfil configuration management
+ instructions). Examples of such configuration management
+ outputs are configuration lists, configuration management
+ plans and/or behaviours during the product life-cycle.
+
+ configuration management plan
+
+ description of how the configuration management system is
+ used for the TOE
+
+ The objective of issuing a configuration management plan is
+ that staff members can see clearly what they have to
+ do. From the point of view of the overall configuration
+ management system this can be seen as an output document
+ (because it may be produced as part of the application of
+ the configuration management system). From the point of view
+ of the concrete project it is a usage document because
+ members of the project team use it in order to understand
+ the steps that they have to perform during the project. The
+ configuration management plan defines the usage of the
+ system for the specific product; the same system may be used
+ to a different extent for other products. That means the
+ configuration management plan defines and describes the
+ output of the configuration management system of a company
+ which is used during the TOE development.
+
+ configuration management system
+
+ set of procedures and tools (including their documentation)
+ used by a developer to develop and maintain configurations
+ of his products during their life-cycles
+
+ Configuration management systems may have varying degrees of
+ rigour and function. At higher levels, configuration
+ management systems may be automated, with flaw remediation,
+ change controls, and other tracking mechanisms.
+
+ configuration management system records
+
+ output produced during the operation of the configuration
+ management system documenting important configuration
+ management activities
+
+ Examples of configuration management system records are
+ configuration management item change control forms or
+ configuration management item access approval forms.
+
+ configuration management tools
+
+ manually operated or automated tools realising or supporting
+ a configuration management system
+
+ For example tools for the version management of the parts of
+ the TOE.
+
+ configuration management usage documentation
+
+ part of the configuration management system, which
+ describes, how the configuration management system is
+ defined and applied by using for example handbooks,
+ regulations and/or documentation of tools and procedures
+
+ delivery
+
+ transmission of the finished TOE from the production
+ environment into the hands of the customer
+
+ This product life-cycle phase may include packaging and
+ storage at the development site, but does not include
+ transportations of the unfinished TOE or parts of the TOE
+ between different developers or different development
+ sites.
+
+ developer
+
+ organisation responsible for the development of the TOE
+
+ development
+
+ product life-cycle phase which is concerned with generating
+ the implementation representation of the TOE
+
+ Throughout the requirements, development
+ and related terms (developer, develop) are meant in the more
+ general sense to comprise development and production.
+
+ development tools
+
+ tools (including test software, if applicable) supporting
+ the development and production of the TOE
+
+ For example for a software TOE, development tools are
+ usually programming languages, compilers, linkers and
+ generating tools.
+
+ implementation representation
+
+ least abstract representation of the TSF, specifically the
+ one that is used to create the TSF itself without further
+ design refinement
+
+ Source code that is then compiled or a hardware drawing that
+ is used to build the actual hardware are examples of parts
+ of an implementation representation.
+
+ life-cycle
+
+ sequence of stages of existence of an object (for example a
+ product or a system) in time
+
+ life-cycle definition
+
+ definition of the life-cycle model
+
+ life cycle model
+
+ description of the stages and their relations to each other
+ that are used in the management of the life-cycle of a
+ certain object, how the sequence of stages looks like and
+ which high level characteristics the stages have
+
+ production
+
+ production life-cycle phase follows the development phase
+ and consists of transforming the implementation
+ representation into the implementation of the TOE, i.e. into
+ a state acceptable for delivery to the customer
+
+ This phase may comprise manufacturing, integration,
+ generation, internal transports, storage, and labelling of
+ the TOE.
+
+ covert channel
+
+ enforced, illicit signalling channel that allows a user to
+ surreptitiously contravene the multi-level separation policy
+ and unobservability requirements of the TOE
+
+ encountered potential vulnerabilities
+
+ potential weakness in the TOE identified by the evaluator
+ while performing evaluation activities that could be used to
+ violate the SFRs
+
+ exploitable vulnerability
+
+ weakness in the TOE that can be used to violate the SFRs in
+ the operational environment for the TOE
+
+ monitoring attacks
+
+ generic category of attack methods that includes passive
+ analysis techniques aiming at disclosure of sensitive
+ internal data of the TOE by operating the TOE in the way
+ that corresponds to the guidance documents
+
+ potential vulnerability
+
+ suspected, but not confirmed, weakness
+
+ Suspicion is by virtue of a postulated attack path to
+ violate the SFRs.
+
+ residual vulnerability
+
+ weakness that cannot be exploited in the operational
+ environment for the TOE, but that could be used to violate
+ the SFRs by an attacker with greater attack potential than
+ is anticipated in the operational environment for the TOE
+
+ vulnerability
+
+ weakness in the TOE that can be used to violate the SFRs in
+ some environment
+
+ base component
+
+ entity in a composed TOE, which has itself been the subject
+ of an evaluation, providing services and resources to a
+ dependent component
+
+ compatible (components)
+
+ property of a component able to provide the services
+ required by the other component, through the corresponding
+ interfaces of each component, in consistent operational
+ environments
+
+ component TOE
+
+ successfully evaluated TOE that is part of another composed
+ TOE
+
+ composed TOE
+
+ TOE comprised solely of two or more components that have
+ been successfully evaluated
+
+ dependent component
+
+ entity in a composed TOE, which is itself the subject of an
+ evaluation, relying on the provision on services by a base
+ component
+
+ functional interface
+
+ external interface providing a user with access to
+ functionality of the TOE which is not directly involved in
+ enforcing security functional requirements
+
+ In a composed TOE these are the interfaces provided by the
+ base component that are required by the dependent component
+ to support the operation of the composed TOE.
+
+ The following abbreviations are used in one or more parts of the
+ CC:API
+ Application Programming Interface
+ CAP
+ Composed Assurance Package
+ CC
+ Common Criteria
+ CCRAArrangement on the
+ Recognition of Common Criteria Certificates in the field of IT
+ Security
+ CM
+ Configuration Management
+ DAC
+ Discretionary Access Control
+ EAL
+ Evaluation Assurance Level
+ GHz
+ Gigahertz
+ GUI
+ Graphical User Interface
+ IC
+ Integrated Circuit
+ IOCTL
+ Input Output Control
+ IP
+ Internet Protocol
+ IT
+ Information Technology
+ MB
+ Mega Byte
+ OS
+ Operating System
+ OSP
+ Organisational Security Policy
+ PC
+ Personal Computer
+ PCI
+ Peripheral Component Interconnect
+ PKI
+ Public Key Infrastructure
+ PP
+ Protection Profile
+ RAM
+ Random Access Memory
+ RPC
+ Remote Procedure Call
+ SAR
+ Security Assurance Requirement
+ SFR
+ Security Functional Requirement
+ SFP
+ Security Function Policy
+ SPD
+ Security Problem Definition
+ ST
+ Security Target
+ TCP
+ Transmission Control Protocol
+ TOE
+ Target of Evaluation
+ TSF
+ TOE Security Functionality
+ TSFI
+ TSF Interface
+ VPN
+ Virtual Private Network
+
+ This Clause introduces the main concepts of the CC. It
+ identifies the concept ``TOE'', the target audience of the CC,
+ and the approach taken to present the material in the remainder
+ of the CC.
+ The CC is flexible in what to evaluate and is therefore not
+ tied to the boundaries of IT products as commonly
+ understood. Therefore in the context of evaluation, the CC
+ uses the term ``TOE'' (Target of Evaluation).
+ A TOE is defined as a set of software, firmware and/or
+ hardware possibly accompanied by guidance.
+ While there are cases where a TOE consists of an IT product,
+ this need not be the case. The TOE may be an IT product, a
+ part of an IT product, a set of IT products, a unique
+ technology that may never be made into a product, or a
+ combination of these.
+ As far as the CC is concerned, the precise relation
+ between the TOE and any IT products is only important in one
+ aspect: the evaluation of a TOE containing only part of an IT
+ product should not be misrepresented as the evaluation of the
+ entire IT product.
+ Examples of TOEs include:
+
+ A software application;
+
+ An operating system;
+
+ A software application in combination with an operating
+ system;
+
+ A software application in combination with an operating
+ system and a workstation;
+
+ An operating system in combination with a workstation;
+
+ A smart card integrated circuit;
+
+ The cryptographic co-processor of a smart card integrated
+ circuit;
+
+ A Local Area Network including all terminals, servers,
+ network equipment and software;
+
+ A database application excluding the remote client
+ software normally associated with that database
+ application.
+
+ In the CC, a TOE can occur in several
+ representations, such as (for a software TOE):
+
+ a list of files in a configuration management system;
+
+ a single master copy, that has just been compiled;
+
+ a box containing a CD-ROM and a manual, ready to be shipped to a customer;
+
+ an installed and operational version.
+
+ All of these are considered to be a TOE: and wherever the
+ term ``TOE'' is used in the remainder of the CC, the
+ context determines the representation that is meant.
+ In general, IT products can be configured in many ways:
+ installed in different ways, with different options enabled
+ or disabled. As, during a CC evaluation, it will be
+ determined whether a TOE meets certain requirements, this
+ flexibility in configuration may lead to problems, as all
+ possible configurations of the TOE must meet the
+ requirements. For these reasons, it is often the case that
+ the guidance part of the TOE strongly constrains the
+ possible configurations of the TOE. That is: the guidance of
+ the TOE may be different from the general guidance of the IT
+ product.
+ An example is an operating system IT product. This product
+ can be configured in many ways (e.g. types of users, number
+ of users, types of external connections allowed/disallowed,
+ options enabled/disabled etc.).
+ If the same IT product is to be a TOE, and is evaluated
+ against a reasonable set of requirements, the configuration
+ should be much more tightly controlled, as many options
+ (e.g. allow all types of external connections or the system
+ administrator does not need to be authenticated) will lead
+ to a TOE not meeting the requirements.
+ For this reason, there would normally be a difference
+ between the guidance of the IT product (allowing many
+ configurations) and the guidance of the TOE (allowing only
+ one or only configurations that do not differ in
+ security-relevant ways).
+ Note that if the guidance of the TOE still allows more than
+ one configuration, these configurations are collectively
+ called ``the TOE'' and each such configuration must meet the
+ requirements levied on the TOE.
+ There are three groups with a general interest in evaluation
+ of the security properties of TOEs: consumers, developers and
+ evaluators. The criteria presented in this CC part 1 have been
+ structured to support the needs of all three groups. They are
+ all considered to be the principal users of the CC. The
+ three groups can benefit from the criteria as explained in the
+ following paragraphs.
+ The CC is written to ensure that evaluation fulfils
+ the needs of the consumers as this is the fundamental
+ purpose and justification for the evaluation process.
+ Consumers can use the results of evaluations to help decide
+ whether a TOE fulfils their security needs. These security
+ needs are typically identified as a result of both risk
+ analysis and policy direction. Consumers can also use the
+ evaluation results to compare different TOEs.
+ The CC gives consumers, especially in consumer groups
+ and communities of interest, an implementation-independent
+ structure, termed the Protection Profile (PP), in which to
+ express their security requirements in an unambiguous
+ manner.
+ The CC is intended to support developers in preparing
+ for and assisting in the evaluation of their TOEs and in
+ identifying security requirements to be satisfied by those
+ TOEs. These requirements are contained in an
+ implementation-dependent construct termed the Security
+ Target (ST). This ST may be based on one or more PPs to show
+ that the ST conforms to the security requirements from
+ consumers as laid down in those PPs.
+ The CC can then be used to determine the
+ responsibilities and actions to provide evidence that is
+ necessary to support the evaluation of the TOE against these
+ requirements. It also defines the content and presentation
+ of that evidence.
+ The CC contains criteria to be used by evaluators
+ when forming judgements about the conformance of TOEs to
+ their security requirements. The CC describes the set
+ of general actions the evaluator is to carry out. Note that
+ the CC does not specify procedures to be followed in
+ carrying out those actions. More information on these
+ procedures may be found in Subclause .
+ While the CC is oriented towards specification and
+ evaluation of the IT security properties of TOEs, it may
+ also be useful as reference material to all parties with an
+ interest in or responsibility for IT security. Some of the
+ additional interest groups that can benefit from information
+ contained in the CC are:
+
+ system custodians and system security officers
+ responsible for determining and meeting organisational
+ IT security policies and requirements;
+
+ auditors, both internal and external, responsible for
+ assessing the adequacy of the security of an IT solution
+ (which may consist of or contain a TOE);
+
+ security architects and designers responsible for the
+ specification of security properties of IT products;
+
+ accreditors responsible for accepting an IT solution for
+ use within a particular environment;
+
+ sponsors of evaluation responsible for requesting and
+ supporting an evaluation; and
+
+ evaluation authorities responsible for the management
+ and oversight of IT security evaluation programmes.
+
+ The CC is presented as a set of distinct but related
+ parts as identified below. Terms used in the description of
+ the parts are explained in Clause .
+ Part 1, Introduction and general model is the
+ introduction to the CC. It defines the general concepts
+ and principles of IT security evaluation and presents a
+ general model of evaluation.
+ Part 2, Security functional components
+ establishes a set of functional components that serve as
+ standard templates upon which to base functional
+ requirements for TOEs. CC Part 2 catalogues the set of
+ functional components and organises them in families and
+ classes.
+ Part 3, Security assurance components
+ establishes a set of assurance components that serve as
+ standard templates upon which to base assurance
+ requirements for TOEs. CC Part 3 catalogues the set of
+ assurance components and organises them into families and
+ classes. CC Part 3 also defines evaluation criteria for
+ PPs and STs and presents seven pre-defined assurance
+ packages which are called the Evaluation Assurance Levels
+ (EALs).
+
+ In support of the three parts of the CC listed above,
+ other documents have been published, the CEM provides
+ the methodology for IT security evaluation using the CC
+ as a basis. It is anticipated that other documents will be
+ published, including technical rationale material and guidance
+ documents.
+ The following table presents, for the three key target
+ audience groupings, how the parts of the CC will be of
+ interest.
+ Consumers
+
+ Developers
+
+ Evaluators
+
+ Part 1
+
+ Use for background information and
+ are obliged to use for reference purposes. Guidance
+ structure for PPs.
+
+ Use for background information and reference
+ purposes. Are obliged to use for the development of
+ security specifications for TOEs.
+
+ Are obliged to use for reference purposes and for
+ guidance in the structure for PPs and STs.
+
+ Part 2
+
+ Use for guidance and reference when formulating
+ statements of requirements for a TOE.
+
+ Are obliged to use for reference when interpreting
+ statements of functional requirements and formulating
+ functional specifications for TOEs.
+
+ Are obliged to use for reference when interpreting
+ statements of functional requirements.
+
+ Part 3
+
+ Use for guidance when determining required levels of
+ assurance.
+
+ Use for reference when interpreting statements of
+ assurance requirements and determining assurance
+ approaches of TOEs.
+
+ Use for reference when interpreting statements of
+ assurance requirements.
+ Road map to the Common Criteria
+ In order to achieve greater comparability between evaluation
+ results, evaluations should be performed within the framework
+ of an authoritative evaluation scheme that sets the standards,
+ monitors the quality of the evaluations and administers the
+ regulations to which the evaluation facilities and evaluators
+ must conform.
+ The CC does not state requirements for the regulatory
+ framework. However, consistency between the regulatory
+ frameworks of different evaluation authorities will be
+ necessary to achieve the goal of mutual recognition of the
+ results of such evaluations.
+ A second way of achieving greater comparability between
+ evaluation results is using a common methodology to achieve
+ these results. For the CC, this methodology is given in
+ the CEM.
+ Use of a common evaluation methodology contributes to the
+ repeatability and objectivity of the results but is not by
+ itself sufficient. Many of the evaluation criteria require the
+ application of expert judgement and background knowledge for
+ which consistency is more difficult to achieve. In order to
+ enhance the consistency of the evaluation findings, the final
+ evaluation results may be submitted to a certification
+ process.
+ The certification process is the independent inspection of the
+ results of the evaluation leading to the production of the
+ final certificate or approval, which is normally publicly
+ available. The certification process is a means of gaining
+ greater consistency in the application of IT security
+ criteria.
+ The evaluation schemes and certification processes are the
+ responsibility of the evaluation authorities that run such
+ schemes and processes and are outside the scope of the CC.
+ This clause presents the general concepts used throughout the
+ CC, including the context in which the concepts are to be used
+ and the CC approach for applying the concepts. CC Part 2 and CC
+ Part 3, which are obliged to be consulted by users of the CC
+ Part 1, expand on the use of these concepts and assume that the
+ approach described is used. Further, for users of the CC who
+ intend to perform evaluation activities the CEM is
+ applicable. This clause assumes some knowledge of IT security
+ and does not propose to act as a tutorial in this area.
+ The CC discusses security using a set of security
+ concepts and terminology. An understanding of these concepts and
+ the terminology is a prerequisite to the effective use of
+ the CC. However, the concepts themselves are quite
+ general and are not intended to restrict the class of IT
+ security problems to which the CC is applicable.
+ Security is concerned with the protection of assets. Assets
+ are entities that someone places value upon. Examples of
+ assets include:
+ contents of a file or a server;the authenticity of votes cast in an election;the availability of an electronic commerce
+ process;the ability to use an expensive printer;access to a classified facility.
+ but given that value is highly subjective, almost anything can
+ be an asset.
+ The environment(s) in which these assets are located is called
+ the operational environment. Examples of (aspects of)
+ operational environments are:
+
+ the computer room of a bank;
+
+ a computer network connected to the Internet;
+
+ a LAN;
+
+ a general office environment.
+
+ Many assets are in the form of information that is stored,
+ processed and transmitted by IT products to meet requirements
+ laid down by owners of the information. Information owners may
+ require that availability, dissemination and modification of
+ any such information are strictly controlled and that the
+ assets are protected from threats by countermeasures. Figure
+ illustrates these
+ high level concepts and relationships.
+ Safeguarding assets of interest is the responsibility of
+ owners who place value on those assets. Actual or presumed
+ threat agents may also place value on the assets and seek to
+ abuse assets in a manner contrary to the interests of the
+ owner. Examples of threat agents include hackers, malicious
+ users, non-malicious users (who sometimes make errors),
+ computer processes and accidents.
+ The owners of the assets will perceive such threats as
+ potential for impairment of the assets such that the value of
+ the assets to the owners would be reduced. Security-specific
+ impairment commonly includes, but is not limited to: loss of
+ asset confidentiality, loss of asset integrity and loss of
+ asset availability.
+ These threats therefore give rise to risks to the assets,
+ based on the likelihood of a threat being realised and the
+ impact on the assets when that threat is
+ realised. Subsequently countermeasures are imposed to reduce
+ the risks to assets. These countermeasures may consist of IT
+ countermeasures (such as firewalls and smart cards) and non-IT
+ countermeasures (such as guards and procedures). See also
+ ISO/IEC 27001 and ISO/IEC 27002 for a more general discussion
+ on security countermeasures (controls).
+ Owners of assets may be (held) responsible for those assets
+ and therefore should be able to defend the decision to accept
+ the risks of exposing the assets to the threats.
+ Two important elements in defending this decision are being
+ able to demonstrate that:
+
+ the countermeasures are sufficient: if the countermeasures do what
+ they claim to do, the threats to the assets are countered;
+
+ the countermeasures are correct: the countermeasures do
+ what they claim to do.
+
+ Many owners of assets lack the knowledge, expertise or
+ resources necessary to judge sufficiency and correctness of
+ the countermeasures, and they may not wish to rely solely on
+ the assertions of the developers of the countermeasures. These
+ consumers may therefore choose to increase their confidence in
+ the sufficiency and correctness of some or all of their
+ countermeasures by ordering an evaluation of these
+ countermeasures.
+ In an evaluation, sufficiency of the countermeasures is
+ analysed through a construct called the Security Target. In
+ this Subclause a simplified view on this construct is
+ provided: a more detailed and complete description may be
+ found in .
+ The Security Target begins with describing the assets and
+ the threats to those assets. The Security Target then
+ describes the countermeasures (in the form of Security
+ Objectives) and demonstrates that these countermeasures are
+ sufficient to counter these threats: if the countermeasures
+ do what they claim to do, the threats are countered.
+ The Security Target then divides these countermeasures in
+ two groups:
+
+ the security objectives for the TOE: these describe the
+ countermeasure(s) for which correctness will be
+ determined in the evaluation;
+
+ the security objectives for the Operational Environment:
+ these describe the countermeasures for which correctness
+ will not be determined in the evaluation.
+
+ The reasons for this division are:
+
+ The CC is only suitable for assessing the
+ correctness of IT countermeasures. Therefore the non-IT
+ countermeasures (e.g. human security guards, procedures)
+ are always in the Operational Environment.
+
+ Assessing correctness of countermeasures costs time and
+ money, possibly making it infeasible to assess the
+ correctness of all IT countermeasures.
+
+ The correctness of some IT countermeasures may already
+ have been assessed in another evaluation. It is
+ therefore not cost-effective to assess this correctness
+ again.
+
+ For the TOE (the IT countermeasures whose correctness will
+ be assessed during the evaluation), the Security Target
+ requires a further detailing of the security objectives for
+ the TOE in Security Functional Requirements (SFRs). These
+ SFRs are formulated in a standardised language (described in
+ CC Part 2) to ensure exactness and facilitate comparability.
+ In summary, the Security Target demonstrates that:
+
+ The SFRs meet the security objectives for the TOE;
+
+ The security objectives for the TOE and the security
+ objectives for the operational environment counter the
+ threats;
+
+ And therefore, the SFRs and the security objectives for
+ the operational environment counter the threats.
+
+ From this it follows that a correct TOE (meeting the SFRs)
+ in combination with a correct operational environment
+ (meeting the security objectives for the operational
+ environment) will counter the threats. In the next two
+ subclauses correctness of the TOE and correctness of the
+ operational environment are discussed separately.
+ A TOE may be incorrectly designed and implemented, and may
+ therefore contain errors that lead to vulnerabilities. By
+ exploiting these vulnerabilities, attackers may still damage
+ and/or abuse the assets.
+ These vulnerabilities may arise from accidental errors made
+ during development, poor design, intentional addition of
+ malicious code, poor testing etc.
+ To determine correctness of the TOE, various activities can
+ be performed such as:
+
+ testing the TOE;
+
+ examining various design representations of the TOE;
+
+ examining the physical security of the development
+ environment of the TOE.
+
+ The Security Target provides a structured description of
+ these activities to determine correctness in the form of
+ Security Assurance Requirements (SARs). These SARs are
+ formulated in a standardised language (described in CC Part
+ 3) to ensure exactness and facilitate comparability.
+ If the SARs are met, there exists assurance in the
+ correctness of the TOE and the TOE is therefore less likely
+ to contain vulnerabilities that can be exploited by
+ attackers. The amount of assurance that exists in the
+ correctness of the TOE is determined by the SARs themselves:
+ a few ``weak'' SARs will lead to a little assurance, a lot
+ of ``strong'' SARs will lead to a lot of assurance.
+ The operational environment may also be incorrectly designed
+ and implemented, and may therefore contain errors that lead
+ to vulnerabilities. By exploiting these vulnerabilities,
+ attackers may still damage and/or abuse the assets.
+ However, in the CC, no assurance is obtained
+ regarding the correctness of the operational
+ environment. Or, in other words, the operational environment
+ is not evaluated (see the next Subclause).
+ As far as the evaluation is concerned, the operational
+ environment is assumed to be a 100% correct instantiation of
+ the security objectives for the operational environment.
+ This does not preclude a consumer of the TOE from using
+ other methods to determine the correctness of his
+ operational environment, such as:
+
+ If, for an OS TOE, the security objectives for the
+ operational environment state ``The operational
+ environment shall ensure that entities from an untrusted
+ network (e.g. the Internet) can only access the TOE by
+ ftp'', the consumer could select an evaluated firewall,
+ and configure it to only allow ftp access to the TOE;
+
+ If the security objectives for the operational
+ environment state ``The operational environment shall
+ ensure that all administrative personnel will not behave
+ maliciously'', the consumer could adapt his contracts
+ with administrative personnel to include punitive
+ sanctions for malicious behaviour, but this
+ determination is not part of a CC evaluation.
+
+ The CC recognises two types of evaluation: an ST/TOE
+ evaluation, which is described below, and an evaluation of
+ PPs, which is defined in CC Part 3. In many places,
+ the CC uses the term evaluation (without qualifiers) to
+ refer to an ST/TOE evaluation.
+ In the CC an ST/TOE evaluation proceeds in two steps:
+
+ An ST evaluation: where the sufficiency of the TOE and the
+ operational environment are determined;
+
+ A TOE evaluation: where the correctness of the TOE is
+ determined. As said earlier, the TOE evaluation does not
+ assess correctness of the operational environment.
+
+ The ST evaluation is carried out by applying the Security
+ Target evaluation criteria (which are defined in CC Part 3) to
+ the Security Target. The precise method to apply the criteria is determined by the evaluation
+ methodology that is used.
+ The TOE evaluation is more complex. The principal inputs to a
+ TOE evaluation are: the evaluation evidence, which includes
+ the TOE and ST, but will usually also include input from the
+ development environment, such as design documents or developer
+ test results.
+ The TOE evaluation consists of applying the SARs (from the
+ Security Target) to the evaluation evidence. The precise
+ method to apply a specific SAR is determined by the evaluation
+ methodology that is used.
+ How the results of applying the SARs are documented, and what
+ reports need to be generated and in what detail, is determined
+ by both the evaluation methodology that is used and the
+ evaluation scheme under which the evaluation is carried out.
+ The result of the TOE evaluation process is either:
+
+ A statement that not all SARs have been met and that
+ therefore there is not the specified level of assurance
+ that the TOE meets the SFRs as stated in the ST;
+
+ A statement that all SARs have been met, and that
+ therefore there is the specified level of assurance that
+ the TOE meets the SFRs as stated in the ST.
+
+ The TOE evaluation may be carried out after TOE development
+ has finished, or in parallel with TOE development.
+ The method of stating ST/TOE evaluation results is described
+ in Clause . These results also
+ identify the PP(s) and package(s) to which the TOE claims
+ conformance, and these constructs are described in the next
+ Clause.
+ The CC functional and assurance components may be used exactly
+ as defined in CC Part 2 and CC Part 3, or they may be tailored
+ through the use of permitted operations. When using
+ operations, the PP/ST author should be careful that the
+ dependency needs of other requirements that depend on this
+ requirement are satisfied. The permitted operations are
+ selected from the following set:
+
+ Iteration: allows a component to be used more than once
+ with varying operations;
+
+ Assignment: allows the specification of parameters;
+
+ Selection: allows the specification of one or more items
+ from a list; and
+
+ Refinement: allows the addition of details.
+
+ The assignment and selection operations are permitted only
+ where specifically indicated in a component. Iteration and
+ refinement are permitted for all components. The operations
+ are described in more detail below.
+ The CC Part 2 Annexes provide the guidance on the valid
+ completion of selections and assignments. This guidance
+ provides normative instructions on how to complete operations,
+ and those instructions shall be followed unless the PP/ST
+ author justifies the deviation:
+
+ ``None'' is only available as a choice for the completion
+ of a selection if explicitly provided.
+
+ The lists provided for the completion of selections must
+ be non-empty. If a ``None'' option is chosen, no
+ additional selection options may be chosen. If ``None''
+ is not given as an option in a selection, it is
+ permissible to combine the choices in a selection with
+ ``and''s and ``or''s, unless the selection explicitly
+ states ``choose one of''.
+ Selection operations may be combined by iteration where
+ needed. In this case, the applicability of the option
+ chosen for each iteration should not overlap the subject
+ of the other iterated selection, since they are intended
+ to be exclusive.
+ For the completion of assignments, the CC Part 2 Annexes
+ shall be consulted in order to determine when ``None''
+ would be a valid completion.
+
+ The iteration operation may be performed on every
+ component. The PP/ST author performs an iteration operation
+ by including multiple requirements based on the same
+ component. Each iteration of a component shall be different
+ from all other iterations of that component, which is
+ realised by completing assignments and selections in a
+ different way, or by applying refinements to it in a
+ different way.
+ Different iterations should be uniquely identified to allow
+ clear rationales and tracings to and from these
+ requirements.
+ It is important to note that sometimes an iteration
+ operation can be used with components where could also be
+ possible to perform an assignment operation with a range or
+ list of values instead of iterate them. In that case the
+ author can select the most appropriate alternative,
+ considering if there is a necessity of providing a whole
+ rationale for the range of values or if it is necessary to
+ have a separate one for each of them. The author should also
+ keep in mind if individual traces are required for those
+ values.
+ An assignment operation occurs where a given component
+ contains an element with a parameter that may be set by the
+ PP/ST author. The parameter may be an unrestricted variable,
+ or a rule that narrows the variable to a specific range of
+ values.
+ Whenever an element in a PP contains an assignment, a PP
+ author shall do one of four things:
+
+ leave the assignment uncompleted. The PP author could
+ include ``When the
+ defined number of unsuccessful authentication attempts
+ has been met or surpassed, the TSF shall
+ [assignment: list of actions].'' in the PP.
+
+ complete the assignment. As an example, the PP author
+ could include ``When
+ the defined number of unsuccessful authentication
+ attempts has been met or surpassed, the TSF shall
+ prevent that external entity from binding to any
+ subject in the future.'' in the PP.
+
+ narrow the assignment, to further limit the range of
+ values that is allowed. As an example, the PP author
+ could include ``The
+ TSF shall detect when [assignment: positive
+ integer between 4 and 9] unsuccessful authentication
+ attempts occur ...'' in the PP.
+
+ transform the assignment to a selection, thereby
+ narrowing the assignment. As an example, the PP author
+ could include ``When
+ the defined number of unsuccessful authentication
+ attempts has been met or surpassed, the TSF shall
+ [selection: prevent that user from binding to any
+ subject in the future, notify the
+ administrator].'' in the PP.
+
+ Whenever an element in an ST contains an assignment, an ST
+ author shall complete that assignment, as indicated in b)
+ above. Options a), c) and d) are not allowed for STs.
+ The values chosen in options b), c) and d) shall conform to
+ the indicated type required by the assignment.
+ When an assignment is to be completed with a set
+ (e.g. subjects), one may list a set of subjects, but also
+ some description of the set from which the elements of the
+ set can be derived such as:
+
+ all subjects
+
+ all subjects of type X
+
+ all subjects except subject a
+
+ as long as it is clear which subjects are meant.
+
+ The selection operation occurs where a given component
+ contains an element where a choice from several items has to
+ be made by the PP/ST author.
+ Whenever an element in a PP contains a selection, the PP
+ author may do one of three things:
+
+ leave the selection uncompleted.
+
+ complete the selection by choosing one or more items.
+
+ restrict the selection by removing some of the choices,
+ but leaving two or more.
+
+ Whenever an element in an ST contains a selection, an ST
+ author shall complete that selection, as indicated in b)
+ above. Options a) and c) are not allowed for STs.
+ The item or items chosen in b) and c) shall be taken from
+ the items provided in the selection.
+ The refinement operation can be performed on every
+ requirement. The PP/ST author performs a refinement by
+ altering that requirement. The first rule for a refinement
+ is that a TOE meeting the refined requirement also meets the
+ unrefined requirement in the context of the PP/ST (i.e. a
+ refined requirement must be ``stricter'' than the original
+ requirement). If a refinement does not meet this rule, the
+ resulting refined requirement is considered to be an
+ extended requirement and shall be treated as such.
+ The first rule for a refinement is that a TOE meeting the
+ refined requirement also meets the unrefined requirement in
+ the context of the PP/ST (i.e. a refined requirement must be
+ ``stricter'' than the original requirement)
+ The only exception to this rule is that a PP/ST author is
+ allowed to refine a SFR to apply to some but not all
+ subjects, objects, operations, security attributes and/or
+ external entities.
+ However, this exception does not apply to refining SFRs that
+ are taken from PPs that compliance is being claimed to;
+ these SFRs may not be refined to apply to fewer subjects,
+ objects, operations, security attributes and/or external
+ entities than the SFR in the PP.
+ The second rule for a refinement is that the refinement
+ shall be related to the original component.
+ A special case of refinement is an editorial refinement,
+ where a small change is made in a requirement,
+ i.e. rephrasing a sentence due to adherence to proper
+ English grammar, or to make it more understandable to the
+ reader. This change is not allowed to modify the meaning of
+ the requirement in any way.
+ Dependencies may exist between components. Dependencies arise
+ when a component is not self sufficient and relies upon the
+ presence of another component to provide security
+ functionality or assurance.
+ The functional components in CC Part 2 typically have
+ dependencies on other functional components as do some of the
+ assurance components in CC Part 3 which may have dependencies
+ on other CC Part 3 components. CC Part 2 dependencies on CC
+ Part 3 components may also be defined. However, this does not
+ preclude extended functional components having dependencies on
+ assurance components or vice versa.
+ Component dependency descriptions are determined by consulting
+ the CC Part 2 and CC Part 3 component definitions. In order to
+ ensure completeness of the TOE security requirements,
+ dependencies should be satisfied when requirements based on
+ components with dependencies are incorporated into PPs and
+ STs. Dependencies should also be considered when constructing
+ packages.
+ In other words: if component A has a dependency on component
+ B, this means that whenever a PP/ST contains a security
+ requirement based on component A, the PP/ST shall also contain
+ one of :
+
+ a security requirement based on component B, or
+
+ a security requirement based on a component that is
+ hierarchically higher than B, or
+
+ a justification why the PP/ST does not contain a security
+ requirement based on component B.
+
+ In cases a) and b), when a security requirement is included
+ because of a dependency, it may be necessary to complete
+ operations (assignment, iteration, refinement, selection) on
+ that security requirement in a particular manner to make sure
+ that it actually satisfies the dependency.
+ In case c), the justification that a security requirement is
+ not included should address either:
+
+ why the dependency is not necessary or useful, or
+
+ that the dependency has been addressed by the operational
+ environment of the TOE, in which case the justification
+ should describe how the security objectives for the
+ operational environment address this dependency, or
+
+ that the dependency has been addressed by the other SFRs
+ in some other manner (extended SFRs, combinations of SFRs
+ etc.)
+
+ In the CC it is mandatory to base requirements on
+ components from CC Part 2 or CC Part 3 with two
+ exceptions:
+
+ there are security objectives for the TOE that can not be
+ translated to Part 2 SFRs, or there are third party
+ requirements (e.g., laws, standards) that can not be
+ translated to Part 3 SARs (e.g. regarding evaluation of
+ cryptography);
+
+ a security objective can be translated, but only with
+ great difficulty and/or complexity based on components in
+ CC Part 2 and/or CC Part 3.
+
+ In both cases the PP/ST author is required to define his own
+ components. These newly defined components are called extended
+ components. A precisely defined extended component is needed
+ to provide context and meaning to the extended SFRs and SARs
+ based on that component.
+ After the new components have been defined correctly, the
+ PP/ST author can then base one or more SFRs or SARs on these
+ newly defined extended components and use them in the same way
+ as the other SFRs and SARs. From this point on, there is no
+ further distinction between SARs and SFRs based on the CC and
+ SARs and SFRs based on extended components. Refer to CC Part 3
+ and for further
+ requirements on extended components.
+ To allow consumer groups and communities of interest to
+ express their security needs, and to facilitate writing STs,
+ this part of the CC provides two special constructs: packages
+ and Protection Profiles (PPs). In the following two subclauses
+ these constructs are described in more detail, followed by a
+ subclause on how these constructs can be used.
+ A package is a named set of security requirements. A package
+ is either
+
+ a functional package, containing only SFRs, or
+
+ an assurance package, containing only SARs.
+
+ Mixed packages containing both SFRs and SARs are not allowed.
+ A package can be defined by any party and is intended to be
+ re-usable. To this goal it should contain requirements that
+ are useful and effective in combination. Packages can be used
+ in the construction of larger packages, PPs and STs. At
+ present there are no criteria for the evaluation of packages,
+ therefore any set of SFRs or SARs can be a package.
+ Examples of assurance packages are the evaluation assurance
+ levels (EALs) that are defined in CC Part 3. At the time
+ of writing there are no functional packages for this version
+ of the CC.
+ Whereas an ST always describes a specific TOE (e.g. the
+ MinuteGap v18.5 Firewall), a PP is intended to describe a TOE
+ type (e.g. firewalls). The same PP may therefore be used as a
+ template for many different STs to be used in different
+ evaluations. A detailed description of PPs is given in .
+ In general an ST describes requirements for a TOE and is
+ written by the developer of that TOE, while a PP describes
+ the general requirements for a TOE type, and is therefore
+ typically written by:
+
+ A user community seeking to come to a consensus on the
+ requirements for a given TOE type;
+
+ A developer of a TOE, or a group of developers of
+ similar TOEs wishing to establish a minimum baseline for
+ that type of TOE;
+
+ A government or large corporation specifying its
+ requirements as part of its acquisition process.
+
+ The PP determines the allowed type of conformance of the ST
+ to the PP. That is, the PP states (in the PP conformance
+ statement, see subclause )
+ what the allowed types of conformance for the ST are:
+
+ if the PP states that strict conformance is required,
+ the ST shall conform to the PP in a strict manner;
+
+ if the PP states that demonstrable conformance is
+ required, the ST shall conform to the PP in a strict or
+ demonstrable manner.
+
+ Restating this in other words, an ST is only allowed to
+ conform in a PP in a demonstrable manner, if the PP
+ explicitly allows this.
+ If an ST claims conformance to multiple PPs, it shall
+ conform (as described above) to each PP in the manner
+ ordained by that PP. This may mean that the ST conforms
+ strictly to some PPs and demonstrably to other PPs.
+ Note that either the ST conforms to the PP in question or it
+ does not. The CC does not recognise ``partial''
+ conformance. It is therefore the responsibility of the PP
+ author to ensure the PP is not overly onerous, prohibiting
+ PP/ST authors in claiming conformance to the PP.
+ An ST is equivalent or more restrictive than a PP if:
+
+ all TOEs that meet the ST also meet the PP, and
+
+ all operational environments that meet the PP also meet
+ the ST.
+
+ or, informally, the ST shall levy the same or more,
+ restrictions on the TOE and the same or less restrictions on
+ the operational environment of the TOE.
+ This general statement can be made more specific for various
+ subclauses of the ST:
+ Security problem definition: The
+ conformance rationale in the ST shall demonstrate that
+ the security problem definition in the ST is equivalent
+ (or more restrictive) than the security problem
+ definition in the PP. This means that:
+
+ all TOEs that would meet the security problem
+ definition in the ST also meet the security problem
+ definition in the PP;
+
+ all operational environments that would meet the
+ security problem definition in the PP would also
+ meet the security problem definition in the ST.
+ Security objectives: The conformance
+ rationale in the ST shall demonstrate that the security
+ objectives in the ST is equivalent (or more restrictive)
+ than the security objectives in the PP. This means that:
+
+ all TOEs that would meet the security objectives for
+ the TOE in the ST also meet the security objectives
+ for the TOE in the PP;
+
+ all operational environments that would meet the
+ security objectives for the operational environment
+ in the PP would also meet the security objectives
+ for the operational environment in the ST.
+
+ If strict conformance for protection profiles is specified
+ then the following requirements apply:
+ Security problem definition: The ST shall
+ contain the security problem definition of the PP, may
+ specify additional threats and OSPs, but may not specify
+ additional assumptions.
+ Security objectives: The ST:
+
+ shall contain all security objectives for the TOE of
+ the PP but may specify additional security
+ objectives for the TOE;
+
+ shall contain all security objectives for the
+ operational environment (with one exception in the
+ next bullet) but may not specify additional security
+ objectives for the operational environment;
+
+ may specify that certain objectives for the
+ operational environment in the PP are security
+ objectives for the TOE in the ST. This is called
+ re-assigning a security objective. If a security
+ objective is re-assigned to the TOE the security
+ objectives rationale has to make clear which
+ assumption or part of the assumption is not
+ necessary any more.
+ Security requirements: The ST shall contain
+ all SFRs and SARs in the PP, but may claim additional or
+ hierarchically stronger SFRs and SARs. The completion of
+ operations in the ST must be consistent with that in the
+ PP; either the same completion will be used in the ST as
+ that in the PP or one that makes the requirement more
+ restrictive (the rules of refinement apply).
+
+ If demonstrable conformance for protection profiles is
+ specified then the following requirements apply:
+
+ the ST shall contain a rationale on why the ST is
+ considered to be ``equivalent or more restrictive'' than
+ the PP.
+
+ Demonstrable conformance allows a PP author to describe
+ a common security problem to be solved and provide
+ generic guidelines to the requirements necessary for its
+ resolution, in the knowledge that there is likely to be
+ more than one way of specifying a resolution.
+
+ PP evaluation is optional. Evaluation is performed by applying
+ the criteria to them as listed in
+ CC Part 3. The goal of such an evaluation is to demonstrate
+ that the PP is complete, consistent, and technically sound and
+ suitable for use as a template on which to build another PP or
+ an ST.
+ Basing a PP/ST on an evaluated PP has two advantages:
+
+ There is much less risk that there are errors, ambiguities
+ or gaps in the PP. If any problems with a PP (that would
+ have been caught by evaluating that PP) are found during
+ the writing or evaluation of the new ST, significant time
+ may elapse before the PP is corrected.
+
+ Evaluation of the new PP/ST may often re-use evaluation
+ results of the evaluated PP, resulting in less effort
+ for evaluating the new PP/ST.
+
+ If an ST claims to be conformant to one or more packages
+ and/or Protection Profiles, the evaluation of that ST will
+ (among other properties of that ST) demonstrate that the ST
+ actually conforms to these packages and/or PPs that they claim
+ conformance to. Details of this determination of conformance
+ can be found in .
+ This allows the following process:
+
+ An organisation seeking to acquire a particular type of
+ IT security product develops their security needs into a
+ PP, then has this evaluated and publishes it;
+
+ A developer takes this PP, writes an ST that claims
+ conformance to the PP and has this ST evaluated;
+
+ The developer then builds a TOE (or uses an existing
+ one) and has this evaluated against the ST.
+
+ The result is that the developer can prove that his TOE is
+ conformant to the security needs of the organisation: the
+ organisation can therefore acquire that TOE. A similar line of
+ reasoning applies to packages.
+ The CC also allows PPs to conform to other PPs, allowing
+ chains of PPs to be constructed, each based on the previous
+ one(s).
+ For instance, one could take a PP for an Integrated Circuit
+ and a PP for a Smart Card OS, and use these to construct a
+ Smart Card PP (IC and OS) that claims conformance to the
+ other two. One could then write a PP on Smart Cards for
+ Public Transport based on the Smart Card PP and a PP on
+ Applet Loading. Finally, a developer could then construct an
+ ST based on this Smart Cards for Public Transport PP.
+ This clause presents the expected results from PP and ST/TOE
+ evaluations performed according to the CEM.
+ PP evaluations lead to catalogues of evaluated PPs.
+ An ST evaluation leads to intermediate results that are used
+ in the frame of a TOE evaluation.
+ ST/TOE evaluations lead to catalogues of evaluated TOEs. In
+ many cases these catalogues will refer to the IT products that
+ the TOEs are derived from rather than the specific
+ TOE. Therefore, the existence of an IT product in a catalogue
+ should not be construed as meaning that the whole IT product
+ has been evaluated; instead the actual extent of the ST/TOE
+ evaluation is defined by the ST. Refer to the bibliography for
+ examples of such catalogues.
+ STs may be based on packages, evaluated PPs or non-evaluated
+ PPs - however this is not mandatory, as STs do not have to be
+ based on anything at all.
+ Evaluation should lead to objective and repeatable results
+ that can be cited as evidence, even if there is no absolute
+ objective scale for representing the results of a security
+ evaluation. The existence of a set of evaluation criteria is a
+ necessary pre-condition for evaluation to lead to a meaningful
+ result and provides a technical basis for mutual recognition
+ of evaluation results between evaluation authorities.
+ An evaluation result represents the findings of a specific
+ type of investigation of the security properties of a
+ TOE. Such a result does not automatically guarantee fitness
+ for use in any particular application environment. The
+ decision to accept a TOE for use in a specific application
+ environment is based on consideration of many security issues
+ including the evaluation findings.
+ CC Part 3 contains the evaluation criteria that an evaluator
+ is obliged to consult in order to state whether a PP is
+ complete, consistent, and technically sound and hence suitable
+ for use in developing an ST.
+ The results of the evaluation shall also include a
+ ``Conformance Claim'' (see Subclause )).
+ CC Part 3 contains the evaluation criteria that an evaluator
+ is obliged to consult in order to determine whether
+ sufficient assurance exists that the TOE satisfies the SFRs
+ in the ST. Evaluation of the TOE shall therefore result in a
+ pass/fail statement for the ST. If both the ST and the TOE
+ evaluation have resulted in a pass statement, the underlying
+ product is eligible for inclusion in a registry. The results
+ of evaluation shall also include a ``Conformance Claim'' as
+ defined in the next subclause.
+ It may be the case that the evaluation results are
+ subsequently used in a certification process, but this
+ certification process is outside the scope of the CC.
+ The conformance claim indicates the source of the collection
+ of requirements that is met by a PP or ST that passes its
+ evaluation. This conformance claim contains a CC conformance
+ claim that:
+
+ describes the version of the CC to which the PP
+ or ST claims conformance.
+
+ describes the conformance to CC Part 2 (security
+ functional requirements) as either:
+ CC Part 2 conformant - A PP or ST
+ is CC Part 2 conformant if all SFRs in that PP
+ or ST are based only upon functional components in
+ CC Part 2, or
+ CC Part 2 extended - A PP or ST
+ is CC Part 2 extended if at least one SFR in
+ that PP or ST is not based upon functional
+ components in CC Part 2.
+
+ describes the conformance to CC Part 3 (security
+ assurance requirements) as either:
+ CC Part 3 conformant - A PP or ST
+ is CC Part 3 conformant if all SARs in that PP
+ or ST are based only upon assurance components in
+ CC Part 3, or
+ CC Part 3 extended - A PP or ST
+ is CC Part 3 extended if at least one SAR in
+ that PP or ST is not based upon assurance components
+ in CC Part 3.
+
+ Additionally, the conformance claim may include a statement
+ made with respect to packages, in which case it consists of
+ one of the following:
+ Package name Conformant - A PP or ST is
+ conformant to a pre-defined package (e.g. EAL) if:
+
+ the SFRs of that PP or ST are identical to the SFRs
+ in the package, or
+
+ the SARs of that PP or ST are identical to the SARs
+ in the package.
+ Package name Augmented - A PP or ST is
+ an augmentation of a predefined package if:
+
+ the SFRs of that PP or ST contain all SFRs in the
+ package, but have at least one additional SFR or one
+ SFR that is hierarchically higher than an SFR in the
+ package.
+
+ the SARs of that PP or ST contain all SARs in the
+ package, but have at least one additional SAR or one
+ SAR that is hierarchically higher than an SAR in the
+ package.
+
+ Note that when a TOE is successfully evaluated to a given
+ ST, any conformance claims of the ST also hold for the
+ TOE. A TOE can therefore also be e.g. CC Part 2 conformant.
+ Finally, the conformance claim may also include two
+ statements with respect to Protection Profiles:
+ PP Conformant - A PP or TOE meets
+ specific PP(s), which are listed as part of the
+ conformance result.
+ Conformance Statement (Only for PPs) -
+ This statement describes the manner in which PPs or STs
+ must conform to this PP: strict or demonstrable. For
+ more information on this Conformance Statement, see
+ .
+
+ Once an ST and a TOE have been evaluated, asset owners can
+ have the assurance (as defined in the ST) that the TOE,
+ together with the operational environment, counters the
+ threats. The evaluation results may be used by the asset
+ owner in deciding whether to accept the risk of exposing the
+ assets to the threats.
+ However, the asset owner should carefully check whether:
+
+ the Security Problem Definition in the ST matches the
+ security problem of the asset owner;
+
+ the Operational Environment of the asset owner conforms
+ (or can be made to conform) to the security objectives
+ for the Operational Environment described in the ST.
+
+ If either of these is not the case, the TOE may not be
+ suitable for the purposes of the asset owner.
+ Additionally, once an evaluated TOE is in operation, it is
+ still possible that previously unknown errors or
+ vulnerabilities in the TOE may surface. In that case, the
+ developer may correct the TOE (to repair the
+ vulnerabilities) or change the ST to exclude the
+ vulnerabilities from the scope of the evaluation. In either
+ case, the old evaluation results may no longer be valid.
+ If it is deemed necessary that confidence is regained,
+ re-evaluation is needed. The CC may be used for this
+ re-evaluation, but detailed procedures for re-evaluation are
+ outside the scope of this part of the CC.
+ The goal of this annex is to explain the Security Target (ST)
+ concept. This annex does not define the criteria; this definition can be found in CC Part
+ 3 and is supported by the documents given in the bibliography.
+ This annex consists of four major parts:
+ What an ST must contain. This is
+ summarised in Subclause , and described in more detail
+ in Subclauses - . These subclauses describe the
+ mandatory contents of the ST, the interrelationships
+ between these contents, and provide examples.
+ How an ST should be used. This is
+ summarised in Subclause , and described in more detail in
+ subclause . These
+ subclauses describe how an ST should be used, and some of
+ the questions that can be answered with an ST.
+ Low Assurance STs. Low Assurance STs are
+ STs with reduced content. They are described in detail in
+ subclause .
+ Claiming compliance with
+ standards. Subclause describes how an ST writer can claim that
+ the TOE meets a particular standard.
+
+ Figure portrays the mandatory
+ contents of an ST that are given in CC Part 3. Figure may also be used as a structural outline
+ of the ST, though alternative structures are allowed. For
+ instance, if the security requirements rationale is
+ particularly bulky, it could be included in an appendix of the
+ ST instead of in the security requirements subclause. The
+ separate subclauses of an ST and the contents of those
+ subclauses are briefly summarised below and explained in much
+ more detail in subclauses to . An ST normally contains:
+ an ST introduction containing three
+ narrative descriptions of the TOE on different levels of
+ abstraction;
+ a conformance claim, showing whether the
+ ST claims conformance to any PPs and/or packages, and if
+ so, to which PPs and/or packages;
+ a security problem definition, showing
+ threats, OSPs and assumptions;
+ security objectives, showing how the
+ solution to the security problem is divided between
+ security objectives for the TOE and security objectives
+ for the operational environment of the TOE;
+ extended components definition
+ (optional), where new components (i.e. those not included
+ in CC Part 2 or CC Part 3) may be defined. These new
+ components are needed to define extended functional and
+ extended assurance requirements;
+ security requirements, where a
+ translation of the security objectives for the TOE into a
+ standardised language is provided. This standardised
+ language is in the form of SFRs. Additionally this
+ subclause defines the SARs;
+ a TOE summary specification, showing how
+ the SFRs are implemented in the TOE.
+
+ There also exists low assurance STs which have reduced
+ contents; these are described in detail in subclause . All other parts of this Annex assume an ST
+ with full contents.
+ A typical ST fulfils two roles:
+
+ Before and during the evaluation, the ST specifies
+ ``what is to be evaluated''. In this role, the ST serves
+ as a basis for agreement between the developer and the
+ evaluator on the exact security properties of the TOE
+ and the exact scope of the evaluation. Technical
+ correctness and completeness are major issues for this
+ role. Subclause describes how
+ the ST should be used in this role.
+
+ After the evaluation, the ST specifies ``what was
+ evaluated''. In this role, the ST serves as a basis for
+ agreement between the developer or re-seller of the TOE
+ and the potential consumer of the TOE. The ST describes
+ the exact security properties of the TOE in an abstract
+ manner, and the potential consumer can rely on this
+ description because the TOE has been evaluated to meet
+ the ST. Ease of use and understandability are major
+ issues for this role. Subclause describes how the ST should be used
+ in this role.
+
+ Two roles (among many) that an ST should not fulfil are:
+ a detailed specification: An ST is
+ designed to be a security specification on a relatively
+ high level of abstraction. An ST should, in general, not
+ contain detailed protocol specifications, detailed
+ descriptions of algorithms and/or mechanisms, long
+ description of detailed operations etc.
+ a complete specification: An ST is
+ designed to be a security specification and not a
+ general specification. Unless security-relevant,
+ properties such as interoperability, physical size and
+ weight, required voltage etc. should not be part of an
+ ST. This means that in general an ST may be a part of a
+ complete specification, but not a complete specification
+ itself.
+
+ The ST introduction describes the TOE in a narrative way on
+ three levels of abstraction:
+
+ the ST reference and the TOE reference, which provide
+ identification material for the ST and the TOE that the ST
+ refers to;
+
+ the TOE overview, which briefly describes the TOE;
+
+ the TOE description, which describes the TOE in more
+ detail.
+
+ An ST contains a clear ST reference that identifies that
+ particular ST. A typical ST reference consists of title,
+ version, authors and publication date. An example of an ST
+ reference is ``MauveRAM Database ST, version 1.3, MauveCorp
+ Specification Team, 11 October 2002''.
+ An ST also contains a TOE reference that identifies the TOE
+ that claims conformance to the ST. A typical TOE reference
+ consists of developer name, TOE name and TOE version
+ number. An example of a TOE reference is ``MauveCorp
+ MauveRAM Database v2.11''. As a single TOE may be evaluated
+ multiple times, for instance by different consumers of that
+ TOE, and therefore have multiple STs, this reference is not
+ necessarily unique.
+ If the TOE is constructed from one or more well-known
+ products, it is allowed to reflect this in the TOE
+ reference, by referring to the product name(s). However,
+ this should not be used to mislead consumers: situations
+ where major parts or security functionalities were not
+ considered in the evaluation, yet the TOE reference does not
+ reflect this are not allowed.
+ The ST reference and the TOE reference facilitate indexing
+ and referencing the ST and TOE and their inclusion in
+ summaries of lists of evaluated TOEs/Products.
+ The TOE overview is aimed at potential consumers of a TOE
+ who are looking through lists of evaluated TOEs/Products to
+ find TOEs that may meet their security needs, and are
+ supported by their hardware, software and firmware. The
+ typical length of a TOE overview is several paragraphs.
+ To this end, the TOE overview briefly describes the usage of
+ the TOE and its major security features, identifies the TOE
+ type and identifies any major non-TOE
+ hardware/software/firmware required by the TOE.
+ The description of the usage and major security features
+ of the TOE is intended to give a very general idea of what
+ the TOE is capable of in terms of security, and what it
+ can be used for in a security context. This subclause
+ should be written for (potential) TOE consumers,
+ describing TOE usage and major security features in terms
+ of business operations, using language that TOE consumers
+ understand.
+ An example of this is ``The MauveCorp MauveRAM Database
+ v2.11 is a multi-user database intended to be used in a
+ networked environment. It allows 1024 users to be active
+ simultaneously. It allows password/token and biometric
+ authentication, protects against accidental data
+ corruption, and can roll-back ten thousand
+ transactions. Its audit features are highly configurable,
+ so as to allow detailed audit to be performed for some
+ users and transactions, while protecting the privacy of
+ other users and transactions.''
+ The TOE overview identifies the general type of TOE, such
+ as: firewall, VPN-firewall, smart card, crypto-modem,
+ intranet, web server, database, web server and database,
+ LAN, LAN with web server and database, etc.
+ It may be the case that the TOE is not of a readily
+ available type, in which case ``none'' would be
+ acceptable.
+ In some cases, a TOE type can mislead consumers. Examples include:
+
+ certain functionality can be expected of the TOE
+ because of its TOE type, but the TOE does not have
+ this functionality. Examples include:
+
+ an ATM-card type TOE, which does not support any
+ identification/authentication functionality;
+
+ a firewall type TOE, which does not support
+ protocols that are almost universally used;
+
+ a PKI-type TOE, which has no certificate
+ revocation functionality.
+
+ the TOE can be expected to operate in certain
+ operational environments because of its TOE type, but
+ it cannot do so. Examples include:
+
+ a PC-operating system type TOE, which is unable to
+ function securely unless the PC has no network
+ connection, floppy drive, and CD/DVD-player;
+
+ a firewall, which is unable to function securely
+ unless all users that can connect through that
+ firewall are benign.
+
+ While some TOEs do not rely upon other IT, many TOEs
+ (notably software TOEs) rely on additional, non-TOE,
+ hardware, software and/or firmware. In the latter case,
+ the TOE overview is required to identify such non-TOE
+ hardware,software and/or firmware . A complete and fully
+ detailed identification of the additional hardware,
+ software and/or firmware is not necessary, but the
+ identification should be complete and detailed enough for
+ potential consumers to determine the major
+ hardware,software and/or firmware needed to use the TOE.
+ Example hardware/software/firmware identifications are:
+
+ a standard PC with a 1GHz or faster processor and
+ 512MB or more RAM, running version 3.0 Update 6b, c,
+ or 7, or version 4.0 of the Yaiza operating system;
+
+ a standard PC with a 1GHz or faster version processor
+ and 512MB or more RAM, running version 3.0 Update 6d
+ of the Yaiza operating system and the WonderMagic 1.0
+ Graphics card with the 1.0 WM Driver Set;
+
+ a standard PC with version 3.0 of the Yaiza OS (or
+ higher);
+
+ a CleverCard SB2067 integrated circuit;
+
+ a CleverCard SB2067 integrated circuit running v2.0 of
+ the QuickOS smart card operating system;
+
+ the December 2002 installation of the LAN of the
+ Director-General's Office of the Department of
+ Traffic.
+
+ A TOE description is a narrative description of the TOE,
+ likely to run to several pages. The TOE description should
+ provide evaluators and potential consumers with a general
+ understanding of the security capabilities of the TOE, in
+ more detail than was provided in the TOE overview. The TOE
+ description may also be used to describe the wider
+ application context into which the TOE will fit.
+ The TOE description discusses the physical scope of the TOE:
+ a list of all hardware, firmware, software and guidance
+ parts that constitute the TOE. This list should be described
+ at a level of detail that is sufficient to give the reader a
+ general understanding of those parts.
+ The TOE description should also discuss the logical scope of
+ the TOE: the logical security features offered by the TOE at
+ a level of detail that is sufficient to give the reader a
+ general understanding of those features. This description is
+ expected to be in more detail than the major security
+ features described in the TOE overview.
+ An important property of the physical and logical scopes is
+ that they describe the TOE in such a way that there remains
+ no doubt on whether a certain part or feature is in the TOE
+ or whether this part or feature is outside the TOE. This is
+ especially important when the TOE is intertwined with and
+ cannot be easily separated from non-TOE entities.
+ Examples where the TOE is intertwined with non-TOE entities
+ are:
+
+ the TOE is a cryptographic co-processor of a smart card
+ IC, instead of the entire IC;
+
+ the TOE is a smart card IC, except for the cryptographic
+ processor;
+
+ the TOE is the Network Address Translation part of the
+ MinuteGap Firewall v18.5.
+
+ This subclause of an ST describes how the ST conforms with:
+
+ Part 2 and Part 3 of this International Standard;
+
+ Protection Profiles (if any);
+
+ Packages (if any).
+
+ The description of how the ST conforms to the CC consists of
+ two items: the version of the CC that is used and whether the
+ ST contains extended security requirements or not (see
+ Subclause ).
+ The description of conformance of the ST to Protection
+ Profiles means that the ST lists the packages that conformance
+ is being claimed to. For an explanation of this, see Subclause
+ .
+ The description of conformance of the ST to packages means
+ that the ST lists the packages that conformance is being
+ claimed to. For an explanation of this, see Subclause .
+ The security problem definition defines the security problem
+ that is to be addressed. The security problem definition is,
+ as far as the CC is concerned, axiomatic. That is,
+ the process of deriving the security problem definition
+ falls outside the scope of the CC.
+ However, it should be noted that the usefulness of the
+ results of an evaluation strongly depends on the ST, and the
+ usefulness of the ST strongly depends on the quality of the
+ security problem definition. It is therefore often
+ worthwhile to spend significant resources and use
+ well-defined processes and analyses to derive a good
+ security problem definition.
+ Note that according to CC Part 3 it is not mandatory
+ to have statements in all subclauses, an ST with threats
+ does not need to have OSPs and vice versa. Also, any ST may
+ omit assumptions.
+ Also note that where the TOE is physically distributed, it
+ may be better to discuss the relevant threats, OSPs and
+ assumptions separately for distinct domains of the TOE
+ operational environment.
+ This subclause of the security problem definition shows
+ the threats that are to be countered by the TOE, its
+ operational environment, or a combination of the two.
+ A threat consists of an adverse action performed by a
+ threat agent on an asset.
+ Adverse actions are actions performed by a threat agent on
+ an asset. These actions influence one or more properties
+ of an asset from which that asset derives its value.
+ Threat agents may be described as individual entities, but
+ in some cases it may be better to describe them as types
+ of entities, groups of entities etc.
+ Examples of threat agents are hackers, users, computer
+ processes, and accidents. Threat agents may be further
+ described by aspects such as expertise, resources,
+ opportunity and motivation.
+ Examples of threats are:
+
+ a hacker (with substantial expertise, standard
+ equipment, and being paid to do so) remotely copying
+ confidential files from a company network;
+
+ a worm seriously degrading the performance of a
+ wide-area network;
+
+ a system administrator violating user privacy;
+
+ someone on the Internet listening in on confidential
+ electronic communication.
+
+ This subclause of the security problem definition shows
+ the OSPs that are to be enforced by the TOE, its
+ operational environment, or a combination of the two.
+ OSPs are security rules, procedures, or guidelines imposed
+ (or presumed to be imposed) now and/or in the future by an
+ actual or hypothetical organisation in the operational
+ environment. OSPs may be laid down by an organisation
+ controlling the operational environment of the TOE, or
+ they may be laid down by legislative or regulatory
+ bodies. OSPs can apply to the TOE and/or the operational
+ environment of the TOE.
+ Examples of OSPs are:
+
+ All products that are used by the Government must
+ conform to the National Standard for password
+ generation and encryption;
+
+ Only users with System Administrator privilege and
+ clearance of Department Secret shall be allowed to
+ manage the Department Fileserver.
+
+ This subclause of the security problem definition shows
+ the assumptions that are made on the operational
+ environment in order to be able to provide security
+ functionality. If the TOE is placed in an operational
+ environment that does not meet these assumptions, the TOE
+ may not be able to provide all of its security
+ functionality anymore. Assumptions can be on physical,
+ personnel and connectivity of the operational environment.
+ Examples of assumptions are:
+
+ Assumptions on physical aspects of the operational environment:
+
+ It is assumed that the TOE will be placed in a
+ room that is designed to minimise electromagnetic
+ emanations;
+
+ It is assumed that the administrator consoles of
+ the TOE will be placed in a restricted access
+ area.
+
+ Assumptions on personnel aspects of the operational
+ environment:
+
+ It is assumed that users of the TOE will be
+ trained sufficiently in order to operate the TOE;
+
+ It is assumed that users of the TOE are approved
+ for information that is classified as National
+ Secret;
+
+ It is assumed that users of the TOE will not write
+ down their passwords.
+
+ Assumptions on connectivity aspects of the operational
+ environment:
+
+ It is assumed that a PC workstation with at least
+ 10GB of disk space is available to run the TOE on;
+
+ It is assumed that the TOE is the only non-OS
+ application running on this workstation;
+
+ It is assumed that the TOE will not be connected
+ to an untrusted network.
+
+ Note that during the evaluation these assumptions are
+ considered to be true: they are not tested in any way. For
+ these reasons, assumptions can only be made on the
+ operational environment. Assumptions can never be made on
+ the behaviour of the TOE because an evaluation consists of
+ evaluating assertions made about the TOE and not by
+ assuming that assertions on the TOE are true.
+ The security objectives are a concise and abstract statement
+ of the intended solution to the problem defined by the
+ security problem definition. The role of the security
+ objectives is threefold:
+
+ provide a high-level, natural language solution of the
+ problem;
+
+ divide this solution into two part wise solutions, that
+ reflect that different entities each have to address a
+ part of the problem;
+
+ demonstrate that these part wise solutions form a
+ complete solution to the problem.
+
+ The security objectives consist of a set of short and
+ clear statements without overly much detail that together
+ form a high-level solution to the security problem. The
+ level of abstraction of the security objectives aims at
+ being clear and understandable to knowledgeable potential
+ consumers of the TOE. The security objectives are in
+ natural language.
+ In an ST the high-level security solution, as described by
+ the security objectives, is divided into two part wise
+ solutions. These part wise solutions are called the
+ security objectives for the TOE and the security
+ objectives for the operational environment. This reflects
+ that these part wise solutions are to be provided by two
+ different entities: the TOE, and the operational
+ environment.
+ The TOE provides security functionality to solve a
+ certain part of the problem defined by the security
+ problem definition. This part wise solution is called
+ the security objectives for the TOE and consists of a
+ set of objectives that the TOE should achieve in order
+ to solve its part of the problem.
+ Examples of security objectives for the TOE are:
+
+ The TOE shall keep confidential the content of all
+ files transmitted between it and a Server;
+
+ The TOE shall identify and authenticate all users
+ before allowing them access to the Transmission
+ Service provided by the TOE;
+
+ The TOE shall restrict user access to data according
+ to the Data Access policy described in Annex 3 of
+ the ST.
+
+ If the TOE is physically distributed, it may be better
+ to subdivide the ST subclause containing the security
+ objectives for the TOE into several sub-subclauses to
+ reflect this.
+ The operational environment of the TOE implements
+ technical and procedural measures to assist the TOE in
+ correctly providing its security functionality (which is
+ defined by the security objectives for the TOE). This
+ part wise solution is called the security objectives for
+ the operational environment and consists of a set of
+ statements describing the goals that the operational
+ environment should achieve.
+ Examples of security objectives for the operational
+ environment are:
+
+ The operational environment shall provide a
+ workstation with the OS Inux version 3.01b to
+ execute the TOE on;
+
+ The operational environment shall ensure that all
+ human TOE users receive appropriate training before
+ allowing them to work with the TOE;
+
+ The operational environment of the TOE shall
+ restrict physical access to the TOE to
+ administrative personnel and maintenance personnel
+ accompanied by administrative personnel;
+
+ The operational environment shall ensure the
+ confidentiality of the audit logs generated by the
+ TOE before sending them to the central Audit Server.
+
+ If the operational environment of the TOE consists of
+ multiple sites, each with different properties, it may
+ be better to subdivide the ST subclause containing the
+ security objectives for the operational environment into
+ several sub-subclauses to reflect this.
+ The ST also contains a security objectives rationale
+ containing two subclauses:
+
+ a tracing that shows which security objectives
+ address which threats, OSPs and assumptions;
+
+ a set of justifications that shows that all threats,
+ OSPs, and assumptions are effectively addressed by
+ the security objectives.
+
+ The tracing shows how the security objectives trace
+ back to the threats, OSPs and assumptions as described
+ in the security problem definition.
+ No spurious objectives: Each
+ security objective traces to at least one threat,
+ OSP or assumption.
+ Complete with respect to the security
+ problem definition: Each threat, OSP and
+ assumption has at least one security objective
+ tracing to it.
+ Correct tracing: Since
+ assumptions are always made by the TOE on the
+ operational environment, security objectives for
+ the TOE do not trace back to assumptions. The
+ tracings allowed by CC Part 3 are depicted in
+ Figure .
+
+ Multiple security objectives may trace to the same
+ threat, indicating that the combination of those
+ security objectives counters that threat. A similar
+ argument holds for OSPs and assumptions.
+ The security objectives rationale also demonstrates
+ that the tracing is effective: All the given threats,
+ OSPs and assumption are addressed (i.e. countered,
+ enforced and upheld respectively) if all security
+ objectives tracing to a particular threat, OSP or
+ assumption are achieved.
+ This demonstration analyses the effect of achieving
+ the relevant security objectives on countering the
+ threats, enforcing the OSPs and upholding the
+ assumptions and leads to the conclusion that this is
+ indeed the case.
+ In some cases, where parts of the security problem
+ definition very closely resemble some security
+ objectives, the demonstration can be very simple. An
+ example is: a threat ``T17: Threat agent X reads the
+ Confidential Information in transit between A and B'',
+ a security objective for the TOE: ``OT12: The TOE
+ shall ensure that all information transmitted between
+ A and B is kept confidential'', and a demonstration
+ ``T17 is directly countered by OT12''.
+ Countering a threat does not necessarily mean removing
+ that threat, it can also mean sufficiently diminishing
+ that threat or sufficiently mitigating that threat.
+ Examples of removing a threat are:
+
+ removing the ability to execute the adverse action
+ from the threat agent;
+
+ moving, changing or protecting the asset in such a
+ way that the adverse action is no longer
+ applicable to it;
+
+ removing the threat agent (e.g. removing machines
+ from a network that frequently crash that
+ network).
+
+ Examples of diminishing a threat are:
+
+ restricting the ability of a threat agent to
+ perform adverse actions;
+
+ restricting the opportunity to execute an adverse
+ action of a threat agent;
+
+ reducing the likelihood of an executed adverse
+ action being successful;
+
+ reducing the motivation to execute an adverse
+ action of a threat agent by deterrence;
+
+ requiring greater expertise or greater resources
+ from the threat agent.
+
+ Examples of mitigating the effects of a threat are:
+
+ making frequent back-ups of the asset;
+
+ obtaining spare copies of an asset;
+
+ insuring an asset;
+
+ ensuring that successful adverse actions are
+ always timely detected, so that appropriate action
+ can be taken.
+
+ Based on the security objectives and the security
+ objectives rationale, the following conclusion can be
+ drawn: if all security objectives are achieved then the
+ security problem as defined in is
+ solved: all threats are countered, all OSPs are
+ enforced, and all assumptions are upheld.
+ In many cases the security requirements (see the next
+ subclause) in an ST are based on components in CC Part 2
+ or CC Part 3. However, in some cases, there may be
+ requirements in an ST that are not based on components in
+ CC Part 2 or CC Part 3. In this case, new components
+ (extended components) must be defined, and this definition
+ should be done in the Extended Components Definition. For
+ more information on this, see Annex .
+ Note that this subclause is intended to contain only the
+ extended components and not the extended requirements
+ (requirements based on extended components). The extended
+ requirements should be included in the security
+ requirements (see the next subclause) and are for all
+ purposes the same as requirements based on components in
+ CC Part 2 or CC Part 3.
+ The security requirements consist of two groups of
+ requirements:
+ the security functional requirements
+ (SFRs): a translation of the security objectives for the
+ TOE into a standardised language;
+ the security assurance requirements
+ (SARs): a description of how assurance is to be gained
+ that the TOE meets the SFRs.
+
+ These two groups are discussed in the following two subclauses:
+ The SFRs are a translation of the security objectives for
+ the TOE. They are usually at a more detailed level of
+ abstraction, but they have to be a complete translation
+ (the security objectives must be completely addressed) and
+ be independent of any specific technical solution
+ (implementation). The CC requires this translation into a
+ standardised language for several reasons:
+
+ to provide an exact description of what is to be
+ evaluated. As security objectives for the TOE are
+ usually formulated in natural language, translation
+ into a standardised language enforces a more exact
+ description of the functionality of the TOE.
+
+ to allow comparison between two STs. As different ST
+ authors may use different terminology in describing
+ their security objectives, the standardised language
+ enforces using the same terminology and concepts. This
+ allows easy comparison.
+
+ There is no translation required in the CC for the
+ security objectives for the operational environment,
+ because the operational environment is not evaluated and
+ does therefore not require a description aimed at its
+ evaluation. See the bibliography for items relevant to the
+ security assessment of operational systems.
+ It may be the case that parts of the operational
+ environment are evaluated in another evaluation, but this
+ is out of scope for the current evaluation. For example:
+ an OS TOE may require a firewall to be present in its
+ operational environment. Another evaluation may
+ subsequently evaluate the firewall, but this evaluation
+ has nothing to do with the evaluation of the OS TOE.
+ The CC supports this translation in three ways:
+
+ by providing a predefined precise ``language''
+ designed to describe exactly what is to be
+ evaluated. This language is defined as a set of
+ components defined in CC Part 2. The use of this
+ language as a well-defined translation of the
+ security objectives for the TOE to SFRs is
+ mandatory, though some exceptions exist (see
+ Subclause ).
+
+ by providing operations: mechanisms that allow the
+ ST writer to modify the SFRs to provide a more
+ accurate translation of the security objectives for
+ the TOE. This part of the CC defines the four
+ allowed operations: assignment, selection,
+ iteration, and refinement. These are described
+ further in Subclause .
+
+ by providing dependencies: a mechanism that supports
+ a more complete translation to SFRs. In the CC Part
+ 2 language, an SFR can have a dependency on other
+ SFRs. This signifies that if an ST uses that SFR, it
+ generally needs to use those other SFRs as
+ well. This makes it much harder for the ST writer to
+ overlook including necessary SFRs and thereby
+ improves the completeness of the ST. Dependencies
+ are described further in Subclause .
+
+ The ST also contains a security requirements rationale,
+ consisting of two subclauses about SFRs:
+
+ a tracing that shows which SFRs address which
+ security objectives for the TOE;
+
+ a set of justifications that shows that all security
+ objectives for the TOE are effectively addressed by
+ the SFRs.
+
+ The tracing shows how the SFRs trace back to the
+ security objectives for the TOE as follows:
+ No spurious SFRs: Each SFR traces
+ back to at least one security objective.
+ Complete with respect to the security
+ objectives for the TOE: Each security
+ objective for the TOE has at least one SFR tracing
+ to it.
+
+ Multiple SFRs may trace to the same security objective
+ for the TOE, indicating that the combination of those
+ security requirements meets that security objective
+ for the TOE.
+ The security requirements rationale demonstrates that
+ the tracing is effective: if all SFRs tracing to a
+ particular security objective for the TOE are
+ satisfied, that security objective for the TOE is
+ achieved.
+ This demonstration should analyse the effects of
+ satisfying the relevant SFRs on achieving the security
+ objective for the TOE and lead to the conclusion that
+ this is indeed the case.
+ In cases where SFRs very closely resemble security
+ objectives for the TOE, the demonstration can be very
+ simple.
+ The SARs are a description of how the TOE is to be
+ evaluated. This description uses a standardised language
+ for two reasons:
+
+ to provide an exact description of how the TOE is to
+ be evaluated. Using a standardised language assists in
+ creating an exact description and avoids ambiguity.
+
+ to allow comparison between two STs. As different ST
+ authors may use different terminology in describing
+ the evaluation, the standardised language enforces
+ using the same terminology and concepts. This allows
+ easy comparison.
+
+ This standardised language is defined as a set of
+ components defined in CC Part 3. The use of this
+ language is mandatory, though some exceptions
+ exist. The CC enhances this language in two ways:
+
+ by providing operations: mechanisms that allow the ST
+ writer to modify the SARs. The CC has four operations:
+ assignment, selection, iteration, and
+ refinement. These are described further in Subclause
+ .
+
+ by providing dependencies: a mechanism that supports a
+ more complete translation to SARs. In CC Part 3
+ language, an SAR can have a dependency on other
+ SARs. This signifies that if an ST uses that SAR, it
+ generally needs to use those other SARs as well. This
+ makes it much harder for the ST writer to overlook
+ including necessary SARs and thereby improves the
+ completeness of STs. Dependencies are described
+ further in Subclause .
+
+ The ST also contains a security requirements rationale
+ that explains why this particular set of SARs was deemed
+ appropriate. There are no specific requirements for this
+ explanation. The goal for this explanation is to allow the
+ readers of the ST to understand the reasons why this
+ particular set was chosen.
+ An example of an inconsistency is if the security problem
+ description mentions threats where the threat agent is
+ very capable, and a low (or no) is
+ included in the SARs.
+ In the security problem definition of the ST, the security
+ problem is defined as consisting of threats, OSPs and
+ assumptions. In the security objectives subclause of the
+ ST, the solution is provided in the form of two
+ sub-solutions:
+
+ security objectives for the TOE;
+
+ security objectives for the operational environment.
+
+ Additionally, a security objectives rationale is provided
+ showing that if all security objectives are achieved, the
+ security problem is solved: all threats are countered, all
+ OSPs are enforced, and all assumptions are upheld.
+ In the security requirements subclause of the ST, the
+ security objectives for the TOE are translated to SFRs and
+ a security requirements rationale is provided showing that
+ if all SFRs are satisfied, all security objectives for the
+ TOE are achieved.
+ Additionally, a set of SARs is provided to show how the
+ TOE is evaluated, together with an explanation for
+ selecting these SARs.
+ All of the above can be combined into the statement: If
+ all SFRs and SARs are satisfied and all security
+ objectives for the operational environment are achieved,
+ then there exists assurance that the security problem as
+ defined in is solved: all
+ threats are countered, all OSPs are enforced, and all
+ assumptions are upheld. This is illustrated in Figure
+ .
+ The amount of assurance obtained is defined by the SARs,
+ and whether this amount of assurance is sufficient is
+ defined by the explanation for choosing these SARs.
+ The objective for the TOE summary specification is to provide
+ potential consumers of the TOE with a description of how the
+ TOE satisfies all the SFRs. The TOE summary specification
+ should provide the general technical mechanisms that the TOE
+ uses for this purpose. The level of detail of this description
+ should be enough to enable potential consumers to understand
+ the general form and implementation of the TOE.
+ For instance if the TOE is an Internet PC and the SFRs contain
+ to specify authentication,
+ the TOE summary specification should indicate how this
+ authentication is done: password, token, iris scanning
+ etc. More information, like applicable standards that the TOE
+ uses to meet SFRs, or more detailed descriptions may also be
+ provided.
+ After the evaluation, the ST specifies ``what was
+ evaluated''. In this role, the ST serves as a basis for
+ agreement between the developer or re-seller of the TOE and
+ the potential consumer of the TOE. The ST can therefore answer
+ the following questions (and more):
+ How can I find the ST/TOE that I need given the
+ multitude of existing STs/TOEs? This question is
+ addressed by the TOE overview, which gives a brief
+ (several paragraphs) summary of the TOE;
+ Does this TOE fit in with my existing
+ IT-infrastructure? This question is addressed by
+ the TOE overview, which identifies the major
+ hardware/firmware/software elements needed to run the TOE;
+ Does this TOE fit in with my existing operational
+ environment? This question is addressed by the
+ security objectives for the operational environment, which
+ identifies all constraints the TOE places on the
+ operational environment in order to function;
+ What does the TOE do (interested reader)?
+ This question is addressed by the TOE overview, which
+ gives a brief (several paragraphs) summary of the TOE;
+ What does the TOE do (potential
+ consumer)? This question is addressed by the TOE
+ description, which gives a less brief (several pages)
+ summary of the TOE;
+ What does the TOE do (technical)? This
+ question is addressed by the TOE summary specification
+ which provides a high-level description of the mechanisms
+ the TOE uses;
+ What does the TOE do (expert)? This
+ question is addressed by the SFRs which provide an
+ abstract highly technical description, and the TOE summary
+ specification which provide additional detail;
+ Does the TOE address the problem as defined by my
+ government/organisation? If your
+ government/organisation has defined packages and/or PPs to
+ define this solution, then the answer can be found in the
+ Conformance Claims subclause of the ST, which lists all
+ packages and PPs that the ST conforms to
+ Does the TOE address my security problem
+ (expert)? What are the threats countered by the
+ TOE? What organisational security policies does it
+ enforce? What assumptions does it make about the
+ operational environment? These questions are addressed by
+ the security problem definition;
+ How much trust can I place in the TOE?
+ This can be found in the SARs in the security requirements
+ subclause, which provide the assurance level that was used
+ to evaluate the TOE, and hence the trust that the
+ evaluation provides in the correctness of the TOE.
+
+ Writing an ST is not a trivial task, and may, especially in
+ low assurance evaluations, be a major part of the total effort
+ expended by the developer and the evaluator in the whole of
+ the evaluation. For this reason, it is also possible to write
+ a low assurance ST.
+ The CC allows the use of a low assurance ST for an EAL 1
+ evaluation, but not for EAL 2 and up. A low-assurance ST may
+ only claim conformance to a low-assurance PP (see ). A regular ST
+ (i.e., one with full contents) may claim conformance with a
+ low assurance PP.
+ A low assurance ST has a significantly reduced content
+ compared to a regular ST:
+
+ there is no need to describe the security problem definition;
+
+ there is no need to describe the security objectives for
+ the TOE. The security objectives for the operational
+ environment must still be described;
+
+ there is no need to describe the security objectives
+ rationale as there is no security problem definition in
+ the ST;
+
+ the security requirements rationale only needs to justify
+ (any) dependencies not being satisfied as there are no
+ security objectives for the TOE in the ST.
+
+ All that remains are:
+
+ the references to TOE and ST;
+
+ a conformance claim;
+
+ the various narrative descriptions;
+
+ the TOE overview;
+
+ the TOE description;
+
+ the TOE summary specification.
+
+ security objectives for the operational environment;
+
+ the SFRs and the SARs (including the extended components
+ definition) and the security requirements rationale (only
+ if the dependencies are not satisfied).
+
+ The reduced content of a low assurance ST is shown in Figure
+ .
+ In some cases, an ST writer may wish to refer to an external
+ standard, such as a particular cryptographic standard or
+ protocol. The CC allows three ways of doing this:
+
+ As an organisational security policy (or part of it).
+
+ If, for example, there exists a government standard
+ defining how passwords have to be chosen, this may be
+ stated as an organisational security policy in an
+ ST. This may lead to an objective for the environment
+ (e. g. if users of the TOE need to choose passwords
+ accordingly), or it may lead to security objectives for
+ the TOE and then to appropriate SFRs (likely of the
+ class), if the TOE generates
+ passwords. In both cases the rationale of the developer
+ needs to make plausible that the security objectives for
+ the TOE and the SFRs are suitable to fulfil the OSP. The
+ evaluator will examine if this is in fact plausible (and
+ may decide to look into the standard for this), if the
+ OSP is implemented by SFRs, as explained below.
+ As a technical standard (for example a cryptographic
+ standard) used in a refinement of an SFR.
+
+ In this case conformance to the standard is part of the
+ fulfilment of the SFR by the TOE and is treated as if
+ the full text of the standard is part of the
+ SFR. Conformance is subsequently determined like any
+ other conformance to SFRs: during and
+ it is analysed, by design analysis and
+ tests, that the SFR is completely and fully implemented
+ in the TOE. If reference to only a certain part of a
+ standard is desired, that part should be unambiguously
+ stated in the SFR refinement.
+ As a technical standard (for example a cryptographic
+ standard) mentioned in the TOE summary specification.
+
+ The TOE summary specification is only considered as an
+ explanation of how the SFRs are realised, and is not
+ strictly used as a strict implementation requirement
+ like the SFRs or the documents delivered for . So the evaluator may detect an inconsistency
+ if the TSS references a technical standard and this is
+ not reflected in documentation, but
+ there is no routine activity to test fulfilment of the
+ standard.
+ The goal of this Annex is to explain the Protection Profile
+ (PP) concept. This Annex does not define the criteria; this definition can be found in
+ CC Part 3 and is supported by the documents given in the
+ bibliography.
+ As PPs and STs have a significant overlap, this Annex focuses
+ on the differences between PPs and STs. The material that is
+ identical between STs and PPs is described in .
+ This annex consists of four major parts:
+ What a PP must contain. This is
+ summarised in Subclause , and described in more detail
+ in Subclauses -. These clauses describe the
+ mandatory contents of the PP, the interrelationships
+ between these contents, and provide examples.
+ How a PP should be used. This is
+ summarised in Subclause .
+ Low Assurance PPs. Low Assurance PPs are
+ PPs with reduced content. They are described in detail in
+ Subclause .
+ Claiming compliance with
+ standards. Subclause describes how a PP writer can claim that
+ the TOE is to meet a particular standard.
+
+ Figure portrays the
+ mandatory content for a PP that is given in
+ CC Part 3. Figure may
+ also be used as a structural outline of the PP, though
+ alternative structures are allowed. For instance, if the
+ security requirements rationale is particularly bulky, it
+ could be included in an appendix of the PP instead of in the
+ security requirements subclause. The separate subclauses of a
+ PP and the contents of those subclauses are briefly summarised
+ below and explained in much more detail in Subclauses - . A
+ PP contains:
+
+ a PP introduction containing a narrative
+ description of the TOE type;
+
+ a conformance claim, showing whether the
+ PP claims conformance to any PPs and/or packages, and if
+ so, to which PPs and/or packages;
+
+ a security problem definition, showing
+ threats, OSPs and assumptions;
+ security objectives, showing how the
+ solution to the security problem is divided between
+ security objectives for the TOE and security objectives
+ for the operational environment of the TOE;
+ extended components definition, where new
+ components (i.e. those not included in CC Part 2 or
+ CC Part 3) may be defined. These new components are
+ needed to define extended functional and extended
+ assurance requirements;
+ security requirements, where a
+ translation of the security objectives for the TOE into a
+ standardised language is provided. This standardised
+ language is in the form of SFRs. Additionally this
+ subclause defines the SARs;
+
+ There also exist low assurance PPs, which have reduced
+ contents; these are described in detail in Subclause . With this exception, all other
+ parts of this Annex assume a PP with full contents.
+ A PP is typically a statement of need where a user
+ community, a regulatory entity, or a group of developers
+ define a common set of security needs. A PP gives consumers
+ a means of referring to this set, and facilitates future
+ evaluation against these needs.
+ A PP is therefore typically used as:
+
+ part of a requirement specification for a specific
+ consumer or group of consumers, who will only consider
+ buying a specific type of IT if it meets the PP;
+
+ part of a regulation from a specific regulatory entity,
+ who will only allow a specific type of IT to be used if
+ it meets the PP;
+
+ a baseline defined by a group of IT developers, who then
+ agree that all IT that they produce of this type will
+ meet this baseline.
+
+ though this does not preclude other uses.
+ Three roles (among many) that a PP should not fulfil are:
+ a detailed specification: A PP is
+ designed to be a security specification on a relatively
+ high level of abstraction. A PP should, in general, not
+ contain detailed protocol specifications, detailed
+ descriptions of algorithms and/or mechanisms, long
+ description of detailed operations etc.
+ a complete specification: A PP is
+ designed to be a security specification and not a general
+ specification. Unless security-relevant, properties such
+ as interoperability, physical size and weight, required
+ voltage etc. should not be part of a PP. This means that
+ in general a PP is a part of a complete specification, but
+ not a complete specification itself.
+ a specification of a single product:
+ Unlike an ST, a PP is designed to describe a certain type
+ of IT, and not a single product. When only a single
+ product is described, it is better to use an ST for this
+ purpose.
+
+ The PP introduction describes the TOE in a narrative way on
+ two levels of abstraction:
+
+ the PP reference, which provides identification material
+ for the PP;
+
+ the TOE overview, which briefly describes the TOE.
+
+ A PP contains a clear PP reference that identifies that
+ particular PP. A typical PP reference consists of title,
+ version, authors and publication date. An example of a PP
+ reference is ``Atlantean Navy CablePhone Encryptor PP,
+ version 2b, Atlantean Navy Procurement Office, April 7,
+ 2003''. The reference must be unique so that it is possible
+ to tell different PPs and different versions of the same PP
+ apart.
+ The PP reference facilitates indexing and referencing the PP
+ and its inclusion in lists of PPs.
+ The TOE overview is aimed at potential consumers of a TOE
+ who are looking through lists of evaluated products to find
+ TOEs that may meet their security needs, and are supported
+ by their hardware, software and firmware.
+ The TOE overview is also aimed at developers who may use the
+ PP in designing TOEs or in adapting existing products.
+ The typical length of a TOE overview is several paragraphs.
+ To this end, the TOE overview briefly describes the usage of
+ the TOE and its major security features, identifies the TOE
+ type and identifies any major non-TOE
+ hardware/software/firmware available to the TOE.
+ The description of the usage and major security features
+ of the TOE is intended to give a very general idea of what
+ the TOE should be capable of, and what it can be used
+ for. This subclause should be written for (potential) TOE
+ consumers, describing TOE usage and major security
+ features in terms of business operations, using language
+ that TOE consumers understand.
+ An example of this is ``The Atlantean Navy CablePhone
+ Encryptor is an encryption device that should allow
+ confidential communication between ships across the
+ Atlantean Navy CablePhone system. To this end it should
+ allow at least 32 different users and support at least 100
+ Mbps encryption speed. It should allow both bilateral
+ communication between ships and broadcast across the
+ entire network.''
+ The TOE overview identifies the general type of TOE, such
+ as: firewall, VPN-firewall, smart card, crypto-modem,
+ intranet, web server, database, web server and database,
+ LAN, LAN with web server and database, etc.
+ While some TOEs do not rely upon other IT, many TOEs
+ (notably software TOEs) rely on additional, non-TOE,
+ hardware, software and/or firmware. In the latter case,
+ the TOE overview is required to identify the non-TOE
+ hardware/software/firmware.
+ As a Protection Profile is not written for a specific
+ product, in many cases only a general idea can be given of
+ the available hardware/software/firmware. In some other
+ cases, e.g. a requirements specification for a specific
+ consumer where the platform is already known, (much) more
+ specific information may be provided.
+ Examples of hardware/software/firmware identifications
+ are:
+
+ None. (for a completely stand-alone TOE);
+
+ The Yaiza 3.0 Operating System running on a general
+ PC;
+
+ a CleverCard SB2067 integrated circuit;
+
+ a CleverCard SB2067 IC running v2.0 of the QuickOS
+ smart card operating system;
+
+ the December 2002 installation of the LAN of the
+ Director-General's Office of the Department of
+ Traffic.
+
+ This subclause of a PP describes how the PP conforms with
+ other PPs and with packages. It is identical to the
+ conformance claims subclause for an ST (see Subclause ), with one exception:
+ the conformance statement.
+ The conformance statement in the PP states how STs and/or
+ other PPs must conform to that PP. The PP author selects
+ whether ``strict'' or ``demonstrable'' conformance is
+ required. See
+ for more details on this.
+ This subclause is identical to the security problem definition
+ subclause of an ST as explained in Subclause .
+ This subclause is identical to the security objectives subclause
+ of an ST as explained in Subclause .
+ This subclause is identical to the extended components subclause
+ of an ST as explained in Subclause .
+ This subclause is identical to the security requirements
+ subclause of an ST as explained in Subclause . Note however that the rules for completing
+ operations in a PP are slightly different from the rules for
+ completing operations in an ST. This is explained in more
+ detail in Subclause .
+ A PP has no TOE summary specification.
+ A low assurance PP has the same relationship to a regular PP
+ (i.e., one with full contents), as a low assurance ST has to a
+ regular ST. This means that a low-assurance PP consists of
+
+ a PP introduction, consisting of a PP reference and a TOE
+ overview;
+
+ a conformance claim;
+
+ security objectives for the operational environment;
+
+ the SFRs and the SARs (including the extended components
+ definition) and the security requirements rationale (only
+ if the dependencies are not satisfied).
+
+ A low-assurance PP may only claim conformance to a
+ low-assurance PP (see ). A
+ regular PP may claim conformance with a low assurance PP.
+ The reduced content of a low assurance PP is shown in Figure
+ .
+ This subclause is identical to the subclause on standards for
+ STs as described in Subclause , with one exception: as a PP has no TOE
+ summary specification, the third option is not valid for PPs.
+ The PP author is reminded that referring to a standard in SFRs
+ may impose a significant burden on a developer developing a
+ TOE to meet that PP (depending on the size and complexity of
+ the standard and the assurance level required), and that it
+ may be more suitable to require alternative (non-CC related)
+ ways to assess conformance to that standard.
+ As described in this CC part 1, Protection Profiles and
+ Security Targets contain pre-defined security requirements, as
+ well as providing PP and ST authors the ability to extend the
+ component lists in some circumstances.
+ The four types of operations are given in section . Examples of the various
+ operations are described below:
+ As described in section
+ the iteration operation may be performed on every
+ component. The PP/ST author performs an iteration operation
+ by including multiple requirements based on the same
+ component. Each iteration of a component is different from
+ all other iterations of that component, which is realised by
+ completing assignments and selections in a different way, or
+ by applying refinements to it in a different way. Different
+ iterations should be uniquely identified to allow clear
+ rationales and tracings to and from these requirements.
+ A typical example of an iteration is
+ being iterated twice in order to require the implementation
+ of two different cryptographic algorithms. An example of
+ each iteration being uniquely identified is:
+
+ Cryptographic operation (RSA and DSA signatures)
+ (FCS_COP.1(1))
+
+ Cryptographic operation (TLS/SSL: symmetric operations)
+ (FCS_COP.1(2))
+
+ As described in subclause
+ an assignment operation occurs where a given component
+ contains an element with a parameter that may be set by the
+ PP/ST author. The parameter may be an unrestricted variable,
+ or a rule that narrows the variable to a specific range of
+ values.
+ An example of an element with an assignment is: ``When the defined number of
+ unsuccessful authentication attempts has been met or
+ surpassed, the TSF shall [assignment: list of
+ actions].''
+ As described in subclause
+ the selection operation occurs where a given component
+ contains an element where a choice from several items has to
+ be made by the PP/ST author.
+ An example of an element with a selection is: ``The TSF shall run a suite of
+ self tests [selection: during initial start-up, periodically
+ during normal operation, at the request of the authorised
+ user, at the conditions [assignment: conditions under which
+ self test should occur]] to demonstrate the correct
+ operation of ...''
+ As described in subclause
+ the refinement operation can be performed on every
+ requirement. The PP/ST author performs a refinement by
+ altering that requirement.
+ An example of a valid refinement is ``The TSF shall require each user to be
+ successfully authenticated before allowing any other
+ TSF-mediated actions on behalf of that user.'' being refined
+ to ``The TSF shall require each user to be successfully
+ authenticated by username/password before
+ allowing any other TSF-mediated actions on behalf of that
+ user.''
+ The first rule for a refinement is that a TOE meeting the
+ refined requirement also meets the unrefined requirement in
+ the context of the PP/ST (i.e. a refined requirement must be
+ ``stricter'' than the original requirement)
+ The only exception to this rule is that a PP/ST author is
+ allowed to refine a SFR to apply to some but not all
+ subjects, objects, operations, security attributes and/or
+ external entities.
+ An example of a such an exception is ``The TSF shall require each user to be
+ successfully authenticated before allowing any other
+ TSF-mediated actions on behalf of that user.'' being refined
+ to ``The TSF shall require each user originating from
+ the internet to be successfully authenticated before
+ allowing any other TSF-mediated actions on behalf of that
+ user.''
+ The second rule for a refinement given is that the
+ refinement shall be related to the original component. For
+ example, refining an audit component with an extra element
+ on prevention of electromagnetic radiation is not allowed.
+ A special case of refinement is an editorial refinement,
+ where a small change is made in a requirement,
+ i.e. rephrasing a sentence due to adherence to proper
+ English grammar, or to make it more understandable to the
+ reader. This change is not allowed to modify the meaning of
+ the requirement in any way. Examples of editorial
+ refinements include:
+
+ the SFR ``The TSF shall
+ continue to preserve a secure state when the following
+ failures occur: breakdown of one CPU''
+ could be refined to
+ ``The TSF shall continue to preserve a secure state when
+ the following failure occurs: breakdown of one
+ CPU'' or even
+ ``The TSF shall continue to preserve a secure state when
+ one CPU breaks down''.
+
+ The CC has organised the components in CC Part 2 and CC Part 3
+ into hierarchical structures:
+ Classes, consisting ofFamilies, consisting ofComponents, consisting ofElements.
+ This organisation into a hierarchy of class - family -
+ component - element is provided to assist consumers,
+ developers and evaluators in locating specific components.
+ The CC presents functional and assurance components in
+ the same general hierarchical style and use the same
+ organisation and terminology for each.
+ An example of a class is the class that is
+ focused at identification of users, authentication of users
+ and binding of users and subjects.
+ An example of a family is the family
+ which is part of the class. This family
+ concentrates on the authentication of users.
+ An example of a component is which
+ concentrates on unforgeable authentication.
+ An example of an element is which
+ concentrates on the prevention of use of copied
+ authentication data.
+ Whenever a PP/ST author defines an extended component,
+ this has to be done in a similar manner to the existing CC
+ components: clear, unambiguous and evaluatable (it is
+ possible to systematically demonstrate whether a
+ requirement based on that component holds for a
+ TOE). Extended components must use similar labelling,
+ manner of expression, and level of detail as the existing
+ CC components.
+ The PP/ST author also has to make to sure that all
+ applicable dependencies of an extended component are
+ included in the definition of that extended
+ component. Examples of possible dependencies are:
+
+ if an extended component refers to auditing,
+ dependencies to components of the
+ class may have to be included;
+
+ if an extended component modifies or accesses data,
+ dependencies to components of the
+ family may have to be included;
+
+ if an extended component uses a particular design
+ description a dependency to the appropriate family (e.g. Functional Specification) may
+ have to be included.
+
+ In the case of an extended functional component, the PP/ST
+ author also has to include any applicable audit and
+ associated operations information in the definition of
+ that component, similar to existing CC Part 2
+ components. In the case of an extended assurance
+ component, the PP/ST author also has to provide suitable
+ evaluation methodology for the component, similar to the
+ methodology provided in the CEM.
+ Extended components may be placed in existing families, in
+ which case the PP/ST writer has to show how these families
+ change. If they do not fit into an existing family, they
+ shall be placed in a new family. New families have to be
+ defined similarly to the CC.
+ New families may be placed in existing classes in which
+ case the PP/ST writer has to show how these classes
+ change. If they do not fit into an existing class, they
+ shall be placed in a new class. New classes have to be
+ defined similarly to the CC.
+ A PP is intended to be used as a ``template'' for an ST. That
+ is: the PP describes a set of user needs, while an ST that
+ conforms to that PP describes a TOE that satisfies those
+ needs.
+ Note that it is also possible for a PP to be used as a
+ template for another PP. That is PPs can claim conformance to
+ other PPs. This case is completely similar to that of an ST
+ vs. a PP. For clarity this Annex describes only the ST/PP
+ case, but it holds also for the PP/PP case.
+ The CC does not allow any form of partial conformance, so if a
+ PP is claimed, the PP or ST must fully conform to the
+ referenced PP or PPs. There are however two types of
+ conformance (``strict'' and demonstrable'') and the type of
+ conformance allowed is determined by the PP. That is, the PP
+ states (in the PP conformance statement, see subclause ) what the allowed types of conformance for the ST
+ are. This distinction between strict and demonstrable
+ conformance is applicable to each PP to which an ST may claim
+ conformance on an individual basis. This may mean that the ST
+ conforms strictly to some PPs and demonstrably to other
+ PPs. An ST is only allowed to conform to a PP in a
+ demonstrable manner, if the PP explicitly allows this, whereas
+ an ST can always conform with strict conformance to any PP.
+ Restating this in other words, an ST is only allowed to
+ conform to a PP in a demonstrable manner, if the PP explicitly
+ allows this.
+ Conformance to a PP means that the PP or ST (and if an ST is
+ of an evaluated product, the product as well) meets all
+ requirements of that PP.
+ Published PPs will normally require demonstrable
+ conformance. This means that STs claiming conformance with the
+ PP must offer a solution to the generic security problem
+ described in the PP, but can do so in any way that is
+ equivalent or more restrictive to that described in the
+ PP. ``Equivalent but more restrictive'' is defined at length
+ within the CC, but in principle it means that the PP
+ and ST may contain entirely different statements that discuss
+ different entities, use different concepts etc., provided that
+ overall the ST levies the same or more restrictions on the
+ TOE, and the same or less restrictions on the operational
+ environment of the TOE.
+ Strict conformance is oriented to the PP-author who requires
+ evidence that the requirements in the PP are met, that the ST
+ is an instantiation of the PP, though the ST could be broader
+ than the PP. In essence, the ST specifies that the TOE does at
+ least the same as in the PP, while the operational environment
+ does at most the same as in the PP.
+ A typical example of the use of strict conformance is in
+ selection based purchasing where a product's security
+ requirements are expected to exactly match those specified in
+ the PP.
+ An ST instantiating strict conformance to a PP can still
+ introduce additional restrictions to those given in the PP.
+ Demonstrable conformance is orientated to the PP-author who
+ requires evidence that the ST is a suitable solution to the
+ generic security problem described in the PP.
+ Where there is a clear subset-superset type relation between
+ PP and ST in the case of strict conformance, the relation is
+ less clear-cut in the case of demonstrable conformance. STs
+ claiming conformance with the PP must offer a solution to the
+ generic security problem described in the PP. but can do so in
+ any way that is equivalent or more restrictive to that
+ described in the PP.
+ This bibliography contains references to further material and
+ standards that the reader of the CC may find useful. For
+ undated references the reader is recommended to refer to the
+ latest edition of the referenced document.ISO/IEC 15292Information technology -- Security techniques --
+ Protection Profile registration proceduresISO/IEC 15443Information technology -- Security techniques
+ -- A framework for IT security assurance - all partsISO/IEC 15446Information technology -- Security techniques
+ -- Guide for the production of Protection Profiles and Security
+ TargetsISO/IEC 19790Information technology -- Security techniques
+ -- Security requirements for cryptographic modulesISO/IEC 19791Information technology -- Security techniques
+ -- Security assessment of operational systemsISO/IEC 27001Information technology -- Security techniques
+ -- Information security management systems -- RequirementsISO/IEC 27002Information technology -- Security techniques
+ -- Code of practice for information security managementIEEE Std 610.12-1990
+ Institute of Electrical and Electronics Engineers, Standard
+ Glossary of Software Engineering Terminology
+ CC portal
+ Common Criteria portal, February 2009. CCRA, www.commoncriteriaportal.org
+
+
+
+ Table describes the
+ relationship between PPs and the families and components of the
+ class.
+
+
+
+
+
+
+
+
+
+
+ The following Subclauses describe the constructs used in
+ representing the assurance classes, families, and
+ components.
+
+ Figure
+ illustrates the SARs defined in this CC Part 3. Note that the
+ most abstract collection of SARs is referred to as a
+ class. Each class contains assurance families, which then
+ contain assurance components, which in turn contain assurance
+ elements. Classes and families are used to provide a taxonomy
+ for classifying SARs, while components are used to specify
+ SARs in a PP/ST.
+
+
+ Figure
+ illustrates the assurance class structure.
+
+
+ Each assurance class is assigned a unique name. The name
+ indicates the topics covered by the assurance
+ class.
+
+ A unique short form of the assurance class name is also
+ provided. This is the primary means for referencing the
+ assurance class. The convention adopted is an ``A''
+ followed by two letters related to the class name.
+
+
+
+ Each assurance class has an introductory Subclause that
+ describes the composition of the class and contains
+ supportive text covering the intent of the class.
+
+
+
+ Each assurance class contains at least one assurance
+ family. The structure of the assurance families is
+ described in the following Subclause.
+
+
+
+
+
+ Figure
+ illustrates the assurance family structure.
+
+
+ Every assurance family is assigned a unique name. The name
+ provides descriptive information about the topics covered
+ by the assurance family. Each assurance family is placed
+ within the assurance class that contains other families
+ with the same intent.
+
+ A unique short form of the assurance family name is also
+ provided. This is the primary means used to reference the
+ assurance family. The convention adopted is that the short
+ form of the class name is used, followed by an underscore,
+ and then three letters related to the family name.
+
+
+
+ The objectives Subclause of the assurance family presents
+ the intent of the assurance family.
+
+ This Subclause describes the objectives, particularly
+ those related to the CC assurance paradigm, that the
+ family is intended to address. The description for the
+ assurance family is kept at a general level. Any specific
+ details required for objectives are incorporated in the
+ particular assurance component.
+
+
+
+ Each assurance family contains one or more assurance
+ components. This Subclause of the assurance family
+ describes the components available and explains the
+ distinctions between them. Its main purpose is to
+ differentiate between the assurance components once it has
+ been determined that the assurance family is a necessary
+ or useful part of the SARs for a PP/ST.
+
+ Assurance families containing more than one component are
+ levelled and rationale is provided as to how the
+ components are levelled. This rationale is in terms of
+ scope, depth, and/or rigour.
+
+
+
+ The application notes Subclause of the assurance family,
+ if present, contains additional information for the
+ assurance family. This information should be of particular
+ interest to users of the assurance family (e.g. PP and ST
+ authors, designers of TOEs, evaluators). The presentation
+ is informal and covers, for example, warnings about
+ limitations of use and areas where specific attention may
+ be required.
+
+
+
+ Each assurance family has at least one assurance
+ component. The structure of the assurance components is
+ provided in the following Subclause.
+
+
+
+
+ Figure illustrates the
+ assurance component structure.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding convention. Those parts of the
+ requirements that are new, enhanced or modified beyond the
+ requirements of the previous component within a hierarchy
+ are bolded.
+
+
+ The component identification Subclause provides
+ descriptive information necessary to identify, categorise,
+ register, and reference a component.
+
+ Every assurance component is assigned a unique name. The
+ name provides descriptive information about the topics
+ covered by the assurance component. Each assurance
+ component is placed within the assurance family that
+ shares its security objective.
+
+ A unique short form of the assurance component name is
+ also provided. This is the primary means used to reference
+ the assurance component. The convention used is that the
+ short form of the family name is used, followed by a
+ period, and then a numeric character. The numeric
+ characters for the components within each family are
+ assigned sequentially, starting from 1.
+
+
+
+ The objectives Subclause of the assurance component, if
+ present, contains specific objectives for the particular
+ assurance component. For those assurance components that
+ have this Subclause, it presents the specific intent of
+ the component and a more detailed explanation of the
+ objectives.
+
+
+
+ The application notes Subclause of an assurance component,
+ if present, contains additional information to facilitate
+ the use of the component.
+
+
+
+ Dependencies among assurance components arise when a
+ component is not self-sufficient, and relies upon the
+ presence of another component.
+
+ Each assurance component provides a complete list of
+ dependencies to other assurance components. Some
+ components may list ``No dependencies'', to indicate that
+ no dependencies have been identified. The components
+ depended upon may have dependencies on other
+ components.
+
+ The dependency list identifies the minimum set of
+ assurance components which are relied upon. Components
+ which are hierarchical to a component in the dependency
+ list may also be used to satisfy the dependency.
+
+ In specific situations the indicated dependencies might
+ not be applicable. The PP/ST author, by providing
+ rationale for why a given dependency is not applicable,
+ may elect not to satisfy that dependency.
+
+
+
+ A set of assurance elements is provided for each assurance
+ component. An assurance element is a security requirement
+ which, if further divided, would not yield a meaningful
+ evaluation result. It is the smallest security requirement
+ recognised in the CC.
+
+ Each assurance element is identified as belonging to one
+ of the three sets of assurance elements:
+
+
+ Developer action elements: the activities that shall
+ be performed by the developer. This set of actions is
+ further qualified by evidential material referenced in
+ the following set of elements. Requirements for
+ developer actions are identified by appending the
+ letter ``D'' to the element number.
+
+
+ Content and presentation of evidence elements: the
+ evidence required, what the evidence shall
+ demonstrate, and what information the evidence shall
+ convey. Requirements for content and presentation of
+ evidence are identified by appending the letter ``C''
+ to the element number.
+
+
+ Evaluator action elements: the activities that shall
+ be performed by the evaluator. This set of actions
+ explicitly includes confirmation that the requirements
+ prescribed in the content and presentation of evidence
+ elements have been met. It also includes explicit
+ actions and analysis that shall be performed in
+ addition to that already performed by the
+ developer. Implicit evaluator actions are also to be
+ performed as a result of developer action elements
+ which are not covered by content and presentation of
+ evidence requirements. Requirements for evaluator
+ actions are identified by appending the letter ``E''
+ to the element number.
+
+
+
+ The developer actions and content and presentation of
+ evidence define the assurance requirements that are used
+ to represent a developer's responsibilities in
+ demonstrating assurance in the TOE meeting the SFRs of a
+ PP or ST.
+
+ The evaluator actions define the evaluator's
+ responsibilities in the two aspects of evaluation. The
+ first aspect is validation of the PP/ST, in accordance
+ with the classes and in Clauses and . The second
+ aspect is verification of the TOE's conformance with its
+ SFRs and SARs. By demonstrating that the PP/ST is valid
+ and that the requirements are met by the TOE, the
+ evaluator can provide a basis for confidence that the TOE
+ in its operational environment solves the defined security
+ problem.
+
+ The developer action elements, content and presentation of
+ evidence elements, and explicit evaluator action elements,
+ identify the evaluator effort that shall be expended in
+ verifying the security claims made in the ST of the
+ TOE.
+
+
+
+
+ Each element represents a requirement to be met. These
+ statements of requirements are intended to be clear,
+ concise, and unambiguous. Therefore, there are no compound
+ sentences: each separable requirement is stated as an
+ individual element.
+
+
+
+ This CC Part 3 contains classes of families and components
+ that are grouped on the basis of related assurance. At the
+ start of each class is a diagram that indicates the families
+ in the class and the components in each family.
+
+
+ In Figure ,
+ above, the class as shown contains a single family. The
+ family contains three components that are linearly
+ hierarchical (i.e. component 2 requires more than component
+ 1, in terms of specific actions, specific evidence, or
+ rigour of the actions or evidence). The assurance families
+ in this CC Part 3 are all linearly hierarchical, although
+ linearity is not a mandatory criterion for assurance
+ families that may be added in the future.
+
+
+
+
+ Figure illustrates
+ the EALs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in an EAL by reference to the actual
+ components defined in the CC.
+
+
+
+ Each EAL is assigned a unique name. The name provides
+ descriptive information about the intent of the EAL.
+
+ A unique short form of the EAL name is also provided. This
+ is the primary means used to reference the EAL.
+
+
+
+ The objectives Subclause of the EAL presents the intent of
+ the EAL.
+
+
+ The application notes Subclause of the EAL, if present,
+ contains information of particular interest to users of the
+ EAL (e.g. PP and ST authors, designers of TOEs targeting
+ this EAL, evaluators). The presentation is informal and
+ covers, for example, warnings about limitations of use and
+ areas where specific attention may be required.
+ A set of assurance components have been chosen for each
+ EAL.
+ A higher level of assurance than that provided by a given
+ EAL can be achieved by:
+
+ including additional assurance components from other
+ assurance families; or
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ assurance levels defined in the CC. While assurance
+ components further decompose into assurance elements,
+ assurance elements cannot be individually referenced by
+ assurance levels. Note that the arrow in the figure
+ represents a reference from an EAL to an assurance component
+ within the class where it is defined.
+
+
+
+
+
+ The structure of the CAPs is similar to that of the EALs. The
+ main difference between these two types of package is the type
+ of TOE they apply to; the EALs applying to component TOEs and
+ the CAPs applying to composed TOEs.
+
+ Figure illustrates
+ the CAPs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in a CAP by reference to the actual
+ components defined in the CC.
+
+
+
+ Each CAP is assigned a unique name. The name provides
+ descriptive information about the intent of the CAP.
+
+ A unique short form of the CAP name is also provided. This
+ is the primary means used to reference the CAP.
+
+
+
+ The objectives Subclause of the CAP presents the intent of
+ the CAP.
+
+
+ The application notes Subclause of the CAP, if present,
+ contains information of particular interest to users of the
+ CAP (e.g. PP and ST authors, integrators of composed TOEs
+ targeting this CAP, evaluators). The presentation is
+ informal and covers, for example, warnings about limitations
+ of use and areas where specific attention may be
+ required.
+ A set of assurance components have been chosen for each
+ CAP.
+ Some dependencies identify the activities performed during
+ the evaluation of the dependent component on which the
+ composed TOE activity relies. Where it is not explicitly
+ identified that the dependency is on a dependent component
+ activity, the dependency is to another evaluation activity
+ of the composed TOE.
+ A higher level of assurance than that provided by a given
+ CAP can be achieved by:
+
+ including additional assurance components from other
+ assurance families; or
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+ The components included in the CAP
+ assurance packages should not be used as augmentations for
+ component TOE evaluations, as this would provide no
+ meaningful assurance for the component.
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ composed assurance packages defined in the CC. While
+ assurance components further decompose into assurance
+ elements, assurance elements cannot be individually
+ referenced by assurance packages. Note that the arrow in the
+ figure represents a reference from a CAP to an assurance
+ component within the class where it is defined.
+
+
+
+
+
+
+
+
+ This clause defines the content and presentation of the
+ functional requirements of the CC, and provides guidance on
+ the organisation of the requirements for new components to be
+ included in an ST. The functional requirements are expressed
+ in classes, families, and components.
+
+
+
+ Figure illustrates the
+ functional class structure in diagrammatic form. Each
+ functional class includes a class name, class introduction,
+ and one or more functional families.
+
+
+
+
+
+ The class name subclause provides information necessary to
+ identify and categorise a functional class. Every
+ functional class has a unique name. The categorical
+ information consists of a short name of three
+ characters. The short name of the class is used in the
+ specification of the short names of the families of that
+ class.
+
+
+
+ The class introduction expresses the common intent or
+ approach of those families to satisfy security
+ objectives. The definition of functional classes does not
+ reflect any formal taxonomy in the specification of the
+ requirements.
+
+ The class introduction provides a figure describing the
+ families in this class and the hierarchy of the components
+ in each family, as explained in subclause .
+
+
+
+
+
+ Figure
+ illustrates the functional family structure in diagrammatic
+ form.
+
+
+
+
+
+ The family name subclause provides categorical and
+ descriptive information necessary to identify and
+ categorise a functional family. Every functional family
+ has a unique name. The categorical information consists of
+ a short name of seven characters, with the first three
+ identical to the short name of the class followed by an
+ underscore and the short name of the family as follows
+ XXX_YYY. The unique short form of the family name provides
+ the principal reference name for the components.
+
+
+
+ The family behaviour is the narrative description of the
+ functional family stating its security objective and a
+ general description of the functional requirements. These
+ are described in greater detail below:
+
+
+ The security objectives of the family
+ address a security problem that may be solved with the
+ help of a TOE that incorporates a component of this
+ family;
+
+
+ The description of the functional
+ requirements summarises all the requirements
+ that are included in the component(s). The description
+ is aimed at authors of PPs, STs and functional
+ packages who wish to assess whether the family is
+ relevant to their specific requirements.
+
+
+
+
+
+ Functional families contain one or more components, any
+ one of which can be selected for inclusion in PPs, STs and
+ functional packages. The goal of this section is to
+ provide information to users in selecting an appropriate
+ functional component once the family has been identified
+ as being a necessary or useful part of their security
+ requirements.
+
+ This section of the functional family description
+ describes the components available, and their
+ rationale. The exact details of the components are
+ contained within each component.
+
+ The relationships between components within a functional
+ family may or may not be hierarchical. A component is
+ hierarchical to another if it offers more security.
+
+ As explained in the descriptions of the
+ families provide a graphical overview of the hierarchy of
+ the components in a family.
+
+
+
+
+ The management clauses contain information for
+ the PP/ST authors to consider as management activities for a
+ given component. The clauses reference components of the
+ management class (FMT), and provide guidance regarding potential
+ management activities that may be applied via operations to
+ those components.
+
+ A PP/ST author may select the indicated management components or
+ may include other management requirements not listed to detail
+ management activities. As such the information should be
+ considered informative.
+
+
+
+
+ The audit requirements contain auditable
+ events for the PP/ST authors to select, if requirements
+ from the class , are included in the
+ PP/ST. These requirements include security relevant events
+ in terms of the various levels of detail supported by the
+ components of the family. For example,
+ an audit note might include actions that are in terms of:
+ Minimal - successful use of the security mechanism; Basic
+ - any use of the security mechanism as well as relevant
+ information regarding the security attributes involved;
+ Detailed - any configuration changes made to the
+ mechanism, including the actual configuration values
+ before and after the change.
+
+ It should be observed that the categorisation of auditable
+ events is hierarchical. For example, when Basic Audit
+ Generation is desired, all auditable events identified as
+ being both Minimal and Basic should be included in the
+ PP/ST through the use of the appropriate assignment
+ operation, except when the higher level event simply
+ provides more detail than the lower level event. When
+ Detailed Audit Generation is desired, all identified
+ auditable events (Minimal, Basic and Detailed) should be
+ included in the PP/ST.
+
+ In the class the rules governing the audit
+ are explained in more detail.
+
+
+
+
+
+ Figure illustrates the
+ functional component structure.
+
+
+
+
+
+ The component identification subclause provides
+ descriptive information necessary to identify, categorise,
+ register and cross-reference a component. The following is
+ provided as part of every functional component:
+
+ A unique name. The name reflects the
+ purpose of the component.
+
+ A short name. A unique short form of the
+ functional component name. This short name serves as the
+ principal reference name for the categorisation,
+ registration and cross-referencing of the component. This
+ short name reflects the class and family to which the
+ component belongs and the component number within the
+ family.
+
+ A hierarchical-to list. A list of other
+ components that this component is hierarchical to and for
+ which this component can be used to satisfy dependencies
+ to the listed components.
+
+
+
+
+ A set of elements is provided for each component. Each
+ element is individually defined and is self-contained.
+
+ A functional element is a security functional requirement
+ that if further divided would not yield a meaningful
+ evaluation result. It is the smallest security functional
+ requirement identified and recognised in the CC.
+
+ When building packages, PPs and/or STs, it is not
+ permitted to select only one or more elements from a
+ component. The complete set of elements of a component
+ must be selected for inclusion in a PP, ST or package.
+
+ A unique short form of the functional element name is
+ provided. For example the requirement name FDP_IFF.4.2
+ reads as follows: F - functional requirement, DP - class
+ ``User data protection'', _IFF -
+ family ``Information flow control
+ functions'', .4 - 4th component named
+ ``Partial elimination of illicit information
+ flows'', .2 - 2nd element of the component.
+
+
+
+
+ Dependencies among functional components arise when a
+ component is not self sufficient and relies upon the
+ functionality of, or interaction with, another component
+ for its own proper functioning.
+
+ Each functional component provides a complete list of
+ dependencies to other functional and assurance
+ components. Some components may list ``No
+ dependencies''. The components depended upon may in
+ turn have dependencies on other components. The list
+ provided in the components will be the direct
+ dependencies. That is only references to the functional
+ requirements that are required for this requirement to
+ perform its job properly. The indirect dependencies, that
+ is the dependencies that result from the depended upon
+ components can be found in
+ of this part of the CC. It is noted that in some cases the
+ dependency is optional in that a number of functional
+ requirements are provided, where each one of them would be
+ sufficient to satisfy the dependency (see for example
+ ).
+
+ The dependency list identifies the minimum functional or
+ assurance components needed to satisfy the security
+ requirements associated with an identified
+ component. Components that are hierarchical to the
+ identified component may also be used to satisfy the
+ dependency.
+
+ The dependencies indicated in CC Part 2 are
+ normative. They must be satisfied within a PP/ST. In
+ specific situations the indicated dependencies might not
+ be applicable. The PP/ST author, by providing the
+ rationale why it is not applicable, may leave the depended
+ upon component out of the package, PP or ST.
+
+
+
+
+
+
+
+
+ The grouping of the components in this part of the CC does not
+ reflect any formal taxonomy.
+
+ This part of the CC contains classes of families and
+ components, which are rough groupings on the basis of related
+ function or purpose, presented in alphabetic order. At the
+ start of each class is an informative diagram that indicates
+ the taxonomy of each class, indicating the families in each
+ class and the components in each family. The diagram is a
+ useful indicator of the hierarchical relationship that may
+ exist between components.
+
+ In the description of the functional components, a section
+ identifies the dependencies between the component and any
+ other components.
+
+ In each class a figure describing the family hierarchy similar
+ to Figure , is provided. In Figure
+ the first family, Family 1,
+ contains three hierarchical components, where component 2 and
+ component 3 can both be used to satisfy dependencies on
+ component 1. Component 3 is hierarchical to component 2 and
+ can also be used to satisfy dependencies on component 2.
+
+
+
+
+ In Family 2 there are three components not all of which are
+ hierarchical. Components 1 and 2 are hierarchical to no other
+ components. Component 3 is hierarchical to component 2, and
+ can be used to satisfy dependencies on component 2, but not to
+ satisfy dependencies on component 1.
+
+ In Family 3, components 2, 3, and 4 are hierarchical to
+ component 1. Components 2 and 3 are both hierarchical to
+ component 1, but non-comparable. Component 4 is hierarchical
+ to both component 2 and component 3.
+
+ These diagrams are meant to complement the text of the
+ families and make identification of the relationships
+ easier. They do not replace the ``Hierarchical
+ to:'' note in each component that is the mandatory
+ claim of hierarchy for each component.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding
+ convention. This bolding convention calls for the bolding of
+ all new requirements. For hierarchical components,
+ requirements are bolded when they are
+ enhanced or modified beyond the requirements of the previous
+ component. In addition, any new or enhanced permitted
+ operations beyond the previous component are also
+ highlighted using bold type.
+
+
+
+
+
+ This annex contains additional guidance for the families and
+ components defined in the elements of this CC Part 2, which
+ may be required by users, developers or evaluators to use the
+ components. To facilitate finding the appropriate information,
+ the presentation of the classes, families and components in
+ this annex is similar to the presentation within the elements.
+
+
+
+ This clause defines the content and presentation of the notes
+ related to functional requirements of the CC.
+
+
+
+ Figure below
+ illustrates the functional class structure in this annex.
+
+
+
+
+
+ This is the unique name of the class defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The class introduction in this annex provides information
+ about the use of the families and components of the
+ class. This information is completed with the informative
+ diagram that describes the organisation of each class with
+ the families in each class and the hierarchical
+ relationship between components in each family.
+
+
+
+
+
+ Figure illustrates
+ the functional family structure for application notes in
+ diagrammatic form.
+
+
+
+
+
+ This is the unique name of the family defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The user notes contain additional information that is of
+ interest to potential users of the family, that is PP, ST
+ and functional package authors, and developers of TOEs
+ incorporating the functional components. The presentation
+ is informative, and might cover warnings about limitations
+ of use and areas where specific attention might be
+ required when using the components.
+
+
+
+
+ The evaluator notes contain any information that is of
+ interest to developers and evaluators of TOEs that claim
+ compliance with a component of the family. The
+ presentation is informative and can cover a variety of
+ areas where specific attention might be needed when
+ evaluating the TOE. This can include clarifications of
+ meaning and specification of the way to interpret
+ requirements, as well as caveats and warnings of specific
+ interest to evaluators.
+
+ These User Notes and Evaluator Notes sections are not
+ mandatory and appear only if appropriate.
+
+
+
+
+
+ Figure illustrates
+ the functional component structure for the application
+ notes.
+
+
+
+
+
+ This is the unique name of the component defined within
+ the normative elements of this part of the CC.
+
+
+
+
+ Any specific information related to the component can be
+ found in this section.
+
+
+ The rationale contains the specifics
+ of the rationale that refine the general statements on
+ rationale for the specific level, and should only be
+ used if level specific amplification is required.
+
+
+ The application notes contain
+ additional refinement in terms of narrative
+ qualification as it pertains to a specific
+ component. This refinement can pertain to user notes,
+ and/or evaluator notes as described in Subclause . This refinement can be
+ used to explain the nature of the dependencies
+ (e.g. shared information, or shared operation).
+
+
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+ This portion of each component contains advice relating to
+ the permitted operations of the component.
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+
+ The following dependency tables for functional components
+ show their direct, indirect and optional dependencies. Each
+ of the components that is a dependency of some functional
+ component is allocated a column. Each functional component is
+ allocated a row. The value in the table cell indicate whether
+ the column label component is directly required (indicated by
+ a cross ``X''), indirectly required (indicated by a
+ dash ``-''), or optionally required (indicated by a
+ ``o'') by the row label component. An example of a
+ component with optional dependencies is , which requires either
+ or to be present. So if is present, is not
+ necessary and vice versa. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+
+
+ Security auditing involves recognising, recording, storing,
+ and analysing information related to security relevant
+ activities (i.e. activities controlled by the TSF). The
+ resulting audit records can be examined to determine which
+ security relevant activities took place and whom (which user)
+ is responsible for them.
+
+
+
+ CC audit families allow PP/ST authors the ability to define
+ requirements for monitoring user activities and, in some
+ cases, detecting real, possible, or imminent violations of
+ the enforcement of the SFRs. The TOE's security audit functions are
+ defined to help monitor security-relevant events, and act as a
+ deterrent against security violations. The requirements of the
+ audit families refer to functions that include audit data
+ protection, record format, and event selection, as well as
+ analysis tools, violation alarms, and real-time analysis. The
+ audit trail should be presented in human-readable format
+ either directly (e.g. storing the audit trail in
+ human-readable format) or indirectly (e.g. using audit
+ reduction tools), or both.
+
+ While developing the security audit requirements, the PP/ST
+ author should take note of the inter-relationships among the
+ audit families and components. The potential exists to specify
+ a set of audit requirements that comply with the
+ family/component dependencies lists, while at the same time
+ resulting in a deficient audit function (e.g. an audit
+ function that requires all security relevant events to be
+ audited but without the selectivity to control them on any
+ reasonable basis such as individual user or object).
+
+
+ The implementation of audit requirements for networks and
+ other large systems may differ significantly from those
+ needed for stand-alone systems. Larger, more complex and
+ active systems require more thought concerning which audit
+ data to collect and how this should be managed, due to
+ lowered feasibility of interpreting (or even storing) what
+ gets collected. The traditional notion of a time-ordered list
+ or ``trail'' of audited events may not
+ be applicable in a global asynchronous network with
+ arbitrarily many events occurring at once.
+
+ Also, different hosts and servers on a distributed TOE may
+ have differing naming policies and values. Symbolic names
+ presentation for audit review may require a net-wide
+ convention to avoid redundancies and ``name
+ clashes.''
+
+ A multi-object audit repository, portions of which are
+ accessible by a potentially wide variety of authorised
+ users, may be required if audit repositories are to serve a
+ useful function in distributed systems.
+
+ Finally, misuse of authority by authorised users should be
+ addressed by systematically avoiding local storage of audit
+ data pertaining to administrator actions.
+
+
+
+
+
+
+ This family defines the response to be taken in case of
+ detected events indicative of a potential security
+ violation.
+
+
+
+ The Security audit automatic response family describes
+ requirements for the handling of audit events. The
+ requirement could include requirements for alarms or TSF
+ action (automatic response). For example, the TSF could
+ include the generation of real time alarms, termination of
+ the offending process, disabling of a service, or
+ disconnection or invalidation of a user account.
+
+ An audit event is defined to be an ``potential
+ security violation'' if so indicated by the
+ components.
+
+
+
+
+
+
+
+
+ An action should be taken for follow up action in the
+ event of an alarm. This action can be to inform the
+ authorised user, to present the authorised user with a set
+ of possible containment actions, or to take corrective
+ actions. The timing of the actions should be carefully
+ considered by the PP/ST author.
+
+
+
+ At , the TSF shall take actions in
+ case a potential security violation is detected.
+
+
+ the management (addition, removal, or modification) of
+ actions.
+
+
+ Actions taken due to potential security violations.
+
+
+ The TSF shall take
+
+
+ list of actions
+
+
+
+ the PP/ST author should specify the actions to be taken
+ in case of a potential security violation. An example of
+ such a list is: ``inform the authorised user, disable
+ the subject that created the potential security
+ violation.'' It can also specify that the action to be
+ taken can be specified by an authorised user.
+
+
+ upon detection of a potential security violation.
+
+
+
+
+
+
+
+ This family defines requirements for recording the
+ occurrence of security relevant events that take place under
+ TSF control. This family identifies the level of auditing,
+ enumerates the types of events that shall be auditable by
+ the TSF, and identifies the minimum set of audit-related
+ information that should be provided within various audit
+ record types.
+
+
+
+ The Security audit data generation family includes
+ requirements to specify the audit events that should be
+ generated by the TSF for security-relevant events.
+
+ This family is presented in a manner that avoids a dependency
+ on all components requiring audit support. Each component has
+ an audit section developed in which the events to be audited
+ for that functional area are listed. When the PP/ST author
+ assembles the PP/ST, the items in the audit area are used to
+ complete the variable in this component. Thus, the
+ specification of what could be audited for a functional area
+ is localised in that functional area.
+
+ The list of auditable events is entirely dependent on the
+ other functional families within the PP/ST. Each family
+ definition should therefore include a list of its
+ family-specific auditable events. Each auditable event in the
+ list of auditable events specified in the functional family
+ should correspond to one of the levels of audit event
+ generation specified in this family (i.e. minimal, basic,
+ detailed). This provides the PP/ST author with information
+ necessary to ensure that all appropriate auditable events are
+ specified in the PP/ST. The following example shows how
+ auditable events are to be specified in appropriate functional
+ families:
+
+ ``The following actions should be auditable if is included in the PP/ST:
+
+
+ Minimal: Successful use of the user security attribute
+ administration functions;
+
+
+ Basic: All attempted uses of the user security attribute
+ administration functions;
+
+
+ Basic: Identification of which user security attributes
+ have been modified;
+
+
+ Detailed: With the exception of specific sensitive
+ attribute data items (e.g. passwords, cryptographic
+ keys), the new values of the attributes should be
+ captured.''
+
+
+
+ For each functional component that is chosen, the auditable
+ events that are indicated in that component, at and below the
+ level indicated in should be
+ auditable. If, for example, in the previous example ``Basic''
+ would be selected in , the
+ auditable events mentioned in a), b) and c) should be
+ auditable.
+
+ Observe that the categorisation of auditable events is
+ hierarchical. For example, when Basic Audit Generation is
+ desired, all auditable events identified as being either
+ Minimal or Basic, should also be included in the PP/ST
+ through the use of the appropriate assignment operation,
+ except when the higher level event simply provides more
+ detail than the lower level event. When Detailed Audit
+ Generation is desired, all identified auditable events
+ (Minimal, Basic, and Detailed) should be included in the
+ PP/ST.
+
+ A PP/ST author may decide to include other auditable events
+ beyond those required for a given audit level. For example,
+ the PP/ST may claim only minimal audit capabilities while
+ including most of the basic capabilities because the few
+ excluded capabilities conflict with other PP/ST constraints
+ (e.g. because they require the collection of unavailable
+ data).
+
+ The functionality that creates the auditable event should be
+ specified in the PP or ST as a functional requirement.
+
+ The following are examples of the types of the events that
+ should be defined as auditable within each PP/ST functional
+ component:
+
+
+ Introduction of objects within the control of the TSF into a
+ subject's address space;
+
+
+ Deletion of objects;
+
+
+ Distribution or revocation of access rights or
+ capabilities;
+
+
+ Changes to subject or object security attributes;
+
+
+ Policy checks performed by the TSF as a result of a
+ request by a subject;
+
+
+ The use of access rights to bypass a policy check;
+
+
+ Use of Identification and Authentication functions;
+
+
+ Actions taken by an operator, and/or authorised user
+ (e.g. suppression of a TSF protection mechanism as
+ human-readable labels);
+
+
+ Import/export of data from/to removable media
+ (e.g. printed output, tapes, diskettes).
+
+
+
+
+
+
+
+
+
+
+ This component defines requirements to identify the
+ auditable events for which audit records should be
+ generated, and the information to be provided in the audit
+ records.
+
+ by itself might be used
+ when the SFRs do not require that individual user identities
+ be associated with audit events. This could be appropriate
+ when the PP/ST also contains privacy requirements. If the
+ user identity must be incorporated could be used in addition.
+
+ If the subject is a user, the user identity may be recorded as
+ the subject identity. The identity of the user may not yet been
+ verified if has not been
+ applied. Therefore in the instance of an invalid login the
+ claimed user identity should be recorded. It should be
+ considered to indicate when a recorded identity has not been
+ authenticated.
+
+
+
+ There is a dependency on . If correctness of time is not an issue for
+ this TOE, elimination of this dependency could be
+ justified.
+
+
+
+ defines the level of auditable
+ events, and specifies the list of data that shall be
+ recorded in each record.
+
+
+ The TSF shall be able to generate an audit record of the
+ following auditable events:
+
+
+ Start-up and shutdown of the audit functions;
+
+
+ All auditable events for the
+
+ minimum
+ basic
+ detailed
+ not specified
+
+
+ the PP/ST author should select the level of
+ auditable events called out in the audit section of
+ other functional components included in the
+ PP/ST. This level is one of the following:
+ ``minimum'', ``basic'', ``detailed'' or ``not
+ specified''.
+
+
+ level of audit; and
+
+
+
+
+ other specifically defined auditable events
+
+
+
+ the PP/ST author should assign a list of other
+ specifically defined auditable events to be included
+ in the list of auditable events. The assignment may
+ comprise none, or events that could be auditable
+ events of a functional requirement that are of a
+ higher audit level than requested in , as well as the
+ events generated through the use of a specified
+ Application Programming Interface (API).
+
+ .
+
+
+
+
+ The TSF shall record within each audit record at least the
+ following information:
+
+
+ Date and time of the event, type of event, subject identity (if
+ applicable), and the outcome (success or failure) of the event;
+ and
+
+
+ For each audit event type, based on the auditable event
+ definitions of the functional components included in the
+ PP/ST,
+
+
+ other audit relevant information
+
+
+
+ the PP/ST author should assign, for each auditable
+ events included in the PP/ST, either a list of other
+ audit relevant information to be included in audit
+ events records or none.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ This component addresses the requirement of accountability
+ of auditable events at the level of individual user
+ identity. This component should be used in addition to
+ .
+
+ There is a potential conflict between the audit and privacy
+ requirements. For audit purposes it may be desirable to know
+ who performed an action. The user may want to keep his/her
+ actions to himself/herself and not be identified by other
+ persons (e.g. a site with job offers). Or it might be
+ required in the Organisational Security Policy that the
+ identity of the users must be protected. In those cases the
+ objectives for audit and privacy might contradict each
+ other. Therefore if this requirement is selected and privacy
+ is important, inclusion of the component user pseudonimity
+ might be considered. Requirements on determining the real
+ user name based on its pseudonym are specified in the
+ privacy class.
+
+ If the identity of the user has not yet been verified through
+ authentication, in the instance of an invalid login the claimed
+ user identity should be recorded. It should be considered to
+ indicate when a recorded identity has not been authenticated.
+
+
+
+ At , the TSF shall associate
+ auditable events to individual user identities.
+
+
+ For audit events resulting from actions of identified users, the
+ TSF shall be able to associate each auditable event with the
+ identity of the user that caused the event.
+
+
+
+
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible or
+ real security violations. This analysis may work in support of
+ intrusion detection, or automatic response to a potential
+ security violation.
+
+ The actions to be taken based on the detection can be
+ specified using the family as
+ desired.
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible
+ or real security violations. This analysis may work in
+ support of intrusion detection, or automatic response to a
+ potential security violation.
+
+ The action to be performed by the TSF on detection of a
+ potential violation is defined in components.
+
+ For real-time analysis, audit data could be transformed into a
+ useful format for automated treatment, but into a different
+ useful format for delivery to authorised users for
+ review.
+
+
+
+
+
+
+
+
+ This component is used to specify the set of auditable
+ events whose occurrence or accumulated occurrence held to
+ indicate a potential violation of the enforcement of the
+ SFRs, and any rules to be used to perform the violation
+ analysis.
+
+
+
+ In , basic threshold
+ detection on the basis of a fixed rule set is
+ required.
+
+
+ maintenance of the rules by (adding, modifying, deletion)
+ of rules from the set of rules.
+
+
+ Enabling and disabling of any of the analysis mechanisms;
+
+
+ Automated responses performed by the tool.
+
+
+ The TSF shall be able to apply a set of rules in monitoring
+ the audited events and based upon these rules indicate a
+ potential violation of the enforcement of the SFRs.
+
+
+ The TSF shall enforce the following rules for monitoring
+ audited events:
+
+
+ Accumulation or combination of
+
+
+ subset of defined auditable events
+
+
+
+ the PP/ST author should identify the subset of
+ defined auditable events whose occurrence or
+ accumulated occurrence need to be detected as an
+ indication of a potential violation of the
+ enforcement of the SFRs.
+
+
+ known to indicate a potential security violation;
+
+
+
+
+ any other rules
+
+
+
+ the PP/ST author should specify any other rules that
+ the TSF should use in its analysis of the audit
+ trail. Those rules could include specific
+ requirements to express the needs for the events to
+ occur in a certain period of time (e.g. period of
+ the day, duration). If there are no additional
+ rules that the TSF should use in the analysis of the
+ audit trail, this assignment can be completed with
+ ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ A profile is a structure that
+ characterises the behaviour of users and/or subjects; it
+ represents how the users/subjects interact with the TSF in
+ a variety of ways. Patterns of usage are established with
+ respect to the various types of activity the
+ users/subjects engage in (e.g. patterns in exceptions
+ raised, patterns in resource utilisation (when, which,
+ how), patterns in actions performed). The ways in which
+ the various types of activity are recorded in the profile
+ (e.g. resource measures, event counters, timers) are
+ referred to as profile metrics.
+
+ Each profile represents the expected patterns of usage
+ performed by members of the profile target
+ group. This pattern may be based on past use
+ (historical patterns) or on normal use for users of
+ similar target groups (expected behaviour). A profile
+ target group refers to one or more users who interact with
+ the TSF. The activity of each member of the profile group
+ is used by the analysis tool in establishing the usage
+ patterns represented in the profile. The following are
+ some examples of profile target groups:
+
+
+ Single user account: one profile per
+ user;
+
+
+ Group ID or Group Account: one profile
+ for all users who possess the same group ID or operate
+ using the same group account;
+
+
+ Operating Role: one profile for all users
+ sharing a given operating role;
+
+
+ System: one profile for all users of a
+ system.
+
+
+
+ Each member of a profile target group is assigned an
+ individual suspicion rating that
+ represents how closely that member's new
+ activity corresponds to the established patterns of usage
+ represented in the group profile.
+
+ The sophistication of the anomaly detection tool will
+ largely be determined by the number of target profile
+ groups required by the PP/ST and the complexity of the
+ required profile metrics.
+
+
+ The PP/ST author should enumerate specifically what activity
+ should be monitored and/or analysed by the TSF. The PP/ST
+ author should also identify specifically what information
+ pertaining to the activity is necessary to construct the
+ usage profiles.
+
+ requires that the TSF
+ maintain profiles of system usage. The word maintain implies
+ that the anomaly detector is actively updating the usage
+ profile based on new activity performed by the profile
+ target members. It is important here that the metrics for
+ representing user activity are defined by the PP/ST
+ author. For example, there may be a thousand different
+ actions an individual may be capable of performing, but the
+ anomaly detector may choose to monitor a subset of that
+ activity. Anomalous activity gets integrated into the
+ profile just like non-anomalous activity (assuming the tool
+ is monitoring those actions). Things that may have appeared
+ anomalous four months ago, might over time become the norm
+ (and vice-versa) as the user's work duties change. The TSF
+ wouldn't be able to capture this notion if it filtered out
+ anomalous activity from the profile updating
+ algorithms.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ suspicion rating.
+
+ The PP/ST author should define how to interpret suspicion
+ ratings and the conditions under which anomalous activity is
+ indicated to the
+ mechanism.
+
+
+
+ In , the TSF maintains
+ individual profiles of system usage, where a profile
+ represents the historical patterns of usage performed by
+ members of the profile target group. A profile target group
+ refers to a group of one or more individuals (e.g. a single
+ user, users who share a group ID or group account, users who
+ operate under an assigned role, users of an entire system or
+ network node) who interact with the TSF. Each member of a
+ profile target group is assigned an individual suspicion
+ rating that represents how well that member's current
+ activity corresponds to the established patterns of usage
+ represented in the profile. This analysis can be performed
+ at runtime or during a post-collection batch-mode
+ analysis.
+
+
+ maintenance (deletion, modification, addition) of the
+ group of users in the profile target group.
+
+
+
+ The TSF shall be able to maintain profiles of system usage,
+ where an individual profile represents the historical
+ patterns of usage performed by the member(s) of
+
+
+ the profile target group
+
+
+
+ the PP/ST author should specify the profile target
+ group. A single PP/ST may include multiple profile
+ target groups.
+
+ .
+
+
+ The TSF shall be able to maintain a suspicion rating
+ associated with each user whose activity is recorded in a
+ profile, where the suspicion rating represents the degree to
+ which the user's current activity is found
+ inconsistent with the established patterns of usage
+ represented in the profile.
+
+
+ The TSF shall be able to indicate a possible violation of
+ the enforcement of the SFRs when a user's suspicion rating exceeds
+ the following threshold conditions
+
+
+ conditions under which anomalous activity is reported by
+ the TSF
+
+
+
+ the PP/ST author should specify conditions under which
+ anomalous activity is reported by the TSF. Conditions
+ may include the suspicion rating reaching a certain
+ value, or be based on the type of anomalous activity
+ observed.
+
+ .
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant that they are always worthy of
+ independent review. Example of such events include the
+ deletion of a key TSF security data file (e.g. the
+ password file) or activity such as a remote user
+ attempting to gain administrative privilege. These events
+ are referred to as signature events in that their
+ occurrence in isolation from the rest of the system
+ activity are indicative of intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data).
+
+ The elements of do not
+ require that the TSF implementing the immediate attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able
+ to detect the occurrence of signature events that represent
+ a significant threat to enforcement of the SFRs. This search
+ for signature events may occur in real-time or during a
+ post-collection batch-mode analysis.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of system
+ events whose occurrence, in isolation from all other
+ system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by
+ themselves indicate a clear violation to the enforcement
+ of the SFRs, or whose occurrence is so significant that
+ they warrant actions.
+
+
+ that may indicate a violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events
+ against the record of system activity discernible from an
+ examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when a system event is found to match
+ a signature event that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant they are always worthy of independent
+ review. Example of such events include the deletion of a key
+ TSF security data file (e.g. the password file) or activity
+ such as a remote user attempting to gain administrative
+ privilege. These events are referred to as signature events
+ in that their occurrence in isolation from the rest of the
+ system activity are indicative of intrusive activity. Event
+ sequences are an ordered set of signature events that might
+ indicate intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events and event sequences.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data). Levelling, therefore, requires the
+ PP/ST author to specify the type of input data used to
+ monitor system activity.
+
+ The elements of do not
+ require that the TSF implementing the complex attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able to
+ represent and detect multi-step intrusion scenarios. The
+ TSF is able to compare system events (possibly performed
+ by multiple individuals) against event sequences known to
+ represent entire intrusion scenarios. The TSF shall be
+ able to indicate when a signature event or event sequence
+ is found that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events;
+
+
+ maintenance (deletion, modification, addition) of the set of
+ sequence of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following event sequences of known intrusion
+ scenarios
+
+
+ list of sequences of system events whose occurrence are
+ representative of known penetration scenarios
+
+
+
+ the PP/ST author should identify a base set of list of
+ sequences of system events whose occurrence are
+ representative of known penetration scenarios. These
+ event sequences represent known penetration
+ scenarios. Each event represented in the sequence should
+ map to a monitored system event, such that as the system
+ events are performed, they are bound (mapped) to the
+ known penetration event sequences.
+
+
+ and the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of
+ system events whose occurrence, in isolation from all
+ other system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by themselves indicate
+ a clear violation to the SFRs, or whose occurrence is
+ so significant they warrant action.
+
+
+ that may indicate a potential
+ violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events and
+ event sequences against the record of system activity
+ discernible from an examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when system activity is found to match
+ a signature event or event sequence that indicates a potential
+ violation of the enforcement of the SFRs.
+
+
+
+
+
+
+
+ This family defines the requirements for audit tools that
+ should be available to authorised users to assist in the
+ review of audit data.
+
+
+
+ The Security audit review family defines requirements
+ related to review of the audit information.
+
+ These functions should allow pre-storage or post-storage
+ audit selection that includes, for example, the ability to
+ selectively review:
+
+
+ the actions of one or more users (e.g. identification,
+ authentication, TOE entry, and access control actions);
+
+
+ the actions performed on a specific object or TOE
+ resource;
+
+
+ all of a specified set of audited exceptions;
+ or
+
+
+ actions associated with a specific SFR attribute.
+
+
+
+ The distinction between audit reviews is based on
+ functionality. Audit review (only) encompasses the ability to
+ view audit data. Selectable review is more sophisticated, and
+ requires the ability to select subsets of audit data based on a
+ single criterion or multiple criteria with logical (i.e. and/or)
+ relations, and order the audit data before it is
+ reviewed.
+
+
+
+
+
+
+
+
+ This component will provide authorised users the
+ capability to obtain and interpret the information. In
+ case of human users this information needs to be in a
+ human understandable presentation. In case of external IT
+ entities the information needs to be unambiguously
+ represented in an electronic fashion.
+
+
+
+ This component is used to specify that users and/or
+ authorised users can read the audit records. These audit
+ records will be provided in a manner appropriate to the
+ user. There are different types of users (human users,
+ machine users) that might have different needs.
+
+ The content of the audit records that can be viewed can be
+ specified.
+
+
+
+ , provides the capability to read
+ information from the audit records.
+
+
+ maintenance (deletion, modification, addition) of the group
+ of users with read access right to the audit records.
+
+
+ Reading of information from the audit records.
+
+
+ The TSF shall provide
+
+
+ authorised users
+
+
+
+ the PP/ST author should specify the authorised users
+ that can use this capability. If appropriate the PP/ST
+ author may include security roles (see ).
+
+
+ with the capability to read
+
+
+ list of audit information
+
+
+
+ the PP/ST author should specify the type of information
+ the specified user is permitted to obtain from the audit
+ records. Examples are ``all'', ``subject identity'',
+ ``all information belonging to audit records referencing
+ this user''. When employing the SFR, FAU_SAR.1, it is not
+ necessary to repeat, in full detail, the list of audit
+ information first specified in FAU_GEN.1. Use of terms
+ such as ``all'' or ``all audit information'' assist in
+ eliminating ambiguity and the further need for
+ comparative analysis between the two security
+ requirements.
+
+
+ from the audit records.
+
+
+ The TSF shall provide the audit records in a manner suitable
+ for the user to interpret the information.
+
+
+
+
+
+
+
+
+
+ This component specifies that any users not identified in
+ will not be able to read
+ the audit records.
+
+
+
+ , requires that there are
+ no other users except those that have been identified in
+ that can read the
+ information.
+
+
+ Unsuccessful attempts to read information from the audit
+ records.
+
+
+ The TSF shall prohibit all users read access to the audit
+ records, except those users that have been granted explicit
+ read-access.
+
+
+
+
+
+
+
+
+
+ This component is used to specify that it should be
+ possible to perform selection of the audit data to be
+ reviewed. If based on multiple criteria, those criteria
+ should be related together with logical
+ (i.e. ``and'' or
+ ``or'') relations, and the tools
+ should provide the ability to manipulate audit data
+ (e.g. sort, filter).
+
+
+
+ , requires audit review
+ tools to select the audit data to be reviewed based on
+ criteria.
+
+
+ the parameters used for the viewing.
+
+
+ The TSF shall provide the ability to apply
+
+ methods of selection and/or ordering
+
+ the PP/ST author should specify whether capabilities to
+ select and/or order audit data is required from the
+ TSF.
+ of audit data based on
+
+ criteria with logical relations
+
+ the PP/ST author should assign the criteria, possibly
+ with logical relations, to be used to select the audit
+ data for review. The logical relations are intended to
+ specify whether the operation can be on an individual
+ attribute or a collection of attributes. An example of
+ this assignment could be: ``application, user account
+ and/or location''. In this case the operation could be
+ specified using any combination of the three attributes:
+ application, user account and location..
+
+
+
+
+
+
+
+ This family defines requirements to select the set of events to
+ be audited during TOE operation from the set of all auditable
+ events.
+
+
+
+ The Security audit event selection family provides
+ requirements related to the capabilities of identifying which
+ of the possible auditable events are to be audited. The
+ auditable events are defined in the family, but those events should be defined as
+ being selectable in this component to be audited.
+
+ This family ensures that it is possible to keep the audit
+ trail from becoming so large that it becomes useless, by
+ defining the appropriate granularity of the selected
+ security audit events.
+
+
+
+
+
+
+
+
+
+ This component defines the selection criteria used, and the
+ resulting audited subsets of the set of all auditable events,
+ based on user attributes, subject attributes, object attributes,
+ or event types.
+
+ The existence of individual user identities is not assumed
+ for this component. This allows for TOEs such as routers
+ that may not support the notion of users.
+
+ For a distributed environment, the host identity could be
+ used as a selection criteria for events to be audited.
+
+ The management function
+ will handle the rights of authorised users to query or
+ modify the selections.
+
+
+ , requires the ability to
+ select the set of events to be audited from the set of all
+ auditable events, identified in , based upon attributes to be specified by the
+ PP/ST author.
+
+
+ maintenance of the rights to view/modify the audit events.
+
+
+ All modifications to the audit configuration that occur
+ while the audit collection functions are operating.
+
+
+ The TSF shall be able to select the set of events to be audited from
+ the set of all auditable events based on the following
+ attributes:
+ object identityuser identitysubject identityhost identityevent type
+ the PP/ST author should select whether the
+ security attributes upon which audit selectivity
+ is based, is related to object identity, user
+ identity, subject identity, host identity, or event type.
+ list of additional attributes that audit selectivity is based upon
+
+ the PP/ST author should specify any additional
+ attributes upon which audit selectivity is based. If
+ there are no additional rules upon which audit
+ selectivity is based, this assignment can be
+ completed with ``none''.
+
+
+
+
+
+
+ This family defines the requirements for the TSF to be able
+ to create and maintain a secure audit trail. Stored audit
+ records refers to those records within the audit trail, and
+ not the audit records that have been retrieved (to temporary
+ storage) through selection.
+
+
+
+ The Security audit event storage family describes
+ requirements for storing audit data for later use, including
+ requirements controlling the loss of audit information due
+ to TOE failure, attack and/or exhaustion of storage
+ space.
+
+
+
+
+
+
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+ The TSF will protect the stored audit records in the audit trail from unauthorised
+ deletion and modification. It is noted that in some TOEs the
+ auditor (role) might not be authorised to delete the audit
+ records for a certain period of time.
+
+
+
+ At , requirements are
+ placed on the audit trail. It will be protected from
+ unauthorised deletion and/or modification.
+
+
+ The TSF shall protect the stored audit records in the audit
+ trail from unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+
+
+
+
+
+
+
+
+ This component allows the PP/ST author to specify to which
+ metrics the audit trail should conform.
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+
+
+ , specifies the guarantees
+ that the TSF maintains over the audit data given the
+ occurrence of an undesired condition.
+
+
+ maintenance of the parameters that control the audit storage
+ capability.
+
+
+ The TSF shall protect the stored audit records in the audit trail from
+ unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+ The TSF shall ensure that
+
+
+ metric for saving audit records
+
+
+
+ the PP/ST author should specify the metric that the TSF
+ must ensure with respect to the stored audit
+ records. This metric limits the data loss by enumerating
+ the number of records that must be kept, or the time
+ that records are guaranteed to be maintained. An example
+ of the metric could be ``100,000'' indicating that
+ 100,000 audit records can be stored.
+
+
+ stored audit records will be maintained when the
+ following conditions occur:
+
+ audit storage exhaustion
+ failure
+ attack
+
+
+ the PP/ST author should specify the condition under which the
+ TSF shall still be able to maintain a defined amount of audit
+ data. This condition can be any of the following: audit
+ storage exhaustion, failure, attack.
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that actions will be taken when
+ the audit trail exceeds certain pre-defined limits.
+
+
+
+ , specifies actions to be taken if a
+ threshold on the audit trail is exceeded.
+
+
+ maintenance of the threshold;
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of imminent audit storage failure.
+
+
+ Actions taken due to exceeding of a threshold.
+
+
+ The TSF shall
+
+
+ actions to be taken in case
+ of possible audit storage failure
+
+
+
+ the PP/ST author should indicate the pre-defined
+ limit. If the management functions indicate that this
+ number might be changed by the authorised user, this
+ value is the default value. The PP/ST author might
+ choose to let the authorised user define this
+ limit. In that case the assignment can be for example
+ ``an authorised user set limit''.
+
+
+ if the audit trail exceeds
+
+
+ pre-defined limit
+
+
+
+ the PP/ST author should specify actions that should be
+ taken in case of imminent audit storage failure
+ indicated by exceeding the threshold. Actions might
+ include informing an authorised user.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies the behaviour of the TOE if the audit
+ trail is full: either audit records are ignored, or the TOE is
+ frozen such that no audited events can take place. The
+ requirement also states that no matter how the requirement is
+ instantiated, the authorised user with specific rights to this
+ effect, can continue to generate audited events (actions). The
+ reason is that otherwise the authorised user could not even
+ reset the TOE. Consideration should be given to the choice of
+ the action to be taken by the TSF in the case of audit storage
+ exhaustion, as ignoring events, which provides better
+ availability of the TOE, will also permit actions to be
+ performed without being recorded and without the user being
+ accountable.
+
+
+
+ , specifies actions in case the
+ audit trail is full.
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of audit storage failure.
+
+
+ Actions taken due to the audit storage failure.
+
+
+ The TSF shall
+ ``ignore audited
+ events''``prevent audited events,
+ except those taken by the authorised user with special
+ rights''
+ ``overwrite the oldest stored audit
+ records''
+
+ the PP/ST author should select whether the TSF shall ignore
+ audited actions, or whether it should prevent audited
+ actions from happening, or whether the oldest audit records
+ should be overwritten when the TSF can no longer store audit
+ records. Only one of these options may be chosen.
+ and
+
+ other actions to be taken in case of audit storage
+ failure
+
+ the PP/ST author should specify other actions that should be
+ taken in case of audit storage failure, such as informing the
+ authorised user. If there is no other action to be taken in
+ case of audit storage failure, this assignment can be
+ completed with ``none''.
+ if the audit trail is full.
+
+
+
+
+
+
+
+ This class provides two families specifically concerned with
+ assuring the identity of a party participating in a data
+ exchange. These families are related to assuring the identity
+ of the originator of transmitted information (proof of origin)
+ and assuring the identity of the recipient of transmitted
+ information (proof of receipt). These families ensure that an
+ originator cannot deny having sent the message, nor can the
+ recipient deny having received it.
+
+
+
+ This class describes requirements specifically of interest for
+ TOEs that are used for the transport of information. Families
+ within this class deal with non-repudiation.
+
+ In this class the concept of ``information'' is
+ used. This information should be interpreted as the object
+ being communicated, and could contain an electronic mail
+ message, a file, or a set of predefined attribute types.
+
+ In the literature, the terms ``proof of receipt''
+ and ``proof of origin'' are commonly used
+ terms. However it is recognised that the term
+ ``proof'' might be interpreted in a legal sense to
+ imply a form of mathematical rationale. The components in this
+ class interpret the de-facto use of the word
+ ``proof'' in the context of ``evidence''
+ that the TSF demonstrates the non-repudiated transport of
+ types of information.
+
+
+
+
+
+ Non-repudiation of origin ensures that the originator of
+ information cannot successfully deny having sent the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that receives information
+ during a data exchange is provided with evidence of the
+ origin of the information. This evidence can then be
+ verified by either this subject or other subjects.
+
+
+
+ Non-repudiation of origin defines requirements to provide
+ evidence to users/subjects about the identity of the
+ originator of some information. The originator cannot
+ successfully deny having sent the information because
+ evidence of origin (e.g. digital signature) provides
+ evidence of the binding between the originator and the
+ information sent. The recipient or a third party can verify
+ the evidence of origin. This evidence should not be
+ forgeable.
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of origin might
+ fail. Therefore a PP/ST author should consider including
+ integrity requirements such as in the
+ PP/ST.
+
+ In non-repudiation there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of origin (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of origin, for
+ example, a recipient or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was transmitted. For example, requests for
+ proposals must be transmitted before a certain date in order
+ to be considered. In such instances, these requirements can
+ be customised to provide a timestamp indication (time of
+ origin).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with the capability to request evidence of the
+ origin of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and recipients of evidence.
+
+
+ The identity of the user who requested that evidence of
+ origin would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall be able to generate evidence of origin for
+ transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection, should specify the third
+ parties that can request evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of origin.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+ list of information fields
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of origin for transmitted information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of origin
+ for transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at all times.
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ Non-repudiation of receipt ensures that the recipient of
+ information cannot successfully deny receiving the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that transmits information
+ during a data exchange is provided with evidence of receipt
+ of the information. This evidence can then be verified by
+ either this subject or other subjects.
+
+
+
+ Non-repudiation of receipt defines requirements to provide
+ evidence to other users/subjects that the information was
+ received by the recipient. The recipient cannot successfully
+ deny having received the information because evidence of
+ receipt (e.g. digital signature) provides evidence of the
+ binding between the recipient attributes and the
+ information. The originator or a third party can verify the
+ evidence of receipt. This evidence should not be forgeable.
+
+ It should be noted that the provision of evidence that the
+ information was received does not necessarily imply that the
+ information was read or comprehended, but only delivered
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of receipt with
+ respect to the original information might fail. Therefore a
+ PP/ST author should consider including integrity
+ requirements such as in the PP/ST.
+
+ In non-repudiation, there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of receipt (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided, (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of receipt, for
+ example, an originator or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case, the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was received. For example, when an offer expires
+ at a certain date, orders must be received before a certain
+ date in order to be considered. In such instances, these
+ requirements can be customised to provide a timestamp
+ indication (time of receipt).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with a capability to request evidence of the
+ receipt of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and third parties recipients of
+ evidence.
+
+
+ The identity of the user who requested that evidence of
+ receipt would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+ The TSF shall be able to generate
+ evidence of receipt for received
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can request
+ evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of receipt.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of receipt for received information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of receipt
+ for received
+
+ list of information types
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example electronic mail messages. at all times.
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+ For each cryptographic key generation method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key distribution method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key access method implemented by the
+ TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key destruction method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic operation (such as digital signature,
+ data encryption, key agreement, secure hash, etc.) performed
+ by the TOE, if any, the PP/ST author should select the component.
+
+ Cryptographic functionality may be used to meet objectives
+ specified in class , and in families , , ,
+ , , , to meet a variety of objectives. In the cases
+ where cryptographic functionality is used to meet objectives
+ for other classes, the individual functional components
+ specify the objectives that cryptographic functionality must
+ satisfy. The objectives in class should be
+ used when cryptographic functionality of the TOE is sought by
+ consumers.
+
+
+
+
+
+ Cryptographic keys must be managed throughout their life
+ cycle. This family is intended to support that lifecycle and
+ consequently defines requirements for the following
+ activities: cryptographic key generation, cryptographic key
+ distribution, cryptographic key access and cryptographic key
+ destruction. This family should be included whenever there
+ are functional requirements for the management of
+ cryptographic keys.
+
+
+
+ Cryptographic keys must be managed throughout their
+ lifetime. The typical events in the lifecycle of a
+ cryptographic key include (but are not limited to):
+ generation, distribution, entry, storage, access
+ (e.g. backup, escrow, archive, recovery) and destruction.
+
+ The inclusion of other stages is dependent on the key management
+ strategy being implemented, as the TOE need not be involved in
+ all of the key life-cycle (e.g. the TOE may only generate and
+ distribute cryptographic keys).
+
+ This family is intended to support the cryptographic key
+ lifecycle and consequently defines requirements for the
+ following activities: cryptographic key generation,
+ cryptographic key distribution, cryptographic key access and
+ cryptographic key destruction. This family should be
+ included whenever there are functional requirements for the
+ management of cryptographic keys.
+
+ If Security Audit Data Generation is
+ included in the PP/ST then, in the context of the events
+ being audited:
+
+
+ The object attributes may include the assigned user
+ for the cryptographic key, the user role, the
+ cryptographic operation that the cryptographic key is
+ to be used for, the cryptographic key identifier and
+ the cryptographic key validity period.
+
+
+ The object value may include the values of cryptographic
+ key(s) and parameters excluding any sensitive
+ information (such as secret or private cryptographic
+ keys).
+
+
+
+ Typically, random numbers are used to generate cryptographic
+ keys. If this is the case, then
+ should be used instead of the component .
+ In cases where random number generation is required for purposes other
+ than for the generation of cryptographic keys, the component
+ should be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic key sizes and
+ method used to generate cryptographic keys to be
+ specified, this can be in accordance with an assigned
+ standard. It should be used to specify the cryptographic
+ key sizes and the method (e.g. algorithm) used to generate
+ the cryptographic keys. Only one instance of the component
+ is needed for the same method and multiple key sizes. The
+ key size could be common or different for the various
+ entities, and could be either the input to or the output
+ from the method.
+
+
+
+ , requires cryptographic keys to be
+ generated in accordance with a specified algorithm and key
+ sizes which can be based on an assigned standard.
+
+
+
+ Success and failure of the activity.
+
+
+ The object attribute(s), and object value(s) excluding any
+ sensitive information (e.g. secret or private keys).
+
+
+ The TSF shall generate cryptographic keys in accordance with
+ a specified cryptographic key generation algorithm
+
+
+ cryptographic key generation algorithm
+
+
+
+ the PP/ST author should specify the cryptographic key
+ generation algorithm to be used.
+
+
+ and specified cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to generate
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to distribute
+ cryptographic keys to be specified, this can be in
+ accordance with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ distributed in accordance with a specified distribution
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall distribute cryptographic keys in accordance
+ with a specified cryptographic key distribution method
+
+
+ cryptographic key distribution method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ distribution method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to distribute
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to access
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires access to cryptographic
+ keys to be performed in accordance with a specified access
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall perform
+
+
+ type of cryptographic key access
+
+
+
+ the PP/ST author should specify the type of
+ cryptographic key access being used. Examples of types
+ of cryptographic key access include (but are not
+ limited to) cryptographic key backup, cryptographic
+ key archival, cryptographic key escrow and
+ cryptographic key recovery.
+
+
+ in accordance with a specified cryptographic key access
+ method
+
+
+ cryptographic key access method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ access method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to access cryptographic
+ keys. The assigned standard may comprise none, one or
+ more actual standards publications, for example, from
+ international, national, industry or organisational
+ standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to destroy
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ destroyed in accordance with a specified destruction
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall destroy cryptographic keys in accordance with
+ a specified cryptographic key destruction method
+
+
+ cryptographic key destruction method
+
+
+
+ the PP/ST author should specify the key destruction
+ method to be used to destroy cryptographic keys.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to destroy
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+ In order for a cryptographic operation to function
+ correctly, the operation must be performed in accordance
+ with a specified algorithm and with a cryptographic key of a
+ specified size. This family should be included whenever
+ there are requirements for cryptographic operations to be
+ performed.
+
+ Typical cryptographic operations include data encryption
+ and/or decryption, digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or verification of checksum, secure hash
+ (message digest), cryptographic key encryption and/or
+ decryption, and cryptographic key agreement.
+
+
+
+ A cryptographic operation may have cryptographic mode(s) of
+ operation associated with it. If this is the case, then the
+ cryptographic mode(s) must be specified. Examples of
+ cryptographic modes of operation are cipher block chaining,
+ output feedback mode, electronic code book mode, and cipher
+ feedback mode.
+
+ Cryptographic operations may be used to support one or more
+ TOE security services. The component
+ may need to be iterated more than once depending on:
+
+
+ the user application for which the security service is
+ being used.
+
+
+ the use of different cryptographic algorithms and/or
+ cryptographic key sizes.
+
+
+ the type or sensitivity of the data being operated on.
+
+
+
+ If Security audit data generation is
+ included in the PP/ST then, in the context of the
+ cryptographic operation events being audited:
+
+
+ The types of cryptographic operation may include digital
+ signature generation and/or verification, cryptographic
+ checksum generation for integrity and/or for
+ verification of checksum, secure hash (message digest)
+ computation, data encryption and/or decryption,
+ cryptographic key encryption and/or decryption,
+ cryptographic key agreement and random number
+ generation.
+
+
+ The subject attributes may include subject role(s) and
+ user(s) associated with the subject.
+
+
+ The object attributes may include the assigned user for
+ the cryptographic key, user role, cryptographic
+ operation the cryptographic key is to be used for,
+ cryptographic key identifier, and the cryptographic key
+ validity period.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic algorithm and
+ key size used to perform specified cryptographic
+ operation(s) which can be based on an assigned standard.
+
+
+
+ , requires a cryptographic operation
+ to be performed in accordance with a specified algorithm
+ and with a cryptographic key of specified sizes. The
+ specified algorithm and cryptographic key sizes can be
+ based on an assigned standard.
+
+
+ Success and failure, and the type of cryptographic
+ operation.
+
+
+ Any applicable cryptographic mode(s) of operation, subject
+ attributes and object attributes.
+
+
+ The TSF shall perform
+
+
+ list of cryptographic operations
+
+
+
+ the PP/ST author should specify the cryptographic
+ operations being performed. Typical cryptographic
+ operations include digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or for verification of checksum, secure
+ hash (message digest) computation, data encryption
+ and/or decryption, cryptographic key encryption and/or
+ decryption, cryptographic key agreement and random
+ number generation. The cryptographic operation may be
+ performed on user data or TSF data.
+
+
+ in accordance with a specified cryptographic algorithm
+
+
+ cryptographic algorithm
+
+
+
+ the PP/ST author should specify the cryptographic
+ algorithm to be used. Typical cryptographic algorithms
+ include, but are not limited to, DES, RSA and IDEA.
+
+
+ and cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents how the identified cryptographic
+ operation(s) are performed. The assigned standard may
+ comprise none, one or more actual standards
+ publications, for example, from international,
+ national, industry or organisational standards.
+
+ .
+
+
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. is split
+ into four groups of families (listed below) that address user
+ data within a TOE, during import, export, and storage as well
+ as security attributes directly related to user data.
+
+ The families in this class are organised into four groups:
+
+
+ User data protection security function policies:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families permit the PP/ST author to
+ name the user data protection security function policies
+ and define the scope of control of the policy, necessary
+ to address the security objectives. The names of these
+ policies are meant to be used throughout the remainder
+ of the functional components that have an operation that
+ calls for an assignment or selection of an "access
+ control SFP" or an "information flow control
+ SFP". The rules that define the functionality of
+ the named access control and information flow control
+ SFPs will be defined in the and
+ families (respectively).
+
+
+ Forms of user data protection:
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ; and
+
+
+ .
+
+
+
+
+ Off-line storage, import and export:
+
+
+ ;
+
+
+ ;
+
+
+ .
+
+
+
+ Components in these families address the trustworthy
+ transfer into or out of the TOE.
+
+
+ Inter-TSF communication:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families address communication
+ between the TSF of the TOE and another trusted IT
+ product.
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. This class differs from FIA and FPT
+ in that specifies components to
+ protect user data, FIA specifies components to protect
+ attributes associated with the user, and FPT specifies
+ components to protect TSF information.
+
+ The class does not contain explicit requirements for
+ traditional Mandatory Access Controls (MAC) or traditional
+ Discretionary Access Controls (DAC); however, such
+ requirements may be constructed using components from this
+ class.
+
+ does not explicitly deal with
+ confidentiality, integrity, or availability, as all three are
+ most often intertwined in the policy and mechanisms. However,
+ the TOE security policy must adequately cover these three
+ objectives in the PP/ST.
+
+ A final aspect of this class is that it specifies access
+ control in terms of ``operations''. An operation
+ is defined as a specific type of access on a specific
+ object. It depends on the level of abstraction of the PP/ST
+ author whether these operations are described as
+ ``read'' and/or ``write''
+ operations, or as more complex operations such as
+ ``update the database''.
+
+ The access control policies are policies that control access
+ to the information container. The attributes represent
+ attributes of the container. Once the information is out of
+ the container, the accessor is free to modify that
+ information, including writing the information into a
+ different container with different attributes. By contrast, an
+ information flow policies controls access to the information,
+ independent of the container. The attributes of the
+ information, which may be associated with the attributes of
+ the container (or may not, as in the case of a multi-level
+ database) stay with the information as it moves. The accessor
+ does not have the ability, in the absence of an explicit
+ authorisation, to change the attributes of the information.
+
+ This class is not meant to be a complete taxonomy of IT access
+ policies, as others can be imagined. Those policies included
+ here are simply those for which current experience with actual
+ systems provides a basis for specifying requirements. There
+ may be other forms of intent that are not captured in the
+ definitions here.
+
+ For example, one could imagine a goal of having user-imposed
+ (and user-defined) controls on information flow (e.g. an
+ automated implementation of the NO FOREIGN handling
+ caveat). Such concepts could be handled as refinements of, or
+ extensions to the components.
+
+ Finally, it is important when looking at the components in
+ to remember that these components are
+ requirements for functions that may be implemented by a
+ mechanism that also serves or could serve another purpose. For
+ example, it is possible to build an access control policy
+ () that uses labels () as the basis of the access control
+ mechanism.
+
+ A set of SFRs may encompass many security function
+ policies (SFPs), each to be identified by the two policy
+ oriented components , and . These policies will typically take
+ confidentiality, integrity, and availability aspects into
+ consideration as required, to satisfy the TOE
+ requirements. Care should be taken to ensure that all objects
+ are covered by at least one SFP and that there are no
+ conflicts arising from implementing the multiple SFPs.
+
+ When building a PP/ST using components from the class, the following information provides guidance
+ on where to look and what to select from the class.
+
+ The requirements in the class are defined in
+ terms of a set of SFRs that will
+ implement a SFP. Since a TOE may implement multiple SFPs
+ simultaneously, the PP/ST author must specify the name for
+ each SFP, so it can be referenced in other families. This name
+ will then be used in each component selected to indicate that
+ it is being used as part of the definition of requirements for
+ that SFP. This allows the author to easily indicate the
+ scope for operations such as objects covered, operations
+ covered, authorised users, etc.
+
+ Each instantiation of a component can apply to only one
+ SFP. Therefore if an SFP is specified in a component then
+ this SFP will apply to all the elements in this
+ component. The components may be instantiated multiple times
+ within a PP/ST to account for different policies if so
+ desired.
+
+ The key to selecting components from this family is to have a
+ well defined set of TOE security objectives to enable proper
+ selection of the components from the two policy components;
+ and . In and respectively, all access control
+ policies and all information flow control policies are
+ named. Furthermore the scope of control of these components in
+ terms of the subjects, objects and operations covered by this
+ security functionality. The names of these policies are meant
+ to be used throughout the remainder of the functional
+ components that have an operation that calls for an assignment
+ or selection of an ``access control SFP'' or an ``information
+ flow control SFP''. The rules that define the functionality
+ of the named access control and information flow control SFPs
+ will be defined in the and
+ families
+ (respectively).
+
+ The following steps are guidance on how this class is applied
+ in the construction of a PP/ST:
+
+
+ Identify the policies to be enforced from the , and families. These
+ families define scope of control for the policy,
+ granularity of control and may identify some rules to go
+ with the policy.
+
+
+ Identify the components and perform any applicable operations
+ in the policy components. The assignment operations may be
+ performed generally (such as with a statement ``All
+ files'') or specifically (``The files
+ ``A'', ``B'', etc.) depending upon
+ the level of detail known.
+
+
+ Identify any applicable function components from the and families to address
+ the named policy families from and
+ . Perform the operations to make the
+ components define the rules to be enforced by the named
+ policies. This should make the components fit the
+ requirements of the selected function envisioned or to be
+ built.
+
+
+ Identify who will have the ability to control and change
+ security attributes under the function, such as only a
+ security administrator, only the owner of the object,
+ etc. Select the appropriate components from
+ and perform the operations. Refinements may be useful here
+ to identify missing features, such as that some or all
+ changes must be done via trusted path.
+
+
+ Identify any appropriate components from the for initial values for new objects and subjects.
+
+
+ Identify any applicable rollback components from the family.
+
+
+ Identify any applicable residual information protection
+ requirements from the family.
+
+
+ Identify any applicable import or export components, and how
+ security attributes should be handled during import and
+ export, from the and families.
+
+
+ Identify any applicable internal TOE communication
+ components from the family.
+
+
+ Identify any requirements for integrity protection of stored
+ information from the .
+
+
+ Identify any applicable inter-TSF communication components
+ from the or
+ families.
+
+
+
+
+
+
+
+ This family identifies the access control SFPs (by name) and
+ defines the scope of control of the policies that form the
+ identified access control portion of the SFRs related to the
+ SFP. This scope of control is characterised by three sets: the
+ subjects under control of the policy, the objects under control
+ of the policy, and the operations among controlled subjects and
+ controlled objects that are covered by the policy. The criteria
+ allows multiple policies to exist, each having a unique name.
+ This is accomplished by iterating components from this family
+ once for each named access control policy. The rules that
+ define the functionality of an access control SFP will be
+ defined by other families such as and . The names
+ of the access control SFPs identified here in are meant to be used throughout the remainder of
+ the functional components that have an operation that calls for
+ an assignment or selection of an ``access control SFP.''
+
+
+
+ This family is based upon the concept of arbitrary controls
+ on the interaction of subjects and objects. The scope and
+ purpose of the controls is based upon the attributes of the
+ accessor (subject), the attributes of the container being
+ accessed (object), the actions (operations) and any
+ associated access control rules.
+
+ The components in this family are capable of identifying the
+ access control SFPs (by name) to be enforced by the traditional
+ Discretionary Access Control (DAC) mechanisms. It further
+ defines the subjects, objects and operations that are covered by
+ identified access control SFPs. The rules that define the
+ functionality of an access control SFP will be defined by other
+ families, such as and . The names of the access control SFPs
+ defined in are meant to be used
+ throughout the remainder of the functional components that have
+ an operation that calls for an assignment or selection of an
+ ``access control SFP.''
+
+ The access control SFP covers a set of triplets: subject,
+ object, and operations. Therefore a subject can be covered
+ by multiple access control SFPs but only with respect to a
+ different operation or a different object. Of course the
+ same applies to objects and operations.
+
+ A critical aspect of an access control function that
+ enforces an access control SFP is the ability for users to
+ modify the attributes involved in access control
+ decisions. The family does not address
+ these aspects. Some of these requirements are left
+ undefined, but can be added as refinements, while others are
+ covered elsewhere in other families and classes such as
+ .
+
+ There are no audit requirements in as
+ this family specifies access control SFP requirements. Audit
+ requirements will be found in families specifying functions
+ to satisfy the access control SFPs identified in this
+ family.
+
+ This family provides a PP/ST author the capability to
+ specify several policies, for example, a fixed access
+ control SFP to be applied to one scope of control, and a
+ flexible access control SFP to be defined for a different
+ scope of control. To specify more than one access control
+ policy, the components from this family can be iterated
+ multiple times in a PP/ST to different subsets of operations
+ and objects. This will accommodate TOEs that contain
+ multiple policies, each addressing a particular set of
+ operations and objects. In other words, the PP/ST author
+ should specify the required information in the ACC component
+ for each of the access control SFPs that the TSF will
+ enforce. For example, a TOE incorporating three access
+ control SFPs, each covering only a subset of the objects,
+ subjects, and operations within the TOE, will contain one
+ component for each of the three
+ access control SFPs, necessitating a total of three components.
+
+
+
+
+
+
+
+
+ The terms object and subject refer to generic elements in
+ the TOE. For a policy to be implementable, the entities
+ must be clearly identified. For a PP, the objects and
+ operations might be expressed as types such as: named
+ objects, data repositories, observe accesses, etc. For a
+ specific TOE these generic terms (subject, object) must be
+ refined, e.g. files, registers, ports, daemons, open
+ calls, etc.
+
+ This component specifies that the policy cover some
+ well-defined set of operations on some subset of the
+ objects. It places no constraints on any operations
+ outside the set - including operations on objects for
+ which other operations are controlled.
+
+
+
+ , requires that each identified
+ access control SFP be in place for a subset of the
+ possible operations on a subset of the objects in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects, objects, and operations among subjects
+ and objects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ objects, and operations among subjects and objects
+ covered by the SFP.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations on
+ objects, that are included in the SFP, are covered by an
+ access control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ objects and subjects is covered by an access control SFP.
+
+
+
+ , requires that each identified
+ access control SFP cover all operations on subjects and
+ objects covered by that SFP. It further requires that all
+ objects and operations protected by the TSF are covered by at
+ least one identified access control SFP.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects and objects
+
+
+
+ the PP/ST author should specify the list of subjects
+ and objects covered by the SFP. All operations among
+ those subjects and objects will be covered by the SFP.
+
+
+ and all operations among subjects and objects covered by the
+ SFP.
+
+
+ The TSF shall ensure that all operations between any subject
+ controlled by the TSF and any object controlled by the TSF are covered by an
+ access control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in . specifies the scope of control of the
+ policy.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in which also specifies the scope of
+ control of the policy.
+
+ This family provides a PP/ST author the capability to
+ describe the rules for access control. This results in a
+ TOE where the access to objects will not change. An
+ example of such an object is ``Message of the Day'', which
+ is readable by all, and changeable only by the authorised
+ administrator. This family also provides the PP/ST author
+ with the ability to describe rules that provide for
+ exceptions to the general access control rules. Such
+ exceptions would either explicitly allow or deny
+ authorisation to access an object.
+
+ There are no explicit components to specify other possible
+ functions such as two-person control, sequence rules for
+ operations, or exclusion controls. However, these
+ mechanisms, as well as traditional DAC mechanisms, can be
+ represented with the existing components, by careful
+ drafting of the access control rules.
+
+ A variety of acceptable access control functionality may be
+ specified in this family such as:
+
+
+ Access control lists (ACLs)
+
+
+ Time-based access control specifications
+
+
+ Origin-based access control specifications
+
+
+ Owner-controlled access control attributes
+
+
+
+
+
+
+
+
+
+
+ This component provides requirements for a mechanism that
+ mediates access control based on security attributes
+ associated with subjects and objects. Each object and
+ subject has a set of associated attributes, such as
+ location, time of creation, access rights (e.g., Access
+ Control Lists (ACLs)). This component allows the PP/ST
+ author to specify the attributes that will be used for the
+ access control mediation. This component allows access
+ control rules, using these attributes, to be
+ specified.
+
+ Examples of the attributes that a PP/ST author might
+ assign are presented in the following paragraphs.
+
+ An identity attribute may be associated with users,
+ subjects, or objects to be used for mediation. Examples of
+ such attributes might be the name of the program image
+ used in the creation of the subject, or a security
+ attribute assigned to the program image.
+
+ A time attribute can be used to specify that access will
+ be authorised during certain times of the day, during
+ certain days of the week, or during a certain calendar
+ year.
+
+ A location attribute could specify whether the location is
+ the location of the request for the operation, the
+ location where the operation will be carried out, or
+ both. It could be based upon internal tables to translate
+ the logical interfaces of the TSF into locations such as
+ through terminal locations, CPU locations, etc.
+
+ A grouping attribute allows a single group of users to be
+ associated with an operation for the purposes of access
+ control. If required, the refinement operation should be
+ used to specify the maximum number of definable groups,
+ the maximum membership of a group, and the maximum number
+ of groups to which a user can concurrently be
+ associated.
+
+ This component also provides requirements for the access
+ control security functions to be able to explicitly
+ authorise or deny access to an object based upon security
+ attributes. This could be used to provide privilege,
+ access rights, or access authorisations within the
+ TOE. Such privileges, rights, or authorisations could
+ apply to users, subjects (representing users or
+ applications), and objects.
+
+
+
+ This family addresses security attribute usage and
+ characteristics of policies. The component within this
+ family is meant to be used to describe the rules for the
+ function that implements the SFP as identified in . The PP/ST author may also
+ iterate this component to address multiple policies in the
+ TOE.
+
+ Security attribute
+ based access control allows the TSF to enforce access
+ based upon security attributes and named groups of
+ attributes. Furthermore, the TSF may have the ability to
+ explicitly authorise or deny access to an object based
+ upon security attributes.
+
+
+ Managing the attributes used to make explicit access or
+ denial based decisions.
+
+
+ Successful requests to perform an operation on an object
+ covered by the SFP.
+
+
+ All requests to perform an operation on an object covered by
+ the SFP.
+
+
+ The specific security attributes used in making an access
+ check.
+
+
+ The TSF shall enforce the
+
+ access control SFP
+
+ the PP/ST author should specify an access control SFP
+ name that the TSF is to enforce. The name of the access
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+ to objects based on the following:
+
+ list of subjects and objects controlled under the
+ indicated SFP, and for each, the SFP-relevant security
+ attributes, or named groups of SFP-relevant security
+ attributes
+
+ the PP/ST author should specify, for each controlled
+ subject and object, the security attributes and/or named
+ groups of security attributes that the function will use
+ in the specification of the rules. For example, such
+ attributes may be things such as the user identity,
+ subject identity, role, time of day, location, ACLs, or
+ any other attribute specified by the PP/ST author. Named
+ groups of security attributes can be specified to
+ provide a convenient means to refer to multiple security
+ attributes. Named groups could provide a useful way to
+ associate ``roles'' defined in , and
+ all of their relevant attributes, with subjects. In
+ other words, each role could relate to a named group of
+ attributes..
+
+
+ The TSF shall enforce the following rules to determine if an
+ operation among controlled subjects and controlled objects
+ is allowed:
+
+
+ rules governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects
+
+
+
+ the PP/ST author should specify the SFP rules
+ governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects. These rules specify when access
+ is granted or denied. It can specify general access
+ control functions (e.g. typical permission bits) or
+ granular access control functions (e.g. ACLs).
+
+ .
+
+
+ The TSF shall explicitly authorise access of subjects to
+ objects based on the following additional rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise access of subjects to objects
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise access
+ of subjects to objects that will be used to explicitly
+ authorise access. These rules are in addition to those
+ specified in . They are
+ included in as they are
+ intended to contain exceptions to the rules in . An example of rules to explicitly
+ authorise access is based on a privilege vector
+ associated with a subject that always grants access to
+ objects covered by the access control SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny access of subjects to objects based on the
+ following additional rules:
+ rules, based on security attributes, that
+ explicitly deny access of subjects to objects the PP/ST author should specify the rules,
+ based on security attributes, that explicitly deny access of subjects
+ to objects. These rules are in addition to those specified in
+
+ . They are included in
+
+ as they are intended to contain exceptions to the rules in
+
+ . An example of rules to explicitly deny access is based on a privilege
+ vector associated with a subject
+ that always denies access to objects covered by the access control SFP
+ that has been specified. If such a capability is not desired, then the
+ PP/ST author should specify ``none''..
+
+
+
+
+
+
+
+ Data authentication permits an entity to accept
+ responsibility for the authenticity of information (e.g., by
+ digitally signing it). This family provides a method of
+ providing a guarantee of the validity of a specific unit of
+ data that can be subsequently used to verify that the
+ information content has not been forged or fraudulently
+ modified. In contrast to , this family is
+ intended to be applied to "static" data rather
+ than data that is being transferred.
+
+
+
+ This family describes specific functions that can be used to
+ authenticate ``static'' data.
+
+ Components in this family are to be used when there is a
+ requirement for ``static'' data
+ authentication, i.e. where data is to be signed but not
+ transmitted. (Note that the family
+ provides for non-repudiation of origin of information
+ received during a data exchange.)
+
+
+
+
+
+ This component may be satisfied by one-way hash functions
+ (cryptographic checksum, fingerprint, message digest), to
+ generate a hash value for a definitive document that may
+ be used as verification of the validity or authenticity of
+ its information content.
+
+
+
+ , requires that the TSF is capable
+ of generating a guarantee of authenticity of the
+ information content of objects (e.g. documents).
+
+
+ The assignment or modification of the objects for which data
+ authentication may apply could be configurable.
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element. The list of subjects could be
+ very specific, if the subjects are known, or it could
+ be more generic and refer to a
+ ``type'' of subject such
+ as an identified role.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information.
+
+
+
+
+
+
+
+
+
+
+ This component additionally requires the ability to verify
+ the identity of the user that provided the guarantee of
+ authenticity (e.g. a trusted third party).
+
+
+
+ additionally requires that the TSF
+ is capable of establishing the identity of the subject who
+ provided the guarantee of authenticity.
+
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The identity of the subject that generated the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element as well as the identity of the
+ user that created the data authentication evidence.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information and the identity of the user that
+ generated the evidence.
+
+
+
+
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes and protection
+ either can be explicitly preserved or can be ignored once it
+ has been exported. It is concerned with limitations on
+ export and with the association of security attributes with
+ the exported user data.
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes either can be
+ explicitly preserved or can be ignored once it has been
+ exported. Consistency of these security attributes are
+ addressed by .
+
+ is concerned with limitations on export
+ and association of security attributes with the exported
+ user data.
+
+ This family, and the corresponding Import family , address how the TOE deals with user data
+ transferred into and outside its control. In principle this
+ family is concerned with the TSF-mediated exporting of user data and its
+ related security attributes.
+
+ A variety of activities might be involved here:
+
+
+ exporting of user data without any security attributes;
+
+
+ exporting user data including security attributes where
+ the two are associated with one another and the security
+ attributes unambiguously represent the exported user
+ data.
+
+
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the TSF-mediated exporting of user data
+ without the export of its security attributes.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs when exporting user data outside the
+ TSF. User data that is exported by this function is
+ exported without its associated security attributes.
+
+
+ Successful export of information.
+
+
+ All attempts to export information.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data without the user
+ data's associated security attributes
+
+
+
+
+
+
+
+
+
+
+
+
+ The user data is exported together with its security
+ attributes. The security attributes are unambiguously
+ associated with the user data. There are several ways of
+ achieving this association. One way that this can be
+ achieved is by physically collocating the user data and
+ the security attributes (e.g. the same floppy), or by
+ using cryptographic techniques such as secure signatures
+ to associate the attributes and the user data. could be used to assure that the attributes
+ are correctly received at the other trusted IT product
+ while can be used to make sure that
+ those attributes are properly interpreted. Furthermore,
+ could be used to make sure that the
+ export is being initiated by the proper user.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs using a function that accurately and
+ unambiguously associates security attributes with the user
+ data that is exported.
+
+
+ The additional exportation control rules could be
+ configurable by a user in a defined role.
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data with the user
+ data's associated security attributes.
+
+
+ The TSF shall ensure that the security attributes, when
+ exported outside the TOE, are unambiguously associated with
+ the exported user data.
+
+
+ The TSF shall enforce the following rules when user data is
+ exported from the TOE:
+
+
+ additional exportation control rules
+
+
+
+ the PP/ST author should specify any additional
+ exportation control rules or
+ ``none'' if there are no
+ additional exportation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family identifies the information flow control SFPs (by
+ name) and defines the scope of control for each named
+ information flow control SFP. This scope of control is
+ characterised by three sets: the subjects under control of the
+ policy, the information under control of the policy, and
+ operations which cause controlled information to flow to and
+ from controlled subjects covered by the policy. The criteria
+ allows multiple policies to exist, each having a unique name.
+ This is accomplished by iterating components from this family
+ once for each named information flow control policy. The rules
+ that define the functionality of an information flow control SFP
+ will be defined by other families such as and . The names
+ of the information flow control SFPs identified here in are meant to be used throughout the
+ remainder of the functional components that have an operation
+ that calls for an assignment or selection of an ``information
+ flow control SFP.''
+
+ The TSF mechanism controls the flow of information in
+ accordance with the information flow control SFP. Operations
+ that would change the security attributes of information are
+ not generally permitted as this would be in violation of an
+ information flow control SFP. However, such operations may
+ be permitted as exceptions to the information flow control
+ SFP if explicitly specified.
+
+
+
+ This family covers the identification of information flow
+ control SFPs; and, for each, specifies the scope of control
+ of the SFP.
+
+ The components in this family are capable of identifying the
+ information flow control SFPs to be enforced by the traditional
+ Mandatory Access Control mechanisms that would be found in a
+ TOE. However, they go beyond just the traditional MAC mechanisms
+ and can be used to identify and describe non-interference
+ policies and state-transitions. It further defines the subjects
+ under control of the policy, the information under control of
+ the policy, and operations which cause controlled information to
+ flow to and from controlled subjects for each information flow
+ control SFP in the TOE. The information flow control SFP will be
+ defined by other families such as and . The
+ information flow control SFPs named here in are meant to be used throughout the remainder of
+ the functional components that have an operation that calls for
+ an assignment or selection of an ``information flow control
+ SFP.''
+
+ These components are quite flexible. They allow the domain
+ of flow control to be specified and there is no requirement
+ that the mechanism be based upon labels. The different
+ elements of the information flow control components also
+ permit different degrees of exception to the policy.
+
+ Each SFP covers a set of triplets: subject, information, and
+ operations that cause information to flow to and from
+ subjects. Some information flow control policies may be at a
+ very low level of detail and explicitly describe subjects in
+ terms of processes within an operating system. Other
+ information flow control policies may be at a high level and
+ describe subjects in the generic sense of users or
+ input/output channels. If the information flow control
+ policy is at too high a level of detail, it may not clearly
+ define the desired IT security functions. In such cases, it
+ is more appropriate to include such descriptions of
+ information flow control policies as objectives. Then the
+ desired IT security functions can be specified as supportive
+ of those objectives.
+
+ In the second component (), each
+ information flow control SFP will cover all possible
+ operations that cause information covered by that SFP to
+ flow to and from subjects covered by that SFP. Furthermore,
+ all information flows will need to be covered by a
+ SFP. Therefore for each action that causes information to
+ flow, there will be a set of rules that define whether the
+ action is allowed. If there are multiple SFPs that are
+ applicable for a given information flow, all involved SFPs
+ must allow this flow before it is permitted to take place.
+
+ An information flow control SFP covers a well-defined set of
+ operations. The SFPs coverage may be
+ ``complete'' with respect to some
+ information flows, or it may address only some of the
+ operations that affect the information flow.
+
+ An access control SFP controls access to the objects that
+ contain information. An information flow control SFP
+ controls access to the information, independent of its
+ container. The attributes of the information, which may be
+ associated with the attributes of the container (or may not,
+ as in the case of a multi-level database) stay with the
+ information as it flows. The accessor does not have the
+ ability, in the absence of an explicit authorisation, to
+ change the attributes of the information.
+
+ Information flows and operations can be expressed at
+ multiple levels. In the case of a ST, the information flows
+ and operations might be specified at a system-specific
+ level: TCP/IP packets flowing through a firewall based upon
+ known IP addresses. For a PP, the information flows and
+ operations might be expressed as types: email, data
+ repositories, observe accesses, etc.
+
+ The components in this family can be applied multiple times
+ in a PP/ST to different subsets of operations and
+ objects. This will accommodate TOEs that contain multiple
+ policies, each addressing a particular set of objects,
+ subjects, and operations.
+
+
+
+
+
+
+
+
+ This component requires that an information flow control
+ policy apply to a subset of the possible operations in the
+ TOE.
+
+
+
+ , requires that each identified
+ information flow control SFPs be in place for a subset of
+ the possible operations on a subset of information flows
+ in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects, information, and operations that cause
+ controlled information to flow to and from controlled
+ subjects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ information, and operations which cause controlled
+ information to flow to and from controlled subjects
+ covered by the SFP. As mentioned above, the list of
+ subjects could be at various levels of detail
+ depending on the needs of the PP/ST author. It could
+ specify users, machines, or processes for
+ example. Information could refer to data such as email
+ or network protocols, or more specific objects similar
+ to those specified under an access control policy. If
+ the information that is specified is contained within
+ an object that is subject to an access control policy,
+ then both the access control policy and information
+ flow control policy must be enforced before the
+ specified information could flow to or from the
+ object.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations that
+ cause information to flow to and from subjects included in
+ the SFP, are covered by an information flow control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ information flows and subjects is covered by an
+ information flow control SFP.
+
+
+
+ , requires that each identified
+ information flow control SFP cover all operations on
+ subjects and information covered by that SFP. It further
+ requires that all information flows and operations controlled
+ by the TSF are covered by at least one identified information
+ flow control SFP.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects and information
+
+
+
+ the PP/ST author should specify the list of subjects
+ and information that will be covered by the SFP. All
+ operations that cause that information to flow to and
+ from subjects will be covered by the SFP. As mentioned
+ above, the list of subjects could be at various levels
+ of detail depending on the needs of the PP/ST
+ author. It could specify users, machines, or processes
+ for example. Information could refer to data such as
+ email or network protocols, or more specific objects
+ similar to those specified under an access control
+ policy. If the information that is specified is
+ contained within an object that is subject to an
+ access control policy, then both the access control
+ policy and information flow control policy must be
+ enforced before the specified information could flow
+ to or from the object.
+
+
+ and all operations that cause that information to flow to
+ and from subjects covered by the SFP.
+
+
+ The TSF shall ensure that all operations that cause any
+ information in the TOE to flow to and from any subject in
+ the TOE are covered by an information flow control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policy. It consists of two kinds of
+ requirements: one addressing the common information flow
+ function issues, and a second addressing illicit information
+ flows (i.e. covert channels). This division arises because
+ the issues concerning illicit information flows are, in some
+ sense, orthogonal to the rest of an information flow control
+ SFP. By their nature they circumvent the information flow
+ control SFP resulting in a violation of the policy. As such,
+ they require special functions to either limit or prevent
+ their occurrence.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policies. It consists of two
+ ``trees:'' one addressing the common
+ information flow control function issues, and a second
+ addressing illicit information flows (i.e. covert channels)
+ with respect to one or more information flow control
+ SFPs. This division arises because the issues concerning
+ illicit information flows are, in some sense, orthogonal to
+ the rest of an SFP. Illicit information flows are flows in
+ violation of policy; thus they are not a policy issue.
+
+ In order to implement strong protection against disclosure
+ or modification in the face of untrusted software, controls
+ on information flow are required. Access controls alone are
+ not sufficient because they only control access to
+ containers, allowing the information they contain to flow,
+ without controls, throughout a system.
+
+ In this family, the phrase ``types of illicit
+ information flows'' is used. This phrase may be
+ used to refer to the categorisation of flows as
+ ``Storage Channels'' or
+ ``Timing Channels'', or it can refer to
+ improved categorisations reflective of the needs of a PP/ST
+ author.
+
+ The flexibility of these components allows the definition of
+ a privilege policy within and to allow the controlled bypass of all or
+ part of a particular SFP. If there is a need for a
+ predefined approach to SFP bypass, the PP/ST author should
+ consider incorporating a privilege policy.
+
+
+
+
+
+
+
+
+
+ This component requires security attributes on
+ information, and on subjects that cause that information
+ to flow and subjects that act as recipients of that
+ information. The attributes of the containers of the
+ information should also be considered if it is desired
+ that they should play a part in information flow control
+ decisions or if they are covered by an access control
+ policy. This component specifies the key rules that are
+ enforced, and describes how security attributes are
+ derived.
+
+ This component does not specify the details of how a
+ security attribute is assigned (i.e. user versus
+ process). Flexibility in policy is provided by having
+ assignments that allow specification of additional policy
+ and function requirements, as necessary.
+
+ This component also provides requirements for the
+ information flow control functions to be able to
+ explicitly authorise and deny an information flow based
+ upon security attributes. This could be used to implement
+ a privilege policy that covers exceptions to the basic
+ policy defined in this component.
+
+
+
+ , requires security attributes on
+ information, and on subjects that cause that information
+ to flow and on subjects that act as recipients of that
+ information. It specifies the rules that must be enforced
+ by the function, and describes how security attributes are
+ derived by the function.
+
+
+ Managing the attributes used to make explicit access based
+ decisions.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+ the PP/ST author should specify any additional information
+ flow control SFP rules that the TSF is to enforce. This
+ includes all rules of the SFP that are either not based on the
+ security attributes of the information and the subject or
+ rules that automatically modify the security attributes of
+ information or subjects as a result of an access operation.
+ An example for the first case is a rule of the SFP controlling
+ a threshold value for specific types of information. This
+ would for example be the case when the information flow SFP
+ contains rules on access to statistical data where a subject
+ is only allowed to access this type of information up to a
+ specific number of accesses. An example for the second case
+ would be a rule stating under which conditions and how the
+ security attributes of a subject or object change as the
+ result of an access operation. Some information flow policies
+ for example may limit the number of access operations to
+ information with specific security attributes. If there are
+ no additional rules then the PP/ST author should specify
+ ``none''.
+ .
+
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on security
+ attributes, that explicitly deny information flows. These rules
+ are in addition to those specified in the preceding
+ elements. They are included in as they
+ are intended to contain exceptions to the rules in the preceding
+ elements. An example of rules to explicitly deny information
+ flows is based on a privilege vector associated with a subject
+ that always denies the subject the ability to cause an
+ information flow for information that is covered by the SFP that
+ has been specified. If such a capability is not desired, then
+ the PP/ST author should specify ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that the named information flow control
+ SFP uses hierarchical security attributes that
+ form a lattice.
+
+ It is important to note that the hierarchical relationship
+ requirements identified in need
+ only apply to the information flow control security
+ attributes for the information flow control SFPs that have
+ been identified in . This
+ component is not meant to apply to other SFPs such as
+ access control SFPs.
+ phrases the requirements for the set of
+ security attributes to form a lattice. A number of information
+ flow policies defined in the literature and implemented in IT
+ products are based on a set of security attributes that form a
+ lattice. is specifically included to
+ address this type of information flow policies.
+
+ If it is the case that multiple information flow control
+ SFPs are to be specified, and that each of these SFPs will
+ have their own security attributes that are not related to
+ one another, then the PP/ST author should iterate this
+ component once for each of those SFPs. Otherwise a
+ conflict might arise with the sub-items of since the required relationships will
+ not exist.
+
+
+ expands on the requirements
+ of by requiring that all
+ information flow control SFPs in the set of SFRs use
+ hierarchical security attributes that form a lattice (as defined
+ in mathematics). is derived from the
+ mathematical properties of a lattice. A lattice consists of a
+ set of elements with an ordering relationship with the property
+ defined in the first bullet, a least upper bound which is the
+ unique element in the set that is greater or equal (in the
+ ordering relationship) than any other element of the lattice,
+ and a greatest lower bound, which is the unique element in the set
+ that is smaller or equal than any other element of the lattice.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules, based on the
+ ordering relationships between security attributes hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce. These
+ relationships should be based upon the ordering
+ relationships between the security attributes.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+ the PP/ST author should specify any additional information
+ flow control SFP rules that the TSF is to enforce. This
+ includes all rules of the SFP that are either not based on the
+ security attributes of the information and the subject or
+ rules that automatically modify the security attributes of
+ information or subjects as a result of an access operation.
+ An example for the first case is a rule of the SFP controlling
+ a threshold value for specific types of information. This
+ would for example be the case when the information flow SFP
+ contains rules on access to statistical data where a subject
+ is only allowed to access this type of information up to a
+ specific number of accesses. An example for the second case
+ would be a rule stating under which conditions and how the
+ security attributes of a subject or object change as the
+ result of an access operation. Some information flow policies
+ for example may limit the number of access operations to
+ information with specific security attributes. If there are
+ no additional rules then the PP/ST author should specify
+ ``none''.
+ .
+
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on security
+ attributes, that explicitly deny information flows. These rules
+ are in addition to those specified in the preceding
+ elements. They are included in as they are intended to contain exceptions to the
+ rules in the preceding elements. An example of rules to
+ explicitly deny information flows is based on a privilege vector
+ associated with a subject that always denies the subject the
+ ability to cause an information flow for information that is
+ covered by the SFP that has been specified. If such a capability
+ is not desired, then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall enforce the following relationships for any
+ two valid information flow control security attributes:
+
+
+ There exists an ordering function that, given two valid
+ security attributes, determines if the security
+ attributes are equal, if one security attribute is
+ greater than the other, or if the security attributes
+ are incomparable; and
+
+
+ There exists a ``least upper bound''
+ in the set of security attributes, such that, given any
+ two valid security attributes, there is a valid security
+ attribute that is greater than or equal to the two valid
+ security attributes; and
+
+
+ There exists a ``greatest lower
+ bound'' in the set of security attributes,
+ such that, given any two valid security attributes,
+ there is a valid security attribute that is not greater
+ than the two valid security attributes.
+
+
+
+
+
+
+
+
+
+
+
+ This component should be used when at least one of the
+ SFPs that requires control of illicit information flows
+ does not require elimination of flows.
+
+ For the specified illicit information flows, certain
+ maximum capacities should be provided. In addition a PP/ST
+ author has the ability to specify whether the illicit
+ information flows must be audited.
+
+
+
+ , requires the SFP to cover illicit
+ information flows, but not necessarily eliminate them.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The use of identified illicit information flow channels.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The use of identified illicit information flow channels with
+ estimated maximum capacity exceeding a specified value.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when all the SFPs that
+ requires control of illicit information flows require
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+ , requires the SFP to cover the
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows which are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+ The TSF shall prevent
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows to be eliminated. This list may not
+ be empty as this component requires that some illicit
+ information flows are to be eliminated.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when the SFPs that require
+ control of illicit information flows require elimination
+ of all illicit information flows. However, the PP/ST
+ author should carefully consider the potential impact that
+ eliminating all illicit information flows might have on
+ the normal functional operation of the TOE. Many practical
+ applications have shown that there is an indirect
+ relationship between illicit information flows and normal
+ functionality within a TOE and eliminating all illicit
+ information flows may result in less than desired
+ functionality.
+
+
+
+ , requires SFP to cover the
+ elimination of all illicit information flows.
+
+
+
+
+
+ The TSF shall ensure that no illicit information flows exist
+ to circumvent
+
+
+ name of information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFP for which illicit information flows are to
+ be eliminated. The name of the information flow
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+
+ .
+
+
+
+
+
+
+
+
+
+ This component should be used when it is desired that the
+ TSF provide the ability to monitor the use of illicit
+ information flows that exceed a specified capacity. If it
+ is desired that such flows be audited, then this component
+ could serve as the source of audit events to be used by
+ components from the family.
+
+
+
+ , requires the SFP to monitor
+ illicit information flows for specified and maximum
+ capacities.
+
+
+ The enabling or disabling of the monitoring function.
+
+
+ Modification of the maximum capacity at which the monitoring
+ occurs.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to monitor
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that will be monitored for exceeding
+ a maximum capacity.
+
+
+ when it exceeds the
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ above which illicit information flows will be
+ monitored by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family defines the mechanisms for TSF-mediated importing of user
+ data into the TOE such that it has appropriate security
+ attributes and is appropriately protected. It is concerned
+ with limitations on importation, determination of desired
+ security attributes, and interpretation of security
+ attributes associated with the user data.
+
+
+
+ This family defines mechanisms for TSF-mediated importing of user data from
+ outside the TOE into the TOE such that the user data
+ security attributes can be preserved. Consistency of these
+ security attributes are addressed by .
+
+ is concerned with limitations on
+ import, user specification of security attributes, and
+ association of security attributes with the user data.
+
+ This family, and the corresponding export family , address how the TOE deals with user data
+ outside its control. This family is concerned with assigning
+ and abstraction of the user data security attributes.
+
+ A variety of activities might be involved here:
+
+
+ importing user data from an unformatted medium
+ (e.g. floppy disk, tape, scanner, video or audit
+ signal), without including any security attributes, and
+ physically marking the medium to indicate its contents;
+
+
+ importing user data, including security attributes, from
+ a medium and verifying that the object security
+ attributes are appropriate;
+
+
+ importing user data, including security attributes, from
+ a medium using a cryptographic sealing technique to
+ protect the association of user data and security
+ attributes.
+
+
+
+ This family is not concerned with the determination of
+ whether the user data may be imported. It is concerned with
+ the values of the security attributes to associate with the
+ imported user data.
+
+ There are two possibilities for the import of user data:
+ either the user data is unambiguously associated with
+ reliable object security attributes (values and meaning of
+ the security attributes is not modified), or no reliable
+ security attributes (or no security attributes at all) are
+ available from the import source. This family addresses both
+ cases.
+
+ If there are reliable security attributes available, they
+ may have been associated with the user data by physical
+ means (the security attributes are on the same media), or by
+ logical means (the security attributes are distributed
+ differently, but include unique object identification,
+ e.g. cryptographic checksum).
+
+ This family is concerned with TSF-mediated importing of user data and
+ maintaining the association of security attributes as
+ required by the SFP. Other families are concerned with other
+ import aspects such as consistency, trusted channels, and
+ integrity that are beyond the scope of this
+ family. Furthermore, is only concerned
+ with the interface to the import medium. is responsible for the other end point of the
+ medium (the source).
+
+ Some of the well known import requirements are:
+
+
+ importing of user data without any security attributes;
+
+
+ importing of user data including security attributes
+ where the two are associated with one another and the
+ security attributes unambiguously represent the
+ information being imported.
+
+
+
+ These import requirements may be handled by the TSF with or
+ without human intervention, depending on the IT limitations
+ and the organisational security policy. For example, if user
+ data is received on a ``confidential''
+ channel, the security attributes of the objects will be set
+ to ``confidential''.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that does not have reliable (or any) security attributes
+ associated with it. This function requires that the
+ security attributes for the imported user data be
+ initialised within the TSF. It could also be the case that
+ the PP/ST author specifies the rules for import. It may be
+ appropriate, in some environments, to require that these
+ attributes be supplied via a trusted path or a trusted
+ channel mechanism.
+
+
+
+ , requires that the security
+ attributes correctly represent the user data and are
+ supplied separately from the object.
+
+
+ The modification of the additional control rules used for
+ import.
+
+
+ Successful import of user data, including any security
+ attributes.
+
+
+ All attempts to import user data, including any security
+ attributes.
+
+
+ The specification of security attributes for imported user
+ data supplied by an authorised user.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s) and/or information flow control SFP(s)
+
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be
+ enforced when importing user data from outside of the
+ TOE. The user data that this function imports is
+ scoped by the assignment of these SFPs.
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall ignore any security attributes associated with
+ the user data when imported from outside the TOE.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that has reliable security attributes associated with
+ it. This function relies upon the security attributes that
+ are accurately and unambiguously associated with the
+ objects on the import medium. Once imported, those objects
+ will have those same attributes. This requires to ensure the consistency of the data. It
+ could also be the case that the PP/ST author specifies the
+ rules for import.
+
+
+
+ , requires that security attributes
+ correctly represent the user data and are accurately and
+ unambiguously associated with the user data imported from
+ outside the TOE.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when importing user data from outside
+ of the TOE. The user data that this function imports
+ is scoped by the assignment of these SFPs.
+
+
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall use the security attributes associated with
+ the imported user data.
+
+
+ The TSF shall ensure that the protocol used provides for the
+ unambiguous association between the security attributes and
+ the user data received.
+
+
+ The TSF shall ensure that interpretation of the security
+ attributes of the imported user data is as intended by the
+ source of the user data.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between separated parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and families,
+ which provide protection for user data when it is
+ transferred between distinct TSFs across an external
+ channel, and and ,
+ which address TSF-mediated transfer of data to or from outside the
+ TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and family, which
+ provide protection for user data when it is transferred
+ between distinct TSFs across an external channel, and and , which address
+ TSF-mediated transfer of data to or from outside the TOE.
+
+ The requirements in this family allow a PP/ST author to
+ specify the desired security for user data while in transit
+ within the TOE. This security could be protection against
+ disclosure, modification, or loss of availability.
+
+ The determination of the degree of physical separation above
+ which this family should apply depends on the intended
+ environment of use. In a hostile environment, there may be
+ risks arising from transfers between parts of the TOE
+ separated by only a system bus. In more benign environments,
+ the transfers may be across more traditional network media.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ , requires that user data be
+ protected when transmitted between parts of the TOE.
+
+
+ If the TSF provides multiple methods to protect user data
+ during transmission between physically separated parts of
+ the TOE, the TSF could provide a pre-defined role with the
+ ability to select the method that will be used.
+
+
+ Successful transfers of user data, including identification
+ of the protection method used.
+
+
+ All attempts to transfer user data, including the protection
+ method used and any errors that occurred.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component could, for example, be used to provide
+ different forms of protection to information with
+ different clearance levels.
+
+ One of the ways to achieve separation of data when it is
+ transmitted is through the use of separate logical or
+ physical channels.
+
+
+
+ , requires separation of data based
+ on the value of SFP-relevant attributes in addition to the
+ first component.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+ The TSF shall separate data controlled by the SFP(s) when
+ transmitted between physically-separated parts of the TOE,
+ based on the values of the following:
+
+
+ security attributes that require separation
+
+
+
+ the PP/ST author should specify the security
+ attributes, the values of which the TSF will use to
+ determine when to separate data that is being
+ transmitted between physically-separated parts of the
+ TOE. An example is that user data associated with the
+ identity of one owner is transmitted separately from
+ the user data associated with the identify of a
+ different owner. In this case, the value of the
+ identity of the owner of the data is what is used to
+ determine when to separate the data for transmission.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with either or . It ensures
+ that the TSF checks received user data (and their
+ attributes) for integrity. or will provide the data in a manner such
+ that it is protected from modification (so that can detect any modifications).
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ , requires that the TSF monitor user
+ data transmitted between parts of the TOE for identified
+ integrity errors.
+
+
+ The specification of the actions to be taken upon detection
+ of an integrity error could be configurable.
+
+
+ Successful transfers of user data, including identification
+ of the integrity protection method used.
+
+
+ All attempts to transfer user data, including the integrity
+ protection method used and any errors that occurred.
+
+
+ Unauthorised attempts to change the integrity protection
+ method.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with . It ensures that the TSF checks received
+ user data, that has been transmitted by separate channels
+ (based on values of specified security attributes), for
+ integrity. It allows the PP/ST author to specify actions
+ to be taken upon detection of an integrity error.
+
+ For example, this component could be used to provide
+ different integrity error detection and action for
+ information at different integrity levels.
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author should specify the attributes (and
+ associated transmission channels) that necessitate
+ integrity error monitoring
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ expands on the third component by
+ allowing the form of integrity monitoring to differ by
+ SFP-relevant attribute.
+
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow
+ control SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ , based on the following attributes:
+
+
+ security attributes that require separate transmission
+ channels
+
+
+
+ the PP/ST author should specify a list of security
+ attributes that require separate transmission
+ channels. This list is used to determine which user
+ data to monitor for integrity errors., based on its
+ security attributes and its transmission channel. This
+ element is directly related to .
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity
+ error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the need to ensure that any data contained
+ in a resource is not available when the resource is de-allocated
+ from one object and reallocated to a different object. This
+ family requires protection for any data contained in a resource
+ that has been logically deleted or released, but may still be
+ present within the TSF-controlled resource which in turn may be
+ re-allocated to another object.
+
+
+
+ Residual information protection ensures that TSF-controlled
+ resources when de-allocated from an object and before they are
+ reallocated to another object are treated by the TSF in a way
+ that it is not possible to reconstruct all or part of the data
+ contained in the resource before it was de-allocated.
+
+ A TOE usually has a number of functions that potentially
+ de-allocate resources from an object and potentially re-allocate
+ those resources to objects. Some, but not all of those resources
+ may have been used to store critical data from the previous use
+ of the resource and for those resources FDP_RIP requires that
+ they are prepared for reuse. Object reuse applies to explicit
+ requests of a subject or user to release resources as well as
+ implicit actions of the TSF that result in the de-allocation and
+ subsequent re-allocation of resources to different
+ objects. Examples of explicit requests are the deletion or
+ truncation of a file or the release of an area of main
+ memory. Examples of implicit actions of the TSF are the
+ de-allocation and re-allocation of cache regions.
+ The requirement for object reuse is related to the content of
+ the resource belonging to an object, not all information about
+ the resource or object that may be stored elsewhere in the
+ TSF. As an example to satisfy the FDP_RIP requirement for files
+ as objects requires that all sectors that make up the file need
+ to be prepared for re-use.
+
+ It also applies to resources that are serially reused by
+ different subjects within the system. For example, most
+ operating systems typically rely upon hardware registers
+ (resources) to support processes within the system. As
+ processes are swapped from a ``run'' state to a ``sleep''
+ state (and vice versa), these registers are serially reused
+ by different subjects. While this ``swapping'' action may
+ not be considered an allocation or deallocation of a
+ resource, could apply to
+ such events and resources.
+
+ typically controls access
+ to information that is not part of any currently defined or
+ accessible object; however, in certain cases this may not be
+ true. For example, object ``A'' is a file and object ``B''
+ is the disk upon which that file resides. If object ``A'' is
+ deleted, the information from object ``A'' is under the
+ control of even though it
+ is still part of object ``B''.
+
+ It is important to note that applies only to on-line objects and not
+ off-line objects such as those backed-up on tapes. For
+ example, if a file is deleted in the TOE, can be instantiated to require that no
+ residual information exists upon deallocation; however, the
+ TSF cannot extend this enforcement to that same file that
+ exists on the off-line back-up. Therefore that same file is
+ still available. If this is a concern, then the PP/ST author
+ should make sure that the proper environmental objectives
+ are in place to support operational user guidance to address
+ off-line objects.
+
+ and can conflict when is instantiated to require that residual
+ information be cleared at the time the application releases
+ the object to the TSF (i.e. upon deallocation). Therefore,
+ the selection of
+ ``deallocation'' should not be used with since there would be no information to roll
+ back. The other selection, ``unavailability upon
+ allocation'', may be used with , but there is the risk that the resource
+ which held the information has been allocated to a new
+ object before the roll back took place. If that were to
+ occur, then the roll back would not be possible.
+
+ There are no audit requirements in because this is not a user-invokable
+ function. Auditing of allocated or deallocated resources
+ would be auditable as part of the access control SFP or the
+ information flow control SFP operations.
+
+ This family should apply to the objects specified in the
+ access control SFP(s) or the information flow control SFP(s)
+ as specified by the PP/ST author.
+
+
+
+
+
+ This component requires that, for a subset of the objects
+ in the TOE, the TSF will ensure that there is no available
+ residual information contained in a resource allocated to
+ those objects or deallocated from those objects.
+
+
+
+ , requires that the TSF
+ ensure that any residual information content of any
+ resources is unavailable to a defined subset of the
+ objects controlled by the TSF upon the resource's
+ allocation or deallocation.
+
+
+ The choice of when to perform residual information
+ protection (i.e. upon allocation or deallocation) could be
+ made configurable within the TOE.
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ the following objects:
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ subject to residual information protection.
+
+ .
+
+
+
+
+
+
+
+ This component requires that for all objects in the TOE,
+ the TSF will ensure that there is no available residual
+ information contained in a resource allocated to those
+ objects or deallocated from those objects.
+
+
+
+ , requires that the TSF ensure that
+ any residual information content of any resources is
+ unavailable to all objects upon the resource's
+ allocation or deallocation.
+
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ all objects.
+
+
+
+
+
+
+
+ The rollback operation involves undoing the last operation
+ or a series of operations, bounded by some limit, such as a
+ period of time, and return to a previous known
+ state. Rollback provides the ability to undo the effects of
+ an operation or series of operations to preserve the
+ integrity of the user data.
+
+
+
+ This family addresses the need to return to a well defined
+ valid state, such as the need of a user to undo
+ modifications to a file or to undo transactions in case of
+ an incomplete series of transaction as in the case of
+ databases.
+
+ This family is intended to assist a user in returning to a
+ well defined valid state after the user undoes the last set
+ of actions, or, in distributed databases, the return of all
+ of the distributed copies of the databases to the state
+ before an operation failed.
+
+ and conflict when
+ enforces that the contents will be made
+ unavailable at the time that a resource is deallocated from
+ an object. Therefore, this use of
+ cannot be combined with as there would
+ be no information to roll back. can be
+ used only with when it enforces that
+ the contents will be unavailable at the time that a resource
+ is allocated to an object. This is because the mechanism will have an opportunity to access
+ the previous information that may still be present in the
+ TOE in order to successfully roll back the operation.
+
+ The rollback requirement is bounded by certain limits. For
+ example a text editor typically only allows you roll back up
+ to a certain number of commands. Another example would be
+ backups. If backup tapes are rotated, after a tape is
+ reused, the information can no longer be retrieved. This
+ also poses a bound on the rollback requirement.
+
+
+
+
+
+
+
+
+
+
+
+ This component allows a user or subject to undo a set of
+ operations on a predefined set of objects. The undo is
+ only possible within certain limits, for example up to a
+ number of characters or up to a time limit.
+
+
+
+ addresses a need to roll back or
+ undo a limited number of operations within the defined
+ bounds.
+
+
+ The boundary limit to which rollback may be performed could
+ be a configurable item within the TOE.
+
+
+ Permission to perform a rollback operation could be
+ restricted to a well defined role.
+
+
+ All successful rollback operations.
+
+
+ All attempts to perform rollback operations.
+
+
+ All attempts to perform rollback operations, including
+ identification of the types of operations rolled back.
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of the
+
+
+ list of operations
+
+
+
+ the PP/ST author should specify the list of operations
+ that can be rolled back.
+
+
+ on the
+
+ information and/or list of objects
+
+ the PP/ST author should specify the information and/or
+ list of objects that are subjected to the rollback policy..
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component enforces that the TSF provide the
+ capability to rollback all operations; however, the user
+ can choose to rollback only a part of them.
+
+
+
+ addresses the need to roll back or
+ undo all operations within the defined bounds.
+
+
+
+
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of all the operations on the
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ that are subjected to the rollback policy.
+
+ .
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF. Integrity
+ errors may affect user data stored in memory, or in a
+ storage device. This family differs from which protects the user data from integrity
+ errors while being transferred within the TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF.
+
+ Hardware glitches or errors may affect data stored in
+ memory. This family provides requirements to detect these
+ unintentional errors. The integrity of user data while
+ stored on storage devices controlled by the TSF are also addressed
+ by this family.
+
+ To prevent a subject from modifying the data, the or families are required
+ (rather than this family).
+
+ This family differs from that protects
+ the user data from integrity errors while being transferred
+ within the TOE.
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify different kinds of
+ user data attributes that will be used as the basis for
+ monitoring.
+
+
+
+ , requires that the TSF monitor user
+ data stored within containers controlled by the TSF for identified integrity
+ errors.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify which action should
+ be taken in case an integrity error is detected.
+
+
+
+ adds the additional capability to
+ the first component by allowing for actions to be taken as
+ a result of an error detection.
+
+
+ The actions to be taken upon the detection of an integrity
+ error could be configurable.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ action to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken in case an integrity error is detected.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT product.
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT
+ product. Confidentiality is enforced by preventing
+ unauthorised disclosure of user data in transit between the
+ two end points. The end points may be a TSF or a user.
+
+ This family provides a requirement for the protection of user
+ data during transit. In contrast, handles TSF data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Depending on the access control or information flow policies the TSF is
+ required to send or receive user data in a manner such that the
+ confidentiality of the user data is protected.
+
+
+
+ In , the goal is to provide
+ protection from disclosure of user data while in transit.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any unauthorised user or subject attempting
+ to use the data exchange mechanisms.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the information.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s) and/or information flow control SFP(s)
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be enforced when exchanging
+ user data. The specified policies will be enforced to make decisions about
+ who can exchange data and which data can be exchanged.
+ to
+ transmitreceivethe PP/ST author should specify whether this element
+ applies to a mechanism that transmits or receives user data.
+ user data in a manner protected from unauthorised disclosure.
+
+
+
+
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TOE and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TSF and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+ This family defines the requirements for providing integrity
+ for user data in transit; while handles
+ TSF data.
+
+ and are duals of
+ each other, as addresses user data
+ confidentiality. Therefore, the same mechanism that
+ implements could possibly be used to
+ implement other families such as and
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Depending on the access control or information flow policies the TSF is
+ required to send or receive user data in a manner such that modification
+ of the user data is detected. There is no requirement for a TSF mechanism
+ to attempt to recover from the modification.
+
+
+
+ addresses detection of
+ modifications, deletions, insertions, and replay errors of
+ the user data transmitted.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+ access control SFP(s) and/or information flow control SFP(s)
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be enforced on the transmitted
+ data or on the received data. The specified policies will be enforced to make
+ decisions about who can transmit or who can receive data, and which data can be
+ transmitted or received.
+ to
+ transmitreceivethe PP/ST author should specify whether this element applies
+ to a TSF that is transmitting or receiving objects.
+ user data in a manner protected from
+ modificationdeletioninsertionreplaythe PP/ST author should specify whether the data should be
+ protected from modification, deletion, insertion or replay.
+ errors.
+
+
+ The TSF shall be able to determine on receipt of user data,
+ whether
+
+
+ modification
+
+
+ deletion
+
+
+ insertion
+
+
+ replay
+
+
+
+ the PP/ST author should specify whether the errors of
+ the type: modification, deletion, insertion or replay
+ are detected.
+
+
+ has occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors, if required, with the
+ help of the other trusted IT product. As the other trusted
+ IT product is outside the TOE, the TSF cannot control its
+ behaviour. However, it can provide functions that have the
+ ability to cooperate with the other trusted IT product for
+ the purposes of recovery. For example, the TSF could
+ include functions that depend upon the source trusted IT
+ product to re-send the data in the event that an error is
+ detected. This component deals with the ability of the TSF
+ to handle such an error recovery.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF with help from the source
+ trusted IT product.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ Successful recovery from errors including they type of error
+ that was detected.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the TSF, with the help of the source
+ trusted IT product, is be able to recover the original
+ user data.
+
+
+ with the help of the source trusted IT product.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors. It accomplishes this
+ task without help from the source trusted IT product. For
+ example, if certain errors are detected, the transmission
+ protocol must be robust enough to allow the TSF to recover
+ from the error based on checksums and other information
+ available within that protocol.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF on its own without any help
+ from the source trusted IT product.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the receiving TSF, alone, is able to
+ recover the original user data.
+
+
+ without any help from the source trusted IT product.
+
+
+
+
+
+
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user identity.
+
+ Identification and Authentication is required to ensure that
+ users are associated with the proper security attributes
+ (e.g. identity, groups, roles, security or integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the intended
+ security policies. The families in this class deal with
+ determining and verifying the identity of users, determining
+ their authority to interact with the TOE, and with the correct
+ association of security attributes for each authorised
+ user. Other classes of requirements (e.g. User Data
+ Protection, Security Audit) are dependent upon correct
+ identification and authentication of users in order to be
+ effective.
+
+
+
+ A common security requirement is to unambiguously identify the
+ person and/or entity performing functions in a TOE. This
+ involves not only establishing the claimed identity of each
+ user, but also verifying that each user is indeed who he/she
+ claims to be. This is achieved by requiring users to provide
+ the TSF with some information that is known by the TSF to be
+ associated with the user in question.
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user
+ identity. Identification and Authentication is required to
+ ensure that users are associated with the proper security
+ attributes (e.g. identity, groups, roles, security or
+ integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the security
+ policies.
+
+ The family addresses determining the
+ identity of a user.
+
+ The family addresses verifying the
+ identity of a user.
+
+ The family addresses defining limits on
+ repeated unsuccessful authentication attempts.
+
+ The family address the definition of user
+ attributes that are used in the enforcement of the SFRs.
+
+ The family addresses the correct
+ association of security attributes for each authorised user.
+
+ The family addresses the generation and
+ verification of secrets that satisfy a defined metric.
+
+
+
+
+
+ This family contains requirements for defining values for
+ some number of unsuccessful authentication attempts and TSF
+ actions in cases of authentication attempt
+ failures. Parameters include, but are not limited to, the
+ number of failed authentication attempts and time
+ thresholds.
+
+
+
+ This family addresses requirements for defining values for
+ authentication attempts and TSF actions in cases of
+ authentication attempt failure. Parameters include, but are
+ not limited to, the number of attempts and time thresholds.
+
+ The session establishment process is the interaction with
+ the user to perform the session establishment independent of
+ the actual implementation. If the number of unsuccessful
+ authentication attempts exceeds the indicated threshold,
+ either the user account or the terminal (or both) will be
+ locked. If the user account is disabled, the user cannot
+ log-on to the system. If the terminal is disabled, the
+ terminal (or the address that the terminal has) cannot be
+ used for any log-on. Both of these situations continue until
+ the condition for re-establishment is satisfied.
+
+
+
+
+
+
+
+
+ The PP/ST author may define the number of unsuccessful
+ authentication attempts or may choose to let the TOE
+ developer or the authorised user to define this
+ number. The unsuccessful authentication attempts need not
+ be consecutive, but rather related to an authentication
+ event. Such an authentication event could be the count
+ from the last successful session establishment at a given
+ terminal.
+
+ The PP/ST author could specify a list of actions that the
+ TSF shall take in the case of authentication failure. An
+ authorised administrator could also be allowed to manage
+ the events, if deemed opportune by the PP/ST author. These
+ actions could be, among other things, terminal
+ deactivation, user account deactivation, or administrator
+ alarm. The conditions under which the situation will be
+ restored to normal must be specified on the action.
+
+ In order to prevent denial of service, TOEs usually ensure
+ that there is at least one user account that cannot be
+ disabled.
+
+ Further actions for the TSF can be stated by the PP/ST
+ author, including rules for re-enabling the user session
+ establishment process, or sending an alarm to the
+ administrator. Examples of these actions are: until a
+ specified time has lapsed, until the authorised
+ administrator re-enables the terminal/account, a time
+ related to failed previous attempts (every time the
+ attempt fails, the disabling time is doubled).
+
+
+
+ , requires that the TSF be able to
+ terminate the session establishment process after a
+ specified number of unsuccessful user authentication
+ attempts. It also requires that, after termination of the
+ session establishment process, the TSF be able to disable
+ the user account or the point of entry (e.g. workstation)
+ from which the attempts were made until an
+ administrator-defined condition occurs.
+
+
+ management of the threshold for unsuccessful authentication
+ attempts;
+
+
+ management of actions to be taken in the event of an
+ authentication failure.
+
+
+ the reaching of the threshold for the unsuccessful
+ authentication attempts and the actions (e.g. disabling of a
+ terminal) taken and the subsequent, if appropriate,
+ restoration to the normal state (e.g. re-enabling of a
+ terminal).
+
+
+ The TSF shall detect when
+
+ positive integer number
+
+ if the assignment of a positive integer is selected,
+ the PP/ST author should specify the default number
+ (positive integer) of unsuccessful authentication
+ attempts that, when met or surpassed, will trigger
+ the events.
+ an administrator configurable positive integer within
+
+ range of acceptable values
+
+ if an administrator configurable positive integer is
+ selected, the PP/ST author should specify the range of
+ acceptable values from which the administrator of the
+ TOE may configure the number of unsuccessful
+ authentication attempts. The number of authentication
+ attempts should be less than or equal to the upper
+ bound and greater or equal to the lower bound values.
+ the PP/ST author should select either the assignment of a positive integer,
+ or the phrase ``an administrator configurable positive integer'' specifying
+ the range of acceptable values.
+ unsuccessful authentication attempts occur related to
+
+
+ list of authentication events
+
+
+
+ the PP/ST author should specify the authentication
+ events. Examples of these authentication events are:
+ the unsuccessful authentication attempts since the
+ last successful authentication for the indicated user
+ identity, the unsuccessful authentication attempts
+ since the last successful authentication for the
+ current terminal, the number of unsuccessful
+ authentication attempts in the last 10 minutes. At
+ least one authentication event must be specified.
+
+ .
+
+
+ When the defined number of unsuccessful authentication
+ attempts has been
+ metsurpassed
+ the PP/ST author should select whether the event of
+ meeting or surpassing the defined number of unsuccessful
+ authentication attemps shall trigger an action by the
+ TSF., the TSF shall
+
+ list of actions
+
+ the PP/ST author should specify the actions to be taken in
+ case the threshold is met or surpassed, as selected. These
+ actions could be disabling of an account for 5 minutes,
+ disabling the terminal for an increasing amount of time (2
+ to the power of the number of unsuccessful attempts in
+ seconds), or disabling of the account until unlocked by
+ the administrator and simultaneously informing the
+ administrator. The actions should specify the measures and
+ if applicable the duration of the measure (or the
+ conditions under which the measure will be ended)..
+
+
+
+
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that is used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that are used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+ There are dependencies on the individual security policy (SFP)
+ definitions. These individual definitions should contain the
+ listing of attributes that are necessary for policy
+ enforcement.
+
+
+
+
+
+ This component specifies the security attributes that
+ should be maintained at the level of the user. This means
+ that the security attributes listed are assigned to and
+ can be changed at the level of the user. In other words,
+ changing a security attribute in this list associated with
+ a user should have no impact on the security attributes of
+ any other user.
+
+ In case security attributes belong to a group of users
+ (such as Capability List for a group), the user will need
+ to have a reference (as security attribute) to the
+ relevant group.
+
+
+
+ , allows user security attributes
+ for each user to be maintained individually.
+
+
+ if so indicated in the assignment, the authorised
+ administrator might be able to define additional security
+ attributes for users.
+
+
+ The TSF shall maintain the following list of security
+ attributes belonging to individual users:
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that are associated to an individual
+ user. An example of such a list is
+ {``clearance'', ``group
+ identifier'', ``rights''}.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets and generate
+ secrets to satisfy the defined metric.
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets, and generate
+ secrets to satisfy the defined metric. Examples of such
+ mechanisms may include automated checking of user supplied
+ passwords, or automated password generation.
+
+ A secret can be generated outside the TOE (e.g. selected by
+ the user and introduced in the TOE). In such cases, the
+ component can be used to
+ ensure that the external generated secret adheres to certain
+ standards, for example a minimum size, not present in a
+ dictionary, and/or not previously used.
+
+ Secrets can also be generated by the TOE. In those cases,
+ the component can be used
+ to require the TOE to ensure that the secrets that will
+ adhere to some specified metrics.
+
+ Secrets contain the authentication data provided by the user
+ for an authentication mechanism that is based on knowledge
+ the user possesses. When cryptographic keys are employed,
+ the class should be used instead of this
+ family.
+
+
+
+
+
+ Secrets can be generated by the user. This component
+ ensures that those user generated secrets can be verified
+ to meet a certain quality metric.
+
+
+
+ , requires the TSF to verify that
+ secrets meet defined quality metrics.
+
+
+ the management of the metric used to verify the secrets.
+
+
+ Rejection by the TSF of any tested secret;
+
+
+ Rejection or acceptance by the TSF of any tested secret;
+
+
+ Identification of any changes to the defined quality
+ metrics.
+
+
+ The TSF shall provide a mechanism to verify that secrets
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed, or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+
+
+
+
+ This component allows the TSF to generate secrets for
+ specific functions such as authentication by means of
+ passwords.
+
+ When a pseudo-random number generator is used in a secret
+ generation algorithm, it should accept as input random
+ data that would provide output that has a high degree of
+ unpredictability. This random data (seed) can be derived
+ from a number of available parameters such as a system
+ clock, system registers, date, time, etc. The parameters
+ should be selected to ensure that the number of unique
+ seeds that can be generated from these inputs should be at
+ least equal to the minimum number of secrets that must be
+ generated.
+
+
+
+ , requires the TSF to be able to
+ generate secrets that meet defined quality metrics.
+
+
+ the management of the metric used to generate the secrets.
+
+
+
+
+
+ The TSF shall provide a mechanism to generate secrets that
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+ The TSF shall be able to enforce the use of TSF generated
+ secrets for
+
+
+ list of TSF functions
+
+
+
+ the PP/ST author should provide a list of TSF
+ functions for which the TSF generated secrets must be
+ used. An example of such a function could include a
+ password based authentication mechanism.
+
+ .
+
+
+
+
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family also defines
+ the required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family defines the
+ required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+
+
+
+
+
+ This component requires that the PP/ST author define the
+ TSF-mediated actions that can be performed by the TSF on
+ behalf of the user before the claimed identity of the user
+ is authenticated. The TSF-mediated actions should have no
+ security concerns with users incorrectly identifying
+ themselves prior to being authenticated. For all other
+ TSF-mediated actions not in the list, the user must be
+ authenticated before the action can be performed by the
+ TSF on behalf of the user.
+
+ This component cannot control whether the actions can also
+ be performed before the identification took place. This
+ requires the use of either or
+ with the appropriate assignments.
+
+
+
+ , allows a user to perform certain
+ actions prior to the authentication of the
+ user's identity.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the associated
+ user;
+
+
+ managing the list of actions that can be taken before the
+ user is authenticated.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism;
+
+
+ All TSF mediated actions performed before authentication of
+ the user.
+
+
+ The TSF shall allow
+
+
+ list of TSF mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the claimed identity of the user is
+ authenticated. This list cannot be empty. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ authenticated.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+
+
+
+
+ This component requires that a user is authenticated before any other
+ TSF-mediated action can take place on behalf of that user.
+
+
+ , requires that users are
+ authenticated before any other action will be allowed by the TSF.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the user associated
+ with this data.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+ This component addresses requirements for mechanisms that
+ provide protection of authentication data. Authentication
+ data that is copied from another user, or is in some way
+ constructed should be detected and/or rejected. These
+ mechanisms provide confidence that users authenticated by
+ the TSF are actually who they claim to be.
+
+ This component may be useful only with authentication
+ mechanisms that are based on authentication data that
+ cannot be shared (e.g. biometrics). It is impossible for a
+ TSF to detect or prevent the sharing of passwords outside
+ the control of the TSF.
+
+
+
+ Unforgeable authentication,
+ requires the authentication mechanism to be able to detect
+ and prevent the use of authentication data that has been
+ forged or copied.
+
+
+ Detection of fraudulent authentication data;
+
+
+ All immediate measures taken and results of checks on the
+ fraudulent data.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent forging of
+ authentication data.
+
+
+ use of authentication data that has been forged by any user
+ of the TSF.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent copying of
+ authentication data.
+
+
+ use of authentication data that has been copied from any
+ other user of the TSF.
+
+
+
+
+
+
+ This component addresses requirements for authentication
+ mechanisms based on single-use authentication
+ data. Single-use authentication data can be something the
+ user has or knows, but not something the user is. Examples
+ of single-use authentication data include single-use
+ passwords, encrypted time-stamps, and/or random numbers
+ from a secret lookup table.
+
+ The PP/ST author can specify to which authentication
+ mechanism(s) this requirement applies.
+
+
+
+ , requires an authentication
+ mechanism that operates with single-use authentication
+ data.
+
+
+ Attempts to reuse authentication data.
+
+
+ The TSF shall prevent reuse of authentication data related
+ to
+
+
+ identified authentication mechanism(s)
+
+
+
+ the PP/ST author should specify the list of
+ authentication mechanisms to which this requirement
+ applies. This assignment can be ``all
+ authentication mechanisms''. An example of
+ this assignment could be ``the
+ authentication mechanism employed to authenticate
+ people on the external network''.
+
+ .
+
+
+
+
+
+
+ The use of this component allows specification of
+ requirements for more than one authentication mechanism to
+ be used within a TOE. For each distinct mechanism,
+ applicable requirements must be chosen from the class to be applied to each
+ mechanism. It is possible that the same component could be
+ selected multiple times in order to reflect different
+ requirements for the different use of the authentication
+ mechanism.
+
+ The management functions in the class FMT may provide
+ maintenance capabilities for the set of authentication
+ mechanisms, as well as the rules that determine whether
+ the authentication was successful.
+
+ To allow anonymous users to interact with the TOE, a
+ ``none'' authentication mechanism can be incorporated. The
+ use of such access should be clearly explained in the
+ rules of .
+
+
+
+ , requires that different
+ authentication mechanisms be provided and used to
+ authenticate user identities for specific events.
+
+
+ the management of authentication mechanisms;
+
+
+ the management of the rules for authentication.
+
+
+ The final decision on authentication;
+
+
+ The result of each activated mechanism together with the
+ final decision.
+
+
+ The TSF shall provide
+
+
+ list of multiple authentication mechanisms
+
+
+
+ the PP/ST author should define the available
+ authentication mechanisms. An example of such a list
+ could be: ``none, password mechanism,
+ biometric (retinal scan), S/key mechanism''.
+
+
+ to support user authentication.
+
+
+ The TSF shall authenticate any user's claimed
+ identity according to the
+
+
+ rules describing how the multiple authentication
+ mechanisms provide authentication
+
+
+
+ the PP/ST author should specify the rules that
+ describe how the authentication mechanisms provide
+ authentication and when each is to be used. This means
+ that for each situation the set of mechanisms that
+ might be used for authenticating the user must be
+ described. An example of a list of such rules is:
+ ``if the user has special privileges a
+ password mechanism and a biometric mechanism both
+ shall be used, with success only if both succeed; for
+ all other users a password mechanism shall be
+ used.''
+
+ The PP/ST author might give the boundaries within
+ which the authorised administrator may specify
+ specific rules. An example of a rule is:
+ ``the user shall always be authenticated by
+ means of a token; the administrator might specify
+ additional authentication mechanisms that also must be
+ used.'' The PP/ST author also might choose
+ not to specify any boundaries but leave the
+ authentication mechanisms and their rules completely
+ up to the authorised administrator.
+
+ .
+
+
+
+
+
+
+ This component addresses potential needs to
+ re-authenticate users at defined points in time. These may
+ include user requests for the TSF to perform security
+ relevant actions, as well as requests from non-TSF
+ entities for re-authentication (e.g. a server application
+ requesting that the TSF re-authenticate the client it is
+ serving).
+
+
+
+ , requires the ability to specify
+ events for which the user needs to be re-authenticated.
+
+
+ if an authorised administrator could request
+ re-authentication, the management includes a
+ re-authentication request.
+
+
+ Failure of reauthentication;
+
+
+ All reauthentication attempts.
+
+
+ The TSF shall re-authenticate the user under the conditions
+
+
+ list of conditions under which re-authentication is
+ required
+
+
+
+ the PP/ST author should specify the list of conditions
+ requiring re-authentication. This list could include a
+ specified user inactivity period that has elapsed, the
+ user requesting a change in active security
+ attributes, or the user requesting the TSF to perform
+ some security critical function.
+
+ The PP/ST author might give the boundaries within
+ which the reauthentication should occur and leave the
+ specifics to the authorised administrator. An example
+ of such a rule is: ``the user shall always
+ be re-authenticated at least once a day; the
+ administrator might specify that the re-authentication
+ should happen more often but not more often than once
+ every 10 minutes.''
+
+ .
+
+
+
+
+
+
+
+
+
+ This component addresses the feedback on the
+ authentication process that will be provided to the
+ user. In some systems the feedback consists of indicating
+ how many characters have been typed but not showing the
+ characters themselves, in other systems even this
+ information might not be appropriate.
+
+ This component requires that the authentication data is
+ not provided as-is back to the user. In a workstation
+ environment, it could display a
+ ``dummy'' (e.g. star) for each
+ password character provided, and not the original
+ character.
+
+
+
+ , requires that only limited
+ feedback information is provided to the user during the
+ authentication.
+
+
+ The TSF shall provide only
+
+
+ list of feedback
+
+
+
+ the PP/ST author should specify the feedback related
+ to the authentication process that will be provided to
+ the user. An example of a feedback assignment is
+ ``the number of characters
+ typed'', another type of feedback is
+ ``the authentication mechanism that failed
+ the authentication''.
+
+
+ to the user while the authentication is in progress.
+
+
+
+
+
+
+
+ This family defines the conditions under which users shall
+ be required to identify themselves before performing any
+ other actions that are to be mediated by the TSF and which
+ require user identification.
+
+
+
+ This family defines the conditions under which users are
+ required to identify themselves before performing any other
+ actions that are to be mediated by the TSF and that require
+ user identification.
+
+
+
+
+
+ This component poses requirements for the user to be
+ identified. The PP/ST author can indicate specific actions
+ that can be performed before the identification takes
+ place.
+
+ If is used, the TSF-mediated
+ actions mentioned in should also
+ appear in this .
+
+
+
+ , allows users to perform certain
+ actions before being identified by the TSF.
+
+
+ the management of the user identities;
+
+
+ if an authorised administrator can change the actions
+ allowed before identification, the managing of the action
+ lists.
+
+
+ Unsuccessful use of the user identification mechanism,
+ including the user identity provided;
+
+
+ All use of the user identification mechanism, including the
+ user identity provided.
+
+
+ The TSF shall allow
+
+
+ list of TSF-mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the user has to identify itself. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ identified.
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ In this component users will be identified. A user is not
+ allowed by the TSF to perform any action before being
+ identified.
+
+
+
+ , requires that users identify
+ themselves before any other action will be allowed by the TSF.
+
+
+ the management of the user identities.
+
+
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ It is intended that a subject is
+ acting on behalf of the user who caused the subject to come into
+ being or to be activated to perform a certain task.
+ Therefore, when a subject is created, that subject is acting on
+ behalf of the user who initiated the creation. In cases where
+ anonymity is used, the subject is still acting on behalf of a
+ user, but the identity of that user is unknown. A special
+ category of subjects are those subjects that serve multiple
+ users (e.g. a server process). In such cases the user that
+ created this subject is assumed to be the ``owner''., requires the specification of any rules
+ governing the association between user attributes and the
+ subject attributes into which they are mapped.
+ an authorised administrator can define default subject security
+ attributes.
+
+ an authorised administrator can change subject security
+ attributes.
+
+ Unsuccessful binding of user security attributes to a subject
+ (e.g. creation of a subject).
+
+ Success and failure of binding of user security attributes to a
+ subject (e.g. success or failure to create a subject).
+
+ The TSF shall associate the following user security attributes
+ with subjects acting on the behalf of that user:
+
+ list of user security attributes
+
+ the PP/ST author should specify a list of the user security
+ attributes that are to be bound to subjects..
+
+ The TSF shall enforce the following rules on the initial
+ association of user security attributes with subjects acting on
+ the behalf of users:
+
+ rules for the initial association of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ upon initial association of attributes with subjects, or
+ ``none''..
+
+ The TSF shall enforce the following rules governing changes to the
+ user security attributes associated with subjects acting on the
+ behalf of users:
+
+ rules for the changing of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ when changes are made to the user security attributes
+ associated with subjects acting on behalf of users, or
+ ``none''..
+
+
+
+
+
+
+ This class is intended to specify the management of several
+ aspects of the TSF: security attributes, TSF data and
+ functions. The different management roles and their
+ interaction, such as separation of capability, can be
+ specified.
+
+ This class has several objectives:
+
+
+ management of TSF data, which include, for example,
+ banners;
+
+
+ management of security attributes, which include, for
+ example, the Access Control Lists, and Capability Lists;
+
+
+ management of functions of the TSF, which includes, for
+ example, the selection of functions, and rules or
+ conditions influencing the behaviour of the TSF;
+
+
+ definition of security roles.
+
+
+
+
+
+ This class specifies the management of several aspects of the
+ TSF: security attributes, TSF data and functions in the
+ TSF. The different management roles and their interaction,
+ such as separation of capability, can also be specified
+
+ In an environment where the TOE is made up of multiple
+ physically separated parts, the timing issues with respect to
+ propagation of security attributes, TSF data, and function
+ modification become very complex, especially if the
+ information is required to be replicated across the parts of
+ the TOE. This should be considered when selecting components
+ such as , or , where the behaviour might be
+ impaired. In such situations, use of components from is advisable.
+
+
+
+
+
+ This family allows authorised users control over the
+ management of functions in the TSF. Examples of functions in
+ the TSF include the audit functions and the multiple
+ authentication functions.
+
+
+
+ The TSF management functions enable authorised users to set
+ up and control the secure operation of the TOE. These
+ administrative functions typically fall into a number of
+ different categories:
+
+
+ Management functions that relate to access control,
+ accountability and authentication controls enforced by
+ the TOE. For example, definition and update of user
+ security characteristics (e.g. unique identifiers
+ associated with user names, user accounts, system entry
+ parameters) or definition and update of auditing system
+ controls (e.g. selection of audit events, management of
+ audit trails, audit trail analysis, and audit report
+ generation), definition and update of per-user policy
+ attributes (such as user clearance), definition of known
+ system access control labels, and control and management
+ of user groups.
+
+
+ Management functions that relate to controls over
+ availability. For example, definition and update of
+ availability parameters or resource quotas.
+
+
+ Management functions that relate to general installation
+ and configuration. For example, TOE configuration,
+ manual recovery, installation of TOE security fixes (if
+ any), repair and reinstallation of hardware.
+
+
+ Management functions that relate to routine control and
+ maintenance of TOE resources. For example, enabling and
+ disabling peripheral devices, mounting of removable
+ storage media, backup and recovery.
+
+
+
+ Note that these functions need to be present in a TOE based
+ on the families included in the PP or ST. It is the
+ responsibility of the PP/ST author to ensure that adequate
+ functions will be provided to manage the TOE in a secure
+ fashion.
+
+ The TSF might contain functions that can be controlled by an
+ administrator. For example, the auditing functions could be
+ switched off, the time synchronisation could be switchable,
+ and/or the authentication mechanism could be modifiable.
+
+
+
+
+
+
+
+
+
+ This component allows identified roles to manage the
+ security functions of the TSF. This might entail obtaining
+ the current status of a security function, disabling or
+ enabling the security function, or modifying the behaviour
+ of the security function. An example of modifying the
+ behaviour of the security functions is changing of
+ authentication mechanisms.
+
+
+
+ allows the authorised users (roles)
+ to manage the behaviour of functions in the TSF that use
+ rules or have specified conditions that may be manageable.
+
+
+ managing the group of roles that can interact with the
+ functions in the TSF;
+
+
+ All modifications in the behaviour of the functions in the
+ TSF.
+
+
+ The TSF shall restrict the ability to
+
+
+ determine the behaviour of
+
+
+ disable
+
+
+ enable
+
+
+ modify the behaviour of
+
+
+
+ the PP/ST author should select whether the role can
+ determine the behaviour of, disable, enable, and/or
+ modify the behaviour of the security functions.
+
+
+ the functions
+
+
+ list of functions
+
+
+
+ the PP/ST author should specify the functions that can
+ be modified by the identified roles. Examples include
+ auditing and time determination.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the functions in the TSF. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+ This family allows authorised users control over the
+ management of security attributes. This management might
+ include capabilities for viewing and modifying of security
+ attributes.
+
+
+
+ This family defines the requirements on the management of
+ security attributes.
+
+ Security attributes affect the behaviour of the TSF. Examples of
+ security attributes are the groups to which a user belongs, the
+ roles he/she might assume, the priority of a process (subject),
+ and the rights belonging to a role or a user. These security
+ attributes might need to be managed by the user, a subject, a
+ specific authorised user (a user with explicitly given rights
+ for this management) or inherit values according to a given
+ policy/set of rules.
+
+ It is noted that the right to assign rights to users is
+ itself a security attribute and/or potentially subject to
+ management by .
+ can be used to ensure that any
+ accepted combination of security attributes is within a
+ secure state. The definition of what
+ ``secure'' means is left to the TOE guidance.
+
+ In some instances subjects, objects or user accounts are
+ created. If no explicit values for the related security
+ attributes are given, default values need to be used. can be used to specify that these default
+ values can be managed.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component allows users acting in certain roles to
+ manage identified security attributes. The users are
+ assigned to a role within the component .
+
+ The default value of a parameter is the value the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter, and
+ overrides the default value.
+
+
+
+ allows authorised users (roles) to
+ manage the specified security attributes.
+
+
+ managing the group of roles that can interact with the
+ security attributes;
+
+ management of rules by which security attributes inherit
+ specified values.
+
+
+ All modifications of the values of security attributes.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s), information flow control SFP(s)
+
+ the PP/ST author should list the access control SFP(s) or
+ the information flow control SFP(s) for which the security
+ attributes are applicable.
+ to restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example of such an operation could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified security
+ attributes. The PP/ST author can specify that the role
+ can modify the default value (change_default), query,
+ modify the security attribute, delete the security
+ attributes entirely or define their own operation.
+
+
+ the security attributes
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that can be operated on by the identified
+ roles. It is possible for the PP/ST author to specify
+ that the default value such as default access-rights
+ can be managed. Examples of these security attributes
+ are user-clearance, priority of service level, access
+ control list, default access rights.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the security attributes. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component contains requirements on the values that
+ can be assigned to security attributes. The assigned
+ values should be such that the TOE will remain in a secure
+ state.
+
+ The definition of what ``secure'' means is
+ not answered in this component but is left to the
+ development of the TOE and the resulting information in the
+ guidance. An example could be that if a user account is
+ created, it should have a non-trivial password.
+
+
+
+ ensures that values assigned to
+ security attributes are valid with respect to the secure
+ state.
+
+ management of rules by which security attributes inherit
+ specified values.
+
+
+ All offered and rejected values for a security attribute;
+
+
+ All offered and accepted secure values for a security
+ attribute.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for
+ list of security attributes
+
+ the PP/ST author should specify the list of security
+ attributes that require only secure values to be provided..
+
+
+
+
+
+
+
+
+
+
+ This component requires that the TSF provide default
+ values for relevant object security attributes, which can
+ be overridden by an initial value. It may still be
+ possible for a new object to have different security
+ attributes at creation, if a mechanism exists to specify
+ the permissions at time of creation.
+
+
+
+ ensures that the default values of
+ security attributes are appropriately either permissive or
+ restrictive in nature.
+
+
+ managing the group of roles that can specify initial values;
+
+
+ managing the permissive or restrictive setting of default values
+ for a given access control SFP;
+
+ management of rules by which security attributes inherit specified values.
+
+
+ Modifications of the default setting of permissive or
+ restrictive rules.
+
+
+ All modifications of the initial values of security
+ attributes.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP, information flow control SFP
+
+
+
+ the PP/ST author should list the access control SFP or
+ the information flow control SFP for which the
+ security attributes are applicable.
+
+
+ to provide
+
+
+ restrictive
+
+
+ permissive
+
+
+ other property
+
+ if the PP/ST author selects another property, the PP/ST
+ author should specify the desired characteristics of the
+ default values.
+
+
+ the PP/ST author should select whether the default property
+ of the access control attribute will be restrictive,
+ permissive, or another property. Only one of these options
+ may be chosen.
+
+
+ default values for security attributes that are used to
+ enforce the SFP.
+
+
+ The TSF shall allow the
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the values of the security
+ attributes. The possible roles are specified in .
+
+
+ to specify alternative initial values to override the
+ default values when an object or information is created.
+
+
+ This component requires specification of the set of rules
+ through which the security attribute inherits values and the
+ conditions to be met for these rules to be applied. allows the rules/policies
+ to be specified that will dictate the value to be inherited
+ by a security attribute.
+ specification of the role permitted to establish or modify
+ security attributes.
+
+ Modifications of security attributes, possibly with the old
+ and/or values of security attributes that were modified.
+
+ The TSF shall use the following rules to set the value of security attributes:
+
+ rules for setting the values of security attributes
+
+ the PP/ST author specifies the rules governing the value
+ that will be inherited by the specified security
+ attribute, including the conditions that are to be met
+ for the rules to be applied. For example, if a new file
+ or directory is created (in a multilevel filesystem),
+ its label is the label at which the user is logged in at
+ the time it is created.
+
+
+
+
+
+ This family allows authorised users (roles) control over the
+ management of TSF data. Examples of TSF data include audit
+ information, clock and other TSF
+ configuration parameters.
+
+
+
+ This component imposes requirements on the management of TSF
+ data. Examples of TSF data are the current time and the
+ audit trail. So, for example, this family allows the
+ specification of whom can read, delete or create the audit
+ trail.
+
+
+
+
+
+
+
+
+ This component allows users with a certain role to manage
+ values of TSF data. The users are assigned to a role
+ within the component .
+
+ The default value of a parameter is the values the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter and
+ overrides the default value.
+
+
+
+ allows authorised users to manage
+ TSF data.
+
+
+ managing the group of roles that can interact with the TSF
+ data.
+
+
+ All modifications to the values of TSF data.
+
+
+ The TSF shall restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+ clear
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified TSF data. The PP/ST
+ author can specify that the role can modify the
+ default value (change_default), clear, query or modify
+ the TSF data, or delete the TSF data entirely. If so
+ desired the PP/ST author could specify any type of
+ operation. To clarify ``clear TSF data'' means that
+ the content of the TSF data is removed, but that the
+ entity that stores the TSF data remains in the
+ TOE.
+
+
+ the
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ be operated on by the identified roles. It is possible
+ for the PP/ST author to specify that the default value
+ can be managed.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the TSF data. The possible roles
+ are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies limits on TSF data, and actions
+ to be taken if these limits are exceeded. This component,
+ for example, will allow limits on the size of the audit
+ trail to be defined, and specification of the actions to
+ be taken when these limits are exceeded.
+
+
+
+ specifies the action to be taken if
+ limits on TSF data are reached or exceeded.
+
+
+ managing the group of roles that can interact with the
+ limits on the TSF data.
+
+
+ All modifications to the limits on TSF data;
+
+
+ All modifications in the actions to be taken in case of
+ violation of the limits.
+
+
+ The TSF shall restrict the specification of the limits for
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ have limits, and the value of those limits. An example
+ of such TSF data is the number of users logged-in.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the limits on the TSF data and the
+ actions to be taken. The possible roles are specified
+ in .
+
+ .
+
+
+ The TSF shall take the following actions, if the TSF data
+ are at, or exceed, the indicated limits:
+
+
+ actions to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken if the specified limit on the specified TSF data
+ is exceeded. An example of such TSF action is that the
+ authorised user is informed and an audit record is
+ generated.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component covers requirements on the values that can
+ be assigned to TSF data. The assigned values should be
+ such that the TOE will remain in a secure state.
+
+ The definition of what ``secure'' means is not
+ answered in this component but is left to the development of
+ the TOE and the
+ resulting information in the guidance.
+
+
+
+ ensures that values assigned to TSF
+ data are valid with respect to the secure state.
+
+
+ All rejected values of TSF data.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for
+ list of TSF data
+
+ the PP/ST author should specify what TSF data require only
+ secure values to be accepted..
+
+
+
+
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+
+
+
+
+
+ This component specifies requirements on the revocation of
+ rights. It requires the specification of the revocation
+ rules. Examples are:
+
+
+ Revocation will take place on the next login of the
+ user;
+
+
+ Revocation will take place on the next attempt to open
+ the file;
+
+
+ Revocation will take place within a fixed time. This
+ might mean that all open connections are re-evaluated
+ every x minutes.
+
+
+
+
+
+ provides for revocation of security
+ attributes to be enforced at some point in time.
+
+
+ managing the group of roles that can invoke revocation of
+ security attributes;
+
+
+ managing the lists of users, subjects, objects and other
+ resources for which revocation is possible;
+
+
+ managing the revocation rules.
+
+
+ Unsuccessful revocation of security attributes;
+
+
+ All attempts to revoke security attributes.
+
+
+ The TSF shall restrict the ability to revoke
+
+ list of security attributes
+
+ the PP/ST author should specify which security attributes
+ are to be revoked when a change is made to the associated
+ object/subject/user/other resource.
+ associated with the
+
+ users
+
+ subjects
+
+ objects
+ other additional resources
+ the PP/ST author should, if additional resources is
+ selected, specify whether the ability to revoke their
+ security attributes shall be provided by the
+ TSF.
+ the PP/ST author should specify whether the ability to
+ revoke security attributes from users, subjects, objects,
+ or any additional resources shall be provided by the
+ TSF.
+ under the control of the TSF to
+
+ the authorised identified roles
+
+ the PP/ST author should specify the roles that are allowed
+ to modify the functions in the TSF. The possible roles are
+ specified in ..
+
+
+ The TSF shall enforce the rules
+
+
+ specification of revocation rules
+
+
+
+ the PP/ST author should specify the revocation
+ rules. Examples of these rules could include:
+ ``prior to the next operation on the
+ associated resource'', or ``for
+ all new subject creations''.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes.
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes. This family can be
+ applied to specify expiration requirements for access
+ control attributes, identification and authentication
+ attributes, certificates (key certificates such as ANSI X509
+ for example), audit attributes, etc.
+
+
+
+
+
+
+
+
+
+ provides the capability for an
+ authorised user to specify an expiration time on specified
+ security attributes.
+
+
+ managing the list of security attributes for which
+ expiration is to be supported;
+
+
+ the actions to be taken if the expiration time has passed.
+
+
+ Specification of the expiration time for an attribute;
+
+
+ Action taken due to attribute expiration.
+
+
+ The TSF shall restrict the capability to specify an
+ expiration time for
+
+
+ list of security attributes for which expiration is to
+ be supported
+
+
+
+ the PP/ST author should provide the list of security
+ attributes for which expiration is to be supported. An
+ example of such an attribute might be a
+ user's security clearance.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the security attributes in the
+ TSF. The possible roles are specified in .
+
+ .
+
+
+ For each of these security attributes, the TSF shall be able
+ to
+
+
+ list of actions to be taken for each security attribute
+
+
+
+ the PP/ST author should provide a list of actions to
+ be taken for each security attribute when it
+ expires. An example might be that the
+ user's security clearance, when it expires,
+ is set to the lowest allowable clearance on the
+ TOE. If immediate revocation is desired by the PP/ST,
+ the action ``immediate
+ revocation'' should be specified.
+
+
+ after the expiration time for the indicated security
+ attribute has passed.
+
+
+
+ This family allows the specification of the management
+ functions to be provided by the TOE. Management functions
+ provide TSFI that allow administrators to define the
+ parameters that control the operation of security-related
+ aspects of the TOE, such as data protection attributes, TOE
+ protection attributes, audit attributes, and identification
+ and authentication attributes. Management functions also
+ include those functions performed by an operator to ensure
+ continued operation of the TOE, such as backup and
+ recovery. This family works in conjunction with the other
+ components in the class: the component in
+ this family calls out the management functions, and other
+ families in restrict the ability to use
+ these management functions.
+ This family allows the specification of the management
+ functions to be provided by the TOE. Each security
+ management function that is listed in fulfilling the
+ assignment is either security attribute management, TSF data
+ management, or security function management.
+ This component specifies the management functions to be
+ provided.
+ PP/ST authors should consult the ``Management'' sections
+ for components included in their PP/ST to provide a basis
+ for the management functions to be listed via this
+ component. requires that the TSF provide
+ specific management functions.
+ Use of the management functions.
+
+ The TSF shall be capable of performing the following
+ management functions:
+
+ list of management functions to be provided by
+ the TSF
+
+ the PP/ST author should specify the management
+ functions to be provided by the TSF, either security
+ attribute management, TSF data management, or security
+ function management..
+
+
+
+
+
+ This family is intended to control the assignment of
+ different roles to users. The capabilities of these roles
+ with respect to security management are described in the
+ other families in this class.
+
+
+
+ This family reduces the likelihood of damage resulting from
+ users abusing their authority by taking actions outside
+ their assigned functional responsibilities. It also
+ addresses the threat that inadequate mechanisms have been
+ provided to securely administer the TSF.
+
+ This family requires that information be maintained to
+ identify whether a user is authorised to use a particular
+ security-relevant administrative function.
+
+ Some management actions can be performed by users, others
+ only by designated people within the organisation. This
+ family allows the definition of different roles, such as
+ owner, auditor, administrator, daily-management.
+
+ The roles as used in this family are security related
+ roles. Each role can encompass an extensive set of
+ capabilities (e.g. root in UNIX), or can be a single right
+ (e.g. right to read a single object such as the
+ helpfile). This family defines the roles. The capabilities
+ of the role are defined in , and .
+
+ Some type of roles might be mutually exclusive. For example
+ the daily-management might be able to define and activate
+ users, but might not be able to remove users (which is
+ reserved for the administrator (role)). This class will
+ allow policies such as two-person control to be specified.
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise. Often the system distinguishes between
+ the owner of an entity, an administrator and other users.
+
+
+
+ specifies the roles with respect to
+ security that the TSF recognises.
+
+
+ managing the group of users that are part of a role.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor and administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise, and conditions on how those roles could
+ be managed. Often the system distinguishes between the
+ owner of an entity, an administrator and other users.
+
+ The conditions on those roles specify the
+ interrelationship between the different roles, as well as
+ restrictions on when the role can be assumed by a user.
+
+
+
+ specifies that in addition to the
+ specification of the roles, there are rules that control
+ the relationship between the roles.
+
+
+ managing the group of users that are part of a role;
+
+
+ managing the conditions that the roles must satisfy.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ unsuccessful attempts to use a role due to the given
+ conditions on the roles;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles:
+
+
+ authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor, administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+ The TSF shall ensure that the conditions
+
+
+ conditions for the different roles
+
+
+
+ the PP/ST author should specify the conditions that
+ govern role assignment. Examples of these conditions
+ are: ``an account cannot have both the
+ auditor and administrator role'' or
+ ``a user with the assistant role must also
+ have the owner role''.
+
+
+ are satisfied.
+
+
+
+
+
+
+
+
+
+ This component specifies that an explicit request must be
+ given to assume the specific role.
+
+
+
+ , requires that an explicit request
+ is given to the TSF to assume a role.
+
+
+ explicit request to assume a role.
+
+
+ The TSF shall require an explicit request to assume the
+ following roles:
+
+
+ the roles
+
+
+
+ the PP/ST author should specify the roles that require
+ an explicit request to be assumed. Examples are:
+ auditor and administrator.
+
+ .
+
+
+
+
+
+
+
+ This class contains privacy requirements. These requirements
+ provide a user protection against discovery and misuse of
+ identity by other users.
+
+
+
+ This class describes the requirements that could be levied to
+ satisfy the users' privacy needs, while still allowing
+ the system flexibility as far as possible to maintain
+ sufficient control over the operation of the system.
+
+ In the components of this class there is flexibility as to
+ whether or not authorised users are covered by the required
+ security functionality. For example, a PP/ST author might
+ consider it appropriate not to require protection of the privacy
+ of users against a suitably authorised user.
+
+ This class, together with other classes (such as those
+ concerned with audit, access control, trusted path, and
+ non-repudiation) provides the flexibility to specify the
+ desired privacy behaviour. On the other hand, the requirements
+ in this class might impose limitations on the use of the
+ components of other classes, such as or . For example, if
+ authorised users are not allowed to see the user identity
+ (e.g. Anonymity or Pseudonymity), it will obviously not be
+ possible to hold individual users accountable for any security
+ relevant actions they perform that are covered by the privacy
+ requirements. However, it may still be possible to include
+ audit requirements in a PP/ST, where the fact that a
+ particular security relevant event has occurred is more
+ important than knowing who was responsible for it.
+
+ Additional information is provided in the application notes
+ for class , where it is explained that the
+ definition of ``identity'' in the context of
+ auditing can also be an alias or other information that could
+ identify a user.
+
+ This class describes four families: Anonymity, Pseudonymity,
+ Unlinkability and Unobservability. Anonymity, Pseudonymity and
+ Unlinkability have a complex interrelationship. When choosing
+ a family, the choice should depend on the threats
+ identified. For some types of privacy threats, pseudonymity
+ will be more appropriate than anonymity (e.g. if there is a
+ requirement for auditing). In addition, some types of privacy
+ threats are best countered by a combination of components from
+ several families.
+
+ All families assume that a user does not explicitly perform an
+ action that discloses the user's own identity. For
+ example, the TSF is not expected to screen the user name in
+ electronic messages or databases.
+
+ All families in this class have components that can be scoped
+ through operations. These operations allow the PP/ST author to
+ state the cooperating users/subjects to which the TSF must be
+ resistant. An example of an instantiation of anonymity could
+ be: `` The TSF shall ensure that the users and/or
+ subjects are unable to determine the user identity bound to
+ the teleconsulting application''.
+
+ It is noted that the TSF should not only provide this
+ protection against individual users, but also against users
+ cooperating to obtain the information.
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing the user's identity. The
+ requirements for Anonymity provide protection of the user
+ identity. Anonymity is not intended to protect the subject
+ identity.
+
+
+
+ Anonymity ensures that a subject may use a resource or
+ service without disclosing its user identity.
+
+ The intention of this family is to specify that a user or
+ subject might take action without releasing its user
+ identity to others such as users, subjects, or objects. The
+ family provides the PP/ST author with a means to identify
+ the set of users that cannot see the identity of someone
+ performing certain actions.
+
+ Therefore if a subject, using anonymity, performs an action,
+ another subject will not be able to determine either the
+ identity or even a reference to the identity of the user
+ employing the subject. The focus of the anonymity is on the
+ protection of the users identity, not on the protection of
+ the subject identity; hence, the identity of the subject is
+ not protected from disclosure.
+
+ Although the identity of the subject is not released to
+ other subjects or users, the TSF is not explicitly
+ prohibited from obtaining the users identity. In case the
+ TSF is not allowed to know the identity of the user, could be invoked. In that case
+ the TSF should not request the user information.
+
+ The interpretation of ``determine'' should be
+ taken in the broadest sense of the word.
+
+ The component levelling distinguishes between the users and
+ an authorised user. An authorised user is often excluded
+ from the component, and therefore allowed to retrieve a
+ user's identity. However, there is no specific
+ requirement that an authorised user must be able to have the
+ capability to determine the user's identity. For
+ ultimate privacy the components would be used to say that no
+ user or authorised user can see the identity of anyone
+ performing any action.
+
+ Although some systems will provide anonymity for all
+ services that are provided, other systems provide anonymity
+ for certain subjects/operations. To provide this
+ flexibility, an operation is included where the scope of the
+ requirement is defined. If the PP/ST author wants to address
+ all subjects/operations, the words ``all subjects and
+ all operations'' could be provided.
+
+ Possible applications include the ability to make enquiries
+ of a confidential nature to public databases, respond to
+ electronic polls, or make anonymous payments or donations.
+
+ Examples of potential hostile users or subjects are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts (e.g. Trojan Horses) into
+ systems. All of these users can investigate usage patterns
+ (e.g. which users used which services) and misuse this
+ information.
+
+
+
+
+
+ This component ensures that the identity of a user is
+ protected from disclosure. There may be instances,
+ however, that a given authorised user can determine who
+ performed certain actions. This component gives the
+ flexibility to capture either a limited or total privacy
+ policy.
+
+
+
+ , requires that other users or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation.
+
+
+ The invocation of the anonymity mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+
+
+
+
+
+ This component is used to ensure that the TSF is not
+ allowed to know the identity of the user.
+
+
+
+ enhances the
+ requirements of by
+ ensuring that the TSF does not ask for the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the anonymity requirement, for
+ example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which the real user name of the subject should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to the real user name.
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing its user identity, but can still
+ be accountable for that use.
+
+
+
+ Pseudonymity ensures that a user may use a resource or
+ service without disclosing its identity, but can still be
+ accountable for that use. The user can be accountable by
+ directly being related to a reference (alias) held by the
+ TSF, or by providing an alias that will be used for
+ processing purposes, such as an account number.
+
+ In several respects, pseudonymity resembles anonymity. Both
+ pseudonymity and anonymity protect the identity of the user,
+ but in pseudonymity a reference to the user's
+ identity is maintained for accountability or other purposes.
+
+ The component does not
+ specify the requirements on the reference to the user's
+ identity. For the purpose of specifying requirements on this
+ reference two sets of requirements are presented: and .
+
+ A way to use the reference is by being able to obtain the
+ original user identity. For example, in a digital cash
+ environment it would be advantageous to be able to trace the
+ user's identity when a check has been issued multiple times
+ (i.e. fraud). In general, the user's identity needs to be
+ retrieved under specific conditions. The PP/ST author might
+ want to incorporate to
+ describe those services.
+
+ Another usage of the reference is as an alias for a
+ user. For example, a user who does not wish to be
+ identified, can provide an account to which the resource
+ utilisation should be charged. In such cases, the reference
+ to the user identity is an alias for the user, where other
+ users or subjects can use the alias for performing their
+ functions without ever obtaining the user's
+ identity (for example, statistical operations on use of the
+ system). In this case, the PP/ST author might wish to
+ incorporate to specify the rules to
+ which the reference must conform.
+
+ Using these constructs above, digital money can be created
+ using specifying that the user
+ identity will be protected and, if so specified in the
+ condition, that there be a requirement to trace the user
+ identity if the digital money is spent twice. When the user
+ is honest, the user identity is protected; if the user tries
+ to cheat, the user identity can be traced.
+
+ A different kind of system could be a digital credit card,
+ where the user will provide a pseudonym that indicates an
+ account from which the cash can be subtracted. In such
+ cases, for example, could be
+ used. This component would specify that the user identity
+ will be protected and, furthermore, that the same user will
+ only get assigned values for which he/she has provided money
+ (if so specified in the conditions).
+
+ It should be realised that the more stringent components
+ potentially cannot be combined with other requirements, such
+ as identification and authentication or audit. The
+ interpretation of ``determine the identity''
+ should be taken in the broadest sense of the word. The
+ information is not provided by the TSF during the operation,
+ nor can the entity determine the subject or the owner of the
+ subject that invoked the operation, nor will the TSF record
+ information, available to the users or subjects, which might
+ release the user identity in the future.
+
+ The intent is that the TSF not reveal any information that
+ would compromise the identity of the user, e.g. the identity
+ of subjects acting on the user's behalf. The
+ information that is considered to be sensitive depends on
+ the effort an attacker is capable of spending.
+
+ Possible applications include the ability to charge a caller
+ for premium rate telephone services without disclosing his
+ or her identity, or to be charged for the anonymous use of
+ an electronic payment system.
+
+ Examples of potential hostile users are providers, system
+ operators, communication partners and users, who smuggle
+ malicious parts (e.g. Trojan Horses) into systems. All of
+ these attackers can investigate which users used which
+ services and misuse this information. Additionally to
+ Anonymity services, Pseudonymity Services contains methods
+ for authorisation without identification, especially for
+ anonymous payment (``Digital Cash''). This
+ helps providers to obtain their payment in a secure way
+ while maintaining customer anonymity.
+
+
+
+
+
+ This component provides the user protection against
+ disclosure of identity to other users. The user will
+ remain accountable for its actions.
+
+
+
+ requires that a set of users and/or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation, but that this user is
+ still accountable for its actions.
+
+
+ The subject/user that requested resolution of the user
+ identity should be audited.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that under
+ specified conditions the user identity related to a
+ provided reference can be determined.
+
+ In the TSF shall provide an alias
+ instead of the user identity. When the specified
+ conditions are satisfied, the user identity to which the
+ alias belong can be determined. An example of such a
+ condition in an electronic cash environment is: ``
+ The TSF shall provide the notary a capability to determine
+ the user identity based on the provided alias only under
+ the conditions that a check has been issued
+ twice.''.
+
+
+
+ , requires the TSF to provide a
+ capability to determine the original user identity based
+ on a provided alias.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF, is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide
+
+
+ an authorised user
+
+
+
+
+ list of trusted subjects
+
+
+
+ the PP/ST author should identify the list of trusted
+ subjects that can obtain the real user name under a
+ specified condition, for example, a notary or
+ special authorised user.
+
+
+
+
+
+ the PP/ST author should select whether the authorised
+ user and/or trusted subjects can determine the real
+ user name.
+
+
+ a capability to determine the user identity based on the
+ provided alias only under the following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions under which the trusted subjects and
+ authorised user can determine the real user name based
+ on the provided reference. These conditions can be
+ conditions such as time of day, or they can be
+ administrative such as on a court order.
+
+ .
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that the provided
+ reference meets certain construction rules, and thereby
+ can be used in a secure way by potentially insecure
+ subjects.
+
+ If a user wants to use disk resources without disclosing
+ its identity, pseudonymity can be used. However, every
+ time the user accesses the system, the same alias must be
+ used. Such conditions can be specified in this component.
+
+
+
+ , requires the TSF to
+ follow certain construction rules for the alias to the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes which might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide an alias to the real user name which
+ shall be identical to an alias provided previously under the
+ following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions that indicate when the used reference for
+ the real user name shall be identical and when it
+ shall be different, for example, ``when the
+ user logs on to the same host'' it will use a
+ unique alias.
+
+
+ otherwise the alias provided shall be unrelated to
+ previously provided aliases.
+
+
+
+
+
+
+ This family ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together.
+
+
+
+ Unlinkability ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together. Unlinkability differs from pseudonymity
+ that, although in pseudonymity the user is also not known,
+ relations between different actions can be provided.
+
+ The requirements for unlinkability are intended to protect
+ the user identity against the use of profiling of the
+ operations. For example, when a telephone smart card is
+ employed with a unique number, the telephone company can
+ determine the behaviour of the user of this telephone
+ card. When a telephone profile of the users is known, the
+ card can be linked to a specific user. Hiding the
+ relationship between different invocations of a service or
+ access of a resource will prevent this kind of information
+ gathering.
+
+ As a result, a requirement for unlinkability could imply
+ that the subject and user identity of an operation must be
+ protected. Otherwise this information might be used to link
+ operations together.
+
+ Unlinkability requires that different operations cannot be
+ related. This relationship can take several forms. For
+ example, the user associated with the operation, or the
+ terminal which initiated the action, or the time the action
+ was executed. The PP/ST author can specify what kind of
+ relationships are present that must be countered.
+
+ Possible applications include the ability to make multiple
+ use of a pseudonym without creating a usage pattern that
+ might disclose the user's identity.
+
+ Examples for potential hostile subjects and users are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts, (e.g. Trojan Horses)
+ into systems, they do not operate but want to get
+ information about. All of these attackers can investigate
+ (e.g. which users used which services) and misuse this
+ information. Unlinkability protects users from linkages,
+ which could be drawn between several actions of a
+ customer. An example is a series of phone calls made by an
+ anonymous customer to different partners, where the
+ combination of the partner's identities might disclose the
+ identity of the customer.
+
+
+
+
+
+ This component ensures that users cannot link different
+ operations in the system and thereby obtain information.
+
+
+
+ , requires that users and/or subjects
+ are unable to determine whether the same user caused
+ certain specific operations.
+
+
+ the management of the unlinkability function.
+
+
+ The invocation of the unlinkability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine whether
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations which should be subjected to the
+ unlinkability requirement, for example,
+ ``sending email''.
+
+
+
+
+ were caused by the same user
+
+
+ are related as follows
+
+
+ list of relations
+
+
+
+ the PP/ST author should identify the list of
+ relations which should be protected against, for
+ example, ``originate from the same
+ terminal''.
+
+
+
+
+
+ the PP/ST author should select the relationships that
+ should be obscured. The selection allows either the
+ user identity or an assignment of relations to be
+ specified.
+
+ .
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+
+
+ Unobservability ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+ Unobservability approaches the user identity from a
+ different direction than the previous families Anonymity,
+ Pseudonymity and Unlinkability. In this case, the intent is
+ to hide the use of a resource or service, rather than to
+ hide the user's identity.
+
+ A number of techniques can be applied to implement
+ unobservability. Examples of techniques to provide
+ unobservability are:
+
+
+ Allocation of information impacting unobservability:
+ Unobservability relevant information (e.g. information
+ that describes that an operation occurred) can be
+ allocated in several locations within the TOE. The
+ information might be allocated to a single randomly
+ chosen part of the TOE such that an attacker does not
+ know which part of the TOE should be attacked. An
+ alternative system might distribute the information such
+ that no single part of the TOE has sufficient
+ information that, if circumvented, the privacy of the
+ user would be compromised. This technique is explicitly
+ addressed in .
+
+
+ Broadcast: When information is broadcast (e.g. ethernet,
+ radio), users cannot determine who actually received and
+ used that information. This technique is especially
+ useful when information should reach receivers which
+ have to fear a stigma for being interested in that
+ information (e.g. sensitive medical information).
+
+
+ Cryptographic protection and message padding: People
+ observing a message stream might obtain information from
+ the fact that a message is transferred and from
+ attributes on that message. By traffic padding, message
+ padding and encrypting the message stream, the
+ transmission of a message and its attributes can be
+ protected.
+
+
+
+ Sometimes, users should not see the use of a resource, but an
+ authorised user must be allowed to see the use of the resource
+ in order to perform his duties. In such cases, the could be used, which provides the
+ capability for one or more authorised users to see the
+ usage.
+
+ This family makes use of the concept ``parts of the
+ TOE''. This is considered any part of the TOE that is either
+ physically or logically separated from other parts of the
+ TOE.
+
+ Unobservability of communications may be an important factor
+ in many areas, such as the enforcement of constitutional
+ rights, organisational policies, or in defence related
+ applications.
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by unauthorised users.
+
+
+
+ , requires that users and/or
+ subjects cannot determine whether an operation is being
+ performed.
+
+
+ the management of the behaviour of the unobservability
+ function.
+
+
+ The invocation of the unobservability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users and/or
+ subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual user
+ or subject, but must protect with respect to cooperating
+ users and/or subjects. A set of users, for example,
+ could be a group of users which can operate under the
+ same role or can all use the same process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by specified users or
+ subjects. Furthermore this component specifies that
+ information related to the privacy of the user is
+ distributed within the TOE such that attackers might not
+ know which part of the TOE to target, or they need to
+ attack multiple parts of the TOE.
+
+ An example of the use of this component is the use of a
+ randomly allocated node to provide a function. In such a
+ case the component might require that the privacy related
+ information shall only be available to one identified part
+ of the TOE, and will not be communicated outside this part
+ of the TOE.
+
+ A more complex example can be found in some
+ ``voting algorithms''. Several parts of the
+ TOE will be involved in the service, but no individual
+ part of the TOE will be able to violate the policy. So a
+ person may cast a vote (or not) without the TOE being able
+ to determine whether a vote has been cast and what the
+ vote happened to be (unless the vote was unanimous).
+
+
+
+
+ , requires that the TSF
+ provide specific mechanisms to avoid the concentration of
+ privacy related information within the TOE. Such
+ concentrations might impact unobservability if a security
+ compromise occurs.
+
+
+
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+ The TSF shall allocate the
+
+
+ unobservability related information
+
+
+
+ the PP/ST author should identify which privacy related
+ information should be distributed in a controlled
+ manner. Examples of this information could be: IP
+ address of subject, IP address of object, time, used
+ encryption keys.
+
+
+ among different parts of the TOE such that the following
+ conditions hold during the lifetime of the information:
+
+
+ list of conditions
+
+
+
+ the PP/ST author should specify the conditions to
+ which the dissemination of the information should
+ adhere. These conditions should be maintained
+ throughout the lifetime of the privacy related
+ information of each instance. Examples of these
+ conditions could be: ``the information shall
+ only be present at a single separated part of the TOE
+ and shall not be communicated outside this part of the
+ TOE.'', ``the information shall only
+ reside in a single separated part of the TOE, but
+ shall be moved to another part of the TOE
+ periodically'', ``the information shall
+ be distributed between the different parts of the TOE
+ such that compromise of any 5 separated parts of the
+ TOE will not compromise the security policy''.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component is used to require that the TSF does not
+ try to obtain information that might compromise
+ unobservability when provided specific services. Therefore
+ the TSF will not solicit (i.e. try to obtain from other
+ entities) any information that might be used to compromise
+ unobservability.
+
+
+
+ , requires that the TSF
+ does not try to obtain privacy related information that
+ might be used to compromise unobservability.
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the unobservability requirement,
+ for example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which privacy related information should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to
+
+
+ privacy related information
+
+
+
+ the PP/ST author should specify the privacy related
+ information that will be protected from the specified
+ subjects. Examples include the identity of the subject
+ that used a service and the quantity of a service that
+ has been used such as memory resource
+ utilisation.
+
+ .
+
+
+
+
+
+
+ This component is used to require that there will be one
+ or more authorised users with the rights to view the
+ resource utilisation. Without this component, this review
+ is allowed, but not mandated.
+
+
+
+ , requires the TSF to
+ provide one or more authorised users with a capability to
+ observe the usage of resources and/or services.
+
+
+ the list of authorised users that are capable of determining
+ the occurrence of operations.
+
+
+ The observation of the use of a resource or service by a
+ user or subject.
+
+
+ The TSF shall provide
+
+
+ set of authorised users
+
+
+
+ the PP/ST author should specify the set of authorised
+ users for which the TSF must provide the capability to
+ observe the resource utilisation. A set of authorised
+ users, for example, could be a group of authorised users
+ which can operate under the same role or can all use the
+ same process(es).
+
+
+ with the capability to observe the usage of
+
+
+ list of resources and/or services
+
+
+
+ the PP/ST author should specify the set of resources
+ and/or services that the authorised user must be able
+ to observe.
+
+ .
+
+
+
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the integrity of TSF data. In some
+ sense, families in this class may appear to duplicate
+ components in the class; they may
+ even be implemented using the same mechanisms. However, focuses on user data protection, while
+ focuses on TSF data
+ protection. In fact, components from the class are necessary to provide requirements that
+ the SFPs in the TOE cannot be tampered with or
+ bypassed.
+
+ From the point of view of this class, regarding to the
+ TSF there are three significant elements:
+
+ The TSF's implementation, which executes and implements the
+ mechanisms that enforce the SFRs.
+
+ The TSF's data, which are the administrative databases that guide the
+ enforcement of the SFRs.
+
+ The external entities that the TSF may interact with in order to
+ enforce the SFRs.
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the
+ integrity of TSF data. In some sense, families in this class may
+ appear to duplicate components in the
+ class; they may even be implemented using the
+ same mechanisms. However, focuses on user
+ data protection, while focuses on TSF data
+ protection. In fact, components from the
+ class are necessary to provide requirements that the SFPs in
+ the TOE cannot be tampered with or bypassed.
+
+ From the point of view of this class, regarding to the
+ TSF there are three significant elements:
+
+ The TSF's implementation, which executes and implements the
+ mechanisms that enforce the SFRs.
+
+ The TSF's data, which are the administrative databases that guide the
+ enforcement of the SFRs.
+
+ The external entities that the TSF may interact with in order to
+ enforce the SFRs.
+
+
+ All of the families in the class can be
+ related to these areas, and fall into the following groupings:
+ , which provides an authorised user
+ with the ability to detect external attacks on the parts
+ of the TOE that comprise the TSF.
+ and ,
+ which provide an authorised user with the ability to verify the correct
+ operation of the external entities interacting with the TSF to enforce
+ the SFRs, and the integrity of the TSF data and TSF itself.
+ , , and , which address the behaviour of the TSF
+ when failure occurs and immediately after.
+ , , ,
+ which address the protection and availability of TSF data between the TSF and another trusted IT product.
+ , which addresses protection of TSF
+ data when it is transmitted between physically-separated
+ parts of the TOE.
+ , which addresses the replay of
+ various types of information and/or operations.
+ , which addresses the synchronisation
+ of states, based upon TSF data, between different parts of
+ a distributed TSF.
+ , which addresses reliable timing.
+ , which addresses the consistency of
+ TSF data shared between the TSF and another trusted IT product.
+
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TOE will always enforce
+ its SFRs in the event of identified categories of
+ failures in the TSF.
+
+
+
+ The requirements of this family ensure that the TOE will
+ always enforce its SFRs in the event of certain
+ types of failures in the TSF.
+
+
+
+
+
+ The term ``secure state'' refers to a state in which the
+ TSF data are consistent and the TSF continues correct
+ enforcement of the SFRs.
+
+ Although it is desirable to audit situations in which
+ failure with preservation of secure state occurs, it is
+ not possible in all situations. The PP/ST author should
+ specify those situations in which audit is desired and
+ feasible.
+
+ Failures in the TSF may include
+ ``hard'' failures, which indicate an
+ equipment malfunction and which may require maintenance,
+ service or repair of the TSF. Failures in the TSF may also
+ include recoverable ``soft'' failures,
+ which may only require initialisation or resetting of the
+ TSF.
+
+
+
+ This family consists of only one component, , which requires that the TSF preserve a
+ secure state in the face of the identified failures.
+
+
+ Failure of the TSF.
+
+
+ The TSF shall preserve a secure state when the following
+ types of failures occur:
+
+
+ list of types of failures in the TSF
+
+
+
+ the PP/ST author should list the types of failures in
+ the TSF for which the TSF should ``fail
+ secure,'' that is, should preserve a secure
+ state and continue to correctly enforce the SFRs.
+
+ .
+
+
+
+
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and another
+ trusted IT product. This data could, for example, be TSF
+ critical data such as passwords, keys, audit data, or TSF
+ executable code.
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and another
+ trusted IT product. This data could be TSF critical data
+ such as passwords, keys, audit data, or TSF executable code.
+
+ This family is used in a distributed context where the TSF
+ is providing TSF data to another trusted IT product. The
+ TSF can only take the measures at its site and cannot be
+ held responsible for the TSF at the other trusted IT
+ product.
+
+ If there are different availability metrics for different
+ types of TSF data, then this component should be iterated
+ for each unique pairing of metrics and types of TSF data.
+
+
+
+
+
+ This family consists of only one component, .
+ This component requires that the TSF ensure, to an identified degree of probability, the
+ availability of TSF data provided to another trusted IT product.
+
+
+ management of the list of types of TSF data that must be
+ available to another trusted IT product.
+
+
+ the absence of TSF data when required by a TOE.
+
+
+ The TSF shall ensure the availability of
+
+ list of types of TSF data
+
+ the PP/ST author should specify the types of TSF data
+ that are subject to the availability metric.
+ provided to another trusted IT product within
+
+ a defined availability metric
+
+ the PP/ST should specify the availability metric for
+ the applicable TSF data.
+ given the following conditions
+
+ conditions to ensure availability
+
+ the PP/ST author should specify the conditions under
+ which availability must be ensured. For example:
+ there must be a connection between the TOE and
+ another trusted IT product..
+
+
+
+
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data during transmission
+ between the TSF and another trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data moving between the TSF
+ and another trusted IT product. Examples of this data are
+ TSF critical data such as passwords, keys, audit data, or
+ TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is providing TSF data to another trusted IT
+ product. The TSF can only take the measures at its site and
+ cannot be held responsible for the behaviour of the other
+ trusted IT product.
+
+
+
+
+
+ Confidentiality of TSF Data during transmission is
+ necessary to protect such information from
+ disclosure. Some possible implementations that could
+ provide confidentiality include the use of cryptographic
+ algorithms as well as spread spectrum techniques.
+
+
+
+ This family consists of only one component, ,
+ which requires that the TSF ensure that data transmitted between the TSF and another trusted IT
+ product is protected from disclosure while in transit.
+
+
+ The TSF shall protect all TSF data transmitted from the TSF
+ to another trusted IT product from unauthorised disclosure
+ during transmission.
+
+
+
+
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and another trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and another trusted IT product. Examples of
+ this data are TSF critical data such as passwords, keys,
+ audit data, or TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is exchanging TSF data with another trusted IT
+ product. Note that a requirement that addresses
+ modification, detection, or recovery at another trusted
+ IT product cannot be specified, as the mechanisms that
+ another trusted IT product will use to protect its data
+ cannot be determined in advance. For this reason, these
+ requirements are expressed in terms of the ``TSF
+ providing a capability'' which another trusted
+ IT product can use.
+
+
+
+
+
+ This component should be used in situations where it is
+ sufficient to detect when data have been modified. An
+ example of such a situation is one in which another
+ trusted IT product can request the TOE's TSF to
+ retransmit data when modification has been detected, or
+ respond to such types of request.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a weak checksum
+ and parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches.
+
+
+ , provides the ability to detect
+ modification of TSF data during transmission between the
+ TSF and another trusted IT product, under the assumption
+ that another trusted IT product is cognisant of the mechanism used.
+
+
+ the detection of modification of transmitted TSF data.
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and
+ another trusted IT product within the following metric:
+
+ a defined modification metric
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection..
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and another
+ trusted IT product and perform
+
+ action to be taken
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+ if modifications are detected.
+
+
+
+
+
+
+
+ This component should be used in situations where it is
+ necessary to detect or correct modifications of TSF
+ critical data.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a checksum and
+ parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches. The metric that needs to be defined can either
+ refer to the attacks it will resist (e.g. only 1 in a 1000
+ random messages will be accepted), or to mechanisms that
+ are well known in the public literature (e.g. the strength
+ must be conformant to the strength offered by Secure Hash
+ Algorithm).
+
+ The approach taken to correct modification might be done
+ through some form of error correcting checksum.
+
+
+
+ Some possible means of satisfying this requirement
+ involves the use of cryptographic functions or some form
+ of checksum.
+
+
+ , provides the ability for
+ another trusted IT product not only to detect modification,
+ but to correct modified TSF data under the assumption that
+ another trusted IT product is cognisant of the mechanism used.
+
+
+ management of the types of TSF data that the TSF should try
+ to correct if modified in transit;
+
+
+ management of the types of action that the TSF could take if
+ TSF data is modified in transit.
+
+
+ the detection of modification of transmitted TSF data;
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ the use of the correction mechanism.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and
+ another trusted IT product within the following metric:
+
+ a defined modification metric
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection..
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and another
+ trusted IT product and perform
+
+ action to be taken
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+ if modifications are detected.
+
+
+ The TSF shall provide the capability to correct
+
+ type of modification
+
+ the PP/ST author should define the types of
+ modification from which the TSF should be capable of
+ recovering.
+ of all TSF data transmitted between the TSF and another
+ trusted IT product.
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+ The determination of the degree of separation (i.e.,
+ physical or logical) that would make application of this
+ family useful depends on the intended environment of use. In
+ a hostile environment, there may be risks arising from
+ transfers between parts of the TOE separated by only a
+ system bus or an inter-process communications channel. In
+ more benign environments, the transfers may be across more
+ traditional network media.
+
+
+
+ One practical mechanism available to a TSF to provide this
+ protection is cryptographically-based.
+
+
+
+
+
+ , requires that TSF data be
+ protected when transmitted between separate parts of the
+ TOE.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+ One of the ways to achieve separation of TSF data based on
+ SFP-relevant attributes is through the use of separate
+ logical or physical channels.
+
+
+
+ , requires that the TSF separate
+ user data from TSF data during transmission.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the separation mechanism.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+ The TSF shall separate user data from TSF data when such
+ data is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+
+
+ , requires that the TSF data
+ transmitted between separate parts of the TOE is monitored
+ for identified integrity errors.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the types of modification of TSF data the TSF
+ should try to detect;
+
+
+ management of the action>s that will be taken.
+
+
+ the detection of modification of TSF data;
+
+
+ the action taken following detection of an integrity error.
+
+
+ The TSF shall be able to detect
+
+
+ modification of data
+
+
+ substitution of data
+
+
+ re-ordering of data
+
+
+ deletion of data
+
+
+
+
+ other integrity errors
+
+
+
+ if the PP/ST author chooses the latter selection
+ noted in the preceding paragraph, then the author
+ should also specify what those other integrity
+ errors are that the TSF should be capable of
+ detecting.
+
+
+
+
+
+ the PP/ST author should specify the desired type of
+ modification that the TSF shall be able to detect. The
+ PP/ST author should select from: modification of data,
+ substitution of data, re-ordering of data, deletion of
+ data, or any other integrity errors.
+
+
+ for TSF data transmitted between separate parts of the TOE.
+
+
+ Upon detection of a data integrity error, the TSF shall take
+ the following actions:
+
+
+ specify the action to be taken
+
+
+
+ the PP/ST author should specify the action to be taken
+ when an integrity error is identified.
+
+ .
+
+
+
+
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements of components in this family ensure that
+ the TSF is protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is enforced. Without these
+ components, the protection functions of a TSF lose their
+ effectiveness in environments where physical damage cannot
+ be prevented. This family also provides requirements
+ regarding how the TSF shall respond to physical tampering
+ attempts.
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements in this family ensure that the TSF is
+ protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is measurable based on
+ defined work factors. Without these components, the
+ protection functions of a TSF lose their effectiveness in
+ environments where physical damage cannot be prevented. This
+ component also provides requirements regarding how the TSF
+ must respond to physical tampering attempts.
+
+ Examples of physical tampering scenarios include mechanical
+ attack, radiation, changing the temperature.
+
+ It is acceptable for the functions that are available to an
+ authorised user for detecting physical tampering to be
+ available only in an off-line or maintenance mode. Controls
+ should be in place to limit access during such modes to
+ authorised users. As the TSF may not be
+ ``operational'' during those modes, it
+ may not be able to provide normal enforcement for authorised
+ user access. The physical implementation of a TOE might
+ consist of several structures: for example an outer
+ shielding, cards, and chips. This set of
+ ``elements'' as a whole must protect
+ (protect, notify and resist) the TSF from physical
+ tampering. This does not mean that all devices must provide
+ these features, but the complete physical construct as a
+ whole should.
+
+ Although there is only minimal auditing associating with
+ these components, this is solely because there is the
+ potential that the detection and alarm mechanisms may be
+ implemented completely in hardware, below the level of
+ interaction with an audit subsystem (for example, a
+ hardware-based detection system based on breaking a circuit
+ and lighting a light emitting diode (LED) if the circuit is
+ broken when a button is pressed by the authorised
+ user). Nevertheless, a PP/ST author may determine that for a
+ particular anticipated threat environment, there is a need
+ to audit physical tampering. If this is the case, the PP/ST
+ author should include appropriate requirements in the list
+ of audit events. Note that inclusion of these requirements
+ may have implications on the hardware design and its
+ interface to the software.
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are not
+ countered by procedural methods. It addresses the threat of
+ undetected physical tampering with the TSF. Typically, an
+ authorised user would be given the function to verify whether
+ tampering took place. As written, this component simply provides
+ a TSF capability to detect tampering. Specification of
+ management functions in should be
+ considered to specify who can make use of that capability, and
+ how they can make use of that capability. If this is done by non-IT mechanisms
+ (e.g. physical inspection) management functions are not required.
+
+
+
+ , provides for features that
+ indicate when a TSF device or TSF element is subject to
+ tampering. However, notification of tampering is not
+ automatic; an authorised user must invoke a security
+ administrative function or perform manual inspection to
+ determining if tampering has occurred.
+
+ management of the user or role that determines whether physical
+ tampering has occurred.
+
+
+ if detection by IT means, detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether
+ physical tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+
+
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are
+ not countered by procedural methods, and it is required
+ that designated individuals be notified of physical
+ tampering. It addresses the threat that physical tampering
+ with TSF elements, although detected, may not be noticed.
+ Specification of management functions in FMT_MOF.1 Management of
+ security functions behaviour should be considered to specify who
+ can make use of that capability, and how they can make use of that capability.
+
+
+
+ , provides for automatic
+ notification of tampering for an identified subset of
+ physical penetrations.
+
+
+ management of the user or role that gets informed about
+ intrusions;
+
+
+ management of the list of devices that should inform the
+ indicated user or role about the intrusion.
+
+
+ detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether physical
+ tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+ For
+
+
+ list of TSF devices/elements for which active detection
+ is required
+
+
+
+ the PP/ST author should provide a list of TSF
+ devices/elements for which active detection of
+ physical tampering is required.
+
+ , the TSF shall monitor the devices and
+ elements and notify
+
+
+ a designated user or role
+
+
+
+ the PP/ST author should designate a user or role that
+ is to be notified when tampering is detected. The type
+ of user or role may vary depending on the particular
+ security administration component (from the family) included in the PP/ST.
+
+
+ when physical tampering with the
+ TSF's devices or TSF's elements has
+ occurred.
+
+
+
+
+
+
+ For some forms of tampering, it is necessary that the TSF
+ not only detects the tampering, but actually resists it or
+ delays the attacker.
+
+ This component should be used when TSF devices and TSF
+ elements are expected to operate in an environment where a
+ physical tampering (e.g. observation, analysis, or
+ modification) of the internals of a TSF device or TSF
+ element itself is a threat.
+
+
+
+ , provides for features that prevent
+ or resist physical tampering with TSF devices and TSF
+ elements.
+
+
+ management of the automatic responses to physical tampering.
+
+
+ The TSF shall resist
+
+
+ physical tampering scenarios
+
+
+
+ the PP/ST author should specify tampering scenarios to
+ a list of TSF devices/elements for which the TSF
+ should resist physical tampering. This list may be
+ applied to a defined subset of the TSF physical
+ devices and elements based on considerations such as
+ technology limitations and relative physical exposure
+ of the device. Such subsetting should be clearly
+ defined and justified. Furthermore, the TSF should
+ automatically respond to physical tampering. The
+ automatic response should be such that the policy of
+ the device is preserved; for example, with a
+ confidentiality policy, it would be acceptable to
+ physically disable the device so that the protected
+ information may not be retrieved.
+
+
+ to the
+
+
+ list of TSF devices/elements
+
+
+
+ the PP/ST author should specify the list of TSF
+ devices/elements for which the TSF should resist
+ physical tampering in the scenarios that have been
+ identified.
+
+
+ by responding automatically such that the SFRs are always enforced.
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started-up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+ Recovery components reconstruct the TSF secure states, or
+ prevent transitions to insecure states, as a direct response
+ to occurrences of expected failures, discontinuity of
+ operation or start-up. Failures that must be generally
+ anticipated include the following:
+
+
+ Unmaskable action failures that always result in a
+ system crash (e.g. persistent inconsistency of critical
+ system tables, uncontrolled transfers within the TSF
+ code caused by transient failures of hardware or
+ firmware, power failures, processor failures,
+ communication failures).
+
+
+ Media failures causing part or all of the media
+ representing the TSF objects to become inaccessible or
+ corrupt (e.g. parity errors, disk head crash, persistent
+ read/write failure caused by misaligned disk heads,
+ worn-out magnetic coating, dust on the disk surface).
+
+
+ Discontinuity of operation caused by erroneous
+ administrative action or lack of timely administrative
+ action (e.g. unexpected shutdowns by turning off power,
+ ignoring the exhaustion of critical resources,
+ inadequate installed configuration).
+
+
+
+ Note that recovery may be from either a complete or partial
+ failure scenario. Although a complete failure might occur in
+ a monolithic operating system, it is less likely to occur in
+ a distributed environment. In such environments, subsystems
+ may fail, but other portions remain operational. Further,
+ critical components may be redundant (disk mirroring,
+ alternative routes), and checkpoints may be available. Thus,
+ recovery is expressed in terms of recovery to a secure
+ state.
+ There are different interactions between
+ and components to be considered when
+ selecting :
+
+ The need for trusted recovery may be indicated through
+ the results of TSF self-testing, where the results of
+ the self-tests indicate that the TSF is in an insecure
+ state and return to a secure state or entrance in
+ maintenance mode is required.
+
+ A failure, as discussed above, may be identified by an
+ administrator. Either the administrator may perform
+ the actions to return the TOE to a secure state and
+ then invoke TSF self-tests to confirm that the secure
+ state has been achieved. Or, the TSF self-tests may be
+ invoked to complete the recovery process.
+
+ A combination of a. and b. above, where the need for
+ trusted recovery is indicated through the results of
+ TSF self-testing, the administrator performs the
+ actions to return the TOE to a secure state and then
+ invokes TSF self-tests to confirm that the secure
+ state has been achieved.
+
+ Self tests detect a failure/service discontinuity,
+ then either automated recovery or entrance to a
+ maintenance mode.
+
+
+ This family identifies a maintenance mode. In this
+ maintenance mode normal operation might be impossible or
+ severely restricted, as otherwise insecure situations might
+ occur. Typically, only authorised users should be allowed
+ access to this mode but the real details of who can access
+ this mode is a function of . If does not put any controls on who can access this
+ mode, then it may be acceptable to allow any user to restore
+ the system if the TOE enters such a state. However, in
+ practice, this is probably not desirable as the user
+ restoring the system has an opportunity to configure the TOE
+ in such a way as to violate the SFRs.
+
+ Mechanisms designed to detect exceptional conditions during
+ operation fall under , , and other areas that address the
+ concept of ``Software Safety.'' It is likely that the use of
+ one of these families will be required to support the adoption
+ of . This is to ensure that
+ the TOE will be able to detect when recovery is
+ required.
+
+ Throughout this family, the phrase ``secure state'' is
+ used. This refers to some state in which the TOE has
+ consistent TSF data and a TSF that can correctly enforce the
+ policy. This state may be the initial ``boot'' of a clean
+ system, or it might be some checkpointed state.
+
+ Following recovery, it may be necessary to confirm that the
+ secure state has been achieved through self-testing of the
+ TSF. However, if the recovery is performed in a manner such
+ that only a secure state can be achieved, else recovery
+ fails, then the dependency to the TSF
+ self-test component may be argued away.
+
+
+
+
+
+
+
+
+ In the hierarchy of the trusted recovery family, recovery
+ that requires only manual intervention is the least
+ desirable, for it precludes the use of the system in an
+ unattended fashion.
+
+ This component is intended for use in TOEs that do not
+ require unattended recovery to a secure state. The
+ requirements of this component reduce the threat of
+ protection compromise resulting from an attended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+
+
+ , allows a TOE to only provide
+ mechanisms that involve human intervention to return to a
+ secure state.
+
+
+ management of who can access the restore capability within
+ the maintenance mode.
+
+
+ the fact that a failure or service discontinuity occurred;
+
+
+ resumption of the regular operation;
+
+
+ type of failure or service discontinuity.
+
+
+ After
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion, any failure or discontinuity)
+ following which the TOE will enter a maintenance mode. the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, as it allows the machine to operate in an
+ unattended fashion.
+
+ The component extends the feature
+ coverage of by requiring that there
+ be at least one automated method of recovery from failure
+ or service discontinuity. It addresses the threat of
+ protection compromise resulting from an unattended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ For , it is the responsibility of
+ the developer of the TSF to determine the set of
+ recoverable failures and service discontinuities.
+
+ It is assumed that the robustness of the automated
+ recovery mechanisms will be verified.
+
+
+
+ , provides, for at least one type of
+ service discontinuity, recovery to a secure state without
+ human intervention; recovery for other discontinuities may
+ require human intervention.
+
+
+ management of who can access the restore capability within
+ the maintenance mode;
+
+
+ management of the list of failures/service discontinuities
+ that will be handled through the automatic procedures.
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode. is not possible, the TSF shall enter a
+ maintenance mode where the ability to return to a secure state
+ is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, but it runs the risk of losing a
+ substantial number of objects. Preventing undue loss of
+ objects provides additional utility to the recovery
+ effort.
+
+ The component extends the feature
+ coverage of by requiring that there
+ not be undue loss of TSF data or objects under the control
+ of the TSF. At , the automated recovery
+ mechanisms could conceivably recover by deleting all
+ objects and returning the TSF to a known secure
+ state. This type of drastic automated recovery is
+ precluded in .
+
+ This component addresses the threat of protection
+ compromise resulting from an unattended TOE returning to
+ an insecure state after recovery from a failure or other
+ discontinuity with a large loss of TSF data or objects
+ under the control of the TSF.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ It is assumed that the evaluators will verify the
+ robustness of the automated recovery mechanisms.
+
+
+
+ , also provides for automated
+ recovery, but strengthens the requirements by disallowing
+ undue loss of protected objects.
+
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode.
+ is not possible, the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+ The functions provided by the TSF to recover from failure or
+ service discontinuity shall ensure that the secure initial
+ state is restored without exceeding
+
+
+ quantification
+
+
+
+ the PP/ST author should provide a quantification for
+ the amount of loss of TSF data or objects that is
+ acceptable.
+
+
+ for loss of TSF data or objects under the control of the TSF.
+
+
+ The TSF shall provide the capability to determine the
+ objects that were or were not capable of being recovered.
+
+
+
+
+
+
+ Function recovery requires that if there should be some
+ failure in the TSF, that certain functions in the TSF should
+ either complete successfully or recover to a secure state.
+
+
+
+ , provides for recovery at the level
+ of particular functions, ensuring either successful completion
+ or rollback of TSF data to a secure state.
+
+
+ if possible, the impossibility to return to a secure state
+ after a failure of the TSF;
+
+
+ if possible, the detection of a failure of a function.
+
+
+ The TSF shall ensure that
+
+
+ list of functions and failure scenarios
+
+
+
+ the PP/ST author should specify a list the functions and
+ failure scenarios. In the event that any of the
+ identified failure scenarios happen, the functions that have
+ been specified must either complete successfully or
+ recover to a consistent and secure state.
+
+
+ have the property that the function either completes successfully,
+ or for the indicated failure scenarios, recovers to a
+ consistent and secure state.
+
+
+
+
+
+
+
+ This family addresses detection of replay for various types
+ of entities (e.g. messages, service requests, service
+ responses) and subsequent actions to correct. In the case
+ where replay may be detected, this effectively prevents it.
+
+
+
+ This family addresses detection of replay for various types
+ of entities and subsequent actions to correct.
+
+
+
+
+
+ The entities included here are, for example, messages,
+ service requests, service responses, or sessions.
+
+
+
+ The family consists of only one component, , which requires that the TSF shall be
+ able to detect the replay of identified entities.
+
+
+ management of the list of identified entities for which
+ replay shall be detected;
+
+
+ management of the list of actions that need to be taken in
+ case of replay.
+
+
+ Detected replay attacks.
+
+
+ Action to be taken based on the specific actions.
+
+
+ The TSF shall detect replay for the following entities:
+
+
+ list of identified entities
+
+
+
+ the PP/ST author should provide a list of identified
+ entities for which detection of replay should be
+ possible. Examples of such entities might include:
+ messages, service requests, service responses, and
+ user sessions.
+
+ .
+
+
+ The TSF shall perform
+
+
+ list of specific actions
+
+
+
+ the PP/ST author should specify the list of actions to
+ be taken by the TSF when replay is detected. The
+ potential set of actions that can be taken includes:
+ ignoring the replayed entity, requesting confirmation
+ of the entity from the identified source, and
+ terminating the subject from which the re-played
+ entity originated.
+
+
+ when replay is detected.
+
+
+
+
+
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use this trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases, synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use a trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+ Some states may never be synchronised, or the transaction
+ cost may be too high for practical use; encryption key
+ revocation is an example, where knowing the state after the
+ revocation action is initiated can never be known. Either
+ the action was taken and acknowledgment cannot be sent, or
+ the message was ignored by hostile communication partners
+ and the revocation never occurred. Indeterminacy is unique
+ to distributed TOEs. Indeterminacy and state synchrony
+ are related, and the same solution may apply. It is futile
+ to design for indeterminate states; the PP/ST author should
+ express other requirements in such cases (e.g. raise an
+ alarm, audit the event).
+
+
+
+
+
+
+
+
+ In this component, the TSF must supply an acknowledgement
+ to another part of the TSF when requested. This
+ acknowledgement should indicate that one part of a
+ distributed TOE successfully received an unmodified
+ transmission from a different part of the distributed TOE.
+
+
+
+ , requires only a simple
+ acknowledgment by the data recipient.
+
+
+ failure to receive an acknowledgement when expected.
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data transmission.
+
+
+
+
+
+
+
+
+
+
+ In this component, in addition to the TSF being able to
+ provide an acknowledgement for the receipt of a data
+ transmission, the TSF must comply with a request from
+ another part of the TSF for an acknowledgement to the
+ acknowledgement.
+
+ For example, the local TSF transmits some data to a remote
+ part of the TSF. The remote part of the TSF acknowledges
+ the successful receipt of the data and requests that the
+ sending TSF confirm that it receives the
+ acknowledgement. This mechanism provides additional
+ confidence that both parts of the TSF involved in the data
+ transmission know that the transmission completed
+ successfully.
+
+
+
+ , requires mutual acknowledgment of
+ the data exchange.
+
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data
+ transmission.
+
+
+ The TSF shall ensure that the relevant parts of the TSF know
+ the correct status of transmitted data among its different
+ parts, using acknowledgements.
+
+
+
+
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+ It is the responsibility of the PP/ST author to clarify the
+ meaning of the phrase ``reliable time
+ stamp'', and to indicate where the responsibility
+ lies in determining the acceptance of trust.
+
+
+
+
+
+ Some possible uses of this component include providing
+ reliable time stamps for the purposes of audit as well as
+ for security attribute expiration.
+
+
+
+ This family consists of only one component, , which requires that the TSF provide
+ reliable time stamps for TSF functions.
+
+
+ management of the time.
+
+
+ changes to the time;
+
+
+ providing a timestamp.
+
+
+ The TSF shall be able to provide reliable time stamps.
+
+
+
+
+
+
+
+ In a distributed environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and a different trusted IT product.
+
+
+
+ In a distributed or composite environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT Product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and that of a different trusted IT Product.
+
+ The components in this family are intended to provide
+ requirements for automated support for TSF data consistency
+ when such data is transmitted between the TSF of the TOE and
+ another trusted IT Product. It is also possible that wholly
+ procedural means could be used to produce security attribute
+ consistency, but they are not provided for here.
+
+ This family is different from FDP_ETC and FDP_ITC, as those
+ two families are concerned only with resolving the security
+ attributes between the TSF and its import/export medium.
+
+ If the integrity of the TSF data is of concern, requirements
+ should be chosen from the family. These
+ components specify requirements for the TSF to be able to
+ detect or detect and correct modifications to TSF data in
+ transit.
+
+
+
+
+
+ The TSF is responsible for maintaining the consistency of
+ TSF data used by or associated with the specified function
+ and that are common between two or more trusted
+ systems. For example, the TSF data of two different
+ systems may have different conventions internally. For the
+ TSF data to be used properly (e.g. to afford the user data
+ the same protection as within the TOE) by the receiving
+ trusted IT product, the TOE and the other trusted IT
+ product must use a pre-established protocol to exchange
+ TSF data.
+
+
+
+ , requires that the TSF provide the
+ capability to ensure consistency of attributes between
+ TSFs.
+
+
+ Successful use of TSF data consistency mechanisms.
+
+
+ Use of the TSF data consistency mechanisms.
+
+
+ Identification of which TSF data have been interpreted.
+
+
+ Detection of modified TSF data.
+
+
+ The TSF shall provide the capability to consistently
+ interpret
+
+
+ list of TSF data types
+
+
+
+ the PP/ST author should define the list of TSF data
+ types, for which the TSF shall provide the capability
+ to consistently interpret, when shared between the TSF
+ and another trusted IT product.
+
+
+ when shared between the TSF and another trusted IT product.
+
+
+ The TSF shall use
+
+
+ list of interpretation rules to be applied by the TSF
+
+
+
+ the PP/ST should assign the list of interpretation
+ rules to be applied by the TSF,
+
+
+ when interpreting the TSF data from another trusted IT
+ product.
+
+
+
+ This family defines requirements for the TSF to perform tests
+ on one or more external entities.
+ This component is not intended to be applied to human users.
+ External entities may include applications running on the TOE, hardware or
+ software running ``underneath'' the TOE (platforms, operating systems etc.)
+ or applications/boxes connected to the TOE (intrusion detection systems,
+ firewalls, login servers, time servers etc.).
+ This family defines requirements for the testing of one or more external
+ entities by the TSF. These external entities are not human users, and they can
+ include combinations of software and/or hardware interacting with the TOE.
+ Examples of the types of tests that may be run are:
+
+ Tests for the presence of a firewall, and possibly whether it is
+ correctly configured;
+
+ Tests of some of the properties of the operating system that an
+ application TOE runs on;
+
+ Tests of some of the properties of the IC that a smart card OS TOE
+ runs on (e.g. the random number generator).
+
+ Note that the external entity may ``lie'' about the test results, either on
+ purpose or because it is not working correctly.
+ These tests can be carried out either in some maintenance state, at start-up,
+ on-line, or continuously. The actions to be taken by the TOE as the result of
+ testing are defined also in this family.
+ The tests of external entities should be sufficient to test all of the
+ characteristics of them upon which the TSF relies.
+ This component is not intended to be applied to human users.
+ This component provides support for the periodic testing of properties
+ related to external entities upon which the TSF's operation depends, by
+ requiring the ability to periodically invoke testing functions.
+ The PP/ST author may refine the requirement to state whether the function
+ should be available in off-line, on-line or maintenance mode.
+ It is acceptable for the functions for periodic testing to be available only in
+ an off-line or maintenance mode. Controls should be in place to limit access,
+ during maintenance, to authorised users., provides for testing of the
+ external entities by the TSF.
+ management of the conditions under which the testing of external
+ entities occurs, such as during initial start-up, regular interval, or
+ under specified conditions;
+
+ management of the time interval if appropriate.
+
+ Execution of the tests of the external entities and the results of
+ the tests.
+
+ The TSF shall run a suite of tests
+
+ during initial start-up
+
+ periodically during normal operation
+
+ at the request of an authorised user
+
+ other conditions
+
+ the PP/ST author should, if other conditions are
+ selected, specify the frequency with which the testing of external entities will be run.
+ An example of this other frecuency or condition may be to run the
+ tests each time a user requests to initiate a session with the TOE. For
+ instance, this could be the case of testing a directory server before its
+ interaction with the TSF during the user authentication process.
+ the PP/ST author should specify when the TSF will
+ run the testing of external entities, during initial start-up, periodically
+ during normal operation, at the request of an authorised user, or under
+ other conditions. If the tests are run often, then the end users should
+ have more confidence that the TOE is operating correctly than if the
+ tests are run less frequently. However, this need for confidence that
+ the TOE is operating correctly must be balanced with the potential
+ impact on the availability of the TOE, as often times, the testing of external entities may
+ delay the normal operation of a TOE.
+ to check the fulfillment of
+
+ list of properties of the external entities
+
+ the PP/ST author should specify the properties of the
+ external entities to be checked by the tests. Examples of these
+ properties may include configuration or availability properties of
+ a directory server supporting some access control part of the TSF.
+ .
+
+ If the test fails, the TSF shall
+
+ action(s)
+
+ the PP/ST author should specify what are the action(s)
+ that the TSF shall perform when the testing fails. Examples of these
+ action(s), illustrated by a directory server instance, may include to
+ connect to an alternative available server or otherwise to look for a
+ backup server.
+ .
+
+
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if
+ the internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network and parts of the TOE network connections are broken,
+ this may occur when parts become disabled.
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if an
+ internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network of parts of the TOE, this can occur when parts
+ become disabled, network connections are broken, and so on.
+
+ The method of ensuring consistency is not specified in this
+ component. It could be attained through a form of
+ transaction logging (where appropriate transactions are
+ ``rolled back'' to a site upon
+ reconnection); it could be updating the replicated data
+ through a synchronisation protocol. If a particular protocol
+ is necessary for a PP/ST, it can be specified through
+ refinement.
+
+ It may be impossible to synchronise some states, or the cost
+ of such synchronisation may be too high. Examples of this
+ situation are communication channel and encryption key
+ revocations. Indeterminate states may also occur; if a
+ specific behaviour is desired, it should be specified via
+ refinement.
+
+
+
+
+
+
+
+
+ This family consists of only one component, , which requires that the TSF ensure the
+ consistency of TSF data that is replicated in multiple
+ locations.
+
+
+ restoring consistency upon reconnection.
+
+
+ Detected inconsistency between TSF data.
+
+
+ The TSF shall ensure that TSF data is consistent when
+ replicated between parts of the TOE.
+
+
+ When parts of the TOE containing replicated TSF data are
+ disconnected, the TSF shall ensure the consistency of the
+ replicated TSF data upon reconnection before processing any
+ requests for
+
+
+ list of functions dependent on TSF data replication
+ consistency
+
+
+
+ the PP/ST author should specify the list of functions
+ dependent on TSF data replication consistency.
+
+ .
+
+
+
+
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of the authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF data and TSF itself (i.e. TSF executable code or
+ TSF hardware component) by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of an authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF data and TSF itself (i.e. TSF executable code or
+ TSF hardware component) by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+ In addition, use of this component may, with appropriate
+ conditions, help to prevent inappropriate or damaging TSF
+ changes being applied to an operational TOE as the result of
+ maintenance activities.
+
+ The term ``correct operation of the TSF'' refers primarily to
+ the operation of the TSF and the integrity of the TSF data.
+
+
+
+
+
+
+ This component provides support for the testing of the
+ critical functions of the TSF's operation by
+ requiring the ability to invoke testing functions and
+ check the integrity of TSF data and executable code.
+
+
+
+ It is acceptable for the functions that are available to
+ the authorised user for periodic testing to be available
+ only in an off-line or maintenance mode. Controls should
+ be in place to limit access during these modes to
+ authorised users.
+
+
+ , provides the ability to test the
+ TSF's correct operation. These tests may be
+ performed at start-up, periodically, at the request of the
+ authorised user, or when other conditions are met. It also
+ provides the ability to verify the integrity of TSF data
+ and TSF itself.
+
+
+ management of the conditions under which TSF self testing
+ occurs, such as during initial start-up, regular interval,
+ or under specified conditions;
+
+
+ management of the time interval if appropriate.
+
+
+ Execution of the TSF self tests and the results of the
+ tests.
+
+
+ The TSF shall run a suite of self tests
+
+ during initial start-up
+
+ periodically during normal operation
+
+ at the request of the authorised user
+
+ at the conditions
+
+ conditions under which self test should occur
+
+ the PP/ST author should, if selected, specify the
+ conditions under which the self test should take
+ place.
+ the PP/ST author should specify when the TSF will execute
+ the TSF test; during initial start-up, periodically during
+ normal operation, at the request of an authorised user, at
+ other conditions. In the case of the latter option, the
+ PP/ST author should also assign what those conditions are
+ via the following assignment.
+ to demonstrate the correct operation of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of parts of the TSF that will be subject to TSF
+ self-testing.
+ the TSF
+
+ the PP/ST author should specify whether the self tests
+ are to be carried out to demonstrate the correct
+ operation of the entire TSF, or of only specified parts
+ of TSF..
+
+
+ The TSF shall provide authorised users with the capability to
+ verify the integrity of
+
+ parts of TSF data
+
+ the PP/ST author should, if selected, specify the
+ list of TSF data that will be verified for
+ integrity.
+ TSF data
+
+ the PP/ST author should specify whether data integrity
+ is to be verified for all TSF data, or only for selected
+ data..
+
+
+ The TSF shall provide authorised users with the capability to
+ verify the integrity of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of TSF that will be verified for
+ integrity.
+ TSF
+
+ the PP/ST author should specify whether TSF integrity
+ is to be verified for all TSF, or only for selected
+ TSF..
+
+
+
+
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks, and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+
+
+ The requirements of this family ensure that the TOE will
+ maintain correct operation even in the event of failures.
+
+
+
+ This family provides requirements for the availability of
+ capabilities even in the case of failures. Examples of such
+ failures are power failure, hardware failure, or software
+ error. In case of these errors, if so specified, the TOE
+ will maintain the specified capabilities. The PP/ST author
+ could specify, for example, that a TOE used in a nuclear
+ plant will continue the operation of the shut-down procedure
+ in the case of power-failure or communication-failure.
+
+ Because the TOE can only continue its correct operation if
+ the SFRs are enforced, there is a requirement that the system
+ must remain in a secure state after a failure. This
+ capability is provided by .
+
+ The mechanisms to provide fault tolerance could be active or
+ passive. In case of an active mechanism, specific functions
+ are in place that are activated in case the error
+ occurs. For example, a fire alarm is an active mechanism:
+ the TSF will detect the fire and can take action such as
+ switching operation to a backup. In a passive scheme, the
+ architecture of the TOE is capable of handling the
+ error. For example, the use of a majority voting scheme with
+ multiple processors is a passive solution; failure of one
+ processor will not disrupt the operation of the TOE
+ (although it needs to be detected to allow correction).
+
+ For this family, it does not matter whether the failure has
+ been initiated accidentally (such as flooding or unplugging
+ the wrong device) or intentionally (such as monopolising).
+
+
+
+
+
+
+
+
+ This component is intended to specify which capabilities
+ the TOE will still provide after a failure of the
+ system. Since it would be difficult to describe all
+ specific failures, categories of failures may be
+ specified. Examples of general failures are flooding of
+ the computer room, short term power interruption,
+ breakdown of a CPU or host, software failure, or buffer
+ overflow.
+
+
+
+ , requires the TOE to continue
+ correct operation of identified capabilities in the event
+ of identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ All TOE capabilities being discontinued due to a failure.
+
+
+ The TSF shall ensure the operation of
+
+
+ list of TOE capabilities
+
+
+
+ the PP/ST author should specify the list of TOE
+ capabilities the TOE will maintain during and after a
+ specified failure.
+
+
+ when the following failures occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component is intended to specify against what type of
+ failures the TOE must be resistant. Since it would be
+ difficult to describe all specific failures, categories of
+ failures may be specified. Examples of general failures
+ are flooding of the computer room, short term power
+ interruption, breakdown of a CPU or host, software
+ failure, or overflow of buffer.
+
+
+
+ , requires the TOE to continue
+ correct operation of all capabilities in the event of
+ identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ The TSF shall ensure the operation of all the
+ TOE's capabilities when the following failures
+ occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without undue interference or delay caused by
+ low priority activities.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without interference or delay due to low
+ priority activities. In other words, time critical tasks
+ will not be delayed by tasks that are less time critical.
+
+ This family could be applicable to several types of
+ resources, for example, processing capacity, and
+ communication channel capacity.
+
+ The Priority of Service mechanism might be passive or
+ active. In a passive Priority of Service system, the system
+ will select the task with the highest priority when given a
+ choice between two waiting applications. While using passive
+ Priority of Service mechanisms, when a low priority task is
+ running, it cannot be interrupted by a high priority
+ task. While using an active Priority of Service mechanisms,
+ lower priority tasks might be interrupted by new high
+ priority tasks.
+
+ The audit requirement states that all reasons for rejection
+ should be audited. It is left to the developer to argue that
+ an operation is not rejected but delayed.
+
+
+
+
+
+ This component defines priorities for a subject, and the
+ resources for which this priority will be used. If a
+ subject attempts to take action on a resource controlled
+ by the Priority of Service requirements, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of a subset of the resources
+ under the control of the TSF.
+
+
+ assignment of priorities to each subject in the TSF.
+
+
+ Rejection of operation based on the use of priority within
+ an allocation.
+
+
+ All attempted uses of the allocation function which involves
+ the priority of the service functions.
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which the TSF enforces priority of service
+ (e.g. resources such as processes, disk space, memory,
+ bandwidth).
+
+
+ shall be mediated on the basis of the subjects assigned
+ priority.
+
+
+
+
+
+
+
+ This component defines priorities for a subject. All
+ shareable resources under the control of the TSF will be subjected to the
+ Priority of Service mechanism. If a subject attempts to
+ take action on a shareable TSF resource, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of all of the resources under the control of the TSF.
+
+
+
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to all shareable
+ resources shall be mediated on the basis of the subjects
+ assigned priority.
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources by users and subjects such that denial of
+ service will not occur because of unauthorised
+ monopolisation of resources.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that unauthorised denial of service will not take place by
+ means of monopolisation of resources by other users or
+ subjects.
+
+ Resource allocation rules allow the creation of quotas or
+ other means of defining limits on the amount of resource
+ space or time that may be allocated on behalf of a specific
+ user or subjects. These rules may, for example:
+
+
+ Provide for object quotas that constrain the number
+ and/or size of objects a specific user may allocate.
+
+
+ Control the allocation/deallocation of preassigned
+ resource units where these units are under the control
+ of the TSF.
+
+
+
+ In general, these functions will be implemented through the
+ use of attributes assigned to users and resources.
+
+ The objective of these components is to ensure a certain
+ amount of fairness among the users (e.g. a single user
+ should not allocate all the available space) and
+ subjects. Since resource allocation often goes beyond the
+ lifespan of a subject (i.e. files often exist longer than
+ the applications that generated them), and multiple
+ instantiations of subjects by the same user should not
+ negatively affect other users too much, the components allow
+ that the allocation limits are related to the users. In some
+ situations the resources are allocated by a subject
+ (e.g. main memory or CPU cycles). In those instances the
+ components allow that the resource allocation be on the
+ level of subjects.
+
+ This family imposes requirements on resource allocation, not
+ on the use of the resource itself. The audit requirements
+ therefore, as stated, also apply to the allocation of the
+ resource, not to the use of the resource.
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to only a specified set of the shareable
+ resources in the TOE. The requirements allow the quotas to
+ be associated with a user, possibly assigned to groups of
+ users or subjects as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will not
+ monopolise a controlled resource.
+
+
+ specifying maximum limits for a resource for groups and/or
+ individual users and/or subjects by an administrator.
+
+
+ Rejection of allocation operation due to resource limits.
+
+
+ All attempted uses of the resource allocation functions for
+ resources that are under control of the TSF.
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources:
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which maximum resource allocation limits
+ are required (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to a specified set of the shareable resources
+ in the TOE. The requirements allow the quotas to be
+ associated with a user, or possibly assigned to groups of
+ users as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will always
+ have at least a minimum of a specified resource and that
+ they will not be able to monopolise a controlled resource.
+
+
+ specifying minimum and maximum limits for a resource for
+ groups and/or individual users and/or subjects by an
+ administrator.
+
+
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which maximum and minimum resource
+ allocation limits are required (e.g. processes, disk
+ space, memory, bandwidth). If all resources under the control of the TSF
+ need to be included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+ The TSF shall ensure the provision of minimum quantity of
+ each
+
+
+ controlled resource
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which a minimum allocation limit needs
+ to be set (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included the words ``all TSF resources''
+ can be specified.
+
+
+ that is available for
+
+
+ an individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ to use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This family specifies functional requirements for controlling
+ the establishment of a user's session.
+
+
+
+ The establishment of a user's session typically
+ consists of the creation of one or more subjects that perform
+ operations in the TOE on behalf of the user. At the end of the
+ session establishment procedure, provided the TOE access
+ requirements are satisfied, the created subjects bear the
+ attributes determined by the identification and authentication
+ functions. This family specifies functional requirements for
+ controlling the establishment of a user's session.
+
+ A user session is defined as the period starting at the time
+ of the identification/authentication, or if more appropriate,
+ the start of an interaction between the user and the system,
+ up to the moment that all subjects (resources and attributes)
+ related to that session have been deallocated.
+
+
+
+
+
+ This family defines requirements to limit the scope of
+ session security attributes that a user may select for a
+ session.
+
+
+
+ This family defines requirements that will limit the session
+ security attributes a user may select, and the subjects to
+ which a user may be bound, based on: the method of access;
+ the location or port of access; and/or the time
+ (e.g. time-of-day, day-of-week).
+
+ This family provides the capability for a PP/ST author to
+ specify requirements for the TSF to place limits on the
+ domain of an authorised user's security attributes
+ based on an environmental condition. For example, a user may
+ be allowed to establish a ``secret session''
+ during normal business hours but outside those hours the
+ same user may be constrained to only establishing
+ ``unclassified sessions''. The identification of
+ relevant constraints on the domain of selectable attributes
+ can be achieved through the use of the selection
+ operation. These constraints can be applied on an
+ attribute-by-attribute basis. When there exists a need to
+ specify constraints on multiple attributes this component
+ will have to be replicated for each attribute. Examples of
+ attributes that could be used to limit the session security
+ attributes are:
+
+
+ The method of access can be used to specify in which
+ type of environment the user will be operating
+ (e.g. file transfer protocol, terminal, vtam).
+
+
+ The location of access can be used to constrain the
+ domain of a user's selectable attributes based
+ on a user's location or port of access. This
+ capability is of particular use in environments where
+ dial-up facilities or network facilities are available.
+
+
+ The time of access can be used to constrain the domain
+ of a user's selectable attributes. For example,
+ ranges may be based upon time-of-day, day-of-week, or
+ calendar dates. This constraint provides some
+ operational protection against user actions that could
+ occur at a time where proper monitoring or where proper
+ procedural measures may not be in place.
+
+
+
+
+
+
+
+ , provides the requirement for a TOE
+ to limit the scope of the session security attributes
+ during session establishment.
+
+
+ management of the scope of the session security attributes
+ by an administrator.
+
+
+ All failed attempts at selecting a session security
+ attributes;
+
+
+ All attempts at selecting a session security attributes;
+
+
+ Capture of the values of each session security attributes.
+
+
+ The TSF shall restrict the scope of the session security
+ attributes
+
+
+ session security attributes
+
+
+
+ the PP/ST author should specify the set of session
+ security attributes that are to be
+ constrained. Examples of these session security
+ attributes are user clearance level, integrity level
+ and roles.
+
+ , based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the set of attributes
+ that can be use to determine the scope of the session
+ security attributes. Examples of such attributes are
+ user identity, originating location, time of access,
+ and method of access.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements to place limits on the
+ number of concurrent sessions that belong to the same user.
+
+
+
+ This family defines how many sessions a user may have at the
+ same time (concurrent sessions). This number of concurrent
+ sessions can either be set for a group of users or for each
+ individual user.
+
+
+
+
+
+
+
+
+ This component allows the system to limit the number of
+ sessions in order to effectively use the resources of the
+ TOE.
+
+
+
+ , provides limitations that apply to
+ all users of the TSF.
+
+
+ management of the maximum allowed number of concurrent user
+ sessions by an administrator.
+
+
+ Rejection of a new session based on the limitation of
+ multiple concurrent sessions.
+
+
+ Capture of the number of currently concurrent user sessions
+ and the user security attribute(s).
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user.
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+
+
+
+ This component provides additional capabilities over those
+ of , by allowing further constraints
+ to be placed on the number of concurrent sessions that
+ users are able to invoke. These constraints are in terms
+ of a user's security attributes, such as a
+ user's identity, or membership of a role.
+
+
+
+ extends by
+ requiring the ability to specify limitations on the number
+ of concurrent sessions based on the related security
+ attributes.
+
+
+ management of the rules that govern the maximum allowed
+ number of concurrent user sessions by an administrator.
+
+
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user according to the rules
+
+
+ rules for the number of maximum concurrent sessions
+
+
+
+ the PP/ST author should specify the rules that
+ determine the maximum number of concurrent
+ sessions. An example of a rule is ``maximum
+ number of concurrent sessions is one if the user has a
+ classification level of ``secret''
+ and five otherwise''.
+
+ .
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to provide the
+ capability for TSF-initiated and user-initiated locking,
+ unlocking, and termination of interactive sessions.
+
+
+ This family defines requirements for the TSF to provide the
+ capability for TSF-initiated and user-initiated locking,
+ unlocking, and termination of interactive sessions.
+ When a user is directly interacting with subjects in the TOE
+ (interactive session), the user's terminal is vulnerable if
+ left unattended. This family provides requirements for the TSF
+ to disable (lock) the terminal or terminate the session after
+ a specified period of inactivity, and for the user to initiate
+ the disabling (locking) of the terminal or terminate the
+ session. To reactivate the terminal, an event specified by the
+ PP/ST author, such as the user re-authentication must
+ occur.
+ A user is considered inactive, if he/she has not provided any
+ stimulus to the TOE for a specified period of time.
+ A PP/ST author should consider whether
+ should be included. In that case, the function ``session
+ locking'' should be included in the operation in .
+
+
+
+
+
+
+
+ , provides the capability for the
+ TSF to lock an active user session after a specified
+ period of time. Locking a terminal would prevent any
+ further interaction with an existing active session
+ through the use of the locked terminal.
+
+ If display devices are overwritten, the replacement
+ contents need not be static (i.e. ``screen
+ savers'' are permitted).
+
+ This component allows the PP/ST author to specify what
+ events will unlock the session. These events may be
+ related to the terminal (e.g. fixed set of keystrokes to
+ unlock the session), the user (e.g. reauthentication), or
+ time.
+
+
+
+ includes system initiated locking
+ of an interactive session after a specified period of user
+ inactivity.
+
+
+ specification of the time of user inactivity after which
+ lock-out occurs for an individual user;
+
+
+ specification of the default time of user inactivity after
+ which lock-out occurs;
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+ Locking of an interactive session by the session locking
+ mechanism.
+
+
+ Successful unlocking of an interactive session.
+
+
+ Any attempts at unlocking an interactive session.
+
+
+ The TSF shall lock an interactive session after
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the locking of an
+ interactive session. If so desired the PP/ST author
+ could, through the assignment, specify that the time
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+
+ by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'' or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+
+
+ , provides the capability for
+ an authorised user to lock and unlock his/her own interactive
+ session. This would provide authorised users with the ability to
+ effectively block further use of their active sessions without
+ having to terminate the active session.
+
+ If devices are overwritten, the replacement contents need
+ not be static (i.e. ``screen savers''
+ are permitted).
+
+
+
+ , provides capabilities for the user
+ to lock and unlock the user's own interactive
+ sessions.
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+
+
+ The TSF shall allow user-initiated locking of the
+ user's own interactive session, by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'', or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+ , requires that the TSF terminate an
+ interactive user session after a period of inactivity.
+
+ The PP/ST author should be aware that a session may
+ continue after the user terminated his/her activity, for
+ example, background processing. This requirement would
+ terminate this background subject after a period of
+ inactivity of the user without regard to the status of the
+ subject.
+
+
+ , provides requirements for
+ the TSF to terminate the session after a specified period of
+ user inactivity.
+
+
+ specification of the time of user inactivity after which
+ termination of the interactive session occurs for an
+ individual user;
+
+
+ specification of the default time of user inactivity after
+ which termination of the interactive session occurs.
+
+
+ Termination of an interactive session by the session locking
+ mechanism.
+
+
+ The TSF shall terminate an interactive session after a
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the termination of an
+ interactive session. If so desired, the PP/ST author
+ could, through the assignment, specify that the
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+ .
+
+ , provides the capability for an
+ authorised user to terminate his/her interactive
+ session..
+ The PP/ST author should be aware that a session may continue
+ after the user terminated his/her activity, for example,
+ background processing. This requirement would allow the user
+ to terminate this background subject without regard to the
+ status of the subject., provides capabilities for the user
+ to terminate the user's own interactive sessions.
+ Termination of an interactive session by the user.
+
+ The TSF shall allow user-initiated termination of the user's own
+ interactive session.
+
+
+
+
+
+
+ This family defines requirements to display a configurable
+ advisory warning message to users regarding the appropriate
+ use of the TOE.
+
+
+
+ Prior to identification and authentication, TOE access
+ requirements provide the ability for the TOE to display an
+ advisory warning message to potential users pertaining to
+ appropriate use of the TOE.
+
+
+
+
+
+ This component requires that there is an advisory warning
+ regarding the unauthorised use of the TOE. A PP/ST author
+ could refine the requirement to include a default banner.
+
+
+
+ , provides the requirement for a TOE
+ Access Banner. This banner is displayed prior to the
+ establishment dialogue for a session.
+
+
+ maintenance of the banner by the authorised administrator.
+
+
+ Before establishing a user session, the TSF shall display an
+ advisory warning message regarding unauthorised use of the
+ TOE.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to display to a
+ user, upon successful session establishment, a history of
+ successful and unsuccessful attempts to access the
+ user's account.
+
+
+
+ This family defines requirements for the TSF to display to
+ users, upon successful session establishment to the TOE, a
+ history of unsuccessful attempts to access the account. This
+ history may include the date, time, means of access, and
+ port of the last successful access to the TOE, as well as
+ the number of unsuccessful attempts to access the TOE since
+ the last successful access by the identified user.
+
+
+
+
+
+
+ This family can provide authorised users with information
+ that may indicate the possible misuse of their user
+ account.
+
+ This component request that the user is presented with the
+ information. The user should be able to review the
+ information, but is not forced to do so. If a user so
+ desires he might, for example, create scripts that ignore
+ this information and start other processes.
+
+
+
+ , provides the requirement for a TOE
+ to display information related to previous attempts to
+ establish a session.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last successful session establishment that will
+ be shown at the user interface. The items are: date,
+ time, method of access (such as ftp), and/or location
+ (e.g. terminal 50).
+
+
+ of the last successful session establishment to the user.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last unsuccessful session establishment that
+ will be shown at the user interface. The items are:
+ date, time, method of access (such as ftp), and/or
+ location (e.g. terminal 50).
+
+
+ of the last unsuccessful attempt to session establishment
+ and the number of unsuccessful attempts since the last
+ successful session establishment.
+
+
+ The TSF shall not erase the access history information from
+ the user interface without giving the user an opportunity to
+ review the information.
+
+
+
+
+
+
+ This family defines requirements to deny a user permission
+ to establish a session with the TOE.
+
+
+
+ This family defines requirements to deny an user permission
+ to establish a session with the TOE based on attributes such
+ as the location or port of access, the user's security
+ attribute (e.g. identity, clearance level, integrity level,
+ membership in a role), ranges of time (e.g. time-of-day,
+ day-of-week, calendar dates) or combinations of parameters.
+
+ This family provides the capability for the PP/ST author to
+ specify requirements for the TOE to place constraints on the
+ ability of an authorised user to establish a session with
+ the TOE. The identification of relevant constraints can be
+ achieved through the use of the selection
+ operation. Examples of attributes that could be used to
+ specify the session establishment constraints are:
+
+
+ The location of access can be used to constrain the
+ ability of a user to establish an active session with
+ the TOE, based on the user's location or port
+ of access. This capability is of particular use in
+ environments where dial-up facilities or network
+ facilities are available.
+
+
+ The user's security attributes can be used to
+ place constraints on the ability of a user to establish
+ an active session with the TOE. For example, these
+ attributes would provide the capability to deny session
+ establishment based on any of the following:
+
+
+ a user's identity;
+
+
+ a user's clearance level;
+
+
+ a user's integrity level; and
+
+
+ a user's membership in a role.
+
+
+
+
+
+ This capability is particularly relevant in situations where
+ authorisation or login may take place at a different
+ location from where TOE access checks are performed.
+
+
+ The time of access can be used to constrain the ability
+ of a user to establish an active session with the TOE
+ based on ranges of time. For example, ranges may be
+ based upon time-of-day, day-of-week, or calendar
+ dates. This constraint provides some operational
+ protection against actions that could occur at a time
+ where proper monitoring or where proper procedural
+ measures may not be in place.
+
+
+
+
+
+
+
+ , provides requirements for denying
+ users access to the TOE based on attributes.
+
+
+ management of the session establishment conditions by the
+ authorised administrator.
+
+
+ Denial of a session establishment due to the session
+ establishment mechanism.
+
+
+ All attempts at establishment of a user session.
+
+
+ Capture of the value of the selected access parameters
+ (e.g. location of access, time of access).
+
+
+ The TSF shall be able to deny session establishment based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the attributes that
+ can be used to restrict the session
+ establishment. Example of possible attributes are user
+ identity, originating location (e.g. no remote
+ terminals), time of access (e.g. outside hours), or
+ method of access (e.g. X-windows).
+
+ .
+
+
+
+
+
+
+
+ Families in this class provide requirements for a trusted
+ communication path between users and the TSF, and for a
+ trusted communication channel between the TSF and other
+ trusted IT products. Trusted paths and channels have the
+ following general characteristics:
+
+
+ The communications path is constructed using internal and
+ external communications channels (as appropriate for the
+ component) that isolate an identified subset of TSF data
+ and commands from the remainder of the TSF and user data.
+
+
+ Use of the communications path may be initiated by the
+ user and/or the TSF (as appropriate for the component).
+
+
+ The communications path is capable of providing assurance
+ that the user is communicating with the correct TSF, and
+ that the TSF is communicating with the correct user (as
+ appropriate for the component).
+
+
+
+ In this paradigm, a trusted channel is a communication channel
+ that may be initiated by either side of the channel, and
+ provides non-repudiation characteristics with respect to the
+ identity of the sides of the channel.
+
+ A trusted path provides a means for users to perform functions
+ through an assured direct interaction with the TSF. Trusted
+ path is usually desired for user actions such as initial
+ identification and/or authentication, but may also be desired
+ at other times during a user's session. Trusted
+ path exchanges may be initiated by a user or the TSF. User
+ responses via the trusted path are guaranteed to be protected
+ from modification by or disclosure to untrusted applications.
+
+
+
+ Users often need to perform functions through direct
+ interaction with the TSF. A trusted path provides confidence
+ that a user is communicating directly with the TSF whenever it
+ is invoked. A user's response via the trusted path
+ guarantees that untrusted applications cannot intercept or
+ modify the user's response. Similarly, trusted
+ channels are one approach for secure communication between the
+ TSF and another trusted IT product.
+
+ Absence of a trusted path may allow breaches of accountability
+ or access control in environments where untrusted applications
+ are used. These applications can intercept user-private
+ information, such as passwords, and use it to impersonate
+ other users. As a consequence, responsibility for any system
+ actions cannot be reliably assigned to an accountable
+ entity. Also, these applications could output erroneous
+ information on an unsuspecting user's display,
+ resulting in subsequent user actions that may be erroneous and
+ may lead to a security breach.
+
+
+
+
+
+ This family defines requirements for the creation of a
+ trusted channel between the TSF and other trusted IT
+ products for the performance of security critical
+ operations. This family should be included whenever there
+ are requirements for the secure communication of user or TSF
+ data between the TOE and other trusted IT products.
+
+
+
+ This family defines the rules for the creation of a trusted
+ channel connection that goes between the TSF and another
+ trusted IT product for the performance of security critical
+ operations between the products. An example of such a
+ security critical operation is the updating of the TSF
+ authentication database by the transfer of data from a
+ trusted product whose function is the collection of audit
+ data.
+
+
+
+
+
+ This component should be used when a trusted communication
+ channel between the TSF and another trusted IT product is
+ required.
+
+
+
+ , requires that the TSF provide a
+ trusted communication channel between itself and another
+ trusted IT product.
+
+
+ Configuring the actions that require trusted channel, if
+ supported.
+
+
+ Failure of the trusted channel functions.
+
+
+ Identification of the initiator and target of failed trusted
+ channel functions.
+
+
+ All attempted uses of the trusted channel functions.
+
+
+ Identification of the initiator and target of all trusted
+ channel functions.
+
+
+ The TSF shall provide a communication channel between itself
+ and another trusted IT product that is logically distinct
+ from other communication channels and provides assured
+ identification of its end points and protection of the
+ channel data from modification or disclosure.
+
+
+ The TSF shall permit
+
+ the TSF
+
+ another trusted IT product
+
+ the PP/ST author must specify whether the local TSF,
+ another trusted IT product, or both shall have the
+ capability to initiate the trusted channel.
+ to initiate communication via the trusted channel.
+
+
+ The TSF shall initiate communication via the trusted channel
+ for
+
+
+ list of functions for which a trusted channel is
+ required
+
+
+
+ the PP/ST author should specify the functions for
+ which a trusted channel is required. Examples of these
+ functions may include transfer of user, subject,
+ and/or object security attributes and ensuring
+ consistency of TSF data.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+
+
+ This component should be used when trusted communication
+ between a user and the TSF is required, either for initial
+ authentication purposes only or for additional specified
+ user operations.
+
+
+
+ , requires that a trusted path
+ between the TSF and a user be provided for a set of events
+ defined by a PP/ST author. The user and/or the TSF may
+ have the ability to initiate the trusted path.
+
+
+ Configuring the actions that require trusted path, if
+ supported.
+
+
+ Failures of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ failures, if available.
+
+
+ All attempted uses of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ invocations, if available.
+
+
+ The TSF shall provide a communication path between itself and
+
+ remote
+
+ local
+
+ the PP/ST author should specify whether the trusted path
+ must be extended to remote and/or local users.
+ users that is logically distinct from other communication
+ paths and provides assured identification of its end points
+ and protection of the communicated data from
+
+ modification
+
+ disclosure
+
+ other types of integrity or confidentiality violation
+
+ if selected, the PP/ST author should identify any
+ additional types of integrity or confidentiality
+ violation against which the trusted path shall protect
+ the data.
+ the PP/ST author should specify whether the trusted path
+ shall protect the data from modification, disclosure,
+ and/or other types of integrity or confidentiality
+ violation..
+
+
+ The TSF shall permit
+
+
+ the TSF
+
+
+ local users
+
+
+ remote users
+
+
+
+ the PP/ST author should specify whether the TSF, local
+ users, and/or remote users should be able to initiate
+ the trusted path.
+
+
+ to initiate communication via the trusted path.
+
+
+ The TSF shall require the use of the trusted path for
+
+
+ initial user authentication
+
+
+
+
+ other services for which trusted path is required
+
+
+
+ if selected, the PP/ST author should identify
+ other services for which trusted path is required,
+ if any.
+
+
+
+
+
+ the PP/ST author should specify whether the trusted
+ path is to be used for initial user authentication
+ and/or for other specified services.
+
+ .
+
+
+
+
+
+
+
+ The class encompasses five
+ families. These families specify assurance requirements that
+ are designed to provide confidence that a composed TOE will
+ operate securely when relying upon security functionality
+ provided by previously evaluated software, firmware or
+ hardware components.
+
+ Composition involves taking two or more IT entities
+ successfully evaluated against CC security assurance
+ requirements packages (base components and dependent
+ components, see ) and
+ combining them for use, with no further development of either
+ IT entity. The development of additional IT entities is not
+ included (entities that have not previously been the subject
+ of a component evaluation). The composed TOE forms a new
+ product that can be installed and integrated into any specific
+ environment instance that meets the objectives for the
+ environment.
+
+ This approach does not provide an alternative approach for the
+ evaluation of components. Composition under provides a composed TOE integrator a method, which
+ can be used as an alternative to other assurance levels
+ specified in the CC, to gain confidence in a TOE that is the
+ combination of two or more successfully evaluated components
+ without having to re-evaluate the composite TSF. (The composed
+ TOE integrator is referred to as ``developer'' throughout the
+ class, with any references to the
+ developer of the base or dependent components clarified as
+ such.)
+
+ Composed Assurance Packages, as defined in Clauses and , is an
+ assurance scale for composed TOEs. This assurance scale is
+ required in addition to EALs because to combine components
+ evaluated against EALs and gain a resulting EAL assurance, all
+ SARs in the EAL have to be applied to the composed
+ TOE. Although reuse can be made of the component TOE
+ evaluation results, there are often additional aspects of the
+ components that have to be considered in the composed TOE, as
+ described in Annex . Due to the different parties involved in a
+ composed TOE evaluation activity it is generally not possible
+ to gain all necessary evidence about these additional aspects
+ of the components to apply the appropriate EAL. Hence, CAPs
+ have been defined to address the issue of combining evaluated
+ components and gaining a meaningful result. This is discussed
+ further in .
+
+
+
+
+ In a composed TOE it is generally the case that one component
+ relies on the services provided by another component. The
+ component requiring services is termed the dependent component
+ and the component providing the services is termed the base
+ component. This interaction and distinct is discussed further
+ in Annex B. It is assumed to be the case that the developer of
+ the dependent component is supporting the composed TOE
+ evaluation in some manner (as developer, sponsor, or just
+ cooperating and providing the necessary evaluation evidence
+ from the dependent component evaluation) The components included in the CAP assurance packages
+ should not be used as augmentations for component TOE
+ evaluations, as this would provide no meaningful assurance for
+ the component.
+
+ The families within the class
+ interact in a similar manner to the , and classes in a component TOE evaluation and hence
+ leverage from the specification of requirements from those
+ classes where applicable. There are however a few items
+ specific to composed TOE evaluations. To determine how the
+ components interact and identify any deviations from the
+ evaluations of the components, the dependencies that the
+ dependent component has upon the underlying base component are
+ identified (). This reliance on
+ the base component is specified in terms of the interfaces
+ through which the dependent component makes calls for services
+ in support of the dependent component SFRs. The interfaces,
+ and at higher levels the supporting behaviour, provided by the
+ base component in response to those service requests are
+ analysed in . The family is based on the family, as at the simplest level the
+ TSF of each component can be viewed as a subsystem of the
+ composed TOE, with additional portions of each component seen
+ as additional subsystems. Therefore, the interfaces between
+ the components are seen as interactions between subsystems in
+ a component TOE evaluation.
+
+ It is possible that the interfaces and supporting behaviour
+ descriptions provided for are
+ incomplete. This is determined during the conduct of . The
+ family takes the outputs of and
+ and determines whether the
+ components are being used in their evaluated configuration and
+ identifies where any specifications are incomplete, which are
+ then identified as inputs into testing () and vulnerability analysis () activities of the composed TOE.
+
+ Testing of the composed TOE is performed to determine that the
+ composed TOE exhibits the expected behaviour as determined by
+ the composed TOE SFRs, and at higher levels demonstrates the
+ compatibility of the interfaces between the components of the
+ composed TOE.
+
+ The vulnerability analysis of the composed TOE leverages from
+ the outputs of the vulnerability analysis of the component
+ evaluations. The composed TOE vulnerability analysis considers
+ any residual vulnerabilities from the component evaluations to
+ determine that the residual vulnerabilities are not applicable
+ to the composed TOE. A search of publicly available
+ information relating to the components is also performed to
+ identify any issues reported in the components since the
+ completion of the respective evaluations.
+
+ The interaction between the
+ families is depicted in Figure below. This shows by solid arrowed lines where
+ the evidence and understanding gained in one family feeds into
+ the next activity and the dashed arrows identify where an
+ activity explicitly traces back to the composed TOE SFRs, as
+ described above.
+
+
+
+
+ Further discussion of the definition and interactions within
+ composed TOEs is provided in .
+
+
+
+ Assurance class defines
+ requirements of the information necessary to ensure that two
+ or more components, which have themselves been the subject of
+ a CC evaluation, can be integrated in a secure manner.
+
+ The assurance requirements will
+ be applied to the composed TOE to:
+
+
+ determine that the required assurance is provided by the
+ base component;
+
+ determine that the base component and dependent component
+ are compatible; and
+
+ search for any vulnerabilities introduced through
+ composing the base and dependent components into a single
+ composed TOE entity.
+
+
+
+ The goal of this activity is to determine whether the
+ components can be integrated in a secure manner, as defined in
+ the ST for the composed TOE. This is achieved through
+ examination and testing of the interfaces between the
+ components, supported by examination of the design of the
+ components and the conduct of vulnerability analysis.
+
+
+
+ The family identifies where
+ the dependent component is reliant upon IT in its operational
+ environment (satisfied by a base component in the composed TOE
+ evaluation) in order to provide its own security
+ services. This reliance is identified in terms of the
+ interfaces expected by the dependent component to be provided
+ by the base component. then
+ determines which interfaces of the base component were
+ considered (as TSFI) during the component evaluation of the
+ base component.
+
+ It should be noted that does
+ not cover other evidence that may be needed to address the
+ technical integration problem of composing components
+ (e.g. descriptions of non-TSF interfaces of the operating
+ system, rules for integration, etc.). This is outside the
+ security assessment of the composition and is a functional
+ composition issue.
+
+ As part of the evaluator will
+ perform testing of the composed TOE SFRs at the composed TOE
+ interfaces and of the interfaces of the base component relied
+ upon by the dependent component to confirm they operate as
+ specified. The subset selected will consider the possible
+ effects of changes to the configuration/use of the base
+ component as used in the composed TOE. These changes are
+ identified from the configuration of the base component
+ determined during the base component evaluation. The developer
+ will provide test evidence for each of the base component
+ interfaces (the requirements for coverage are consistent with
+ those applied to the evaluation of the base component).
+
+ requires the evaluator to
+ determine whether the appropriate assurance measures have been
+ applied to the base component, and whether the base component
+ is being used in its evaluated configuration. This includes
+ determination of whether all security functionality required
+ by the dependent component was within the TSF of the base
+ component. The requirement
+ may be met through the production of evidence that each of
+ these is demonstrated to be upheld. This evidence may be in
+ the form of the security target and a public report of the
+ component evaluation (e.g. certification report).
+
+ If, on the other hand, one of the above have not been upheld,
+ then it may be possible that an argument can be made as to why
+ the assurance gained during an original evaluation is
+ unaffected. If this is not possible then additional evaluation
+ evidence for those aspects of the base component not covered
+ may have to be provided. This material is then assessed in
+ .
+
+ For example, it may be the case as described in the
+ Interactions between entities (see Annex in CC Part 3) that the
+ dependent component requires the base component to provide
+ more security functionality in the composed TOE than included
+ in the base component evaluation. This would be determined
+ during the application of the
+ and families. In this case
+ the composition rationale evidence provided for would demonstrate that the
+ assurance gained from the base component evaluation is
+ unaffected. This may be achieved by means including:
+
+
+ Performing a re-evaluation of the base component focusing
+ on the evidence relating to the extended part of the
+ TSF;
+
+ Demonstrating that the extended part of the TSF cannot
+ affect other portions of the TSF, and providing evidence
+ that the extended part of the TSF provides the necessary
+ security functionality.
+
+
+
+
+ This family addresses the requirement to demonstrate that
+ the base component can provide an appropriate level of
+ assurance for use in composition.
+
+
+
+ The family is used to
+ determine whether or not the appropriate assurance measures
+ have been applied to the base component for successful
+ integration in the composed TOE. That is, the SARs claimed
+ by the base component are consistent with the SARs in the
+ assurance package for the composed TOE. (e.g. if the
+ assurance package for the composed TOE included , a base component that was
+ evaluated against would
+ not have had the appropriate assurance measures applied, as
+ insufficient design evidence would have been
+ examined.)
+
+ The family calls for
+ evidence that the appropriate assurance is provided, without
+ being specific about how this is achieved. If the
+ appropriate evidence is not available, then it may be
+ necessary to report an assessment of the residual risk to
+ assist consumers of the composed TOE
+ (e.g. accreditors). This report would need to identify the
+ change to the base component that may have an effect on the
+ assurance gained during the original evaluation, along with
+ any known effects.
+
+
+
+
+ There is only a single component in this family.
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+ the composition rationale;
+
+ the reliance information;
+
+ the development information;
+
+ unique identifier.
+
+
+
+
+ The developer shall provide composition rationale for the
+ base component.
+
+
+ The composition rationale shall demonstrate that a level of
+ assurance at least as high as that of the dependent
+ component has been obtained for the support functionality of
+ the base component, when the base component is configured as
+ required to support the TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the correspondence analysis
+ with the development information and the reliance
+ information to identify the interfaces that are relied
+ upon by the dependent component which are not detailed
+ in the development information.
+
+ The evaluator's goal in this work unit is two fold:
+
+
+ to determine which interfaces relied upon by the
+ dependent component have had the appropriate
+ assurance measures applied.
+
+ to determine that the assurance package applied to
+ the base component during the base component
+ evaluation contained either the same assurance
+ requirements as those in the package applied to the
+ dependent component during its' evaluation, or
+ hierarchically higher assurance requirements.
+
+
+ The evaluator may use the correspondence tracing in the
+ development information developed during the activities (e.g. , , ) to
+ help identify the interfaces identified in the reliance
+ information that are not considered in the development
+ information.
+
+ The evaluator will record the SFR-enforcing interfaces
+ described in the reliance information that are not
+ included in the development information. These will
+ provide input to
+ work unit, helping to identify the portions of the base
+ component in which further assurance is required.
+
+ If the both the base and dependent components were
+ evaluated against the same assurance package, then the
+ determination of whether the level of assurance in the
+ portions within the base component evaluation is at
+ least as high as that of the dependent component is
+ trivial. If however, the assurance packages applied to
+ the components during the component evaluations differ,
+ the evaluator needs to determine that the assurance
+ requirements applied to the base component are all
+ hierarchically higher to the assurance requirements
+ applied to the dependent component.
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine, for those included base component interfaces
+ on which the dependent TSF relies, whether the interface
+ was considered during the evaluation of the base
+ component.
+
+ The ST, component public evaluation report (e.g. certification
+ report) and guidance documents for the base component all
+ provide information on the scope and boundary of the base
+ component. The ST provides details of the logical scope and
+ boundary of the composed TOE, allowing the evaluator to
+ determine whether an interface relates to a portion of the
+ product that was within the scope of the evaluation. The
+ guidance documentation provides details of use of all interfaces
+ for the composed TOE. Although the guidance documentation may
+ include details of interfaces in the product that are not within
+ the scope of the evaluation, any such interfaces should be
+ identifiable, either from the scoping information in the ST or
+ through a portion of the guidance that deals with the evaluated
+ configuration. The public evaluation report may provide any
+ additional constraints on the use of the composed TOE that are
+ necessary.
+
+ Therefore, the combination of these inputs allows the
+ evaluator to determine whether an interface described in
+ the composition rationale has the necessary assurance
+ associated with it, or whether further assurance is
+ required. The evaluator will record those interfaces of
+ the base component for which additional assurance is
+ required, for consideration during .
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine that the necessary assurance measures have
+ been applied to the base component.
+
+ The evaluation verdicts, and resultant assurance, for
+ the base component can be reused provided the same
+ portions of the base component are used in the composed
+ TOE and they are used in a consistent manner.
+
+ In order to determine whether the necessary assurance
+ measures have already been applied to the component, and
+ the portions of the component for which assurance
+ measures still need to be applied, the evaluator should
+ use the output of the .*.2E action and the work units and :
+
+
+
+ For those interfaces identified in the reliance
+ information (), but
+ not discussed in development information (), additional information
+ is required. (Identified in .)
+
+ For those interfaces used inconsistently in the
+ composed TOE from the base component (difference
+ between the information provided in and the impact of the differences in use
+ need to be considered. (Identified in .*.2E.)
+
+ For those interfaces identified in composition
+ rationale for which no assurance has previously been
+ gained, additional information is
+ required. (Identified in .)
+
+ For those interfaces consistently described in the
+ reliance information, composition rationale and the
+ development information, no further action is
+ required as the results from the base component
+ evaluation can be re-used.
+
+ The interfaces of the base component reported to be
+ required by the reliance information but not included in
+ the development information indicate the portions of the
+ base component where further assurance is required. The
+ interfaces identify the entry points into the base
+ component.
+
+ For those interfaces included in both the development
+ information and reliance information, the evaluator is
+ to determine whether the interfaces are being used in
+ the composed TOE in a manner that is consistent with the
+ base component evaluation. The method of use of the
+ interface will be considered during the activities to determine that
+ the use of the interface is consistent in both the base
+ component and the composed TOE. The remaining
+ consideration is the determination of whether the
+ configurations of the base component and the composed
+ TOE are consistent. To determine this, the evaluator
+ will consider the guidance documentation of each to
+ ensure they are consistent (see further guidance below
+ regarding consistent guidance documentation). Any
+ deviation in the documentation will be further analysed
+ by the evaluation to determine the possible
+ effects.
+
+ For those interfaces that are consistently described in
+ the reliance information and development information,
+ and for which the guidance is consistent for the base
+ component and the composed TOE, the required level of
+ assurance has been provided.
+
+ The following subsubclauses provide guidance on how to
+ determine consistency between assurance gained in the
+ base component, the evidence provided for the composed
+ TOE, and the analysis performed by the evaluator in the
+ instances where inconsistencies are identified.
+
+
+ The reliance information identifies the interfaces in
+ the dependent component that are to be matched by the
+ base component. If an interface identified in the
+ reliance information is not identified in the
+ development information, then the composition
+ rationale is to provide a justification of how the
+ base component provides the required
+ interfaces.
+
+ If an interface identified in the reliance information
+ is identified in the development information, but
+ there are inconsistencies between the descriptions,
+ further analysis is required. The evaluator identifies
+ the differences in use of the base component as
+ considered in the base component evaluation and the
+ composed TOE evaluation. The evaluator will devise
+ testing to be performed (during the conduct of ) to test the
+ interface.
+
+ The patch status of the base and dependent components
+ as used in the composed TOE should be compared to the
+ patch status of the components during the component
+ evaluations. If any patches have been applied to the
+ components, the composition rationale is to include
+ details of the patches, including any potential impact
+ to the SFRs of the evaluated component. The evaluator
+ should consider the details of the changes provided
+ and verify the accuracy of the potential impact of the
+ change on the component SFRs. The evaluator should
+ then consider whether the changes made by the patch
+ should be verified through testing, and will identify
+ the necessary testing approach. The testing may take
+ the form of repeating the applicable
+ evaluator/developer testing performed for the
+ component evaluation of the component or it may be
+ necessary for the evaluator to devise new tests to
+ confirm the modified component.
+
+ If any of the individual components have been the
+ subject of assurance continuity activities since the
+ completion of the component evaluation, the evaluator
+ will consider the changes assessed in the assurance
+ continuity activities during the independent
+ vulnerability analysis activity for the composed TOE
+ (in ).
+
+
+
+ The guidance for the composed TOE is likely to make
+ substantial reference out to the guidance for the
+ individual components. The minimal guidance expected
+ to be necessary is the identification of any ordering
+ dependencies in the application of guidance for the
+ dependent and base components, particularly during the
+ preparation (installation) of the composed TOE.
+
+ In addition to the application of the and families to the guidance for the
+ composed TOE, it is necessary to analyse the
+ consistency between the guidance for the components
+ and the composed TOE, to identify any
+ deviations.
+
+ If the composed TOE guidance refers out to the base
+ component and dependent component guidance, then the
+ consideration for consistency is limited to
+ consistency between the guidance documentation
+ provided for each of the components (i.e. consistency
+ between the base component guidance and the dependent
+ component guidance). However, if additional guidance
+ is provided for the composed TOE, to that provided for
+ the components, greater analysis is required, as
+ consistency is also required between the guidance
+ documentation for the components and guidance
+ documentation for the composed TOE.
+
+ Consistent in this instance is
+ understood to mean that either the guidance is the
+ same or it places additional constraints on the
+ operation of the individual components when combined,
+ in a similar manner to refinement of
+ functional/assurance components.
+
+ With the information available (that used as input for
+ or the development
+ aspects discussed above) the evaluator may be able to
+ determine all possible impacts of the deviation from
+ the configuration of the base component specified in
+ the component evaluation. However, for high EALs
+ (where evaluation of the base component included requirements) it is
+ possible that, unless detailed design abstractions for
+ the base component are delivered as part of the
+ development information for the composed TOE, the
+ possible impacts of the modification to the guidance
+ cannot be fully determined as the internals are
+ unknown. In this case the evaluator will report the
+ residual risk of the analysis.
+
+ These residual risks are to be included in any public
+ evaluation report for the composed TOE.
+
+ The evaluator will note these variances in the
+ guidance for input into evaluator independent testing
+ activities ().
+
+ The guidance for the composed TOE may add to the
+ guidance for the components, particularly in terms of
+ installation and the ordering of installation steps
+ for the base component in relation to the installation
+ steps for the dependent component. The ordering of
+ the steps for the installation of the individual
+ components should not change, however they may need to
+ be interleaved. The evaluator will examine this
+ guidance to ensure that it still meets the requirement
+ of the activity
+ performed during the evaluations of the
+ components.
+
+ It may be the case that the reliance information
+ identifies that interfaces of the base component, in
+ addition to those identified as TSFIs of the base
+ component, are relied upon by the dependent component
+ are identified in the reliance information. It may be
+ necessary for guidance to be provided for the use of
+ any such additional interfaces in the base
+ component. Provided the consumer of the composed TOE
+ is to receive the guidance documentation for the base
+ component, then the results of the and
+ verdicts for the base component can be reused for
+ those interfaces considered in the evaluation of the
+ base component. However, for the additional interfaces
+ relied upon by the dependent component, the evaluator
+ will need to determine that the guidance documentation
+ for the base component meets the requirements of and , as applied in the base component
+ evaluations.
+
+ For those interfaces considered during the base
+ component evaluation, and therefore, for which
+ assurance has already been gained, the evaluator will
+ ensure that the guidance for the use of each interface
+ for the composed TOE is consistent with that provided
+ for the base component. To determine the guidance for
+ the composed TOE is consistent with that for the base
+ component, the evaluator should perform a mapping for
+ each interface to the guidance provided for both the
+ composed TOE and the base component. The evaluator
+ then compares the guidance to determine
+ consistency.
+
+ Examples of additional constraints provided in
+ composed TOE guidance that would be considered to be
+ consistent with component guidance are (guidance for a
+ component is given followed by an example of guidance
+ for a composed TOE that would be considered to provide
+ additional constraints):
+
+
+ Component: The password length must be set to a
+ minimum of 8 characters length, including
+ alphabetic and numeric characters.
+
+ Composed TOE: The password length must be set to a
+ minimum of 10 characters in length, including
+ alphabetic and numeric characters and at
+ least one of the following special characters: ( )
+ { } ^ < > - _
+
+ NOTE: It would only be acceptable to increase the
+ password length to [integer >
+ 8] characters while removing the mandate
+ for the inclusion of both alphabetic and numeric
+ characters for the composed TOE, if the same or a
+ higher metric was achieved for the strength rating
+ (taking into account the likelihood of the
+ password being guessed).
+
+ Component: The following services are to be
+ disabled in the registry settings: WWW Publishing
+ Service and ICDBReporter service.
+
+ Composed TOE: The following services are to be
+ disabled in the registry settings:
+ Publishing Service, ICDBReporter service,
+ Remote Procedure Call (RPC) Locator and Procedure
+ Call (RPC) Service.
+
+ Component: Select the following attributes to be
+ included in the accounting log files: date, time,
+ type of event, subject identity and
+ success/failure.
+
+ Composed TOE: Select the following attributes to
+ be included in the accounting log files: date,
+ time, type of event, subject identity,
+ success/failure, event message and process
+ thread.
+
+ If the guidance for the composed TOE deviates (is not
+ a refinement) from that provided for the base
+ component, the evaluator will assess the potential
+ risks of the modification to the guidance. The
+ evaluator will use the information available
+ (including that provided in the public domain, the
+ architectural description of the base component in the
+ public evaluation report (e.g. certification report),
+ the context of the guidance from the remainder of the
+ guidance documentation) to identify likely impact of
+ the modification to the guidance on the SFRs of the
+ composed TOE.
+
+ If during the dependent component evaluation the trial
+ installation used the base component to satisfy the
+ environment requirements of the dependent component
+ this work unit for the composed TOE is considered to
+ be satisfied. If the base component was not used in
+ satisfaction of the work unit during the dependent component
+ evaluation, the evaluator will apply the user
+ procedures provided for the composed TOE to prepare
+ the composed TOE, in accordance with the guidance
+ specified in . This will allow the evaluator to
+ determine that the preparative guidance provided for
+ the composed TOE is sufficient to prepare the composed
+ TOE and its operational environment securely.
+
+
+
+
+ If there is a different delivery mechanism used for
+ the delivery of the composed TOE (i.e. the
+ components are not delivered to the consumer in
+ accordance with the secure delivery procedures
+ defined and assessed during the evaluation of the
+ components), the delivery procedures for the
+ composed TOE will require evaluation against the
+ requirements
+ applied during the components evaluations.
+
+ The composed TOE may be delivered as an integrated
+ product or may require the components to be
+ delivered separately.
+
+ If the components are delivered separately, the
+ results of the delivery of the base component and
+ dependent component are reused. The delivery of the
+ base component is checked during the evaluator trial
+ installation of the dependent component, using the
+ specified guidance and checking the aspects of
+ delivery that are the responsibility of the user, as
+ described in the guidance documentation for the base
+ component.
+
+ If the composed TOE is delivered as a new entity,
+ then the method of delivery of that entity must be
+ considered in the composed TOE evaluation
+ activities.
+
+ The assessment of the delivery procedures for
+ composed TOE items is to be performed in accordance
+ with the methodology for as for any other [component] TOE,
+ ensuring any additional items (e.g. additional
+ guidance documents for the composed TOE) are
+ considered in the delivery procedures.
+
+
+
+ The unique identification of the composed TOE is
+ considered during the application of and the items from
+ which that composed TOE is comprised are considered
+ during the application of .
+
+ Although additional guidance may be produced for the
+ composed TOE, the unique identification of this
+ guidance (considered as part of the unique
+ identification of the composed TOE during ) is considered
+ sufficient control of the guidance.
+
+ The verdicts of the remaining (not considered above)
+ activities can be
+ reused from the base component evaluation, as no
+ further development is performed during integration
+ of the composed TOE.
+
+ There are no additional considerations for
+ development security as the integration is assumed
+ to take place at either the consumer's site or, in
+ the instance that the composed TOE is delivered as
+ an integrated product, at the site of the dependent
+ component developer. Control at the consumer's site
+ is outside the consideration of the CC. No
+ additional requirements or guidance are necessary if
+ integration is at the same site as that for the
+ dependent component, as all components are
+ considered to be configuration items for the
+ composed TOE, and should therefore be considered
+ under the dependent component developer's security
+ procedures anyway.
+
+ Tools and techniques adopted during integration will
+ be considered in the evidence provided by the
+ dependent component developer. Any tools/techniques
+ relevant to the base component will have been
+ considered during the evaluation of the base
+ component. For example, if the base component is
+ delivered as source code and requires compilation by
+ the consumer (e.g. dependent component developer who
+ is performing integration) the compiler would have
+ been specified and assessed, along with the
+ appropriate arguments, during evaluation of the base
+ component.
+
+ There is no life-cycle definition applicable to the
+ composed TOE, as no further development of items is
+ taking place.
+
+ The results of flaw remediation for a component are
+ not applicable to the composed TOE. If flaw
+ remediation is included in the assurance package for
+ the composed TOE, then the requirements are to be applied during
+ the composed TOE evaluation (as for any
+ augmentation).
+
+
+
+
+ The composed TOE will have been tested during the
+ conduct of the activities
+ for evaluation of the dependent component, as the
+ configurations used for testing of the dependent
+ component should have included the base component to
+ satisfy the requirements for IT in the operational
+ environment. If the base component was not used in the
+ testing of the dependent component for the dependent
+ component evaluation, or the configuration of either
+ component varied from their evaluated configurations,
+ then the developer testing performed for evaluation of
+ the dependent component to satisfy the requirements is to be repeated
+ on the composed TOE.
+
+
+
+
+
+
+
+
+ This family sets out requirements for a specification of the
+ base component in increasing levels of detail. Such
+ information is required to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component (as identified
+ in the reliance information).
+
+
+
+ provides details of the
+ base component interfaces and internals in increasing levels
+ of detail, mirroring the level of detail provided by . The application of these two
+ families will provide the specifications of security
+ services from each perspective of the TSF making the call
+ and the TSF servicing the call.
+
+ Having the two descriptions then allows a determination to
+ be made, as part of the
+ activities (.*.2E actions),
+ that these two descriptions are consistent.
+
+
+
+ The components are levelled on the basis of increasing
+ amounts of detail about the interfaces provided, and how
+ they are implemented.
+
+
+
+ The TSF of the base component is often defined without
+ knowledge of the dependencies of the possible applications
+ with which it may by composed. The TSF of this base
+ component is defined to include all parts of the base
+ component that have to be relied upon for enforcement of the
+ base component SFRs. This will include all parts of the base
+ component required to implement the base component
+ SFRs.
+
+ The functional specification of the base component will
+ describe the TSFI in terms of the interfaces the base
+ component provides to allow an external entity to invoke
+ operations of the TSF. This includes interfaces to the
+ human user to permit interaction with the operation of the
+ TSF invoking SFRs and also interfaces allowing an external
+ IT entity to make calls into the TSF.
+
+ The functional specification only provides a description of
+ what the TSF provides at its interface and the means by
+ which that TSF functionality are invoked. Therefore, the
+ functional specification does not necessarily provide a
+ complete interface specification of all possible interfaces
+ available between an external entity and the base
+ component. It does not include what the TSF expects/requires
+ from the operational environment. The description of what a
+ dependent component TSF relies upon of a base component is
+ considered in and the
+ development information evidence provides a response to the
+ interfaces specified.
+
+ The development information evidence includes a
+ specification of the base component. This may be the
+ evidence used during evaluation of the base component to
+ satisfy the requirements, or may
+ be another form of evidence produced by either the base
+ component developer or the composed TOE developer. This
+ specification of the base component is used during to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component. The level of
+ detail required of this evidence increases to reflect the
+ level of required assurance in the composed TOE. This is
+ expected to broadly reflect the increasing confidence gained
+ from the application of the assurance packages to the
+ components. The evaluator determines that this description
+ of the base component is consistent with the reliance
+ information provided for the dependent component.
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces of the base
+ component to determine that they are consistent with the
+ interfaces specified in the reliance information; those
+ required by the dependent component.
+
+ The description of the interfaces into the base component
+ is to be provided at a level of detail consistent with
+ although not all of the
+ aspects necessary for satisfaction of are required for , as once the interface has been identified
+ and the purpose described the remaining detail of the
+ interface specification can be reused from evaluation of
+ the base component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose of
+ each interface of the base component used in the composed
+ TOE.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during activity).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ In addition, the security behaviour of the base component
+ that supports the dependent component TSF is
+ described.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component, which
+ supports the enforcement of the dependent component SFRs.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component that supports the enforcement of the dependent
+ component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ The interface description of the architecture of the base
+ component is provided to enable the evaluator to determine
+ whether or not that interface formed part of the TSF of
+ the base component.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+ In addition to the interface description, the subsystems
+ of the base component that provide the security
+ functionality required by the dependent component will be
+ described to enable the evaluator to determine whether or
+ not that interface formed part of the TSF of the base
+ component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall identify the subsystems of
+ the base component that provide interfaces of the base
+ component used in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component
+ subsystems, which support the enforcement of the dependent
+ component SFRs.
+
+
+ The development information shall provide a mapping from the
+ interfaces to the subsystems of the base component.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that all subsystems of the base component
+ that provide interfaces to the dependent component are
+ identified.
+
+ For those interfaces that are considered to form part of
+ the TSFI of the base component, the subsystems
+ associated with the interface will be subsystems
+ considered in the
+ activity during the base component evaluation. The
+ interfaces on which the dependent component relies that
+ did not form part of the TSFI of the base component will
+ map to subsystems outside of the base component
+ TSF.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component subsystems that support the enforcement of the
+ dependent component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that the correspondence between the
+ interfaces and subsystems of the base component is
+ accurate.
+
+ If the TOE design and functional specification evidence
+ from the base component evaluation is available, this
+ can be used to verify the accuracy of the correspondence
+ between the interfaces and subsystems of the base
+ component as used in the composed TOE. Those interfaces
+ of the base component, which formed part of the base
+ component TSFI will be described in the base component
+ functional specification, and the associated subsystems
+ will be described in the base component TOE design
+ evidence. The tracing between the two will be provided
+ in the base component TOE design evidence.
+
+ If, however, the base component interface did not form
+ part of the TSFI of the base component, the description
+ of the subsystem behaviour provided in the development
+ information will be used to verify the accuracy of the
+ correspondence.
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+ The purpose of this family is to provide evidence that
+ describes the reliance that a dependent component has upon
+ the base component. This information is useful to persons
+ responsible for integrating the component with other
+ evaluated IT components to form the composed TOE, and for
+ providing insight into the security properties of the
+ resulting composition.
+
+ This provides a description of the interface between the
+ dependent and base components of the composed TOE that may
+ not have been analysed during evaluation of the individual
+ components, as the interfaces were not TSFIs of the
+ individual component TOEs.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant during
+ evaluation of the component, either because of the inherent
+ purpose of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces when evaluating the base component, and are in
+ addition to the security interfaces (TSFIs) considered in
+ the functional specification.
+
+
+
+ The components in this family are levelled according to the
+ amount of detail provided in the description of the reliance
+ by the dependent component upon the base component.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant in the
+ component evaluation, either because of the inherent purpose
+ of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces in the evaluation of the base component, and are
+ in addition to the security interfaces (TSFI) considered in
+ the functional specification.
+
+ In summary, the TSFIs described in the functional
+ specification only include the calls made into a TSF by
+ external entities and responses to those calls. Calls made
+ by a TSF, which were not explicitly considered during
+ evaluation of the components, are described by the reliance
+ information provided to satisfy .
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. These are
+ provided in terms of a high-level description.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF protects
+ itself from interference and tampering by the base
+ component.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. This is
+ provided in terms of the interfaces between the
+ dependent and base component and the return values from
+ those interfaces called by the dependent component.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component implementation representation;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe each interaction in
+ terms of the interface used and the return values from those
+ interfaces.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see Annex in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The reliance information shall describe each interaction
+ in terms of the interface used and the return values
+ from those interfaces.
+
+ The identification of the interfaces used by the
+ dependent component TSF when making services requests of
+ the base component allows an integrator to determine
+ whether the base component provides all the necessary
+ corresponding interfaces. This understanding is further
+ gained through the specification of the return values
+ expected by the dependent component. The evaluator
+ ensures that interfaces are described for each
+ interaction specified (as analysed in ).
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF protects
+ itself from interference and tampering by the base
+ component.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ This family requires that testing of composed TOE and
+ testing of the base component, as used in the composed TOE,
+ is performed.
+
+
+
+ The family details
+ requirements for testing to demonstrate that the composed
+ TOE operates as specified in the composed TOE SFRs and the
+ base component interfaces match the design descriptions as
+ provided in the development information (). Testing evidence is to be provided of all
+ SFRs specified in the composed TOE ST and to exercise all
+ base component interfaces used by the dependent component,
+ as identified in .
+
+
+
+ The components in this family are levelled on the basis of
+ increasing rigour of interface testing and increasing rigour
+ of the analysis of the sufficiency of the tests to
+ demonstrate that the composed TSF operates in accordance
+ with the reliance information and the composed TOE
+ SFRs.
+
+
+
+ There are two distinct aspects of testing associated with
+ this family:
+
+
+ testing of the interfaces between the base component and
+ the dependent component, which the dependent component
+ rely upon for enforcement of security functionality, to
+ demonstrate their compatibility;
+
+
+ testing of the composed TOE to demonstrate that the TOE
+ behaves in accordance with the SFRs for the composed
+ TOE.
+
+
+
+ If the test configurations used during evaluation of the
+ dependent component included use of the base component as a
+ ``platform'' and the test analysis sufficiently demonstrates
+ that the TSF behaves in accordance with the SFRs, the
+ developer need perform no further testing of the composed
+ TOE functionality. However, if the base component was not
+ used in the testing of the dependent component, or the
+ configuration of either component varied, then the developer
+ is to perform testing of the composed TOE. This may take
+ the form of repeating the dependent component developer
+ testing of the dependent component, provided this adequately
+ demonstrates the composed TOE TSF behaves in accordance with
+ the SFRs.
+
+ The developer is to provide evidence of testing the base
+ component interfaces used in the composition. The operation
+ of base component TSFIs would have been tested as part of
+ the activities during
+ evaluation of the base component. Therefore, provided the
+ appropriate interfaces were included within the test sample
+ of the base component evaluation and it was determined in
+ that the base component is
+ operating in accordance with the base component evaluated
+ configuration, with all security functionality required by
+ the dependent component included in the TSF, the evaluator
+ action may be met
+ through reuse of the base component verdicts.
+
+ If this is not the case, the base component interfaces used
+ relevant to the composition that are affected by any
+ variations to the evaluated configuration and any additional
+ security functionally will be tested to ensure they
+ demonstrate the expected behaviour. The expected behaviour
+ to be tested is that described in the reliance information
+ ( evidence).
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to ensure the expected behaviour of all composed TOE SFRs
+ and interfaces of the base component relied upon by the
+ dependent component is demonstrated.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the SFRs specified
+ for the composed TOE to identify which SFRs have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the interfaces of
+ the base component relied upon by the dependent
+ component (as specified in the reliance information,
+ examined under ) to
+ identify which base component interfaces have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to verify the
+ developer test results.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to confirm that the
+ TSF operates as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to fully demonstrate the expected behaviour of the
+ composed TOE and the interfaces of the base component
+ relied upon by the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified and is complete.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified and is complete.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the composed TOE and the composed TOE
+ SFRs in the composed TOE security target.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and SFRs presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the base component interfaces relied upon
+ by the dependent component and the interfaces specified
+ in the reliance information.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and interfaces presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The tests are to be selected and executed in accordance
+ with , to
+ demonstrate the correct behaviour of the SFRs specified
+ in the composed TOE security target.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to confirm that the
+ TSF operates as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+ The evaluator shall perform testing, in accordance with
+ , for a subset of the
+ interfaces to the base component to confirm they operate
+ as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the base component to test,
+ the evaluator should take into account any modifications
+ to the base component from the evaluated version or
+ configuration. In particular, the evaluator should
+ consider the development of tests to demonstrate the
+ correct behaviour of interfaces of the base component
+ that were not considered during the evaluation of the
+ base component. These additional interfaces and other
+ modifications to the base component will have been
+ identified during the
+ activity.
+
+
+
+
+
+
+
+ This family calls for an analysis of vulnerability
+ information available in the public domain and of
+ vulnerabilities that may be introduced as a result of the
+ composition.
+
+
+
+ The vulnerability analysis in includes determination of two different
+ aspects of resistance by the composed TOE, namely:
+
+
+ Residual vulnerabilities in the base and dependent
+ components remain unexploitable in the operational
+ environment of the composed TOE;
+
+ The composed TOE is resistant to attackers with a given
+ level of attack potential.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing scrutiny of vulnerability information from the
+ public domain and independent vulnerability analysis.
+
+
+
+ The developer will provide details of any residual
+ vulnerabilities reported during evaluation of the
+ components. These may be gained from the component
+ developers or evaluation reports for the components. These
+ will be used as inputs into the evaluator's vulnerability
+ analysis of the composed TOE in the operational
+ environment.
+
+
+ The operational environment of the composed TOE is examined
+ to ensure that the assumptions and objectives for the
+ component operational environment (specified in each
+ component ST) are satisfied in the composed TOE. An initial
+ analysis of the consistency of assumptions and objectives
+ between the components and the composed TOE STs will have
+ been performed during the conduct of the activities for the composed TOE. However, this
+ analysis is revisited with the knowledge acquired during the
+ , and the
+ activities to ensure that, for example, assumptions of the
+ dependent component that were addressed by the environment
+ in the dependent component ST are not reintroduced as a
+ result of composition (i.e. that the base component
+ adequately addresses the assumptions of the dependent
+ component ST in the composed TOE).
+
+ A search by the evaluator for issues in each component will
+ identify potential vulnerabilities reported in the public
+ domain since completion of the evaluation of the components.
+ Any potential vulnerabilities will then be subject to
+ testing.
+
+ If the base component used in the composed TOE has been the
+ subject of assurance continuity activities since
+ certification, the evaluator will consider during the
+ composed TOE vulnerability analysis activities the changes
+ made in base component.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ easily exploitable vulnerabilities.
+
+ The developer provides details of any residual
+ vulnerabilities reported from evaluation of the
+ components. The evaluator performs an analysis of the
+ disposition the residual vulnerabilities reported and also
+ performs a search of the public domain, to identify any
+ new potential vulnerabilities in the components
+ (i.e. those issues that have been reported in the public
+ domain since evaluation of the base component). The
+ evaluator then performs penetration testing to demonstrate
+ that the potential vulnerabilities cannot be exploited in
+ the TOE, in its operational environment, by an attacker
+ with basic attack potential.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities;
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes a component from the
+ family, then the
+ evaluator may refer to the result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the base component
+ that have become known since the completion of
+ evaluation of the base component.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the
+ dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (i.e. ), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing basic
+ attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the evaluation
+ of the components). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information publicly
+ available to support the identification of possible security
+ vulnerabilities in the base component that have become known
+ since the completion of the base component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public domain as
+ described in to search for
+ vulnerabilities in the dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components of the composed TOE
+ in the independent evaluator vulnerability analysis will
+ take a slightly different form to that documented in
+ for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the components, but the evidence may
+ not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the individual
+ components. The focus of the vulnerability analysis
+ during the composed TOE evaluation is to identify any
+ vulnerabilities introduced as a result of the
+ integration of the components or due to any changes in
+ the use of the components between the evaluated
+ component configuration to the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ development information and composition rationale for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact and
+ identify potential vulnerabilities that may be
+ introduced as a result of this interaction.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch(es) in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report) will be the main source of
+ input material of the change. This will be supplemented
+ by any updates to the guidance documentation resulting
+ from the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether the
+ composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Enhanced-Basic attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the component
+ evaluations). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information publicly
+ available to support the identification of possible security
+ vulnerabilities in the base component that have become known
+ since the completion of the base component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since completion of the
+ dependent component evaluation.
+
+ The evaluator will use the information in the public domain as
+ described in to search for
+ vulnerabilities in the dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components in the independent
+ evaluator vulnerability analysis will take a slightly
+ different form to that documented in for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the base component, but the evidence
+ may not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the components. The focus
+ of the vulnerability analysis during the composed TOE
+ evaluation is to identify any vulnerabilities introduced
+ as a result of the integration of the components or due
+ to any changes in the use of the components between the
+ configuration of the component determined during the
+ component evaluation and the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ composition rationale and development information for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report). This will be supplemented by
+ any updates to the guidance documentation resulting from
+ the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on the
+ identified vulnerabilities, to demonstrate that the composed TOE
+ is resistant to attacks by an attacker with Enhanced-Basic
+ attack potential.
+
+ The evaluator shall conduct penetration testing as detailed
+ for .
+ The evaluator will apply all work units necessary for the
+ satisfaction of evaluator action , reporting in the ETR for the composed TOE all
+ analysis and verdicts as dictated by the work units.
+ The evaluator will also apply the work units for the
+ evaluator action to
+ determine that the composed TOE provided by the developer is
+ suitable for testing.
+
+
+
+
+
+
+ The requirements of the Development class provide information
+ about the TOE. The knowledge obtained by this information is
+ used as the basis for conducting vulnerability analysis and
+ testing upon the TOE, as described in the and classes.
+
+ The Development class encompasses six families of requirements
+ for structuring and representing the TSF at various levels and
+ varying forms of abstraction. These families include:
+
+ requirements for the description (at the various
+ levels of abstraction) of the design and implementation of
+ the SFRs (, , )
+ requirements for the description of the
+ architecture-oriented features of domain separation, TSF
+ self-protection and non-bypassability of the security
+ functionality ()
+ requirements for a security policy model and for correspondence
+ mappings between security policy model and the functional
+ specification ()
+ requirements on the internal structure of the TSF,
+ which covers aspects such as modularity, layering, and
+ minimisation of complexity ()
+
+ When documenting the security functionality of a TOE, there
+ are two properties that need to be demonstrated. The first
+ property is that the security functionality works correctly;
+ that is, it performs as specified. The second property, and
+ one that is arguably harder to demonstrate, is that the TOE
+ cannot be used in a way such that the security functionality
+ can be corrupted or bypassed. These two properties require
+ somewhat different approaches in analysis, and so the families
+ in are structured to support these
+ different approaches. The families , , , and deal with the first property: the specification
+ of the security functionality. The families and deal with
+ the second property: the specification of the design of the
+ TOE demonstrating the security functionality cannot be
+ corrupted or bypassed. It should be noted that both properties
+ need to be realised: the more confidence one has that the
+ properties are satisfied, the more trustworthy the TOE is. The
+ components in the families are designed so that more assurance
+ can be gained as the components hierarchically
+ increase.
+
+ The paradigm for the families targeted at the first property
+ is one of design decomposition. At the highest level, there is
+ a functional specification of the TSF in terms of its
+ interfaces (describing what the TSF does in
+ terms of requests to the TSF for services and resulting
+ responses), decomposing the TSF into smaller units (dependent
+ on the assurance desired and the complexity of the TOE) and
+ describing how the TSF accomplishes its
+ functions (to a level of detail commensurate with the
+ assurance level), and showing the implementation of the TSF. A
+ formal model of the security behaviour also may be given. All
+ levels of decomposition are used in determining the
+ completeness and accuracy of all other levels, ensuring that
+ the levels are mutually supportive. The requirements for the
+ various TSF representations are separated into different
+ families, to allow the PP/ST author to specify which TSF
+ representations are required. The level chosen will dictate
+ the assurance desired/gained.
+
+ Figure indicates the
+ relationships among the various TSF representations of the
+ class, as well as their
+ relationships with other classes. As the figure indicates, the
+ and
+ classes define the requirements for the correspondence between
+ the SFRs and the security objectives for the TOE. Class also defines requirements for the
+ correspondence between both the security objectives and SFRs,
+ and for the TOE summary specification which explains how the
+ TOE meets its SFRs. The activities of include the verification that the TSF that is
+ tested under the and classes is in fact the one described by all of the
+ decomposition levels.
+
+
+ The requirements for all other correspondence shown in Figure
+ are defined in the
+ class. The family defines the requirements for formally
+ modelling selected SFRs, and providing correspondence between
+ the functional specification and the formal model. Each
+ assurance family specific to a TSF representation (i.e., ,
+ and ) defines requirements
+ relating that TSF representation to the SFRs. All
+ decompositions must accurately reflect all other
+ decompositions (i.e., be mutually supportive); the developer
+ supplies the tracings in the last .C elements of the
+ components. Assurance relating to this factor is obtained
+ during the analysis for each of the levels of decomposition by
+ referring to other levels of decomposition (in a recursive
+ fashion) while the analysis of a particular level of
+ decomposition is being performed; the evaluator verifies the
+ correspondence as part of the second E element. The
+ understanding gained from these levels of decomposition form
+ the basis of the functional and penetration testing
+ efforts.
+
+ The family is not represented
+ in this figure, as it is related to the internal structure of
+ the TSF, and is only indirectly related to the process of
+ refinement of the TSF representations. Similarly, the family is not represented in the
+ figure because it relates to the architectural soundness,
+ rather than representation, of the TSF. Both and
+ relate to the analysis of the property that the TOE cannot be
+ made to circumvent or corrupt its security
+ functionality.
+
+ The TOE security functionality (TSF) consists of all parts of
+ the TOE that have to be relied upon for enforcement of the
+ SFRs. The TSF includes both functionality that directly
+ enforces the SFRs, as well as functionality that, while not
+ directly enforcing the SFRs, contributes to their enforcement
+ in a more indirect manner, including functionality with the
+ capability to cause the SFRs to be violated. This includes
+ portions of the TOE that are invoked on start-up that are
+ responsible for putting the TSF into its initial secure
+ state.
+
+ Several important concepts were used in the development of the
+ components of the families. These
+ concepts, while introduced briefly here, are explained more
+ fully in the application notes for the families.
+
+ One over-riding notion is that, as more information becomes
+ available, greater assurance can be obtained that the security
+ functionality 1) is correctly implemented; 2) cannot be
+ corrupted; and 3) cannot be bypassed. This is done through the
+ verification that the documentation is correct and consistent
+ with other documentation, and by providing information that
+ can be used to ensure that the testing activities (both
+ functional and penetration testing) are comprehensive. This is
+ reflected in the levelling of the components of the
+ families. In general, components are levelled based on the
+ amount of information that is to be provided (and subsequently
+ analysed).
+
+ While not true for all TOEs, it is generally the case that the
+ TSF is sufficiently complex that there are portions of the TSF
+ that deserve more intense examination than other portions of
+ the TSF. Determining those portions is unfortunately somewhat
+ subjective, thus terminology and components have been defined
+ such that as the level of assurance increases, the
+ responsibility for determining what portions of the TSF need
+ to be examined in detail shifts from the developer to the
+ evaluator. To aid in expressing this concept, the following
+ terminology is introduced. It should be noted that in the
+ families of the class, this terminology is used when
+ expressing SFR-related portions of the TOE (that is, elements
+ and work units embodied in the , , and families). While the general
+ concept (that some portions of the TOE are more
+ interesting than others) applies to other
+ families, the criteria are expressed differently in order to
+ obtain the assurance required.
+
+ All portions of the TSF are security
+ relevant, meaning that they must preserve the
+ security of the TOE as expressed by the SFRs and
+ requirements for domain separation and
+ non-bypassability. One aspect of security relevance is the
+ degree to which a portion of the TSF enforces a security
+ requirement. Since different portions of the TOE play
+ different roles (or no apparent role at all) in enforcing
+ security requirements, this creates a continuum of SFR
+ relevance: at one end of this continuum are portions of the
+ TOE that are termed SFR-enforcing. Such
+ portions play a direct role in implementing any SFR on the
+ TOE. Such SFRs refer to any functionality provided by one of
+ the SFRs contained in the ST. It should be noted that the
+ definition of plays a role in for
+ SFR-enforcing functionality is impossible to express
+ quantitatively. For example, in the implementation of a
+ Discretionary Access Control (DAC) mechanism, a very narrow
+ view of SFR-enforcing might be the several
+ lines of code that actually perform the check of a subject's
+ attributes against the object's attributes. A broader view
+ would include the software entity (e.g., C function) that
+ contained the several lines of code. A broader view still
+ would include callers of the C function, since they would be
+ responsible for enforcing the decision returned by the
+ attribute check. A still broader view would include any code
+ in the call tree (or programming equivalent for the
+ implementation language used) for that C function (e.g., a
+ sort function that sorted access control list entries in a
+ first-match algorithm implementation). At some point, the
+ component is not so much enforcing the
+ security policy but rather plays a
+ supporting role; such components are termed
+ SFR supporting.
+
+ One of the characteristics of SFR-supporting functionality is
+ that it is trusted to preserve the correctness of the SFR
+ implementation by operating without error. Such functionality
+ may be depended on by SFR-enforcing functionality, but the
+ dependence is generally at a functional level; for example,
+ memory management, buffer management, etc. Further down on the
+ security relevance continuum is functionality termed
+ SFR non-interfering. Such functionality has
+ no role in implementing the SFRs, and is likely part of the
+ TSF because of its environment; for example, any code running
+ in a privileged hardware mode on an operating system. It needs
+ to be considered part of the TSF because, if compromised (or
+ replaced by malicious code), it could compromise the correct
+ operation of an SFR by virtue of its operating in the
+ privileged hardware mode. An example of SFR non-interfering
+ functionality might be a set of mathematical floating point
+ operations implemented in kernel mode for speed
+ considerations.
+
+ The architecture family ()
+ provides for requirements and analysis of the TOE based on
+ properties of domain separation, self-protection, and
+ non-bypassability. These properties relate to the SFRs in
+ that, if these properties are not present, it will likely lead
+ to the failure of mechanisms implementing SFRs. Functionality
+ and design relating to these properties is
+ not considered a part of the continuum described
+ above, but instead is treated separately due to its
+ fundamentally different nature and analysis
+ requirements.
+
+ The difference in analysis of the implementation of SFRs
+ (SFR-enforcing and SFR-supporting functionality) and the
+ implementation of somewhat fundamental security properties of
+ the TOE, which include the initialisation, self-protection,
+ and non-bypassability concerns, is that the SFR-related
+ functionality is more or less directly visible and relatively
+ easy to test, while the above-mentioned properties require
+ varying degrees of analysis on a much broader set of
+ functionality. Further, the depth of analysis for such
+ properties will vary depending on the design of the TOE. The
+ families are constructed to address
+ this by a separate family ()
+ devoted to analysis of the initialisation, self-protection,
+ and non-bypassability requirements, while the other families
+ are concerned with analysis of the functionality supporting
+ SFRs.
+
+ Even in cases where different descriptions are necessary for
+ the multiple levels of abstraction, it is not absolutely
+ necessary for each and every TSF representation to be in a
+ separate document. Indeed, it may be the case that a single
+ document meets the documentation requirements for more than
+ one TSF representation, since it is the information about each
+ of these TSF representations that is required, rather than the
+ resulting document structure. In cases where multiple TSF
+ representations are combined within a single document, the
+ developer should indicate which portions of the documents meet
+ which requirements.
+
+ Three types of specification style are mandated by this class:
+ informal, semiformal and formal. The functional specification
+ and TOE design documentation are always written in either
+ informal or semiformal style. A semiformal style reduces the
+ ambiguity in these documents over an informal presentation. A
+ formal specification may also be required in addition
+ to the semi-formal presentation; the value is that a
+ description of the TSF in more than one way will add increased
+ assurance that the TSF has been completely and accurately
+ specified.
+
+ An informal specification is written as prose in natural
+ language. Natural language is used here as meaning
+ communication in any commonly spoken tongue (e.g. Spanish,
+ German, French, English, Dutch). An informal specification is
+ not subject to any notational or special restrictions other
+ than those required as ordinary conventions for that language
+ (e.g. grammar and syntax). While no notational restrictions
+ apply, the informal specification is also required to provide
+ defined meanings for terms that are used in a context other
+ than that accepted by normal usage.
+
+ The difference between semiformal and informal documents is
+ only a matter of formatting or presentation: a semiformal
+ notation includes such things as an explicit glossary of
+ terms, a standardised presentation format, etc. A semiformal
+ specification is written to a standard presentation
+ template. The presentation should use terms consistently if
+ written in a natural language. The presentation may also use
+ more structured languages/diagrams (e.g. data-flow diagrams,
+ state transition diagrams, entity-relationship diagrams, data
+ structure diagrams, and process or program structure
+ diagrams). Whether based on diagrams or natural language, a
+ set of conventions must be used in the presentation. The
+ glossary explicitly identifies the words that are being used
+ in a precise and constant manner; similarly, the standardised
+ format implies that extreme care has been taken in
+ methodically preparing the document in a manner that maximises
+ clarity. It should be noted that fundamentally different
+ portions of the TSF may have different semiformal notation
+ conventions and presentation styles (as long as the number of
+ different ``semiformal notations'' is small); this still
+ conforms to the concept of a semiformal
+ presentation.
+
+ A formal specification is written in a notation based upon
+ well-established mathematical concepts, and is typically
+ accompanied by supporting explanatory (informal) prose. These
+ mathematical concepts are used to define the syntax and
+ semantics of the notation and the proof rules that support
+ logical reasoning. The syntactic and semantic rules supporting
+ a formal notation should define how to recognise constructs
+ unambiguously and determine their meaning. There needs to be
+ evidence that it is impossible to derive contradictions, and
+ all rules supporting the notation need to be defined or
+ referenced.
+
+
+
+ The purpose of the Development class is to provide evidence
+ about the TOE. Without the knowledge about the TOE that is
+ gained from this information, there could be no useful
+ vulnerability analysis or testing conducted upon the TOE (as
+ described in the and classes).
+
+
+ The purpose of the development activity is to assess the
+ design documentation in terms of its adequacy to understand
+ how the TSF meets the SFRs and how the implementation of these
+ SFRs cannot be tampered with or bypassed. This understanding
+ is achieved through examination of increasingly refined
+ descriptions of the TSF design documentation. Design
+ documentation consists of a functional specification (which
+ describes the interfaces of the TSF), a TOE design description
+ (which describes the architecture of the TSF in terms of how
+ it works in order to perform the functions related to the SFRs
+ being claimed), and an implementation description (a source
+ code level description). In addition, there is a security
+ architecture description (which describes the architectural
+ properties of the TSF to explain how its security enforcement
+ cannot be compromised or bypassed), an internals description
+ (which describes how the TSF was constructed in a manner that
+ encourages understandability), and a security policy model
+ (which formally describes the security policies enforced by
+ the TSF).
+
+
+
+ The CC requirements for design documentation are levelled by
+ the amount, and detail of information provided, and the degree
+ of formality of the presentation of the information. At lower
+ levels, the most security-critical portions of the TSF are
+ described with the most detail, while less security-critical
+ portions of the TSF are merely summarised; added assurance is
+ gained by increasing the amount of information about the most
+ security-critical portions of the TSF, and increasing the
+ details about the less security-critical portions. The most
+ assurance is achieved when thorough details and information of
+ all portions are provided.
+
+ The CC considers a document's degree of formality (that is,
+ whether it is informal or semiformal) to be hierarchical. An
+ informal document is one that is expressed in a natural
+ language. The methodology does not dictate the specific
+ language that must be used; that issue is left for the
+ scheme. The following paragraphs differentiate the contents of
+ the different informal documents.
+
+ A functional specification provides a description of the
+ purpose and method-of-use of interfaces to the TSF. For
+ example, if an operating system presents the user with a means
+ of self-identification, of creating files, of modifying or
+ deleting files, of setting permissions defining what other
+ users may access files, and of communicating with remote
+ machines, its functional specification would contain
+ descriptions of each of these and how they are realised
+ through interactions with the externally-visible interfaces to
+ the TSF. If there is also audit functionality that detects and
+ record the occurrences of such events, descriptions of this
+ audit functionality would also be expected to be part of the
+ functional specification; while this functionality is
+ technically not directly invoked by the user at the external
+ interface, it certainly is affected by what occurs at the
+ user's external interface.
+
+ A design description is expressed in terms of logical
+ divisions (subsystems or modules) that each provide a
+ comprehensible service or function. For example, a firewall
+ might be composed of subsystems that deal with packet
+ filtering, with remote administration, with auditing, and with
+ connection-level filtering. The design description of the
+ firewall would describe the actions that are taken, in terms
+ of what actions each subsystem takes when an incoming packet
+ arrives at the firewall.
+
+
+
+
+ The objective of this family is for the developer to provide
+ a description of the security architecture of the TSF. This
+ will allow analysis of the information that, when coupled
+ with the other evidence presented for the TSF, will confirm
+ the TSF achieves the desired properties. The security
+ architecture descriptions supports the implicit claim that
+ security analysis of the TOE can be achieved by examining
+ the TSF; without a sound architecture, the entire TOE
+ functionality would have to be examined.
+
+
+
+ The information presented for the security architecture of
+ the TOE is related to the information contained in other
+ decomposition documentation (functional specification and
+ TOE design documentation) provided for the TSF, but presents
+ the design in a manner that supports architectural arguments
+ (e.g., the TSF cannot be compromised; the TSF provides
+ security domains consistent with its SFRs; the TSF cannot be
+ bypassed).
+
+
+
+ This family contains only one component.
+
+
+
+ The properties of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed by Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the TSF
+ that are achieved through the design of the TOE and TSF, and
+ enforced by the correct implementation of that
+ design.
+
+ The approach used in this family is for the developer to
+ design and provide a TSF that exhibits the above-mentioned
+ properties, and to provide evidence (in the form of
+ documentation) that explains these properties of the
+ TSF. This explanation is provided at the same level of
+ detail as the description of the SFR-enforcing elements of
+ the TOE in the TOE design document. The evaluator has the
+ responsibility for looking at the evidence and, coupled with
+ other evidence delivered for the TOE and TSF, determining
+ that the properties are achieved.
+
+ Specification of security functionality implementing the
+ SFRs (in the and ) will not necessarily describe
+ mechanisms employed in implementing self-protection and
+ non-bypassability (e.g. memory management
+ mechanisms). Therefore, the material needed to provide the
+ assurance that these requirements are being achieved is
+ better suited to a presentation separate from the design
+ decomposition of the TSF as embodied in and . This is not
+ to imply that the security architecture description called
+ for by this component cannot reference or make use of the
+ design decomposition material; but it is likely that much of
+ the detail present in the decomposition documentation will
+ not be relevant to the argument being provided for the
+ security architecture description document.
+
+ The description of architectural soundness can be thought of
+ as a developer's vulnerability analysis, in that it provides
+ the justification for why the TSF is sound and enforces all
+ of its SFRs. Where the soundness is achieved through
+ specific security mechanisms, these will be tested as part
+ of the requirements; where
+ the soundness is achieved solely through the architecture,
+ the behaviour will be tested as part of the requirements.
+
+ This family consists of requirements for a security
+ architecture description that describes the self-protection,
+ domain separation, non-bypassability principles, including a
+ description of how these principles are supported by the
+ parts of the TOE that are used for TSF
+ initialisation.
+ Additional information on the security architecture
+ properties of self-protection, domain separation, and
+ non-bypassability can be found in Annex .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is structured such that it cannot be tampered with
+ or bypassed, and whether TSFs that provide security
+ domains isolate those domains from each other.
+
+
+
+ The notions of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed in Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the
+ TSF that are achieved through the design of the TOE, and
+ enforced by the correct implementation of that
+ design. Also, the evaluation of these properties is less
+ straight-forward than the evaluation of mechanisms; it is
+ more difficult to check for the absence of functionality
+ than for its presence. However, the determination that
+ these properties are being satisfied is just as critical
+ as the determination that the mechanisms are properly
+ implemented.
+
+ The overall approach used is that the developer provides a
+ TSF that meets the above-mentioned properties, and
+ provides evidence (in the form of documentation) that can
+ be analysed to show that the properties are indeed
+ met. The evaluator has the responsibility for looking at
+ the evidence and, coupled with other evidence delivered
+ for the TOE, determining that the properties are
+ achieved. The work units can be characterised as those
+ detailing with what information has to be provided, and
+ those dealing with the actual analysis the evaluator
+ performs.
+
+ The security architecture description describes how
+ domains are defined and how the TSF keeps them
+ separate. It describes what prevents untrusted processes
+ from getting to the TSF and modifying it. It describes
+ what ensures that all resources under the TSF's control
+ are adequately protected and that all actions related to
+ the SFRs are mediated by the TSF. It explains any role the
+ environment plays in any of these (e.g. presuming it gets
+ correctly invoked by its underlying environment, how is
+ its security functionality invoked?). In short, it
+ explains how the TOE is considered to be providing any
+ kind of security service.
+
+ The analyses the evaluator performs must be done in the
+ context of all of the development evidence provided for
+ the TOE, at the level of detail the evidence is
+ provided. At lower assurance levels there should not be
+ the expectation that, for example, TSF self-protection is
+ completely analysed, because only high-level design
+ representations will be available. The evaluator also
+ needs to be sure to use information gleaned from other
+ portions of their analysis (e.g., analysis of the TOE
+ design) in making their assessments for the properties
+ being examined in the following work units.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation (if available);
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall design and implement the TOE so that the
+ security features of the TSF cannot be bypassed.
+
+
+ The developer shall design and implement the TSF so that it
+ is able to protect itself from tampering by untrusted active
+ entities.
+
+
+ The developer shall provide a security architecture
+ description of the TSF.
+
+
+ The security architecture description shall be at a level of
+ detail commensurate with the description of the
+ SFR-enforcing abstractions described in the TOE design
+ document.
+
+
+ The security architecture description shall describe the
+ security domains maintained by the TSF consistently with the
+ SFRs.
+
+
+ The security architecture description shall describe how the
+ TSF initialisation process is secure.
+
+
+ The security architecture description shall demonstrate that
+ the TSF protects itself from tampering.
+
+
+ The security architecture description shall demonstrate that
+ the TSF prevents bypass of the SFR-enforcing functionality.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the information provided
+ in the evidence is presented at a level of detail
+ commensurate with the descriptions of the SFR-enforcing
+ abstractions contained in the functional specification
+ and TOE design document.
+
+ With respect to the functional specification, the
+ evaluator should ensure that the self-protection
+ functionality described cover those effects that are
+ evident at the TSFI. Such a description might include
+ protection placed upon the executable images of the TSF,
+ and protection placed on objects (e.g., files used by
+ the TSF). The evaluator ensures that the functionality
+ that might be invoked through the TSFI is
+ described.
+
+ If or is included, the evaluator
+ ensures the security architecture description contains
+ information on how any subsystems that contribute to TSF
+ domain separation work.
+
+ If or higher is
+ available, the evaluator ensures that the security
+ architecture description also contains
+ implementation-dependent information. For example, such
+ a description might contain information pertaining to
+ coding conventions for parameter checking that would
+ prevent TSF compromises (e.g. buffer overflows), and
+ information on stack management for call and return
+ operations. The evaluator checks the descriptions of the
+ mechanisms to ensure that the level of detail is such
+ that there is little ambiguity between the description
+ in the security architecture description and the
+ implementation representation.
+
+ The evaluator action related to this work unit is assigned a fail verdict
+ if the security architecture description mentions any module, subsystem, or interface
+ that is not described in the functional specification or TOE design document.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it describes the security
+ domains maintained by the TSF.
+
+ Security domains refer to environments supplied by the
+ TSF for use by potentially-harmful entities; for
+ example, a typical secure operating system supplies a
+ set of resources (address space, per-process environment
+ variables) for use by processes with limited access
+ rights and security properties. The evaluator determines
+ that the developer's description of the security domains
+ takes into account all of the SFRs claimed by the
+ TOE.
+
+ For some TOEs such domains do not exist because all of
+ the interactions available to users are severely
+ constrained by the TSF. A packet-filter firewall is an
+ example of such a TOE. Users on the LAN or WAN do not
+ interact with the TOE, so there need be no security
+ domains; there are only data structures maintained by
+ the TSF to keep the users' packets separated. The
+ evaluator ensures that any claim that there are no
+ domains is supported by the evidence and that no such
+ domains are, in fact, available.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the initialisation process
+ preserves security.
+
+ The information provided in the security architecture
+ description relating to TSF initialisation is directed
+ at the TOE components that are involved in bringing the
+ TSF into an initial secure state (i.e. when all parts of
+ the TSF are operational) when power-on or a reset is
+ applied. This discussion in the security architecture
+ description should list the system initialisation
+ components and the processing that occurs in
+ transitioning from the ``down'' state to the initial
+ secure state.
+
+ It is often the case that the components that perform
+ this initialisation function are not accessible after
+ the secure state is achieved; if this is the case then
+ the security architecture description identifies the components and
+ explains how they are not reachable by untrusted
+ entities after the TSF has been established. In this
+ respect, the property that needs to be preserved is that
+ these components either 1) cannot be accessed by
+ untrusted entities after the secure state is achieved,
+ or 2) if they provide interfaces to untrusted entities,
+ these TSFI cannot be used to tamper with the TSF.
+
+ The TOE components related to TSF initialisation, then,
+ are treated themselves as part of the TSF, and analysed
+ from that perspective. It should be noted that even
+ though these are treated as part of the TSF, it is
+ likely that a justification (as allowed by ) can be made that they do not
+ have to meet the internal structuring requirements of
+ .
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it contains information
+ sufficient to support a determination that the TSF is
+ able to protect itself from tampering by untrusted
+ active entities.
+
+ ''Self-protection'' refers to the ability of the TSF to
+ protect itself from manipulation from external entities
+ that may result in changes to the TSF. For TOEs that
+ have dependencies on other IT entities, it is often the
+ case that the TOE uses services supplied by the other IT
+ entities in order to perform its functions. In such
+ cases, the TSF alone does not protect itself because it
+ depends on the other IT entities to provide some of the
+ protection. For the purposes of the security
+ architecture description, the notion of
+ self-protection applies only to the
+ services provided by the TSF through its TSFI, and not
+ to services provided by underlying IT entities that it
+ uses.
+
+ Self-protection is typically achieved by a variety of
+ means, ranging from physical and logical restrictions on
+ access to the TOE; to hardware-based means (e.g.
+ ``execution rings'' and memory management
+ functionality); to software-based means (e.g. boundary
+ checking of inputs on a trusted server). The evaluator
+ determines that all such mechanisms are
+ described.
+
+ The evaluator determines that the design description
+ covers how user input is handled by the TSF in such a
+ way that the TSF does not subject itself to being
+ corrupted by that user input. For example, the TSF might
+ implement the notion of privilege and protect itself by
+ using privileged-mode routines to handle user input. The
+ TSF might make use of processor-based separation
+ mechanisms such as privilege levels or rings. The TSF
+ might implement software protection constructs or coding
+ conventions that contribute to implementing separation of
+ software domains, perhaps by delineating user address
+ space from system address space. And the TSF might have
+ reliance its environment to provide some support to the
+ protection of the TSF.
+
+ All of the mechanisms contributing to the domain
+ separation functions are described. The evaluator should
+ use knowledge gained from other evidence (functional
+ specification, TOE design, TSF internals description,
+ other parts of the security architecture description, or
+ implementation representation, as included in the
+ assurance package for the TOE) in determining if any
+ functionality contributing to self-protection was
+ described that is not present in the security
+ architecture description.
+
+ Accuracy of the description of the self-protection mechanisms is the property that the
+ description faithfully describes what is implemented. The evaluator should use other
+ evidence (functional specification, TOE design, TSF Internals documentation, other parts
+ of the security architecture description, implementation representation, as included in
+ the ST for the TOE) in determining whether there are discrepancies in any descriptions
+ of the self-protection mechanisms. If
+
+ is included in the assurance package for the TOE, the evaluator will choose a sample of
+ the implementation representation; the evaluator should also ensure that the descriptions
+ are accurate for the sample chosen. If an evaluator cannot understand how a certain
+ self-protection mechanism works or could work in the system architecture, it may be the
+ case that the description is not accurate.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it presents an analysis
+ that adequately describes how the SFR-enforcing
+ mechanisms cannot be bypassed.
+
+ Non-bypassability is a property that the security
+ functionality of the TSF (as specified by the SFRs) is
+ always invoked. For example, if access control to files
+ is specified as a capability of the TSF via an SFR,
+ there must be no interfaces through which files can be
+ accessed without invoking the TSF's access control
+ mechanism (such as an interface through which a raw disk
+ access takes place).
+
+ Describing how the TSF mechanisms cannot be bypassed
+ generally requires a systematic argument based on the
+ TSF and the TSFIs. The description of how the TSF works
+ (contained in the design decomposition evidence, such as
+ the functional specification, TOE design documentation)
+ - along with the information in the TSS - provides the
+ background necessary for the evaluator to understand
+ what resources are being protected and what security
+ functions are being provided. The functional
+ specification provides descriptions of the TSFIs through
+ which the resources/functions are accessed.
+
+ The evaluator assesses the description provided (and other
+ information provided by the developer, such as the functional
+ specification) to ensure that no available interface can be used
+ to bypass the TSF. This means that every available interface
+ must be either unrelated to the SFRs that are claimed in the ST
+ (and does not interact with anything that is used to satisfy
+ SFRs) or else uses the security functionality that is described
+ in other development evidence in the manner described. For
+ example, a game would likely be unrelated to the SFRs, so there
+ must be an explanation of how it cannot affect security. Access
+ to user data, however, is likely to be related to access control
+ SFRs, so the explanation would describe how the security
+ functionality works when invoked through the data-access
+ interfaces. Such a description is needed for every available
+ interface.
+
+ An example of a description follows. Suppose the TSF
+ provides file protection. Further suppose that although
+ the ``traditional'' system call TSFIs for open, read,
+ and write invoke the file protection mechanism described
+ in the TOE design, there exists a TSFI that allows
+ access to a batch job facility (creating batch jobs,
+ deleting jobs, modifying unprocessed jobs). The
+ evaluator should be able to determine from the
+ vendor-provided description that this TSFI invokes the
+ same protection mechanisms as do the ``traditional''
+ interfaces. This could be done, for example, by
+ referencing the appropriate subclauses of the TOE design
+ that discuss how the batch job facility
+ TSFI achieves its security objectives.
+
+ Using this same example, suppose there is a TSFI whose
+ sole purpose is to display the time of day. The
+ evaluator should determine that the description
+ adequately argues that this TSFI is not capable of
+ manipulating any protected resources and should not
+ invoke any security functionality.
+
+ Another example of bypass is when the TSF is supposed to
+ maintain confidentiality of a cryptographic key (one is
+ allowed to use it for cryptographic operations, but is
+ not allowed to read/write it). If an attacker has direct
+ physical access to the device, he might be able to
+ examine side-channels such as the power usage of the
+ device, the exact timing of the device, or even any
+ electromagnetic emanations of the device and, from this,
+ infer the key.
+
+ If such side-channels may be present, the demonstration
+ should address the mechanisms that prevent these
+ side-channels from occurring, such as random internal
+ clocks, dual-line technology etc. Verification of these
+ mechanisms would be verified by a combination of purely
+ design-based arguments and testing.
+
+ For a final example using security functionality rather
+ than a protected resource, consider an ST that contains
+ , which requires that
+ the TSF provides evidence of origination for information
+ types specified in the ST. Suppose that the
+ ``information types'' included all information that is
+ sent by the TOE via e-mail. In this case the evaluator
+ should examine the description to ensure that all TSFI
+ that can be invoked to send e-mail perform the
+ ``evidence of origination generation'' function are
+ detailed. The description might point to user guidance
+ to show all places where e-mail can originate (e.g.,
+ e-mail program, notification from scripts/batch jobs)
+ and then how each of these places invokes the evidence
+ generation function.
+
+ The evaluator should also ensure that the description is comprehensive, in that each
+ interface is analysed with respect to the entire set of claimed SFRs. This may require the
+ evaluator to examine supporting information (functional specification, TOE design, other
+ parts of the security architecture description, operational user guidance, and perhaps even
+ the implementation representation, as provided for the TOE) to determine that the description
+ has correctly capture all aspects of an interface. The evaluator should consider what SFRs each
+ TSFI might affect (from the description of the TSFI and its implementation in the supporting
+ documentation), and then examine the description to determine whether it covers those aspects.
+
+
+
+
+
+
+
+ This family levies requirements upon the functional specification,
+ which describes the TSF interfaces (TSFIs).
+ The TSFI consists of all means by which external entities (or
+ subjects in the TOE but outside of the TSF) supply data to the TSF,
+ receive data from the TSF and invoke services from the TSF.
+ It does not describe how the TSF processes those service
+ requests, nor does it describe the communication when the TSF invokes services
+ from its operational environment; this information is addressed by the
+ and
+ families, respectively.
+
+ This family provides assurance directly by allowing the
+ evaluator to understand how the TSF meets the claimed SFRs. It
+ also provides assurance indirectly, as input to other assurance
+ families and classes:
+ , where the description of
+ the TSFIs may be used to gain better understanding of how the
+ TSF is protected against corruption (i.e. subversion of
+ self-protection or domain separation) and/or bypass;
+ , where the description of the
+ TSFIs is an important input for both developer and evaluator
+ testing;
+ , where the description of the
+ TSFIs is used to search for vulnerabilities.
+
+
+
+
+ The information presented in the functional specification
+ describes the interfaces through which the TSF services are
+ invoked. At the lower levels of assurance, there is an
+ effort to reduce the amount of information that must be
+ supplied by requiring only the most security-critical
+ information.
+
+
+
+ The components in this family are levelled on the degree of
+ detail required of the description of the TSFIs, and the degree
+ of formalism required of the description of the TSFIs.
+
+
+
+ Once the TSFIs are determined (see for guidance and
+ examples of determining TSFI), they are described. At
+ lower-level components, developers focus their documentation
+ (and evaluators focus their analysis) on the more
+ security-relevant aspects of the TOE. Three categories of
+ TSFIs are defined, based upon the relevance the services
+ available through them have to the SFRs being claimed:
+ If a service available through an interface can be
+ traced to one of the SFRs levied on the TSF, then that
+ interface is termed SFR-enforcing.
+ Note that it is possible that an interface may have
+ various services and results, some of which may be
+ SFR-enforcing and some of which may not.
+ interfaces to (or services available through an
+ interface relating to) services that SFR-enforcing
+ functionality depends upon, but need only to function
+ correctly in order for the security policies of the TOE
+ to be preserved, are termed
+ SFR-supporting.
+ Interfaces to services on which SFR-enforcing
+ functionality has no dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR-supporting or SFR non-interfering it must have
+ no SFR-enforcing services or results. In
+ contrast, an SFR-enforcing interface may have SFR-supporting
+ services (for example, the ability to set the system clock
+ may be an SFR-enforcing service of an interface, but if that
+ same interface is used to display the system date that
+ service may be only SFR-supporting). An example of a purely
+ SFR-supporting interface is a system call interface that is
+ used both by users and by a portion of the TSF that is
+ running on behalf of users.
+
+ As more information about the TSFIs becomes available, the
+ greater the assurance that can be gained that the interfaces are
+ correctly categorised/analysed. The requirements are structured
+ such that, at the lowest level, the information required for SFR
+ non-interfering interfaces is the minimum necessary in order for
+ the evaluator to make this determination in an effective
+ manner. At higher levels, more information becomes available so
+ that the evaluator has greater confidence in the
+ designation.
+
+ The purpose in defining these labels (SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering) and for levying
+ different requirements upon each (at the lower assurance
+ components) is to provide a first approximation of where to
+ focus the analysis and the evidence upon which that analysis
+ is performed. If the developer's documentation of the TSF
+ interfaces describes all of the interfaces to the degree
+ specified in the requirements for the SFR-enforcing
+ interfaces (that is, if the documentation exceeds the
+ requirements), there is no need for the developer to create
+ new evidence to match the requirements. Similarly, because
+ the labels are merely a means of differentiating the
+ interface types within the requirements, there is no need
+ for the developer to update the evidence solely to label the
+ interfaces as SFR-enforcing, SFR-supporting, and
+ SFR-non-interfering. The primary purpose of this labelling
+ is to allow developers with less mature development
+ methodologies (and associated artifacts, such as detailed
+ interface and design documentation) to provide only the
+ necessary evidence without undue cost.
+
+ The last C element of each component within this family provides
+ a direct correspondence between the SFRs and the functional
+ specification; that is, an indication of which interfaces are
+ used to invoke each of the claimed SFRs. In the cases where the
+ ST contains such functional requirements as , whose functionality may not manifest itself at
+ the TSFIs, the functional specification and/or the tracing is
+ expected to identify these SFRs; including them in the functional
+ specification helps to ensure that they are not lost at lower
+ levels of decomposition, where they will be relevant.
+
+
+ The requirements define collections of details about TSFI
+ to be provided. For the purposes of the requirements,
+ interfaces are specified (in varying degrees of detail) in
+ terms of their purpose, method of use, parameters,
+ parameter descriptions, and error messages.
+
+ The purpose of an interface is a
+ high-level description of the general goal of the
+ interface (e.g. process GUI commands, receive network
+ packets, provide printer output, etc.)
+
+ The interface's method of use describes
+ how the interface is supposed to be used. This description
+ should be built around the various interactions available
+ at that interface. For instance, if the interface were a Unix
+ command shell, ls, mv
+ and cp would be interactions for that
+ interface. For each interaction the method of use
+ describes what the interaction does, both for behaviour
+ seen at the interface (e.g. the programmer calling the
+ API, the Windows users changing a setting in the registry,
+ etc.) as well as behaviour at other interfaces
+ (e.g. generating an audit record).
+
+ Parameters are explicit inputs to and
+ outputs from an interface that control the behaviour of
+ that interface. For example, parameters are the arguments
+ supplied to an API; the various fields in a packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; the flags that can be set for the
+ ls, etc. The parameters are
+ ``identified'' with a simple list of what they are.
+
+ A parameter description tells what the
+ parameter is in some meaningful way. For instance, an
+ acceptable parameter description for interface
+ foo(i) would be ``parameter i is an
+ integer that indicates the number of users currently
+ logged in to the system''. A description such as
+ ``parameter i is an integer'' is not an acceptable.
+
+ The description of an interface's actions
+ describes what the interface does. This is more detailed
+ than the purpose in that, while the ``purpose'' reveals
+ why one might want to use it, the ``actions'' reveals
+ everything that it does. These actions might be related to
+ the SFRs or not. In cases where the interface's action is
+ not related to SFRs, its description is said to be
+ summarised, meaning the description
+ merely makes clear that it is indeed not SFR-related.
+
+ The error message description identifies
+ the condition that generated it, what the message is, and
+ the meaning of any error codes. An error message is
+ generated by the TSF to signify that a problem or
+ irregularity of some degree has been encountered. The
+ requirements in this family refer to different kinds of
+ error messages:
+ a ``direct'' error message is a
+ security-relevant response through a specific TSFI
+ invocation.
+ an ``indirect'' error cannot be tied to a
+ specific TSFI invocation because it results from
+ system-wide conditions (e.g. resource exhaustion,
+ connectivity interruptions, etc.). Error messages that
+ are not security-relevant are also considered
+ ``indirect''.
+ ``remaining'' errors are any other errors, such as those
+ that might be referenced within the code. For example, the use of
+ condition-checking code that checks for conditions that would not
+ logically occur (e.g. a final ``else'' after a list of ``case''
+ statements), would provide for generating a catch-all error
+ message; in an operational TOE, these error messages should never
+ be seen.
+
+ An example functional specification is provided in .
+
+
+
+ Increasing assurance through increased completeness and
+ accuracy in the interface specification is reflected in
+ the documentation required from the developer as detailed
+ in the various hierarchical components of this
+ family.
+
+ At , the only
+ documentation required is a characterisation of all TSFIs
+ and a high level description of SFR-enforcing and
+ SFR-supporting TSFIs. To provide some assurance that the
+ ``important'' aspects of the TSF have been correctly
+ characterised at the TSFIs, the developer is required to
+ provide the purpose and method of use, parameters for the
+ SFR-enforcing and SFR-supporting TSFIs.
+
+ At , the developer is
+ required to provide the purpose, method of use,
+ parameters, and parameter descriptions for all
+ TSFIs. Additionally, for the SFR-enforcing TSFIs the
+ developer has to describe the SFR-enforcing actions and
+ direct error messages.
+
+ At , the developer must now,
+ in addition to the information required at , provide enough information about the SFR-supporting
+ and SFR-non-interfering actions to show that they are not
+ SFR-enforcing. Further, the developer must now document all of
+ the direct error messages resulting from the invocation of
+ SFR-enforcing TSFIs.
+
+ At , all TSFIs - whether
+ SFR-enforcing, SFR-supporting, SFR-non-interfering - must
+ be described to the same degree, including all of the
+ direct error messages.
+
+ At , the TSFIs descriptions
+ also include error messages that do not result from an
+ invocation of a TSFI.
+
+ At , in addition to the
+ information required by , all
+ remaining error messages are included. The developer must also
+ provide a formal description of the TSFI. This provides an
+ alternative view of the TSFI that may expose inconsistencies or
+ incomplete specification.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has provided a high-level description of at least the
+ SFR-enforcing and SFR-supporting TSFIs, in terms of descriptions
+ of their parameters. There is no other required evidence that
+ can be expected to be available to measure the accuracy of these
+ descriptions; the evaluator merely ensures the descriptions seem
+ plausible.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall describe the purpose and
+ method of use for each SFR-enforcing and SFR-supporting
+ TSFI.
+
+
+ The functional specification shall identify all parameters
+ associated with each SFR-enforcing and SFR-supporting TSFI.
+
+
+ The functional specification shall provide rationale for the
+ implicit categorisation of interfaces as
+ SFR-non-interfering.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ SFR-supporting and SFR-enforcing TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of the parameters; this can be done in
+ association with other work units for this
+ component.
+
+ If an action available through an interface plays a role in
+ enforcing any security policy on the TOE (that is, if one of the
+ actions of the interface can be traced to one of the SFRs levied
+ on the TSF), then that interface is
+ SFR-enforcing. Such policies are not limited to
+ the access control policies, but also refer to any functionality
+ specified by one of the SFRs contained in the ST. Note that it
+ is possible that an interface may have various actions and
+ results, some of which may be SFR-enforcing and some of which
+ may not.
+
+ Interfaces to (or actions available through an interface
+ relating to) actions that SFR-enforcing functionality
+ depends on, but need only to function correctly in order
+ for the security policies of the TOE to be preserved,
+ are termed SFR supporting. Interfaces
+ to actions on which SFR-enforcing functionality has no
+ dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR supporting or SFR non-interfering it must have
+ no SFR-enforcing actions or results. In
+ contrast, an SFR-enforcing interface may have
+ SFR-supporting actions (for example, the ability to set
+ the system clock may be an SFR-enforcing action of an
+ interface, but if that same interface is used to display
+ the system date that action may only be SFR
+ supporting). An example of a purely SFR-supporting
+ interface is a system call interface that is used both
+ by untrusted users and by a portion of the TSF that is
+ running in user mode.
+
+ At this level, it is unlikely that a developer will have
+ expended effort to label interfaces as SFR-enforcing and
+ SFR-supporting. In the case that this has been done,
+ the evaluator should verify to the extent that
+ supporting documentation (e.g., operational user
+ guidance) allows that this identification is correct.
+ Note that this identification activity is necessary for
+ several work units for this component.
+
+ In the more likely case that the developer has not
+ labelled the interfaces, the evaluator must perform
+ their own identification of the interfaces first, and
+ then determine whether the required information (for
+ this work unit, the purpose) is present. Again, because
+ of the lack of supporting evidence this identification
+ will be difficult and have low assurance that all
+ appropriate interfaces have been correctly identified,
+ but nonetheless the evaluator examines other evidence
+ available for the TOE to ensure as complete coverage as
+ is possible.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each
+ SFR-supporting and SFR-enforcing TSFI is given.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it identifies all parameters
+ associated with each SFR-enforcing and SFR-supporting
+ TSFI.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for
+ identified TSFI. Parameters are explicit inputs or
+ outputs to an interface that control the behaviour of
+ that interface. For examples, parameters are the
+ arguments supplied to an API; the various fields in
+ packet for a given network protocol; the individual key
+ values in the Windows Registry; the signals across a set
+ of pins on a chip; etc.
+
+ While difficult to obtain much assurance that all
+ parameters for the applicable TSFI have been identified,
+ the evaluator should also check other evidence provided
+ for the evaluation (e.g., operational user guidance) to
+ see if behaviour or additional parameters are described
+ there but not in the functional specification.
+
+
+
+
+ The evaluator shall examine the rationale provided by
+ the developer for the implicit categorisation of
+ interfaces as SFR-non-interfering to determine that it
+ is accurate.
+
+ In the case where the developer has provided adequate
+ documentation to perform the analysis called for by the
+ rest of the work units for this component without
+ explicitly identifying SFR-enforcing and SFR-supporting
+ interfaces, this work unit should be considered
+ satisfied.
+
+ This work unit is intended to apply to cases where the developer
+ has not described a portion of the TSFI, claiming that it is
+ SFR-non-interfering and therefore not subject to other
+ requirements of this component. In such a case, the developer
+ provides a rationale for this characterisation in sufficient
+ detail such that the evaluator understands the rationale, the
+ characteristics of the interfaces affected (e.g., their
+ high-level function with respect to the TOE, such as ``colour
+ palette manipulation''), and that the claim that these are
+ SFR-non-interfering is supported. Given the level of assurance
+ the evaluator should not expect more detail than is provided for
+ the SFR-enforcing or SFR-supporting interfaces, and in fact the
+ detail should be much less. In most cases, individual
+ interfaces should not need to be addressed in the
+ developer-provided rationale subclause.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis, the
+ evaluator may build upon the developer's tracing (see a map between the TOE security
+ functional requirements and the TSFI). Note that this map may
+ have to be at a level of detail below the component or even
+ element level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that have
+ little or no manifestation at the TSF boundary (e.g., ) it is not expected that they
+ completely map those requirements to the TSFI. The analysis for
+ those requirements will be performed in the analysis for the TOE
+ design () when included in the
+ ST. It is also important to note that since the parameters
+ associated with TSFIs must be fully specified, the evaluator
+ should be able to determine if all aspects of an SFR appear to
+ be implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the SFR-enforcing actions, results and error
+ messages of each TSFI that is SFR-enforcing are also
+ described.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe direct error messages resulting from processing
+ associated with the SFR-enforcing actions.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer"; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface can be
+ traced to one of the SFRs levied on the TSF, then that
+ interface is SFR-enforcing. Such
+ policies are not limited to the access control policies,
+ but also refer to any functionality specified by one of
+ the SFRs contained in the ST. Note that it is possible
+ that an interface may have various actions and results,
+ some of which may be SFR-enforcing and some of which may not.
+
+ The developer is not required to ``label'' interfaces as
+ SFR-enforcing, and likewise is not required to identify
+ actions available through an interface as SFR-enforcing.
+ It is the evaluator's responsibility to examine the
+ evidence provided by the developer and determine that
+ the required information is present. In the case where
+ the developer has identified the SFR-enforcing TSFI and
+ SFR-enforcing actions available through those TSFI, the
+ evaluator must judge completeness and accuracy based on
+ other information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and on the other information presented
+ for the interfaces (parameters and parameter
+ descriptions, error messages, etc.).
+
+ In this case (where the developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing.
+
+ In the case where the developer has provided the same
+ level of information on all interfaces, the evaluator
+ performs the same type of analysis mentioned in the
+ previous paragraphs. The evaluator should determine
+ which interfaces are SFR-enforcing and which are not,
+ and subsequently ensure that the SFR-enforcing aspects
+ of the SFR-enforcing actions are appropriately
+ described.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from SFR-enforcing
+ actions associated with each SFR-enforcing TSFI.
+
+ This work unit should be performed in conjunction with,
+ or after, work unit
+ in order to ensure the set of SFR-enforcing TSFI and
+ SFR-enforcing actions is correctly identified. The
+ developer may provide more information than is required
+ (for example, all error messages associated with each
+ interface), in which the case the evaluator should
+ restrict their assessment of completeness and accuracy
+ to only those that they determine to be associated with
+ SFR-enforcing actions of SFR-enforcing TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+ In order to determine that the description of the
+ error messages of a TSFI is accurate and complete, the
+ evaluator measures the interface description against the
+ other evidence provided for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), as well as other evidence available for
+ that TSFI (parameters, analysis from work unit ).
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the actions, results and error messages of each
+ TSFI are also described sufficiently that it can be
+ determined whether they are SFR-enforcing, with the
+ SFR-enforcing TSFI being described in more detail than
+ other TSFIs.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe direct error messages resulting from SFR-enforcing
+ actions and exceptions associated with invocation of the TSFI.
+
+
+ The functional specification shall summarise the SFR-supporting
+ and SFR-non-interfering actions associated with each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface plays a role
+ in enforcing any security policy on the TOE (that is, if
+ one of the actions of the interface can be traced to one
+ of the SFRs levied on the TSF), then that interface is
+ SFR-enforcing. Such policies are not
+ limited to the access control policies, but also refer
+ to any functionality specified by one of the SFRs
+ contained in the ST. Note that it is possible that an
+ interface may have various actions and results, some of
+ which may be SFR-enforcing and some of which may
+ not.
+ The developer is not required to ``label''
+ interfaces as SFR-enforcing, and likewise is not
+ required to identify actions available through an
+ interface as SFR-enforcing. It is the evaluator's
+ responsibility to examine the evidence provided by the
+ developer and determine that the required information is
+ present. In the case where the developer has identified
+ the SFR-enforcing TSFI and SFR-enforcing actions
+ available through those TSFI, the evaluator must judge
+ completeness and accuracy based on other information
+ supplied for the evaluation (e.g., TOE design, security
+ architecture description, operational user guidance),
+ and on the other information presented for the
+ interfaces (parameters and parameter descriptions, error
+ messages, etc.).
+
+ In this case (developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing. The analysis
+ done for work units
+ and are also used in
+ making this determination.
+ In the case where the developer has provided the
+ same level of information on all interfaces, the
+ evaluator performs the same type of analysis mentioned
+ in the previous paragraphs. The evaluator should
+ determine which interfaces are SFR-enforcing and which
+ are not, and subsequently ensure that the SFR-enforcing
+ aspects of the SFR-enforcing actions are appropriately
+ described. Note that in this case, the evaluator should
+ be able to perform the bulk of the work associated with
+ work unit in the
+ course of performing this SFR-enforcing analysis.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from an invocation of
+ each SFR-enforcing TSFI.
+
+ This work unit should be performed in conjunction with, or
+ after, work unit in order
+ to ensure the set of SFR-enforcing TSFI is correctly identified.
+ The evaluator should note that the requirement and associated
+ work unit is that all direct error messages associated with an
+ SFR-enforcing TSFI must be described, that are associated with
+ SFR-enforcing actions. This is because at this level of
+ assurance, the ``extra'' information provided by the error
+ message descriptions should be used in determining whether all
+ of the SFR-enforcing aspects of an interface have been
+ appropriately described. For instance, if an error message
+ associated with a TSFI (e.g., ``access denied'') indicated that
+ an SFR-enforcing decision or action had taken place, but in the
+ description of the SFR-enforcing actions there was no mention of
+ that particular SFR-enforcing mechanism, then the description
+ may not be complete.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+
+ In order to determine that the description of the error messages
+ of a TSFI is accurate and complete, the evaluator measures the
+ interface description against the other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance), as well as for other
+ evidence supplied for that TSFI (description of SFR-enforcing
+ actions, summary of SFR-supporting and SFR-non-interfering
+ actions and results).
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to
+ determine that it summarises the SFR-supporting and
+ SFR-non-interfering actions associated with each TSFI.
+
+ The purpose of this work unit is to supplement the details about
+ the SFR-enforcing actions (provided in work unit ) with a summary of the remaining
+ actions (i.e., those that are not SFR-enforcing). This covers
+ all SFR-supporting and SFR-non-interfering
+ actions, whether invokable through SFR-enforcing TSFI or through
+ SFR-supporting or SFR-non-interfering TSFI. Such a summary
+ about all SFR-supporting and SFR-non-interfering actions helps
+ to provide a more complete picture of the functions provided by
+ the TSF, and is to be used by the evaluator in determining
+ whether an action or TSFI may have been mis-categorised.
+
+ The information to be provided is more abstract than that
+ required for SFR-enforcing actions. While it should still be
+ detailed enough so that the reader can understand what the
+ action does, the description does not have to be detailed enough
+ to support writing tests against it, for instance. For the
+ evaluator, the key is that the information must be sufficient to
+ make a positive determination that the action is SFR-supporting
+ or SFR-non-interfering. If that level of information is
+ missing, the summary is insufficient and more information must
+ be obtained.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST.
+
+
+
+ The functional specification describes the interfaces to
+ the TSF (the TSFI) in a structured manner. Because of the
+ dependency on , the
+ evaluator is expected to have identified the TSF prior to
+ beginning work on this sub-activity. Without firm
+ knowledge of what comprises the TSF, it is not possible to
+ assess the completeness of the TSFI.
+
+ In performing the various work units included in this family,
+ the evaluator is asked to make assessments of accuracy and
+ completeness of several factors (the TSFI itself, as well as the
+ individual components (parameters, actions, error messages,
+ etc.) of the TSFI). In doing this analysis, the evaluator is
+ expected to use the documentation provided for the
+ evaluation. This includes the ST, the TOE design, and may
+ include other documentation such as the operational user
+ guidance, security architecture description, and implementation
+ representation. The documentation should be examined in an
+ iterative fashion. The evaluator may read, for example, in the
+ TOE design how a certain function is implemented, but see no way
+ to invoke that function from the interface. This might cause the
+ evaluator to question the completeness of a particular TSFI
+ description, or whether an interface has been left out of the
+ functional specification altogether. Describing analysis
+ activities of this sort in the ETR is a key method in providing
+ rationale that the work units have been performed
+ appropriately.
+
+ It should be recognised that there exist functional
+ requirements whose functionality is manifested wholly or
+ in part architecturally, rather than through a specific
+ mechanism. An example of this is the implementation of
+ mechanisms implementing the requirements. Such mechanisms typically are
+ implemented to ensure a behaviour isn't present, which is
+ difficult to test and typically is verified through
+ analysis. In the cases where such functional requirements
+ are included in the ST, it is expected that the evaluator
+ recognise that there may be SFRs of this type that have no
+ interfaces, and that this should not be considered a
+ deficiency in the functional specification.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+ The evaluator shall examine the functional specification to
+ determine the completeness of the TSFI
+ The evaluator shall use the design documentation to identify the possible types of
+ interfaces. The evaluator shall search the design documentation and the guidance
+ documentation for potential TSFI not contained in the developer's documentation,
+ thus indicating that the set of TSFI defined by the developer is incomplete. The
+ evaluator shall examine the arguments presented by the developer that the TSFI is
+ complete and check down to the lowest level of design or with the
+ implementation representation that no additional TSFI exist.
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ Actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to determine
+ that it completely and accurately describes the meaning of all
+ error messages resulting from an invocation of each TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation
+ (e.g. TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST. The completeness of the interfaces
+ is judged based upon the implementation
+ representation.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the implementation representation.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ semi-formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+ The functional specification
+ shall describe all error messages that do not result from an
+ invocation of a TSFI.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation yet
+ does not result from an invocation of a TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is presented using a semiformal
+ style.
+
+ A semi-formal presentation is characterised by a
+ standardised format with a well-defined syntax that
+ reduces ambiguity that may occur in informal
+ presentations. Since the intent of the semi-formal
+ format is to enhance the reader's ability to understand
+ the presentation, use of certain structured presentation
+ methods (pseudo-code, flow charts, block diagrams) are
+ appropriate, though not required.
+
+ For the purposes of this activity, the evaluator should
+ ensure that the interface descriptions are formatted in
+ a structured, consistent manner and use common
+ terminology. A semiformal presentation of the interfaces
+ also implies that the level of detail of the
+ presentation for the interfaces is largely consistent
+ across all TSFI. For the functional specification, it is
+ acceptable to refer to external specifications for
+ portions of the interface as long as those external
+ specifications are themselves semiformal.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+ The evaluator shall examine the functional specification to
+ determine the completeness of the TSFI
+ The evaluator shall use the design documentation to identify the possible types of
+ interfaces. The evaluator shall search the design documentation and the guidance
+ documentation for potential TSFI not contained in the developer's documentation,
+ thus indicating that the set of TSFI defined by the developer is incomplete. The
+ evaluator shall examine the arguments presented by the developer that the TSFI is
+ complete and check down to the lowest level of design or with the
+ implementation representation that no additional TSFI exist.
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system''. is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to determine
+ that it completely and accurately describes the meaning of all
+ error messages resulting from an invocation of each TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation (e.g.,
+ TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it completely and accurately describes
+ all errors messages that do not result from an
+ invocation of any TSFI.
+
+ This work unit complements work unit , which describes those
+ error messages that result from an invocation of the
+ TSFI. Taken together, these work units cover all error
+ messages that might be generated by the TSF.
+
+ The evaluator assesses the completeness and accuracy of
+ the functional specification by comparing its contents
+ to instances of error message generation within the
+ implementation representation. Most of these error
+ messages will have already been covered by work unit
+ .
+
+ The error messages related to this work unit are
+ typically those that are not expected to be generated,
+ but are constructed as a matter of good programming
+ practises. For example, a case statement that defines
+ actions resulting from each of a list of cases may end
+ with a final else statement to apply
+ to anything that might not be expected; this practise
+ ensures the TSF does not get into an undefined state.
+ However, it is not expected that the path of execution
+ would ever get to this else
+ statement; therefore, any error message generation
+ within this else statement would
+ never be generated. Although it would not get
+ generated, it must still be included in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it provides a rationale for each error
+ message contained in the TSF implementation yet does not
+ result from an invocation of a TSFI.
+
+ The evaluator ensures that every error message found
+ under work unit
+ contains a rationale describing why it cannot be invoked
+ from the TSFI.
+
+ As was described in the previous work unit, this
+ rationale might be as straightforward as the fact that
+ the error message in question is provided for
+ completeness of execution logic and that it is never
+ expected to be generated. The evaluator ensures that the
+ rationale for each such error message is logical.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ (Need Objectives text for FSP.6 methodology)
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a formal presentation of the
+ functional specification of the TSF.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+
+ The functional specification shall describe all error messages
+ contained in the TSF implementation representation.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation that
+ is not otherwise described in the functional specification
+ justifying why it is not associated with a TSFI.
+
+
+ The formal presentation of the functional specification of
+ the TSF shall describe the TSFI using a formal style,
+ supported by informal, explanatory text where appropriate.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+
+
+
+
+ The function of the family
+ is for the developer to make available the implementation
+ representation (and, at higher levels, the implementation
+ itself) of the TOE in a form that can be analysed by the
+ evaluator. The implementation representation is used in
+ analysis activities for other families (analysing the TOE
+ design, for instance) to demonstrate that the TOE conforms
+ its design and to provide a basis for analysis in other
+ areas of the evaluation (e.g., the search for
+ vulnerabilities). The implementation representation is
+ expected to be in a form that captures the detailed internal
+ workings of the TSF. This may be software source code,
+ firmware source code, hardware diagrams and/or IC hardware
+ design language code or layout data.
+
+
+
+ The implementation representation of the TOE is made
+ available so that it can be analysed by the evaluator to
+ demonstrate that the TOE conforms its design and to provide
+ a basis for analysis in other areas of the evaluation (e.g.,
+ the search for vulnerabilities). The implementation
+ representation captures the detailed internal workings of
+ the TSF. This may be software source code, firmware source
+ code, hardware diagrams and/or chip specifications.
+
+
+
+ The components in this family are levelled on the amount of
+ implementation that is mapped to the TOE design
+ description.
+
+
+
+ Source code or hardware diagrams and/or IC hardware design
+ language code or layout data that are used to build the
+ actual hardware are examples of parts of an implementation
+ representation. It is important to note that while the
+ implementation representation must be made available to the
+ evaluator, this does not imply that the evaluator needs to
+ possess that representation. For instance, the developer may
+ require that the evaluator review the implementation
+ representation at a site of the developer's choosing.
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due to
+ lack of information. This does not, however, imply that all
+ of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. The implementation representation is made
+ available to allow analysis of other TOE design
+ decompositions (e.g., functional specification, TOE design),
+ and to gain confidence that the security functionality
+ described at a higher level in the design actually appear to
+ be implemented in the TOE. Conventions in some forms of the
+ implementation representation may make it difficult or
+ impossible to determine from just the implementation
+ representation itself what the actual result of the
+ compilation or run-time interpretation will be. For example,
+ compiler directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code. For this reason, it is important that such ``extra''
+ information or related tools (scripts, compilers, etc.) be
+ provided so that the implementation representation can be
+ accurately determined.
+
+ The purpose of the mapping between the implementation
+ representation and the TOE design description is to aid the
+ evaluator's analysis. The internal workings of the TOE may
+ be better understood when the TOE design is analysed with
+ corresponding portions of the implementation representation.
+ The mapping serves as an index into the implementation
+ representation. At the lower component, only a subset of the
+ implementation representation is mapped to the TOE design
+ description. Because of the uncertainty of which portions of
+ the implementation representation will need such a mapping,
+ the developer may choose either to map the entire
+ implementation representation beforehand, or to wait to see
+ which portions of the implementation representation the
+ evaluator requires to be mapped.
+
+ The implementation representation is manipulated by the
+ developer in a form that is suitable for transformation to
+ the actual implementation. For instance, the developer may
+ work with files containing source code, which is eventually
+ compiled to become part of the TSF. The developer makes
+ available the implementation representation in the form used
+ by the developer, so that the evaluator may use automated
+ techniques in the analysis. This also increases the
+ confidence that the implementation representation examined
+ is actually the one used in the production of the TSF (as
+ opposed to the case where it is supplied in an alternate
+ presentation format, such as a word processor document). It
+ should be noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to supply
+ the evaluator with the information that will maximise the
+ effectiveness of the evaluator's analysis efforts.
+
+ Some forms of the implementation representation may require
+ additional information because they introduce significant
+ barriers to understanding and analysis. Examples include
+ ``shrouded'' source code or source code that has been
+ obfuscated in other ways such that it prevents understanding
+ and/or analysis. These forms of implementation
+ representation typically result from the TOE developer
+ taking a version of the implementation representation and
+ running a shrouding or obfuscation program on it. While the
+ shrouded representation is what is compiled and may be
+ closer to the implementation (in terms of structure) than
+ the original, un-shrouded representation, supplying such
+ obfuscated code may cause significantly more time to be
+ spent in analysis tasks involving the representation. When
+ such forms of representation are created, the components
+ require details on the shrouding tools/algorithms used so
+ that the un-shrouded representation can be supplied, and the
+ additional information can be used to gain confidence that
+ the shrouding process does not compromise any security
+ functionality.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer is suitable for use in other analysis
+ activities; suitability is judged by its
+ conformance to the requirements for this component.
+
+
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due
+ to lack of information. This does not, however, imply that
+ all of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. For this sub-activity, this is even
+ truer. It would not be productive for the evaluator to
+ spend large amounts of time verifying the requirements for
+ one portion of the implementation representation, and then
+ use a different portion of the implementation
+ representation in performing analysis for other work
+ units. Therefore, the evaluator is encouraged to select
+ the sample of the implementation representation from the
+ areas of the TOE that will be of most interest during the
+ analysis performed during work units from other families
+ (e.g. , and ).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the sample of the implementation
+ representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ sample of the implementation representation shall
+ demonstrate their correspondence.
+
+
+ The evaluator shall confirm that, for the selected sample of
+ the implementation representation, the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the implementation
+ representation defines the TSF to a level of detail such
+ that the TSF can be generated without further design
+ decisions.
+
+ Source code or hardware diagrams and/or IC hardware
+ design language code or layout data that are used to
+ build the actual hardware are examples of parts of an
+ implementation representation. The evaluator samples the
+ implementation representation to gain confidence that it
+ is at the appropriate level and not, for instance, a
+ pseudo-code level which requires additional design
+ decisions to be made. The evaluator is encouraged to
+ perform a quick check when first looking at the
+ implementation representation to assure themselves that
+ the developer is on the right track. However, the
+ evaluator is also encourage to perform the bulk of this
+ check while working on other work units that call for
+ examining the implementation; this will ensure the
+ sample examined for this work unit is relevant.
+
+
+
+
+ The evaluator shall check that the implementation
+ representation is in the form used by development
+ personnel.
+
+ The implementation representation is manipulated by the
+ developer in form that it suitable for transformation to
+ the actual implementation. For instance, the developer
+ may work with files containing source code, which is
+ eventually compiled to become part of the TSF. The
+ developer makes available the implementation
+ representation in the form they use, so that the
+ evaluator may use automated techniques in the
+ analysis. This also increases the confidence that the
+ implementation representation examined is actually the
+ one used in the production of the TSF (as opposed to the
+ case where it is supplied in an alternate presentation
+ format, such as a word processor document). It should be
+ noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to
+ supply the evaluator with the information that will
+ maximise the evaluator's analysis efforts.
+
+ The evaluator samples the implementation representation
+ to gain confidence that it is the version that is usable
+ by the developer. The sample is such that the evaluator
+ has assurance that all areas of the implementation
+ representation are in conformance with the requirement;
+ however, a complete examination of the entire
+ implementation representation is unnecessary.
+
+ Conventions in some forms of the implementation
+ representation may make it difficult or impossible to
+ determine from just the implementation representation
+ itself what the actual result of the compilation or
+ run-time interpretation will be. For example, compiler
+ directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code.
+
+ Some forms of the implementation representation may
+ require additional information because they introduce
+ significant barriers to understanding and
+ analysis. Examples include shrouded source code or
+ source code that has been obfuscated in other ways such
+ that it prevents understanding and/or analysis. These
+ forms of implementation representation typically result
+ from by taking a version of the implementation
+ representation that is used by the TOE developer and
+ running a shrouding or obfuscation program on it. While
+ the shrouded representation is what is compiled and may
+ be closer to the implementation (in terms of structure)
+ than the original, un-shrouded representation, supplying
+ such obfuscated code may cause significantly more time
+ to be spent in analysis tasks involving the
+ representation. When such forms of representation are
+ created, the components require details on the shrouding
+ tools/algorithms used so that the un-shrouded
+ representation can be supplied, and the additional
+ information can be used to gain confidence that the
+ shrouding process does not compromise any security
+ mechanisms.
+
+ The evaluator samples the implementation representation
+ to gain confidence that all of the information needed to
+ interpret the implementation representation has been
+ supplied. Note that the tools are among those referenced
+ by components. The
+ evaluator is encouraged to perform a quick check when
+ first looking at the implementation representation to
+ assure themselves that the developer is on the right
+ track. However, the evaluator is also encouraged to
+ perform the bulk of this check while working on other
+ work units that call for examining the implementation;
+ this will ensure the sample examined for this work unit
+ is relevant.
+
+
+
+
+ The evaluator shall examine the mapping between the TOE
+ design description and the sample of the implementation
+ representation to determine that it is accurate.
+
+ The evaluator augments the determination of existence
+ (specified in work unit ) by verifying the accuracy of a portion of
+ the implementation representation and the TOE design
+ description. For parts of the TOE design description
+ that are interesting, the evaluator would verify the
+ implementation representation accurately reflects the
+ description provided in the TOE design
+ description.
+
+ For example, the TOE design description might identify a
+ login module that is used to identify and authenticate
+ users. If user authentication is sufficiently
+ significant, the evaluator would verify that the
+ corresponding code in fact implements that service as
+ described in the TOE design description. It might also
+ be worthwhile to verify that the code accepts the
+ parameters as described in the functional
+ specification.
+
+ It is worth pointing out the developer must choose
+ whether to perform the mapping for the entire
+ implementation representation, thereby guaranteeing that
+ the chosen sample will be covered, or waiting for the
+ sample to be chosen before performing the mapping. The
+ first option is likely more work, but may be completed
+ before the evaluation begins. The second option is less
+ work, but will produce a suspension of evaluation
+ activity while the necessary evidence is being
+ produced.
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer can be transformed into the implementation that
+ is used in the testing activities.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the entire implementation representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ entire implementation representation shall demonstrate their
+ correspondence.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ This family addresses the assessment of the internal
+ structure of the TSF. A TSF whose internals are
+ well-structured is easier to implement and less likely to
+ contain flaws that could lead to vulnerabilities; it is also
+ easier to maintain without the introduction of flaws.
+
+
+
+ The internal structure of the TSF can aid or hamper
+ understandability of the implementation representation.
+ Source code that conforms to coding standards, that exhibit
+ a minimum of interactions, and that is written in modules
+ each with a single purpose, is much easier to understand
+ than poorly-structured code with unnecessary or
+ loosely-defined interactions.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of structure and minimisation of complexity
+ required. places
+ requirements for well-structured internals on only selected
+ parts of the TSF. This component is not included in an EAL
+ because this component is viewed for use in special
+ circumstances (e.g., the sponsor has a specific concern
+ regarding a cryptographic module, which is isolated from the
+ rest of the TSF) and would not be widely applicable.
+
+ At the next level, the requirements for well-structured
+ internals are placed on the entire TSF. Finally,
+ minimisation of complexity is introduced in the highest
+ component.
+
+
+
+ These requirements, when applied to the internal structure
+ of the TSF, typically result in improvements that aid both
+ the developer and the evaluator in understanding the TSF,
+ and also provide the basis for designing and evaluating test
+ suites. Further, improving understandability of the TSF
+ should assist the developer in simplifying its
+ maintainability.
+
+ The requirements in this family are presented at a fairly
+ abstract level. The wide variety of TOEs makes it impossible
+ to codify anything more specific than ``well-structured'' or
+ ``minimum complexity''. Judgements on structure and
+ complexity are expected to be derived from the specific
+ technologies used in the TOE. For example, software is
+ likely to be considered well-structured if it exhibits the
+ characteristics cited in the software engineering
+ disciplines. The components within this family call for
+ identifying the standards for measuring the characteristic
+ of being well-structured and not overly-complex.
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring specific portions of the TSF to be
+ well-structured. The intent is that the entire TSF has
+ been designed and implemented using sound engineering
+ principles, but the analysis is performed upon only a
+ specific subset.
+
+
+
+ This component requires the PP or ST author to fill in an
+ assignment with the subset of the TSF. This subset may be
+ identified in terms of the internals of the TSF at any
+ layer of abstraction. For example:
+
+ the structural elements of the TSF as identified
+ in the TOE design (e.g. ``The developer shall design
+ and implement the audit subsystem
+ such that it has well-structured internals.'')
+ the implementation (e.g. ``The developer shall
+ design and implement the encrypt.c and
+ decrypt.c files such that it has
+ well-structured internals.'' or ``The developer shall
+ design and implement the 6227 IC chip
+ such that it has well-structured
+ internals.'')
+
+ It is likely this would not be readily accomplished by
+ referencing the claimed SFRs (e.g. ``The developer shall
+ design and implement the portion of the TSF that
+ provide anonymity as defined in
+ such that it has well-structured
+ internals.'') because this does not indicate where to
+ focus the analysis.
+
+ This component has limited value and would be suitable in cases
+ where potentially-malicious users/subjects have limited or
+ strictly controlled access to the TSFIs or where there is
+ another means of protection (e.g., domain separation) that
+ ensures the chosen subset of the TSF cannot be adversely
+ affected by the rest of the TSF (e.g., the cryptographic
+ functionality, which is isolated from the rest of the TSF, is
+ well-structured).
+
+
+
+ The objective of this sub-activity is to determine whether
+ the defined subset of the TSF is designed and structured
+ such that the likelihood of flaws is reduced and that
+ maintenance can be more readily performed without the
+ introduction of flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The use of the assignment in this component levies stricter
+ constraints on the subset of the TSF that is explicitly
+ identified in the assignment
+ than on the remainder of the TSF.
+ While the entire TSF is to be designed using good
+ engineering principles and result in a well-structured TSF, only
+ the specified subset is specifically analysed for this
+ characteristic. The evaluator determines that the developer's
+ application of coding standards result in a TSF that is
+ understandable.
+
+ The primary goal of this component is to ensure the TSF
+ subset's implementation representation is understandable
+ to facilitate maintenance and analysis (of both the
+ developer and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance);
+
+
+ the TSF internals description and justification;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement subset
+ of the TSF such that it has well-structured
+ internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall explain the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ assigned subset of the TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF subset:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ subset
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the TSF
+ subset
+
+ For other types of technologies used in the TOE - such as
+ non-procedural software (e.g. object-oriented programming),
+ widespread commodity hardware (e.g. PC microprocessors), and
+ special-purpose hardware (e.g. smart-card processors) - the
+ evaluator should seek guidance from the evaluation authority for
+ determining the adequacy of criteria for being
+ ``well-structured''.
+
+
+
+ The evaluator shall check the TSF internals
+ description to determine that it identifies the Assigned
+ subset of the TSF.
+
+ This subset may be identified in terms of the internals
+ of the TSF at any layer of abstraction. For example, it
+ may be in terms of the structural elements of the TSF as
+ identified in the TOE design (e.g. the audit subsystem),
+ or in terms of the implementation
+ (e.g. encrypt.c and
+ decrypt.c files, or the 6227 IC
+ chip).
+
+ It is insufficient to identify this subset in terms of
+ the claimed SFRs (e.g. the portion of the TSF that
+ provide anonymity as defined in ) because this does not indicate where to
+ focus the analysis.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ assigned TSF subset is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF subset meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF subset meets the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF subset and
+ the modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ assigned subset of the TSF.
+
+
+ The evaluator shall determine that the TOE design for
+ the assigned TSF subset is well-structured.
+
+ The evaluator examines a sample of the TOE design to
+ verify the accuracy of the justification. For example, a
+ sample of the TOE design is analysed to determine its
+ adherence to the design standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the assigned TSF
+ subset is well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF subset to
+ verify the accuracy of the internals description. For
+ example, a sample of the procedural software portions of
+ the TSF subset is analysed to determine its cohesion and
+ coupling, its adherence to the coding standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured. The intent is
+ that the entire TSF has been designed and implemented
+ using sound engineering principles.
+
+
+
+ Judgements on the adequacy of the structure are expected to
+ be derived from the specific technologies used in the TOE.
+ This component calls for identifying the standards for
+ measuring the characteristic of being
+ well-structured.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is designed and structured such that the
+ likelihood of flaws is reduced and that maintenance can be
+ more readily performed without the introduction of
+ flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The primary goal of this component is to ensure the TSF's
+ implementation representation is understandable to
+ facilitate maintenance and analysis (of both the developer
+ and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance));
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall describe the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the
+ TSF
+
+ For other types of technologies used in the TOE - such
+ as non-procedural software (e.g. object-oriented
+ programming), widespread commodity hardware (e.g. PC
+ microprocessors), and special-purpose hardware
+ (e.g. smart-card processors) - the evaluation authority
+ should be consulted for determining the adequacy of
+ criteria for being ``well-structured''.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ TSF is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF meet the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF and the
+ modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ TSF.
+
+
+ The evaluator shall determine that the TOE design is
+ well-structured.
+
+ The evaluator examines the TOE design of a sample of the
+ TSF to verify the accuracy of the justification. For
+ example, a sample of the TOE design is analysed to
+ determine its adherence to the design standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the TSF is
+ well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF to verify the
+ accuracy of the internals description. For example, a
+ sample of the procedural software portions of the TSF is
+ analysed to determine its cohesion and coupling, its
+ adherence to the coding standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured and of minimal
+ complexity. The intent is that the entire TSF has been
+ designed and implemented using sound engineering
+ principles.
+
+
+
+ Judgements on the adequacy of the structure and complexity
+ are expected to be derived from the specific technologies
+ used in the TOE. This component calls for identifying the
+ standards for measuring the structure and
+ complexity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall describe the characteristics used to
+ judge the meaning of ``well-structured'' and ``complex''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured and is not overly complex.
+
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform an internals analysis on the
+ entire TSF.
+
+
+
+
+
+
+ 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.
+
+
+
+ A formal security model precisely describes important
+ aspects of security and their relationship to the behaviour
+ of the TSF. Formalism helps to prove mathematically the
+ thoroughness of the security.
+
+
+
+ This family contains only one component.
+
+
+
+ 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.
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+ 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.
+
+ 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. contains an assignment for identifying these
+ policies that are formally modelled.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the formal TOE security policy model clearly and
+ consistently describes the rules of operation, states,
+ transition, invariants, and other security properties of
+ the claimed SFRs and whether this description corresponds
+ with the description of the security functionality in the
+ functional specification.
+
+
+
+ This activity applies to cases where the developer has
+ formally modelled all security policies of the TOE that
+ are capable of being modelled formally.
+
+ A formal TOE security policy model is a representation of
+ the rules (synonymously termed ``principles'') and
+ characteristics of security policies in mathematical
+ terms. Their formal counterparts are called security
+ properties and security features, respectively. The
+ representation includes but is not limited to algebraic
+ specifications, finite state machines and logic formalisms
+ strong enough to formally infer the properties from the
+ features. The formal security policy model is accompanied
+ by an informal interpretation explaining how the rules and
+ characteristics are mapped to the respective properties
+ and features.
+
+ It is recognised that not all policies (see work unit
+ ) can be formally
+ modelled for all TOEs. This is because either the state of
+ the art is insufficient to formally model a given policy,
+ or because the nature of the TOE renders impossible the
+ modelling of policies that would otherwise be possible to
+ model. If none of the SFRs can be formally modelled, this
+ component cannot be met.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a formal security policy model for
+ the list of policies that are formally
+ modelled.
+
+ 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.
+
+
+ The developer shall provide a formal proof of correspondence
+ between the model and any formal functional specification.
+
+
+ The developer shall provide a demonstration of
+ correspondence between the model and the functional
+ specification.
+
+
+ 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.
+
+
+ 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.
+
+
+ The correspondence between the model and the functional
+ specification shall be at the correct level of formality.
+
+
+ The correspondence shall show that the functional
+ specification is consistent and complete with respect to the
+ model.
+
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it is written in a formal
+ style.
+
+ The evaluator identifies the formal framework upon which
+ the TOE security policy model is based and ensures that
+ it is founded on well established mathematical concepts,
+ and identifies the security properties and features
+ addressed in the application notes and ensures the
+ formalisation of at least one security policy. If no
+ policy is formally modelled, this component cannot be
+ successfully claimed.
+
+ For additional guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all necessary
+ informal explanatory text.
+
+ Supporting narrative descriptions are necessary for all
+ parts of the model (for example, to make clear the
+ meaning of any formal notation and how they are used)
+ including the security properties and features.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all policies that
+ can be formally modelled.
+
+ It is recognised that not all policies can be formally
+ modelled for all TOEs. This is because either the state
+ of the art is insufficient to formally model a given
+ policy, or because the nature of the TOE renders
+ impossible the modelling of policies that would
+ otherwise be possible to model.
+
+ While access control, information flow control, and data
+ integrity policies have all been formally modelled
+ successfully, the possibility of modelling other
+ policies is based on a case by case decision. Abstention
+ from formally modelling security relevant policies
+ requires argumentation and rests the burden of proof
+ entirely on the developer's side.
+
+ For any security policy where formal models are not
+ possible, the policy must be identified in the
+ assignment of .
+
+
+
+
+ The evaluator shall examine the model to determine that
+ the security behaviour of the TOE is clearly
+ articulated.
+
+ The security policy model's properties describe the
+ TOE's behaviour in enforcing the principles of the
+ policy. For example, a policy that is modelled on the
+ basis of state transitions would include principles of
+ its states, identify its initial state, and define what
+ it means to be a secure state.
+
+ The security policy model's features describe the
+ attributes and conditions of the TOE that come into
+ consideration when enforcing its policy's
+ characteristics. For example, a policy that is modelled
+ on the basis of state transitions would describe the
+ necessary conditions to transform the TOE from one state
+ to the next.
+
+ An informal interpretation of all formal concepts
+ (including attributes, predicates and variables, if
+ available) must also be provided in order to make clear
+ their intended meaning.
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the formal functional
+ specification to determine that it is presented in a
+ formal style.
+
+ If no part of the functional specification is formal,
+ this work unit is not applicable and is therefore
+ considered to be satisfied. The corresponding work will
+ be performed under work unit .
+
+ For any part of the functional specification that is
+ formally presented, the correspondence between that part
+ of the functional specification and the security policy
+ model must be formal. Analysis of the content is
+ performed as part of work units through .
+
+ For guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the semiformal functional
+ specification to determine that it is presented in a
+ semiformal style.
+
+ If the entire functional specification is formal, this
+ work unit is not applicable and is therefore considered
+ to be satisfied. The corresponding work will be
+ performed under work unit .
+
+ For formally-modelled policies whose corresponding
+ description in the functional specification is not
+ formally presented, the correspondence between the model
+ and the functional specification must be a semiformal
+ demonstration. Analysis of the content is performed as
+ part of work units
+ through .
+
+ If a security policy model exists, either this work unit
+ or the previous work unit (or both) will be
+ applicable.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it formally proves the
+ correspondence between the security properties and the
+ security features.
+
+ The proof shall show that the security features enforce
+ the security properties. To determine the enforcement,
+ the evaluator considers the security properties and the
+ security features and verifies that the arguments used
+ in the proof are valid. The proof of correspondence
+ between the security properties and the security
+ features shall be formal.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it proves the internal
+ consistency of the TOE security policy model.
+
+ The proof shall show the absence of contradictions
+ within the TOE security policy model. In determining the
+ absence of contradictions, the evaluator verifies that
+ the arguments used in the proof are valid.
+
+ Since the TOE security policy model is formal, the proof
+ of its internal consistency shall be formal. It is
+ recognised that a complete formal proof of the internal
+ consistency of the TOE security policy model usually is
+ not possible due to the fundamental nature of formal
+ frameworks. Generally, it is sufficient to generate
+ evidence using formal proofs based on the specific TOE
+ security policy model that prove the internal
+ consistency by means of a combination with generic
+ arguments of the formal framework.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is consistent with respect to policies described by the
+ security policies (as articulated by the functional
+ requirements in the ST).
+
+ The examination considers the informal relationships of
+ the model. Hence the meaning of consistency reflects
+ the conventional understanding in contrast to the
+ internal consistency concept of the previous work
+ unit.
+
+ In determining consistency, the evaluator verifies that
+ the rationale shows that each description of properties
+ and features in the security policy model accurately
+ reflects the intent of the security policies. For
+ example, if a policy stated that access control was
+ necessary to the granularity of a single individual,
+ then a security policy model describing the security
+ behaviour of a TOE in the context of controlling groups
+ of users would not be consistent. Likewise, if the
+ policy stated that access control for groups of users
+ was necessary, then a security policy model describing
+ the security behaviour of a TOE in the context of
+ controlling individual users would also not be
+ consistent.
+
+ The evaluator also examines whether the security
+ policies are reflected within their formal counterparts
+ of the security policy model.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is complete with respect to the policies described by
+ the security policies (i.e. as articulated by the
+ functional requirements in the ST).
+
+ In determining completeness of this rationale, the
+ evaluator considers the properties and features of the
+ security policy model and maps those properties and
+ features to explicit policy statements (i.e. functional
+ requirements). The rationale should show that all
+ policies that are required to be modelled have an
+ associated property or feature description in the TOE
+ security policy model.
+
+ Abstention from formally modelling policy statements
+ always calls for justification on the developer's side
+ (also confer the application notes above).
+
+
+
+
+ The evaluator shall examine the demonstration of
+ correspondence to determine that all Assigned policies
+ are mapped to functions within the functional
+ specification.
+
+ If all policies are included within the security policy
+ model (i.e. they are all formally modelled) and the
+ assignment in is
+ therefore empty, this work unit is not applicable and is
+ therefore considered to be satisfied.
+
+ The evaluator verifies that the correspondence
+ demonstrates that the descriptions of the SFR-related
+ functions in the functional specification correspond to
+ the SFRs. This may be done as part of the work units addressing
+ correspondence to the SFRs. However, if the developer
+ provides a well-structured semiformal or informal
+ security policy model to better articulate the notions
+ of security enforced by the TOE, the evaluator will
+ verify that such a model is consistent with the
+ SFRs.
+
+
+
+
+
+
+
+ The design description of a TOE provides both context for a
+ description of the TSF, and a thorough description of the
+ TSF. As assurance needs increase, the level of detail
+ provided in the description also increases. As the size and
+ complexity of the TSF increase, multiple levels of
+ decomposition are appropriate. The design requirements are
+ intended to provide information (commensurate with the given
+ assurance level) so that a determination can be made that
+ the security functional requirements are realised.
+
+
+
+ The design description provides a further-refined
+ description of the TSF from that presented in the functional
+ specification. The functional specification provides a
+ description of what the TSF does at its
+ interface; the design description provides more insight into
+ the TSF by describing how the TSF works in
+ order to perform the functions supporting the SFRs. At lower
+ assurance levels, complete details relating to all portions
+ of the TSF are not required. As the desired assurance
+ increases, more detail is made available so that analysis
+ can be performed that supports the assurance claims being
+ made.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of information that is required to be presented
+ with respect to the TSF, and on the degree of formalism
+ required of the design description.
+
+
+
+ The goal of design documentation is to provide sufficient
+ information to determine the TSF boundary, and to describe
+ how the TSF implements the Security
+ Functional Requirements. The amount and structure of the
+ design documentation will depend on the complexity of the
+ TOE and the number of SFRs; in general, a very complex TOE
+ with a large number of SFRs will require more design
+ documentation than a very simple TOE implementing only a few
+ SFRs. Very complex TOEs will benefit (in terms of the
+ assurance provided) from the production of differing levels
+ of decomposition in describing the design, while very simple
+ TOEs do not require both high-level and low-level
+ descriptions of its implementation.
+
+ This family uses two levels of decomposition: the
+ subsystem and the module.
+ A module is the most specific description of functionality:
+ it is a description of the implementation. A developer
+ should be able to implement the part of the TOE described by
+ the module with no further design decisions. A subsystem is
+ a description of the design of the TOE; it helps to provide
+ a high-level description of what a portion of the TOE is
+ doing and how. As such, a subsystem may be further divided
+ into lower-level subsystems, or into modules. Very complex
+ TOEs might require several levels of subsystems in order to
+ adequately convey a useful description of how the TOE works.
+ Very simple TOEs, in contrast, might not require a subsystem
+ level of description; the module might clearly describe how
+ the TOE works.
+
+ The general approach adopted for design documentation is
+ that, as the level of assurance increases, the emphasis of
+ description shifts from the general (subsystem level) to
+ more (module level) detail. In cases where a module-level
+ of abstraction is appropriate because the TOE is simple
+ enough to be described at the module level, yet the level of
+ assurance calls for a subsystem level of description, the
+ module-level description alone will suffice. For complex
+ TOEs, however, this is not the case: an enormous amount of
+ (module-level) detail would be incomprehensible without an
+ accompanying subsystem level of description.
+
+ This approach follows the general paradigm that providing
+ additional detail about the implementation of the TSF will
+ result in greater assurance that the SFRs are implemented
+ correctly, and provide information that can be used to
+ demonstrate this in testing ().
+
+ In the requirements for this family, the term
+ interface is used as the means of
+ communication (between two subsystems or modules). It
+ describes how the communication is invoked; this is similar
+ to the details of TSFI (see ). The term interaction is
+ used to identify the purpose for communication; it
+ identifies why two subsystems or modules are
+ communicating.
+
+
+ The requirements define collections of details about
+ subsystems and modules to be provided:
+
+ The subsystems and modules are
+ identified with a simple list of what
+ they are.
+
+ Subsystems and modules may be categorised
+ (either implicitly or explicitly) as ``SFR-enforcing'',
+ ``SFR-supporting'', or ``SFR-non-interfering''; these terms are
+ used the same as they are used in .
+
+ A subsystem's behaviour is what it does. The
+ behaviour may also be categorised as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering. The behaviour of the
+ subsystem is never categorised as more SFR-relevant than the
+ category of the subsystem itself. For example, an SFR-enforcing
+ subsystem can have SFR-enforcing behaviour as well as
+ SFR-supporting or SFR-non-interfering behaviour.
+ A behaviour summary of a
+ subsystem is an overview of the actions it performs
+ (e.g. ``The TCP subsystem assembles IP datagrams into
+ reliable byte streams'').
+ A behaviour description of a
+ subsystem is an explanation of everything it
+ does. This description should be at a level of detail
+ that one can readily determine whether the behaviour
+ has any relevance to the enforcement of the
+ SFRs.
+
+ A description of interactions among or between
+ subsystems or modules identifies the reason that subsystems or
+ modules communicate, and characterises the information that is
+ passed. It need not define the information to the same level of
+ detail as an interface specification. For example, it would be
+ sufficient to say ``subsystem X requests a block of memory from
+ the memory manager, which responds with the location of the
+ allocated memory.
+ A description of interfaces provides the
+ details of how the interactions among modules are achieved.
+ Rather than describing the reason the modules are communicating
+ or the purpose of their communication (that is, the description
+ of interactions), the description of interfaces describes the
+ details of how that communication is accomplished, in terms of
+ the structure and contents of the messages, semaphores, internal
+ process communications, etc.
+
+
+ The purpose describes how a module provides
+ their functionality. It provides sufficient detail that no
+ further design decisions are needed. The correspondence between
+ the implementation representation that implements the module,
+ and the purpose of the module should be readily apparent.
+ A module is otherwise described
+ in terms of whatever is identified in the
+ element. Subsystems and modules, and
+ ``SFR-enforcing'', etc. are all further explained in
+ greater detail in .
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each
+ SFR-supporting or SFR-non-interfering TSF subsystem in
+ sufficient detail to determine that it is not SFR-enforcing.
+
+
+ The design shall summarise the SFR-enforcing behaviour of
+ the SFR-enforcing subsystems.
+
+
+ The design shall provide a description of the interactions
+ among SFR-enforcing subsystems of the TSF, and between the
+ SFR-enforcing subsystems of the TSF and other subsystems of
+ the TSF.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-supporting or SFR-non-interfering subsystem of the TSF
+ is described such that the evaluator can determine that the
+ subsystem is SFR-supporting or SFR-non-interfering.
+
+ SFR-supporting and SFR-non-interfering subsystems do not need to
+ be described in detail as to how they function in the system.
+ However, the evaluator makes a determination, based on the
+ evidence provided by the developer, that the subsystems that do
+ not have high-level descriptions are SFR-supporting or
+ SFR-non-interfering. Note that if the developer provides a
+ uniform level of detailed documentation then this work unit will
+ be largely satisfied, since the point of categorising the
+ subsystems is to allow the developer to provide less information
+ for SFR-supporting and SFR-non-interfering subsystems than for
+ SFR-enforcing subsystems.
+
+ An SFR-supporting subsystem is one that is depended on
+ by an SFR-enforcing subsystem in order to implement an
+ SFR, but does not play as direct a role as an
+ SFR-enforcing subsystem. An SFR-non-interfering
+ subsystem is one that is not depended upon, in either a
+ supporting or enforcing role, to implement an
+ SFR.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and high-level
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. A high-level description need not refer to
+ specific data structures (although it may), but instead
+ talks about more general data flow, message flow, and
+ control relationships within a subsystem. The goal of
+ these descriptions is to give the evaluator enough
+ information to understand how the
+ SFR-enforcing behaviour is achieved. Note that the
+ evaluator should find unacceptable asserts of
+ SFR-enforcement in the TOE design documentation for this
+ work unit. It should be noted that it is the
+ evaluator's determination with respect to what
+ ``high-level'' means for a particular TOE, and the
+ evaluator obtains enough information from the developer
+ to make a sound verdict for this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work
+ unit
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the
+ SFR-enforcing subsystems and other subsystems is to help provide
+ the reader a better understanding of how the TSF performs it
+ functions. These interactions do not need to be characterised at
+ the implementation level (e.g., parameters passed from one
+ routine in a subsystem to a routine in a different subsystem;
+ global variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem), but the
+ data elements identified for a particular subsystem that are
+ going to be used by another subsystem need to be covered in this
+ discussion. Any control relationships between subsystems (e.g.,
+ a subsystem responsible for configuring a rule base for a
+ firewall system and the subsystem that actually implements these
+ rules) should also be described.
+
+ The evaluators need to use their own judgement in assessing the
+ completeness of the description. If the reason for an
+ interaction is unclear, or if there are SFR-related interactions
+ (discovered, for instance, in examining the descriptions of
+ subsystem behaviour) that do not appear to be described, the
+ evaluator ensures that this information is provided by the
+ developer. However, if the evaluator can determine that
+ interactions among a particular set of subsystems, while
+ incompletely described by the developer, will not aid in
+ understanding the overall functionality nor security
+ functionality provided by the TSF, then the evaluator may choose
+ to consider the description sufficient, and not pursue
+ completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each SFR
+ non-interfering subsystem of the TSF in detail sufficient to
+ determine that it is SFR non-interfering.
+
+
+ The design shall describe the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+
+ The design shall summarise the SFR-supporting and
+ SFR-non-interfering behaviour of the SFR-enforcing subsystems.
+
+
+ The design shall summarise the behaviour of the
+ SFR-supporting subsystems.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each SFR-non-interfering subsystem of the TSF is
+ described such that the evaluator can determine that the
+ subsystem is SFR-non-interfering.
+
+ SFR-non-interfering subsystems do not need to be
+ described in detail as to how they function in the
+ system. However, the evaluator makes a determination,
+ based on the evidence provided by the developer, that
+ the subsystems that do not have detailed descriptions
+ are SFR-non-interfering. Note that if the developer
+ provides a uniform level of detailed documentation then
+ this work unit will be largely satisfied, since the
+ point of categorising the subsystems is to allow the
+ developer to provide less information for
+ SFR-non-interfering subsystems than for SFR-enforcing
+ and SFR-supporting subsystems.
+
+ An SFR-non-interfering subsystem is one on which the
+ SFR-enforcing and SFR-supporting subsystems have no
+ dependence; that is, they play no role in implementing
+ SFR functionality.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and detailed
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. While not at the level of an algorithmic
+ description, a detailed description of behaviour
+ typically discusses how the functionality is provided in
+ terms of what key data and data structures are, what
+ control relationships exist within a subsystem, and how
+ these elements work together to provide the
+ SFR-enforcing behaviour. Such a description also
+ references SFR-supporting behaviour, which the evaluator
+ should consider in performing subsequent work
+ units.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work unit.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that it
+ provides a complete and accurate high-level description of the
+ SFR-supporting and SFR-non-interfering behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous work unit, this work unit calls for
+ the evaluator to assess the information provided for
+ SFR-enforcing subsystems that is SFR-supporting or
+ SFR-non-interfering. The goal of this assessment is two-fold.
+ First, it should provide the evaluator greater understanding of
+ the way each subsystem works. Second, the evaluator determines
+ that all SFR-enforcing behaviour exhibited by a subsystem has
+ been described. Unlike the previous work unit, the information
+ provided for the SFR-supporting or SFR-non-interfering behaviour
+ does not have to be as detailed as that provided by the
+ SFR-enforcing behaviour. For example, data structures or data
+ items that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all. It is the
+ evaluator's determination, however, with respect to what
+ ``high-level'' means for a particular TOE, and the evaluator
+ obtains enough information from the developer (even if it turns
+ out to be equivalent to information provided for the parts of
+ the subsystem that are SFR-enforcing) to make a sound verdict
+ for this work unit.
+
+ The evaluator is cautioned, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator examines
+ other information available (e.g., functional specification,
+ security architecture description). Descriptions of functionality in these
+ documents should be consistent with what is provided for
+ evidence for this work unit. In particular, the functional
+ specification should be used to determine that the behaviour
+ required to implement the TSF Interfaces described by the
+ functional specification are completely described by the
+ subsystem, since the behaviour will either be SFR-enforcing,
+ SFR-supporting or SFR-non-interfering.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete and accurate high-level
+ description of the behaviour of the SFR-supporting
+ subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous two work units, this work
+ unit calls for the developer to provide (and the
+ evaluator to assess) information about SFR supporting
+ subsystems. Such subsystems should be referenced by the
+ descriptions of the SFR-enforcing subsystems, as well as
+ by the descriptions of interactions in work unit . The goal of evaluator's
+ assessment, like that for the previous work unit, is
+ two-fold. First, it should provide the evaluator with
+ an understanding of the way each SFR-supporting
+ subsystem works. Second, the evaluator determines that
+ the behaviour is described in enough detail so that the
+ way in which the subsystem supports the SFR-enforcing
+ behaviour is clear, and that the behaviour is not itself
+ SFR-enforcing. The information provided for
+ SFR-supporting subsystem's behaviour does not have to be
+ as detailed as that provided by the SFR-enforcing
+ behaviour. For example, data structures or data items
+ that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all.
+ It is the evaluator's determination, however, with
+ respect to what ``high-level'' means for a particular
+ TOE, and the evaluator obtains enough information from
+ the developer (even if it turns out to be equivalent to
+ information provided for the parts of the subsystem that
+ are SFR-enforcing) to make a sound verdict for this work
+ unit.
+
+ The evaluator is cautions, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work unit.
+ In particular, the functional specification should be
+ used to determine that the behaviour required to
+ implement the TSF Interfaces described by the functional
+ specification are completely described by the
+ subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs it functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem need to
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be
+ described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the descriptions of subsystem behaviour) that do not
+ appear to be described, the evaluator ensures that this
+ information is provided by the developer. However, if the
+ evaluator can determine that interactions among a particular set
+ of subsystems, while incompletely described by the developer,
+ will not aid in understanding the overall functionality nor
+ security functionality provided by the TSF, then the evaluator
+ may choose to consider the description sufficient, and not
+ pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing
+ modules and enough information about the SFR-supporting
+ and SFR-non-interfering modules for the evaluator to
+ determine that the SFRs are completely and accurately
+ implemented; as such, the TOE design provides an
+ explanation of the implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the evaluator
+ determines that the TSF boundary has been adequately
+ described. Second, the evaluator determines that the developer
+ has provided documentation that conforms to the content and
+ presentation requirements for this subsystem, and that is
+ consistent with other documentation provided for the
+ TOE. Finally, the evaluator must analyse the design information
+ provided for the SFR-enforcing modules (at a detailed level) and
+ the SFR-supporting and SFR-non-interfering modules (at a less detailed level) to
+ understand how the system is implemented, and with that
+ knowledge ensure that the TSFI in the functional specification
+ are adequately described, and that the test information
+ adequately tests the TSF (done in the work units).
+
+ It is important to note that while the developer is obligated to
+ provide a complete description of the TSF (although
+ SFR-enforcing modules will have more detail than the
+ SFR-supporting or SFR-non-interfering modules), the evaluator is
+ expected to use their judgement in performing their
+ analysis. While the evaluator is expected to look at every
+ module, the detail to which they examine each module may
+ vary. The evaluator analyses each module in order to gain enough
+ understanding to determine the effect of the functionality of
+ the module on the security of the system, and the depth to which
+ they need to analyse the module may vary depending on the
+ module's role in the system. An important aspect of this
+ analysis is that the evaluator should use the other
+ documentation provided (TSS, functional specification, security
+ architecture description, and the TSF internal document) in
+ order to determine that the functionality that is described is
+ correct, and that the implicit designation of SFR-supporting or
+ SFR-non-interfering modules (see below) is supported by their
+ role in the system architecture.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a description of each subsystem of
+ the TSF.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing module in terms of
+ its purpose and relationship with other modules.
+
+
+ The design shall describe each SFR-enforcing module in terms of
+ its SFR-related interfaces, return values from those interfaces,
+ interaction with other modules and called
+ SFR-related interfaces to other SFR-enforcing modules.
+
+
+ The design shall describe each SFR-supporting or
+ SFR-non-interfering module in terms of its purpose and
+ interaction with other modules.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules). Depending upon the
+ complexity of the TOE, its design may be described in terms of
+ subsystems and modules, as described in CC Part 3 . For a very simple TOE that can be
+ described solely at the ``module'' level (see ), this work unit is not
+ applicable and therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ security architecture description) in making this
+ determination. For example, if the
+ functional specification contains interfaces to
+ functionality that does not appear to be described in
+ the TOE design description, it may be the case that a
+ portion of the TSF has not been included
+ appropriately. Making this determination will likely be
+ an iterative process, where as more analysis is done on
+ the other evidence, more confidence can be gained with
+ respect to the completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation in a level of detail that can serve
+ as a guide to reviewing the implementation representation. A description of a module should
+ be such that one could create an implementation of the module from the description, and the
+ resulting implementation would be 1) identical to the actual TSF implementation in terms of
+ the interfaces presented, 2) identical in the use of interfaces that are mentioned in the
+ design, and 3) functionally equivalent to the description of the purpose of the TSF module.
+ For instance, RFC 793 provides a high-level description of the TCP protocol. It is
+ necessarily implementation independent. While it provides a wealth of detail, it is
+ not
+ a suitable design description because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC, and implementation choices (for
+ instance, the use of global data vs. local data in various parts of the implementation) may
+ have an impact on the analysis that is performed. The design description of the TCP module would
+ list the interfaces presented by the implementation (rather than just those defined in RFC 793),
+ as well as an algorithm description of the processing associated with the modules implementing
+ TCP (assuming it was part of the TSF).
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-non-interfering subsystem of the TSF is described such that
+ the evaluator can determine that the subsystem is SFR-non-interfering.
+ If the design is presented solely in terms of modules, then this work unit
+ will be considered satisfied by the assessment done in subsequent work units;
+ no explicit action on the part of the evaluator is necessary in this case.
+ An SFR-non-interfering subsystem is one on which the SFR-enforcing and
+ SFR-supporting subsystems have no dependence; that is, they play no role
+ in implementing SFR functionality.
+ The evaluator ensures that all subsystems of the TSF have a description.
+ While the description should focus on the role that the subsystem do not plays
+ in enforcing or supporting the implementation of the SFRs, enough information
+ must be present so that a context for understanding the SFR-non-interfering
+ functionality is provided.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a subsystem-level
+ description of the TSF in addition to the modular description,
+ the goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs its functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem should
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the module-level documentation) that do not appear to
+ be described, the evaluator ensures that this information is
+ provided by the developer. However, if the evaluator can
+ determine that interactions among a particular set of
+ subsystems, while incompletely described by the developer, and a
+ complete description will not aid in understanding the overall
+ functionality nor security functionality provided by the TSF,
+ then the evaluator may choose to consider the description
+ sufficient, and not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing module and relationship with other modules is complete and accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for component. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the TSF internals, or the security architecture
+ description. However, the evaluator uses the information present
+ in those documents to the extent possible to help ensure that
+ the purpose is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing module contain an accurate and complete
+ description of the SFR-related parameters, the
+ invocation conventions for each interface, and any
+ values returned directly by the interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are fixed)
+ need not be specified or described, since they are not a factor in testing.
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of SFR-related
+ parameters, and descriptions of these parameters. Note
+ that global data would also be considered parameters if
+ used by the module (either as inputs or outputs) when
+ invoked. If a parameter were expected to take on a set
+ of values (e.g., a ``flag'' parameter), the complete set
+ of values the parameter could take on that would have an
+ effect on module processing would be
+ specified. Likewise, parameters representing data
+ structures are described such that each field of the
+ data structure is identified and described. Note that
+ different programming languages may have additional
+ ``interfaces'' that would be non-obvious; an example
+ would be operator/function overloading in C++. This
+ ``implicit interface'' in the class description would
+ also be described as part of the low-level TOE
+ design. Note that although a module could present only
+ one interface, it is more common that a module presents
+ a small set of related interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TOE design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+
+
+
+
+ The evaluator shall examine the TOE design to determine that
+ SFR-supporting and SFR-non-interfering modules are correctly
+ categorised.
+
+ In the cases where the developer has provided different amounts
+ of information for different modules, an implicit categorisation
+ has been done. That is, modules (for instance) with detail
+ presented on their SFR-related interfaces (see ) are candidate SFR-enforcing
+ modules, although examination by the evaluator may lead to a
+ determination that some set of them are SFR-supporting or
+ SFR-non-interfering. Those with only a description of their
+ purpose and interaction with other modules (for instance) are
+ ``implicitly categorised'' as SFR-supporting or
+ SFR-non-interfering.
+
+ In these cases, a key focus of the evaluator for this work unit
+ is attempting to determine from the evidence provided for each
+ module implicitly categorised as SFR-supporting or
+ SFR-non-interfering and the evaluation information about other
+ modules (in the TOE design, the functional specification, the
+ security architecture description, and the operational user
+ guidance), whether the module is indeed SFR-supporting or
+ SFR-non-interfering. At this level of assurance some error
+ should be tolerated; the evaluator does not have to be
+ absolutely sure that a given module is SFR-supporting or
+ SFR-non-interfering, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ SFR-supporting or SFR-non-interfering module is SFR-enforcing,
+ the evaluator requests additional information from the developer
+ in order to resolve the apparent inconsistency. For instance,
+ suppose the documentation for Module A (an SFR-enforcing module)
+ indicates that it calls Module B to perform an access check on a
+ certain type of construct. When the evaluator examines the
+ information associated with Module B, they find that all the
+ developer has provided is a purpose and a set of interactions
+ (thus implicitly categorising Module B as SFR-supporting or
+ SFR-non-interfering). On examining the purpose and interactions
+ from Module A, the evaluator finds no mention of Module B
+ performing any access checks, and Module A is not listed as a
+ module with which Module B interacts. At this point the
+ evaluator should approach the developer to resolve the
+ discrepancies between the information provided in Module A and
+ that in Module B.
+
+ Another example would be where the evaluator examines the
+ mapping of the TSFI to the modules as provided by . This examination shows that
+ Module C is associated with an SFR requiring identification of
+ the user. Again, when the evaluator examines the information
+ associated with Module C, they find that all the developer has
+ provided is a purpose and a set of interactions (thus implicitly
+ categorising Module C as SFR-supporting or
+ SFR-non-interfering). Examining the purpose and interactions
+ presented for Module C, the evaluator is unable to determine why
+ Module C, listed as mapping to a TSFI concerned with user
+ identification, would not be classified as SFR-enforcing. Again,
+ the evaluator should approach the developer to resolve this
+ discrepancy.
+
+
+ A final example is from the opposite point of view. As
+ before, the developer has provided information associated
+ with Module D consisting of a purpose and a set of
+ interactions (thus implicitly categorising Module D as
+ SFR-supporting or SFR-non-interfering). The evaluator
+ examines all of the evidence provided, including the purpose
+ and interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the TOE,
+ the interactions are consistent with that description, and
+ there is nothing to indicate that Module D is
+ SFR-enforcing. In this case, the evaluator should not demand
+ more information about Module D ``just be to sure'' it is
+ correctly categorised. The developer has met their
+ obligations and the resulting assurance the evaluator has in
+ the implicit categorisation of Module D is (by definition)
+ appropriate for this assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that the
+ description of the purpose of each SFR-supporting or
+ SFR-non-interfering module is complete and accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ Because the modules are at such a low level, it may be difficult determine
+ completeness and accuracy impacts from other documentation,
+ such as administrative guidance, the functional specification,
+ the security architecture description, or the TSF internals document.
+ However, the evaluator uses the information present in those documents
+ to the extent possible to help ensure that the function is accurately
+ and completely described. This analysis can be aided by the analysis
+ performed for the work units for the ADV_TDS.3.10C element,
+ which maps the TSFI in the functional specification to the modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that the
+ description of a SFR-supporting or SFR-non-interfering module's
+ interaction with other modules is complete and accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the function is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a description of
+ the implementation of the TSF. The TSFI provide a description of
+ how the implementation is exercised. The evidence from the
+ developer identifies the module that is initially invoked when
+ an operation is requested at the TSFI, and identifies the chain
+ of modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However, a
+ complete call tree for each TSFI is not required for this work
+ unit. The cases in which more than one module would have to be
+ identified are where there are ``entry point'' modules or
+ wrapper modules that have no functionality other than
+ conditioning inputs or de-multiplexing an input. Mapping to one
+ of these modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped to a module at the TSF boundary.
+ This determination can be made by reviewing the module description and its
+ interfaces/interactions. The next aspect of accuracy is that each TSFI identifies
+ a chain of modules between the initial module identified and a module
+ that is primarily responsible for implementing the function presented at the TSF.
+ Note that this may be the initial module, or there may be several modules,
+ depending on how much pre-conditioning of the inputs is done. It should be noted that
+ one indicator of a pre-conditioning module is that it is invoked for a large number
+ of the TSFI, where the TSFI are all of similar type (e.g., system call).
+ The final aspect of accuracy is that the mapping makes sense. For instance,
+ mapping a TSFI dealing with access control to a module that checks passwords
+ is not accurate. The evaluator should again use judgement in making this determination.
+ The goal is that this information aids the evaluator in understanding the system and
+ implementation of the SFRs, and ways in which entities at the TSF boundary can interact
+ with the TSF. The bulk of the assessment of whether the SFRs are described accurately
+ by the modules is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems, and later to modules. Note that this map may have to be
+ at a level of detail below the component or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to modules x, y, and z of subsystem A;
+ (rule 2) to modules x, p, and q of subsystem A; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems, and modules that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and modules, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems, and modules implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems and modules have been identified, or if
+ adequate detail had been provided for those subsystems and modules.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing and
+ SFR-supporting modules and enough information about the
+ SFR-non-interfering modules for the evaluator to determine
+ that the SFRs are completely and accurately implemented;
+ as such, the TOE design provides an explanation of the
+ implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the evaluator
+ determines that the TSF boundary has been adequately
+ described. Second, the evaluator determines that the developer
+ has provided documentation that conforms to the content and
+ presentation requirements this subsystem, and that is consistent
+ with other documentation provided for the TOE. Finally, the
+ evaluator must analyse the design information provided for the
+ SFR-enforcing modules (at a detailed level) and the
+ SFR-supporting and SFR-non-interfering modules (at a less detailed level) to
+ understand how the system is implemented, and with that
+ knowledge ensure that the TSFI in the functional specification
+ are adequately described, and that the test information
+ adequately tests the TSF (done in the work units).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each subsystem of
+ the TSF, supported by informal, explanatory text where appropriate.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing and SFR-supporting
+ module in terms of its purpose and relationship with other
+ modules.
+
+
+ The design shall describe each SFR-enforcing and SFR-supporting module
+ in terms of its SFR-related interfaces, return values from those interfaces,
+ interaction with other modules and called SFR-related
+ interfaces to other SFR-enforcing or SFR-supporting modules.
+
+
+ The design shall describe each SFR-non-interfering module in
+ terms of its purpose and interaction with other modules.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . For a very
+ simple TOE that can be described solely at the
+ ``module'' level (see ), this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ architectural description) in making this
+ determination. For example, if the functional
+ specification contains interfaces to functionality that
+ does not appear to be described in the TOE design
+ description, it may be the case that a portion of the
+ TSF has not been included appropriately. Making this
+ determination will likely be an iterative process, where
+ as more analysis is done on the other evidence, more
+ confidence can be gained with respect to the
+ completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation in a level of detail that can serve
+ as a guide to reviewing the implementation representation. A description of a module should
+ be such that one could create an implementation of the module from the description, and the
+ resulting implementation would be 1) identical to the actual TSF implementation in terms of
+ the interfaces presented, 2) identical in the use of interfaces that are mentioned in the
+ design, and 3) functionally equivalent to the description of the purpose of the TSF module.
+ For instance, RFC 793 provides a high-level description of the TCP protocol. It is
+ necessarily implementation independent. While it provides a wealth of detail, it is
+ not
+ a suitable design description because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC, and implementation choices (for
+ instance, the use of global data vs. local data in various parts of the implementation) may
+ have an impact on the analysis that is performed. The design description of the TCP module would
+ list the interfaces presented by the implementation (rather than just those defined in RFC 793),
+ as well as an algorithm description of the processing associated with the modules implementing
+ TCP (assuming it was part of the TSF).
+
+
+
+
+ The evaluator shall check the TOE design to determine
+ that the TSF modules are identified as either
+ SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The purpose of designating each module (according to the role a
+ particular module plays in the enforcement of the SFRs) is to
+ allow developers to provide less information about the parts of
+ the TSF that have little role in security. It is always
+ permissible for the developer to provide more information or
+ detail than the requirements demand, as might occur when the
+ information has been gathered outside the evaluation context. In
+ such cases the developer must still designate the modules as
+ either SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The accuracy of these designations is continuously
+ reviewed as the evaluation progresses. The concern is
+ the mis-designation of modules as being less important
+ (and hence, having less information) than is really the
+ case. While blatant mis-designations may be immediately
+ apparent (e.g., designating an authentication module as
+ anything but SFR-enforcing when is one of the SFRs being claimed), other
+ mis-designations might not be discovered until the TSF
+ is better understood. The evaluator must therefore keep
+ in mind that these designations are the developer's
+ initial best effort, but are subject to change. Further
+ guidance is provided under work unit , which examines the
+ accuracy of these designations.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+ The evaluator shall examine the TDS documentation to determine
+ that the semiformal notation used for describing the subsystems, modules and
+ their interfaces is defined or referenced.A semiformal notation can be either defined by the sponsor or
+ a corresponding standard be referenced. The evaluator should provide a mapping
+ of security functions and their interfaces outlining in what part of the
+ documentation a function or interface is semiformal described and what notation
+ is used. The evaluator examines all semiformal notations used to make sure that
+ they are of a semiformal style and to justify the appropriateness of the manner
+ how the semiformal notations are used for the TOE.The evaluator is reminded that a semi-formal presentation is
+ characterised by a standardised format with a well-defined syntax that reduces
+ ambiguity that may occur in informal presentations. The syntax of all semiformal
+ notations used in the functional specification shall be defined or a corresponding
+ standard be referenced. The evaluator verifies that the semiformal notations used
+ for expressing the functional specification are capable of expressing features
+ relevant to security. In order to determine this, the evaluator can refer to the
+ SFR and compare the TSF security features stated in the ST and those described
+ in the FSP using the semiformal notations.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-non-interfering subsystem of the TSF is described such that
+ the evaluator can determine that the subsystem is SFR-non-interfering.
+ If the design is presented solely in terms of modules, then this work unit
+ will be considered satisfied by the assessment done in subsequent work units;
+ no explicit action on the part of the evaluator is necessary in this case.
+ An SFR-non-interfering subsystem is one on which the SFR-enforcing and
+ SFR-supporting subsystems have no dependence; that is, they play no role
+ in implementing SFR functionality.
+ The evaluator ensures that all subsystems of the TSF have a description.
+ While the description should focus on the role that the subsystem do not plays
+ in enforcing or supporting the implementation of the SFRs, enough information
+ must be present so that a context for understanding the SFR-non-interfering
+ functionality is provided.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a subsystem-level
+ description of the TSF in addition to the modular description,
+ the goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs it functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem need to
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be
+ described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the module-level documentation) that do not appear to
+ be described, the evaluator ensures that this information is
+ provided by the developer. However, if the evaluator can
+ determine that interactions among a particular set of
+ subsystems, while incompletely described by the developer, and a
+ complete description will not aid in understanding the overall
+ functionality nor security functionality provided by the TSF,
+ then the evaluator may choose to consider the description
+ sufficient, and not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF to
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing and SFR-supporting module, and relationship with other modules
+ is complete and accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the modules
+ have been categorised by the developer or not, it is the
+ evaluator's responsibility to determine that the modules
+ have the appropriate information for their role
+ (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for subsystems. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the TSF internals, or the security architecture
+ description. However, the evaluator uses the information present
+ in those documents to the extent possible to help ensure that
+ the purpose is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing and SFR-supporting module contain an
+ accurate and complete description of the SFR-related
+ parameters, the invocation conventions for each
+ interface, and any values returned directly by the
+ interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are
+ fixed).
+ SFR-related interfaces of SFR-supporting modules are all
+ interfaces of SFR-supporting modules that are called directly
+ or indirectly from SFR-enforcing modules. Those interfaces
+ need to be described with all the parameter used in such a
+ call. This allows the evaluator to understand the purpose of
+ the call to the SFR-supporting module in the context of
+ operation of the SFR-enforcing modules.
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of parameters, and
+ descriptions of these parameters. Note that global data
+ would also be considered parameters if used by the
+ module (either as inputs or outputs) when invoked. If a
+ parameter were expected to take on a set of values
+ (e.g., a ``flag'' parameter), the complete set of values
+ the parameter could take on that would have an effect on
+ module processing would be specified. Likewise,
+ parameters representing data structures are described
+ such that each field of the data structure is identified
+ and described. Note that different programming languages
+ may have additional ``interfaces'' that would be
+ non-obvious; an example would be operator/function
+ overloading in C++. This ``implicit interface'' in the
+ class description would also be described as part of the
+ low-level TOE design. Note that although a module could
+ present only one interface, it is more common that a
+ module presents a small set of related
+ interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TDS design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that SFR-non-interfering modules are correctly
+ categorised.
+
+ As mentioned in work unit ,
+ less information is required about modules that are
+ SFR-non-interfering. A key focus of the evaluator for this work
+ unit is attempting to determine from the evidence provided for
+ each module implicitly categorised as SFR-non-interfering and
+ the evaluation (information about other modules in the TOE
+ design, the functional specification, the security architecture
+ description, the operational user guidance, the TSF internals
+ document, and perhaps even the implementation representation)
+ whether the module is indeed SFR-non-interfering. At this level
+ of assurance some error should be tolerated; the evaluator does
+ not have to be absolutely sure that a given module is
+ SFR-non-interfering, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ SFR-non-interfering module is SFR-enforcing or SFR-supporting,
+ the evaluator requests additional information from the developer
+ in order to resolve the apparent inconsistency. For example,
+ suppose the documentation for Module A (an SFR-enforcing module)
+ indicates that it calls Module B to perform an access check on a
+ certain type of construct. When the evaluator examines the
+ information associated with Module B, it is discovered that the
+ only information the developer has provided is a purpose and a
+ set of interactions (thus implicitly categorising Module B as
+ SFR-supporting or SFR-non-interfering). On examining the purpose and interactions
+ from Module A, the evaluator finds no mention of Module B
+ performing any access checks, and Module A is not listed as a
+ module with which Module B interacts. At this point the
+ evaluator should approach the developer to resolve the
+ discrepancies between the information provided in Module A and
+ that in Module B.
+
+ Another example would be where the evaluator examines
+ the mapping of the TSFI to the modules as provided by
+ . This examination
+ shows that Module C is associated with an SFR requiring
+ identification of the user. Again, when the evaluator
+ examines the information associated with Module C, they
+ find that all the developer has provided is a purpose
+ and a set of interactions (thus implicitly categorising
+ Module C as SFR-non-interfering). Examining the purpose
+ and interactions presented for Module C, the evaluator
+ is unable to determine why Module C, listed as mapping
+ to a TSFI concerned with user identification, would not
+ be classified as SFR-enforcing or SFR-supporting. Again,
+ the evaluator should approach the developer to resolve
+ this discrepancy.
+
+ A final example illustrates the opposite situation. As
+ before, the developer has provided information
+ associated with Module D consisting of a purpose and a
+ set of interactions (thus implicitly categorising Module
+ D as SFR-non-interfering). The evaluator examines all of
+ the evidence provided, including the purpose and
+ interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the
+ TOE, the interactions are consistent with that
+ description, and there is nothing to indicate that
+ Module D is SFR-enforcing or SFR-supporting. In this
+ case, the evaluator should not demand more information
+ about Module D ``just be to sure'' it is correctly
+ categorised. The developer has met the obligations and
+ the resulting assurance the evaluator has in the
+ implicit categorisation of Module D is (by definition)
+ appropriate for this assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-non-interfering module is complete and
+ accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the function is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of a SFR-non-interfering module's
+ interaction with other modules is complete and
+ accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ A module's interaction with other modules can be captured in
+ many ways. The intent for the TOE design is to allow the
+ evaluator to understand (in part through analysis of module
+ interactions) the role of the SFR-supporting and
+ SFR-non-interfering modules in the overall TOE
+ design. Understanding of this role will aid the evaluator in
+ performing work unit .
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the interactions are accurately and completely
+ described.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a
+ description of the implementation of the TSF. The TSFI
+ provide a description of how the implementation is
+ exercised. The evidence from the developer identifies
+ the module that is initially invoked when an operation
+ is requested at the TSFI, and identify the chain of
+ modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However,
+ a complete call tree for each TSFI is not required for
+ this work unit. The cases in which more than one module
+ would have to be identified are where there are ``entry
+ point'' modules or wrapper modules that have no
+ functionality other than conditioning inputs or
+ de-multiplexing an input. Mapping to one of these
+ modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a module at the TSF boundary. This determination can
+ be made by reviewing the module description and its
+ interfaces/interactions. The next aspect of accuracy is
+ that each TSFI identifies a chain of modules between the
+ initial module identified and a module that is primarily
+ responsible for implementing the function presented at
+ the TSF. Note that this may be the initial module, or
+ there may be several modules, depending on how much
+ pre-conditioning of the inputs is done. It should be
+ noted that one indicator of a pre-conditioning module is
+ that it is invoked for a large number of the TSFI, where
+ the TSFI are all of similar type (e.g., system
+ call). The final aspect of accuracy is that the mapping
+ makes sense. For instance, mapping a TSFI dealing with
+ access control to a module that checks passwords is not
+ accurate. The evaluator should again use judgement in
+ making this determination. The goal is that this
+ information aids the evaluator in understanding the
+ system and implementation of the SFRs, and ways in which
+ entities at the TSF boundary can interact with the
+ TSF. The bulk of the assessment of whether the SFRs are
+ described accurately by the modules is performed in
+ other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems, and later to modules. Note that this map may have to be
+ at a level of detail below the component or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to modules x, y and z of subsystem A;
+ (rule 2) to x, p, and q of subsystem A; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems, and modules that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and modules, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems, and modules implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems and modules have been identified, or if
+ adequate detail had been provided for those subsystems and modules.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of all modules for the
+ evaluator to determine that the SFRs are completely and
+ accurately implemented; as such, the TOE design provides
+ an explanation of the implementation
+ representation.
+
+
+
+ At this level, there is no differentiation of required
+ information according to SFR-relevance.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each
+ subsystem of the TSF, supported by informal, explanatory text where
+ appropriate.
+
+
+ The design shall provide a description of the interactions among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall provide a semiformal description of each module
+ in terms of its purpose, interaction, interfaces, return values
+ from those interfaces, and called interfaces to other modules,
+ supported by informal, explanatory text where appropriate.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The developer shall provide a formal specification of the
+ TSF subsystems.
+
+
+ The developer shall provide a proof of correspondence
+ between the formal specifications of the TSF subsystems and
+ of the functional specification.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each
+ subsystem of the TSF, supported by informal, explanatory text where
+ appropriate.
+
+
+ The design shall provide a description of the interactions among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each module in semiformal style in terms
+ of its purpose, interaction, interfaces, return values from those interfaces,
+ and called interfaces to other modules, supported by informal, explanatory
+ text where appropriate.
+
+
+ The formal specification of the TSF subsystems shall
+ describe the TSF using a formal style, supported by
+ informal, explanatory text where appropriate.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The proof of correspondence between the formal
+ specifications of the TSF subsystems and of the functional
+ specification shall demonstrate that all behaviour described
+ in the TOE design is a correct and complete refinement of
+ the TSFI that invoked it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The guidance documents class provides the requirements for
+ guidance documentation for all user roles. For the secure
+ preparation and operation of the TOE it is necessary to
+ describe all relevant aspects for the secure handling of the
+ TOE. The class also addresses the possibility of unintended
+ incorrect configuration or handling of the TOE.
+
+ In many cases it may be appropriate that guidance is provided
+ in separate documents for preparation and operation of the
+ TOE, or even separate for different user roles as end-users,
+ administrators, application programmers using software or
+ hardware interfaces, etc.
+
+ The guidance documents class is subdivided into two families
+ which are concerned with the preparative user guidance (what
+ has to be done to transform the delivered TOE into its
+ evaluated configuration in the operational environment as
+ described in the ST) and with the operational user guidance
+ (what has to be done during the operation of the TOE in its
+ evaluated configuration).
+
+
+
+ Assurance class defines
+ requirements directed at the understandability, coverage and
+ completeness of the preparative and operational documentation
+ provided by the developer. This documentation, which provides
+ information for all user roles, is an important factor in the
+ secure preparation and operation of the TOE.
+
+
+
+ The purpose of the guidance document activity is to judge the
+ adequacy of the documentation describing how the user can
+ handle the TOE in a secure manner. Such documentation should
+ take into account the various types of users (e.g. those who
+ accept, install, administrate or operate the TOE) whose
+ incorrect actions could adversely affect the security of the
+ TOE or of their own data.
+
+ The guidance documents class is subdivided into two families
+ which are concerned firstly with the preparative procedures
+ (all that has to be done to transform the delivered TOE into
+ its evaluated configuration in the environment as described in
+ the ST, i.e. accepting and installing the TOE) and secondly
+ with the operational user guidance (all that has to be done
+ during the operation of the TOE in its evaluated
+ configuration, i.e. operation and administration).
+
+
+
+ The guidance documents activity applies to those functions and
+ interfaces which are related to the security of the TOE. The
+ secure configuration of the TOE is described in the ST.
+
+
+
+
+ Operational user guidance refers to written material that is
+ intended to be used by all types of users of the TOE in its
+ evaluated configuration: end-users, persons responsible for
+ maintaining and administering the TOE in a correct manner
+ for maximum security, and by others (e.g. programmers) using
+ the TOE's external interfaces. Operational user guidance
+ describes the security functionality provided by the TSF,
+ provides instructions and guidelines (including warnings),
+ helps to understand the TSF and includes the
+ security-critical information, and the security-critical
+ actions required, for its secure use. Misleading and
+ unreasonable guidance should be absent from the guidance
+ documentation, and secure procedures for all modes of
+ operation should be addressed. Insecure states should be
+ easy to detect.
+
+ The operational user guidance provides a measure of
+ confidence that non-malicious users, administrators,
+ application providers and others exercising the external
+ interfaces of the TOE will understand the secure operation
+ of the TOE and will use it as intended. The evaluation of
+ the user guidance includes investigating whether the TOE can
+ be used in a manner that is insecure but that the user of
+ the TOE would reasonably believe to be secure. The objective
+ is to minimise the risk of human or other errors in
+ operation that may deactivate, disable, or fail to activate
+ security functionality, resulting in an undetected insecure
+ state.
+
+
+
+ Requirements for operational user guidance help ensure that
+ all types of users are able to operate the TOE in a secure
+ manner (e.g. the usage constraints assumed by the PP or ST
+ must be clearly explained and illustrated). It should be
+ excluded that the TOE can be used in a manner that is
+ insecure but that the user of the TOE would reasonably
+ believe to be secure. Operational user guidance is the
+ primary vehicle available to the developer for providing the
+ TOE users with the necessary background and specific
+ information on how to correctly use the TOE's protection
+ functions.
+
+ Operational user guidance must do two things. First, it
+ needs to explain what the security functionality accessible
+ by the user does and how it is to be used, so that users are
+ able to consistently and effectively protect their
+ information. Second, it needs to explain the user's role in
+ maintaining the TOE's security.
+
+
+
+ This family contains only one component.
+
+
+
+ There may be different user roles or groups that are
+ recognised by the TOE and that can interact with the
+ TSF. These user roles and groups should be taken into
+ consideration by the operational user guidance. They may be
+ roughly grouped into administrators and non-administrative
+ users, or more specifically grouped into persons responsible
+ for receiving, accepting, installing and maintaining the
+ TOE, application programmers, revisors, auditors,
+ daily-management, end-users. Each role can encompass an
+ extensive set of capabilities, or can be a single
+ one.
+
+ The requirement
+ encompasses the aspect that any warnings to the users during
+ operation of a TOE with regard to the security problem
+ definition and the security objectives for the operational
+ environment described in the PP/ST are appropriately covered
+ in the user guidance.
+
+ The concept of secure values, as employed in , has relevance where a user
+ has control over security parameters. Guidance needs to be
+ provided on secure and insecure settings for such
+ parameters.
+
+ requires that the
+ user guidance describes the appropriate reactions to all
+ security-relevant events. Although many security-relevant
+ events are the result of performing functions, this need not
+ always be the case (e.g. the audit log fills up, an
+ intrusion is detected). Furthermore, a security-relevant
+ event may happen as a result of a specific chain of
+ functions or, conversely, several security-relevant events
+ may be triggered by one function.
+
+ requires that the
+ user guidance is clear and reasonable. Misleading or
+ unreasonable guidance may result in a user of the TOE
+ believing that the TOE is secure when it is not.
+
+ An example of misleading guidance would be the description
+ of a single guidance instruction that could be parsed in
+ more than one way, one of which may result in an insecure
+ state.
+
+ An example of unreasonable guidance would be a
+ recommendation to follow a procedure that is so complicated
+ that it cannot reasonably be expected that users will follow
+ this guidance.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the user guidance describes for each user role the
+ security functionality and interfaces provided by the TSF,
+ provides instructions and guidelines for the secure use of
+ the TOE, addresses secure procedures for all modes of
+ operation, facilitates prevention and detection of
+ insecure TOE states, or whether it is misleading or
+ unreasonable.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design, if applicable;
+
+
+ the user guidance;
+
+
+
+
+ The developer shall provide operational user guidance.
+
+
+ The operational user guidance shall describe, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+
+ The operational user guidance shall describe, for each user
+ role, how to use the available interfaces provided by the
+ TOE in a secure manner.
+
+
+ The operational user guidance shall describe, for each user
+ role, the available functions and interfaces, in particular
+ all security parameters under the control of the user,
+ indicating secure values as appropriate.
+
+
+ The operational user guidance shall, for each user role,
+ clearly present each type of security-relevant event
+ relative to the user-accessible functions that need to be
+ performed, including changing the security characteristics
+ of entities under the control of the TSF.
+
+
+ The operational user guidance shall identify all possible
+ modes of operation of the TOE (including operation following
+ failure or operational error), their consequences and
+ implications for maintaining secure operation.
+
+
+ The operational user guidance shall, for each user role,
+ describe the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+
+ The operational user guidance shall be clear and reasonable.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+ The configuration of the TOE may allow different user
+ roles to have dissimilar privileges in making use of the
+ different functions of the TOE. This means that some
+ users are authorised to perform certain functions, while
+ other users may not be so authorised. These functions
+ and privileges should be described, for each user role,
+ by the user guidance.
+
+ The user guidance identifies, for each user role, the
+ functions and privileges that must be controlled, the
+ types of commands required for them, and the reasons for
+ such commands. The user guidance should contain warnings
+ regarding the use of these functions and
+ privileges. Warnings should address expected effects,
+ possible side effects, and possible interactions with
+ other functions and privileges.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the secure use of the available interfaces
+ provided by the TOE.
+
+ The user guidance should provide advice regarding
+ effective use of the TSF (e.g. reviewing password
+ composition practises, suggested frequency of user file
+ backups, discussion on the effects of changing user
+ access privileges).
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the available security functionality and
+ interfaces, in particular all security parameters under
+ the control of the user, indicating secure values as
+ appropriate.
+
+ The user guidance should contain an overview of the
+ security functionality that is visible at the user
+ interfaces.
+
+ The user guidance should identify and describe the
+ purpose, behaviour, and interrelationships of the
+ security interfaces and functionality.
+
+ For each user-accessible interface, the user guidance
+ should:
+
+
+ describe the method(s) by which the interface is
+ invoked (e.g. command-line, programming-language
+ system call, menu selection, command button);
+
+
+ describe the parameters to be set by the user, their
+ particular purposes, valid and default values, and
+ secure and insecure use settings of such parameters,
+ both individually or in combination;
+
+
+ describe the immediate TSF response, message, or
+ code returned.
+
+
+
+ The evaluator should consider the functional
+ specification and the ST to determine that the TSF
+ described in these documents is consistent to the
+ operational user guidance. The evaluator has to ensure
+ that the operational user guidance is complete to allow
+ the secure use through the TSFI available to all types
+ of human users. The evaluator may, as an aid, prepare an
+ informal mapping between the guidance and these
+ documents. Any omissions in this mapping may indicate
+ incompleteness.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, each type of security-relevant event relative to
+ the user functions that need to be performed, including
+ changing the security characteristics of entities under
+ the control of the TSF and operation following failure
+ or operational error.
+
+ All types of security-relevant events are detailed for
+ each user role, such that each user knows what events
+ may occur and what action (if any) he may have to take
+ in order to maintain security. Security-relevant events
+ that may occur during operation of the TOE (e.g. audit
+ trail overflow, system crash, updates to user records,
+ such as when a user account is removed when the user
+ leaves the organisation) are adequately defined to allow
+ user intervention to maintain secure operation.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance and other evaluation evidence to determine that
+ the guidance identifies all possible modes of operation
+ of the TOE (including, if applicable, operation
+ following failure or operational error), their
+ consequences and implications for maintaining secure
+ operation.
+
+ Other evaluation evidence, particularly the functional
+ specification, provide an information source that the
+ evaluator should use to determine that the guidance
+ contains sufficient guidance information.
+
+ If test documentation is included in the assurance
+ package, then the information provided in this evidence
+ can also be used to determine that the guidance contains
+ sufficient guidance documentation. The detail provided
+ in the test steps can be used to confirm that the
+ guidance provided is sufficient for the use and
+ administration of the TOE.
+
+ The evaluator should focus on a single human visible
+ TSFI at a time, comparing the guidance for securely
+ using the TSFI with other evaluation evidence, to
+ determine that the guidance related to the TSFI is
+ sufficient for the secure usage (i.e. consistent with
+ the SFRs) of that TSFI. The evaluator should also
+ consider the relationships between interfaces, searching
+ for potential conflicts.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+ The evaluator analyses the security objectives for the
+ operational environment in the ST and determines that
+ for each user role, the relevant security measures are
+ described appropriately in the user guidance.
+
+ The security measures described in the user guidance
+ should include all relevant external procedural,
+ physical, personnel and connectivity measures.
+
+ Note that those measures relevant for secure
+ installation of the TOE are examined in .
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is clear.
+
+ The guidance is unclear if it can reasonably be
+ misconstrued by an administrator or user, and used in a
+ way detrimental to the TOE, or to the security provided
+ by the TOE.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is reasonable.
+
+ The guidance is unreasonable if it makes demands on the
+ TOE's usage or operational environment that are
+ inconsistent with the ST or unduly onerous to maintain
+ security.
+
+
+
+
+
+
+
+ Preparative procedures are useful for ensuring that the TOE
+ has been received and installed in a secure manner as
+ intended by the developer. The requirements for preparation
+ call for a secure transition from the delivered TOE to its
+ initial operational environment. This includes investigating
+ whether the TOE can be configured or installed in a manner
+ that is insecure but that the user of the TOE would
+ reasonably believe to be secure.
+
+
+
+ Preparation requires that the delivered copy of the TOE is
+ accepted, configured and activated by the user to exhibit
+ the protection properties as needed during operation of the
+ TOE. The preparative procedures provide confidence that the
+ user will be aware of the TOE configuration parameters and
+ how they can affect the TSF.
+
+
+
+ This family contains only one component.
+
+
+
+ It is recognised that the application of these requirements
+ will vary depending on aspects such as whether the TOE is
+ delivered in an operational state, or whether it has to be
+ installed at the TOE owner's site, etc.
+
+ The first process covered by the preparative procedures is
+ the consumer's secure acceptance of the received TOE in
+ accordance with the developer's delivery procedures. If the
+ developer has not defined delivery procedures, security of
+ the acceptance has to be ensured otherwise.
+
+ Installation of the TOE includes transforming its
+ operational environment into a state that conforms to the
+ security objectives for the operational environment provided
+ in the ST.
+
+ It might also be the case that no installation is necessary,
+ for example a smart card. In this case it may be
+ inappropriate to require and analyse installation
+ procedures.
+
+ The requirements in this assurance family are presented
+ separately from those in the family, due to the infrequent, possibly
+ one-time use of the preparative procedures.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the procedures and steps for the secure preparation of the
+ TOE have been documented and result in a secure
+ configuration.
+
+
+
+ The preparative procedures refer to all acceptance and
+ installation procedures, that are necessary to progress
+ the TOE to the secure configuration as described in the
+ ST.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE including its preparative procedures;
+
+
+ the description of developer's delivery procedures, if
+ applicable;
+
+
+
+
+ The developer shall provide the TOE including its
+ preparative procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure acceptance
+ of the delivered TOE in accordance with the developer's
+ delivery procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure
+ installation of the TOE and for the secure preparation of
+ the operational environment in accordance with the security
+ objectives for the operational environment as described in
+ the ST.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+ The evaluator shall examine the provided acceptance
+ procedures to determine that they describe the steps
+ necessary for secure acceptance of the TOE in accordance
+ with the developer's delivery procedures.
+ If it is not anticipated by the developer's delivery
+ procedures that acceptance procedures will or can be
+ applied, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+ The acceptance procedures should include as a minimum,
+ that the user has to check that all parts of the TOE as
+ indicated in the ST have been delivered in the correct
+ version.
+
+ The acceptance procedures should reflect the steps the
+ user has to perform in order to accept the delivered TOE
+ that are implied by the developer's delivery
+ procedures.
+
+ The acceptance procedures should provide detailed
+ information about the following, if applicable:
+
+
+ making sure that the delivered TOE is the complete
+ evaluated instance;
+
+
+ detecting modification/masquerading of the delivered
+ TOE.
+
+
+
+
+
+
+
+ The evaluator shall examine the provided installation
+ procedures to determine that they describe the steps
+ necessary for secure installation of the TOE and the
+ secure preparation of the operational environment in
+ accordance with the security objectives in the
+ ST.
+
+ If it is not anticipated that installation procedures
+ will or can be applied (e.g. because the TOE may already
+ be delivered in an operational state), this work unit is
+ not applicable, and is therefore considered to be
+ satisfied.
+
+ The installation procedures should provide detailed
+ information about the following, if applicable:
+
+
+ minimum system requirements for secure installation;
+
+
+ requirements for the operational environment in
+ accordance with the security objectives provided by
+ the ST;
+
+ the steps the user has to perform in order to get to an
+ operational TOE being commensurate with its evaluated
+ configuration. Such a description shall include - for each step
+ - a clear scheme for the decision on the next step depended on
+ success, failure or problems at the current step;
+
+
+ changing the installation specific security
+ characteristics of entities under the control of the
+ TSF (for example parameters, settings, passwords);
+
+
+ handling exceptions and problems.
+
+
+
+
+
+ The evaluator shall apply the preparative procedures to
+ confirm that the TOE can be prepared securely for operation.
+
+
+ The evaluator shall perform all user procedures
+ necessary to prepare the TOE to determine that the TOE
+ and its operational environment can be prepared securely
+ using only the supplied preparative procedures.
+ Preparation requires the evaluator to advance the
+ TOE from a deliverable state to the state in which it is
+ operational, including acceptance and installation of
+ the TOE, and enforcing the SFRs consistent with the
+ security objectives for the TOE specified in the
+ ST.
+
+ The evaluator should follow only the developer's
+ procedures and may perform the activities that customers
+ are usually expected to perform to accept and install
+ the TOE, using the supplied preparative procedures only.
+ Any difficulties encountered during such an exercise may
+ be indicative of incomplete, unclear or unreasonable guidance.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+ If it is known that the TOE will be used as a dependent
+ component for a composed TOE evaluation, then the
+ evaluator should ensure that the operational environment
+ is satisfied by the base component used in the composed
+ TOE.
+
+
+
+
+
+
+
+
+ Life-cycle support is an aspect of establishing discipline and
+ control in the processes of refinement of the TOE during its
+ development and maintenance. Confidence in the correspondence
+ between the TOE security requirements and the TOE is greater
+ if security analysis and the production of the evidence are
+ done on a regular basis as an integral part of the development
+ and maintenance activities.
+
+ In the product life-cycle it is distinguished whether the TOE
+ is under the responsibility of the developer or the user
+ rather than whether it is located in the development or user
+ environment. The point of transition is the moment where the
+ TOE is handed over to the user. This is also the point of
+ transition from the to the class.
+
+ The class consists of seven
+ families. is the high-level
+ description of the TOE life-cycle; a more detailed description of the management
+ of the configuration items.
+ requires a minimum set of configuration items to be managed in
+ the defined way. is
+ concerned with the developer's physical, procedural,
+ personnel, and other security measures; with the development tools and implementation
+ standards used by the developer; with the handling of security flaws. defines the procedures used for
+ the delivery of the TOE to the consumer. Delivery processes
+ occurring during the development of the TOE are denoted rather
+ as transportations, and are handled in the context of
+ integration and acceptance procedures in other families of
+ this class.
+
+ Throughout this class, development and related terms
+ (developer, develop) are meant in the more general sense to
+ comprise development and production, whereas
+ production specifically means the process of transforming the
+ implementation representation into the final TOE.
+
+
+
+ Assurance class defines
+ requirements for assurance through the adoption of a well
+ defined life-cycle model for all the steps of the TOE
+ development, including flaw remediation procedures and
+ policies, correct use of tools and techniques and the security
+ measures used to protect the development environment.
+
+ Configuration management (CM) helps to ensure that the
+ integrity of the TOE is preserved, by preventing unauthorised
+ modifications, additions, or deletions to the TOE, thus
+ providing assurance that the TOE and documentation used for
+ evaluation are the ones prepared for distribution.
+
+ The delivery procedures define requirements for the measures,
+ procedures, and standards concerned with secure delivery of
+ the TOE, ensuring that the security protection offered by the
+ TOE is not compromised during the transfer to the user.
+
+
+
+ The purpose of the life-cycle support activity is to determine
+ the adequacy of the security procedures that the developer
+ uses during the development and maintenance of the TOE. These
+ procedures include the life-cycle model used by the developer,
+ the configuration management, the security measures used
+ throughout TOE development, the tools used by the developer
+ throughout the life-cycle of the TOE, the handling of security
+ flaws, and the delivery activity.
+
+ Poorly controlled development and maintenance of the TOE can
+ result in vulnerabilities in the implementation. Conformance
+ to a defined life-cycle model can help to improve controls in
+ this area. A measurable life-cycle model used for the TOE can
+ remove ambiguity in assessing the development progress of the
+ TOE.
+
+ The purpose of the configuration management activity is to
+ assist the consumer in identifying the evaluated TOE, to
+ ensure that configuration items are uniquely identified, and
+ the adequacy of the procedures that are used by the developer
+ to control and track changes that are made to the TOE. This
+ includes details on what changes are tracked, how potential
+ changes are incorporated, and the degree to which automation
+ is used to reduce the scope for error.
+
+ Developer security procedures are intended to protect the TOE
+ and its associated design information from interference or
+ disclosure. Interference in the development process may allow
+ the deliberate introduction of vulnerabilities. Disclosure of
+ design information may allow vulnerabilities to be more easily
+ exploited. The adequacy of the procedures will depend on the
+ nature of the TOE and the development process.
+
+ The use of well-defined development tools and the application
+ of implementation standards by the developer and by third
+ parties involved in the development process help to ensure
+ that vulnerabilities are not inadvertently introduced during
+ refinement.
+
+ The flaw remediation activity is intended to track security
+ flaws, to identify corrective actions, and to distribute the
+ corrective action information to TOE users.
+
+ The purpose of the delivery activity is to judge the adequacy
+ of the documentation of the procedures used to ensure that the
+ TOE is delivered to the consumer without modification.
+
+
+
+
+ Configuration management (CM) is one means for increasing
+ assurance that the TOE meets the SFRs. CM establishes this
+ by requiring discipline and control in the processes of
+ refinement and modification of the TOE and the related
+ information. CM systems are put in place to ensure the
+ integrity of the portions of the TOE that they control, by
+ providing a method of tracking any changes, and by ensuring
+ that all changes are authorised.
+
+ The objective of this family is to require the developer's
+ CM system to have certain capabilities. These are meant to
+ reduce the likelihood that accidental or unauthorised
+ modifications of the configuration items will occur. The CM
+ system should ensure the integrity of the TOE from the early
+ design stages through all subsequent maintenance
+ efforts.
+
+ The objective of introducing automated CM tools is to
+ increase the effectiveness of the CM system. While both
+ automated and manual CM systems can be bypassed, ignored, or
+ proven insufficient to prevent unauthorised modification,
+ automated systems are less susceptible to human error or
+ negligence.
+
+ The objectives of this family include the following:
+
+
+ ensuring that the TOE is correct and complete before it
+ is sent to the consumer;
+
+
+ ensuring that no configuration items are missed during
+ evaluation;
+
+
+ preventing unauthorised modification, addition, or
+ deletion of TOE configuration items.
+
+
+
+
+
+ Configuration management capabilities define the
+ characteristics of the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ the CM system capabilities, the scope of the CM
+ documentation and the evidence provided by the
+ developer.
+
+
+
+ While it is desired that CM be applied from the early design
+ stages and continue into the future, this family requires
+ that CM be in place and in use prior to the end of the
+ evaluation.
+
+ In the case where the TOE is a subset of a product, the
+ requirements of this family apply only to the TOE
+ configuration items, not to the product as a whole.
+
+ For developers that have separate CM systems for different
+ life-cycle phases (for example development, production
+ and/or the final product), it is required to document all of
+ them. For evaluation purposes, the separate CM systems
+ should be regarded as parts of an overall CM system which is
+ addressed in the criteria.
+
+ Similarly, if parts of the TOE are produced by different
+ developers or at different sites, the CM systems being in
+ use at the different places should be regarded as parts of
+ an overall CM system which is addressed in the criteria. In
+ this situation, integration aspects have also to be taken
+ into account.
+
+ Several elements of this family refer to configuration
+ items. These elements identify CM requirements to be imposed
+ on all items identified in the configuration list, but leave
+ the contents of the list to the discretion of the
+ developer. can be used to
+ narrow this discretion by identifying specific items that
+ must be included in the configuration list, and hence
+ covered by CM.
+
+ introduces a
+ requirement that the CM system uniquely identify all
+ configuration items. This also requires that modifications
+ to configuration items result in a new, unique identifier
+ being assigned to the configuration item.
+
+ introduces the
+ requirement that the evidence shall demonstrate that the CM
+ system operates in accordance with the CM plan. Examples of
+ such evidence might be documentation such as screen
+ snapshots or audit trail output from the CM system, or a
+ detailed demonstration of the CM system by the
+ developer. The evaluator is responsible for determining that
+ this evidence is sufficient to show that the CM system
+ operates in accordance with the CM plan.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ support the production of the TOE. This requires that the CM
+ system provide an automated means to assist in determining
+ that the correct configuration items are used in generating
+ the TOE.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ ascertain the changes between the TOE and its preceding
+ version. If no previous version of the TOE exists, the
+ developer still needs to provide an automated means to
+ ascertain the changes between the TOE and a future version
+ of the TOE.
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the
+ TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items.
+
+
+
+ This component contains an implicit evaluator action to
+ determine that the CM system is being used. As the
+ requirements here are limited to identification of the TOE
+ and provision of a configuration list, this action is
+ already covered by, and limited to, the existing work
+ units. At the
+ requirements are expanded beyond these two items, and more
+ explicit evidence of operation is required.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+ Assurance that the CM system uniquely identifies
+ all configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items, and whether the
+ ability to modify these items is properly
+ controlled.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide measures such that only
+ authorised changes are made to the configuration items.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan to determine that they
+ are effective in preventing unauthorised access to the
+ configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan.
+ The CM plan needs not to be a connected document, but it is
+ recommended that there is a single document that describes where
+ the various parts of the CM plan can be found. If the CM plan is
+ no single document, the list in the following work unit gives
+ hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the composed TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For configuration
+ items identified under ,
+ the evaluator confirms that each configuration item possesses
+ a unique identifier in a manner consistent with the unique
+ identification method that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that they
+ are automated and effective in preventing unauthorised
+ access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan.
+ The CM plan does not need to be contained within a single
+ document, but it is recommended that there is a separate
+ document that describes where the various parts of the CM plan
+ can be found. If the CM plan is provided by a set of documents,
+ the list in the following work unit gives guidance regarding the
+ required content.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+ If this work unit is applied to a dependent component
+ that is going to be integrated in a composed TOE, the CM
+ plan should consider the control of base components
+ obtained by the dependent TOE developer.
+
+ When obtaining the components the evaluators are to
+ verify the following:
+
+
+ Transfer of each base component from the base
+ component developer to the integrator (dependent TOE
+ developer) was performed in accordance with the base
+ component TOE's secure delivery procedures, as
+ reported in the base component TOE certification
+ report.
+
+
+ The component received has the same identifiers as
+ those stated in the ST and Certification Report for
+ the component TOE.
+
+
+ All additional material required by a developer for
+ composition (integration) is provided. This is to
+ include the necessary extract of the component TOE's
+ functional specification.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+ Requiring that the CM system be able to identify the
+ version of the implementation representation from which
+ the TOE is generated helps to ensure that the integrity of
+ this material is preserved by the appropriate technical,
+ physical and procedural safeguards.
+
+ Providing an automated means of ascertaining changes
+ between versions of the TOE and identifying which
+ configuration items are affected by modifications to other
+ configuration items assists in determining the impact of
+ the changes between successive versions of the TOE. This
+ in turn can provide valuable information in determining
+ whether changes to the TOE result in all configuration
+ items being consistent with one another.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM documentation shall justify that the acceptance
+ procedures provide for an adequate and appropriate review of
+ changes to all configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM system shall ensure that the person responsible for
+ accepting a configuration item into CM is not the person who
+ developed it.
+
+
+ The CM system shall identify the configuration items that
+ comprise the TSF.
+
+
+ The CM system shall support the audit of all changes to the
+ TOE by automated means, including the originator, date, and
+ time in the audit trail.
+
+
+ The CM system shall provide an automated means to identify
+ all other configuration items that are affected by the
+ change of a given configuration item.
+
+
+ The CM system shall be able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the CM documentation to
+ determine that it justifies that the acceptance
+ procedures provide for an adequate and appropriate
+ review of changes to all configuration items.
+
+ The CM documentation should make it sufficiently clear
+ that by following the acceptance procedures only parts
+ of adequate quality are incorporated into the
+ TOE.
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that
+ they are automated and effective in preventing
+ unauthorised access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it ensures that the person responsible for
+ accepting a configuration item is not the person who
+ developed it.
+
+ The acceptance procedures describe who is responsible
+ for accepting a configuration item. From these
+ descriptions, the evaluator should be able to determine
+ that the person who developed a configuration item is in
+ no case responsible for its acceptance.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it identifies the configuration items that comprise
+ the TSF.
+
+ The CM documentation should describe how the CM system
+ identifies the configuration items that comprise the
+ TSF. The evaluator should select a sample of
+ configuration items covering each type of items,
+ particularly containing TSF and non-TSF items, and check
+ that they are correctly classified by the CM
+ system.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it supports the audit of all changes to the TOE by
+ automated means, including the originator, date, and
+ time in the audit trail.
+
+ The evaluator should inspect a sample of audit trails
+ and check, if they contain the minimum
+ information.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it provides an automated means to identify all
+ other configuration items that are affected by the
+ change of a given configuration item.
+
+ The CM documentation should describe how the CM system
+ identifies all other configuration items that are
+ affected by the change of a given configuration
+ item. The evaluator should select a sample of
+ configuration items, covering all types of items, and
+ exercise the automated means to determine that it
+ identifies all items that are affected by the change of
+ the selected item.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it is able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+ The CM documentation should describe how the CM system
+ identifies the version of the implementation
+ representation from which the TOE is generated. The
+ evaluator should select a sample of the parts used to
+ produce the TOE and should apply the CM system to verify
+ that it identifies the corresponding implementation
+ representation in the correct version.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check that the CM documentation provided
+ includes a CM plan.
+ The CM plan needs not to be a connected document, but it is
+ recommended that there is a single document that describes where
+ the various parts of the CM plan can be found. If the CM plan is
+ no single document, the list in the following work unit gives
+ hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include
+ change control forms, or configuration item access
+ approval forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+ The evaluator shall determine that the application of the
+ production support procedures results in a TOE as provided
+ by the developer for testing activities.
+
+
+ The evaluator shall examine the production support
+ procedures to determine that by following these
+ procedures a TOE would be produced like that one
+ provided by the developer for testing activities.
+
+ If the TOE is a small software TOE and production
+ consists of compiling and linking, the evaluator might
+ confirm the adequacy of the production support
+ procedures by reapplying them himself.
+
+ If the production process of the TOE is more complicated
+ (as for example in the case of a smart card), but has
+ already started, the evaluator should inspect the
+ application of the production support procedures during
+ a visit of the development site. He might compare a copy
+ of the TOE produced in his presence with the samples
+ used for his testing activities.
+
+ For guidance on site visits see .
+
+ Otherwise the evaluator's determination should be based
+ on the documentary evidence provided by the
+ developer.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+ The objective of this family is to identify items to be
+ included as configuration items and hence placed under the
+ CM requirements of .
+ Applying configuration management to these additional items
+ provides additional assurance that the integrity of TOE is
+ maintained.
+
+
+
+ Configuration management scope indicates the TOE items that
+ need to be controlled by the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ which of the following are required to be included as
+ configuration items: the TOE and the evaluation evidence
+ required by the SARs; the parts of the TOE; the
+ implementation representation; security flaws; and
+ development tools and related information.
+
+
+
+ While mandates a list of
+ configuration items and that each item on this list be under
+ CM, leaves the contents of
+ the configuration list to the discretion of the
+ developer. narrows this
+ discretion by identifying items that must be included in the
+ configuration list, and hence come under the CM requirements
+ of .
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself and the evaluation evidence required by the other
+ SARs in the ST under CM provides assurance that they have
+ been modified in a controlled manner with proper
+ authorisations.
+
+
+
+ introduces the
+ requirement that the TOE itself and the evaluation
+ evidence required by the other SARs in the ST be included
+ in the configuration list and hence be subject to the CM
+ requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer performs configuration management on the TOE
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; and the evaluation evidence required by the SARs.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, and the
+ evaluation evidence required by the other SARs under CM
+ provides assurance that they have been modified in a
+ controlled manner with proper authorisations.
+
+
+
+ introduces the
+ requirement that the parts that comprise the TOE (all
+ parts that are delivered to the consumer, for example
+ hardware parts or executable files) be included in the
+ configuration list and hence be subject to the CM
+ requirements of .
+
+ introduces the
+ requirement that the configuration list indicate the
+ developer of each TSF relevant configuration
+ item. ``Developer'' here does not refer to a person, but
+ to the organisation responsible for the development of the
+ item.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; and
+ the parts that comprise the TOE.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+ the TOE itself;
+
+ the parts that comprise the TOE;
+
+ the evaluation evidence required by the SARs.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+
+
+ introduces the
+ requirement that the TOE implementation representation be
+ included in the list of configuration items and hence be
+ subject to the CM requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; and the implementation
+ representation.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+
+
+ introduces the
+ requirement that security flaws be included in the
+ configuration list and hence be subject to the CM
+ requirements of . This
+ requires that information regarding previous security
+ flaws and their resolution be maintained, as well as
+ details regarding current security flaws.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; and security flaw reports and resolution
+ status.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database).
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+ Development tools play an important role in ensuring the
+ production of a quality version of the TOE. Therefore, it
+ is important to control modifications to these
+ tools.
+
+
+
+ introduces the
+ requirement that development tools and other related
+ information be included in the list of configuration items
+ and hence be subject to the CM requirements of . Examples of development tools
+ are programming languages and compilers. Information
+ pertaining to TOE generation items (such as compiler
+ options, generation options, and build options) is an
+ example of information relating to development
+ tools.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, development tools and related information,
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; security flaw reports and resolution status;
+ and development tools and related information.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database);
+
+
+ all tools (incl. test software, if applicable)
+ involved in the development and production of the
+ TOE including the names, versions, configurations
+ and roles of each development tool, and related
+ documentation.
+
+
+ For a software TOE, ``development tools'' are usually
+ programming languages and compiler and ``related documentation''
+ comprises compiler and linker options. For a hardware TOE,
+ ``development tools'' might be hardware design languages,
+ simulation and synthesis tools, compilers, and ``related
+ documentation'' might comprise compiler options again.
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ The concern of this family is the secure transfer of the
+ finished TOE from the development environment into the
+ responsibility of the user.
+
+ The requirements for delivery call for system control and
+ distribution facilities and procedures that detail the
+ measures necessary to provide assurance that the security of
+ the TOE is maintained during distribution of the TOE to the
+ user. For a valid distribution of the TOE, the procedures
+ used for the distribution of the TOE address the objectives
+ identified in the PP/ST relating to the security of the TOE
+ during delivery.
+
+
+
+ Delivery covers the procedures used to maintain security
+ during transfer of the TOE to the user, both on initial
+ delivery and as part of subsequent modification. It includes
+ special procedures or operations required to demonstrate the
+ authenticity of the delivered TOE. Such procedures and
+ measures are the basis for ensuring that the security
+ protection offered by the TOE is not compromised during
+ transfer. While compliance with the delivery requirements
+ cannot always be determined when a TOE is evaluated, it is
+ possible to evaluate the procedures that a developer has
+ developed to distribute the TOE to users.
+
+
+
+ This family contains only one component. An increasing level
+ of protection is established by requiring commensurability
+ of the delivery procedures with the assumed attack potential
+ in the family .
+
+
+
+ Transportations from subcontractors to the developer or
+ between different development sites are not considered here,
+ but in the family .
+
+ The end of the delivery phase is marked by the transfer of
+ the TOE into the responsibility of the user. This does not
+ necessarily coincide with the arrival of the TOE at the
+ user's location.
+
+ The delivery procedures should consider, if applicable,
+ issues such as:
+
+
+ ensuring that the TOE received by the consumer
+ corresponds precisely to the evaluated version of the
+ TOE;
+
+
+ avoiding or detecting any tampering with the actual
+ version of the TOE;
+
+
+ preventing submission of a false version of the TOE;
+
+
+ avoiding unwanted knowledge of distribution of the TOE
+ to the consumer: there might be cases where potential
+ attackers should not know when and how it is delivered;
+
+
+ avoiding or detecting the TOE being intercepted during
+ delivery; and
+
+
+ avoiding the TOE being delayed or stopped during
+ distribution.
+
+
+
+ The delivery procedures should include the recipient's
+ actions implied by these issues. The consistent description
+ of these implied actions is examined in the family, if present.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the delivery documentation describes all procedures used
+ to maintain security of the TOE when distributing the TOE
+ to the user.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the delivery documentation.
+
+
+
+
+ The developer shall document and provide procedures for delivery of the
+ TOE or parts of it to the consumer.
+
+
+ The developer shall use the delivery procedures.
+
+
+ The evaluator shall examine aspects of the delivery
+ process to determine that the delivery procedures are
+ used.
+
+ The approach taken by the evaluator to check the
+ application of delivery procedures will depend on the
+ nature of the TOE, and the delivery process itself. In
+ addition to examination of the procedures themselves,
+ the evaluator seeks some assurance that they are applied
+ in practise. Some possible approaches are:
+
+
+ a visit to the distribution site(s) where practical
+ application of the procedures may be observed;
+
+
+ examination of the TOE at some stage during
+ delivery, or after the user has received it
+ (e.g. checking for tamper proof seals);
+
+
+ observing that the process is applied in practise
+ when the evaluator obtains the TOE through regular
+ channels;
+
+
+ questioning end users as to how the TOE was
+ delivered.
+
+
+
+ For guidance on site visits see .
+
+ It may be the case of a newly developed TOE that the
+ delivery procedures have yet to be exercised. In these
+ cases, the evaluator has to be satisfied that
+ appropriate procedures and facilities are in place for
+ future deliveries and that all personnel involved are
+ aware of their responsibilities. The evaluator may
+ request a ``dry run'' of a delivery if this is
+ practical. If the developer has produced other similar
+ products, then an examination of procedures in their use
+ may be useful in providing assurance.
+
+
+
+ The delivery documentation shall describe all procedures
+ that are necessary to maintain security when distributing
+ versions of the TOE to the consumer.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the delivery documentation
+ to determine that it describes all procedures that are
+ necessary to maintain security when distributing
+ versions of the TOE or parts of it to the
+ consumer.
+
+ The delivery documentation describes proper procedures
+ to maintain security of the TOE during transfer of the
+ TOE or its component parts and to determine the
+ identification of the TOE.
+
+ The delivery documentation should cover the entire TOE,
+ but may contain different procedures for different parts
+ of the TOE. The evaluation should consider the totality
+ of procedures.
+
+ The delivery procedures should be applicable across all
+ phases of delivery from the production environment to
+ the installation environment (e.g. packaging, storage
+ and distribution). Standard commercial practise for
+ packaging and delivery may be acceptable. This includes
+ shrink wrapped packaging, a security tape or a sealed
+ envelope. For the distribution, physical (e.g. public
+ mail or a private distribution service) or electronic
+ (e.g. electronic mail or downloading off the Internet)
+ procedures may be used.
+
+ Cryptographic checksums or a software signature may be
+ used by the developer to ensure that tampering or
+ masquerading can be detected. Tamper proof seals
+ additionally indicate if the confidentiality has been
+ broken. For software TOEs, confidentiality might be
+ assured by using encryption. If availability is of
+ concern, a secure transportation might be
+ required.
+
+ Interpretation of the term ``necessary to maintain
+ security'' will need to consider:
+
+
+ The nature of the TOE (e.g. whether it is software
+ or hardware).
+
+
+ The overall security level stated for the TOE by the
+ chosen level of the Vulnerability Assessment. If the
+ TOE is required to be resistant against attackers of
+ a certain potential in its intended environment,
+ this should also apply to the delivery of the
+ TOE. The evaluator should determine that a balanced
+ approach has been taken, such that delivery does not
+ present a weak point in an otherwise secure
+ development process.
+
+
+ The security objectives provided by the ST. The emphasis in the
+ delivery documentation is likely to be on measures related to
+ integrity, as integrity of the TOE is always important. However,
+ confidentiality and availability of the delivery will be of
+ concern in the delivery of some TOEs; procedures relating to
+ these aspects of the secure delivery should also be discussed in
+ the procedures.
+
+
+
+
+
+
+
+
+
+ Development security is concerned with physical, procedural,
+ personnel, and other security measures that may be used in
+ the development environment to protect the TOE and its
+ parts. It includes the physical security of the development
+ location and any procedures used to select development
+ staff.
+
+
+
+ Development security covers the physical, procedural,
+ personnel, and other security measures used in the
+ development environment. It includes physical security of
+ the development location(s) and controls on the selection
+ and hiring of development staff.
+
+
+
+ The components in this family are levelled on the basis of
+ whether justification of the sufficiency of the security
+ measures is required.
+
+
+
+ This family deals with measures to remove or reduce threats
+ existing at the developer's site.
+
+ The evaluator should visit the site(s) in order to assess
+ evidence for development security. This may include sites of
+ subcontractors involved in the TOE development and
+ production. Any decision not to visit shall be agreed with
+ the evaluation authority.
+
+ Although development security deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, the requirements specify only that the
+ development security measures be in place at the time of
+ evaluation. Furthermore,
+ does not contain any requirements related to the sponsor's
+ intention to apply the development security measures in the
+ future, after completion of the evaluation.
+
+ It is recognised that confidentiality may not always be an
+ issue for the protection of the TOE in its development
+ environment. The use of the word ``necessary'' allows for
+ the selection of appropriate safeguards.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce and provide development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first referring to
+ the ST for any information that may assist in the determination
+ of necessary protection.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material within and out of
+ the development environment and between
+ different development sites in accordance with
+ defined acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ The evaluator should examine whether the following is included
+ in the policies:
+
+ what information relating to the TOE development needs to be
+ kept confidential, and which members of the development
+ staff are allowed to access such material;
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the ,
+ mandating only necessary measures, are dependent on the nature of the TOE,
+ and on information that may be provided in the ST. The evaluators would
+ then determine that such a policy had been applied under this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised. Additionally, sufficiency of the measures
+ as applied is intended be justified.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce and provide development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The development security documentation shall justify that
+ the security measures provide the necessary level of
+ protection to maintain the confidentiality and integrity of
+ the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first referring to
+ the ST for any information that may assist in the determination
+ of necessary protection.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material out of the
+ development environment and between different
+ development sites in accordance with defined
+ acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by the ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in the .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that an appropriate
+ justification is given why the security measures provide
+ the necessary level of protection to maintain the
+ confidentiality and integrity of the TOE.
+
+ Since attacks on the TOE or its related information are
+ assumed in different design and production stages,
+ measures and procedures need to have an appropriate
+ level necessary to prevent those attacks or to make them
+ more difficult.
+
+ Since this level depends on the overall attack potential
+ claimed for the TOE (cf. the component chosen), the development
+ security documentation should justify the necessary
+ level of protection to maintain the confidentiality and
+ integrity of the TOE. This level has to be achieved by
+ the security measures applied.
+
+ The concept of protection measures should be consistent,
+ and the justification should include an analysis of how
+ the measures are mutually supportive. All aspects of
+ development and production on all the different sites
+ with all roles involved up to delivery of the TOE should
+ be analysed.
+
+ Justification may include an analysis of potential
+ vulnerabilities taking the applied security measures
+ into account.
+
+ There may be a convincing argument showing that e.g.
+
+
+ The technical measures and mechanisms of the
+ developer's infrastructure are sufficient for
+ keeping the appropriate security level
+ (e.g. cryptographic mechanisms as well as physical
+ protection mechanisms, properties of the CM system
+ (cf. ));
+
+ The system containing the implementation
+ representation of the TOE (including concerning
+ guidance documents) provides effective protection
+ against logical attacks e.g. by ``Trojan'' code or
+ viruses. It might be adequate, if the implementation
+ representation is kept on an isolated system where
+ only the software necessary to maintain it is
+ installed and where no additional software is
+ installed afterwards.
+
+ Data brought into this system need to be carefully considered to
+ prevent the installation of hidden functionality onto the
+ system. The effectiveness of these measures need to be tested,
+ e.g. by independently trying to get access to the machine,
+ install some additional executable (program, macro etc.) or get
+ some information out of the machine using logical
+ attacks.
+
+ The appropriate organisational (procedural and
+ personal) measures are unconditionally
+ enforced.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ The evaluator should examine whether the following is included
+ in the policies:
+
+ what information relating to the TOE development needs to be
+ kept confidential, and which members of the development
+ staff are allowed to access such material;
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the , mandating only necessary measures, are
+ dependent on the nature of the TOE, and on information
+ that may be provided in the ST. For example, the ST may
+ identify a security objective for the development
+ environment that requires the TOE to be developed by
+ staff that has security clearance. The evaluators would
+ then determine that such a policy had been applied under
+ this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ Flaw remediation requires that discovered security flaws be
+ tracked and corrected by the developer. Although future
+ compliance with flaw remediation procedures cannot be
+ determined at the time of the TOE evaluation, it is possible
+ to evaluate the policies and procedures that a developer has
+ in place to track and correct flaws, and to distribute the
+ flaw information and corrections.
+
+
+
+ Flaw remediation ensures that flaws discovered by the TOE
+ consumers will be tracked and corrected while the TOE is
+ supported by the developer. While future compliance with the
+ flaw remediation requirements cannot be determined when a
+ TOE is evaluated, it is possible to evaluate the procedures
+ and policies that a developer has in place to track and
+ repair flaws, and to distribute the repairs to
+ consumers.
+
+
+
+ The components in this family are levelled on the basis of
+ the increasing extent in scope of the flaw remediation
+ procedures and the rigour of the flaw remediation
+ policies.
+
+
+
+ This family provides assurance that the TOE will be
+ maintained and supported in the future, requiring the TOE
+ developer to track and correct flaws in the
+ TOE. Additionally, requirements are included for the
+ distribution of flaw corrections. However, this family does
+ not impose evaluation requirements beyond the current
+ evaluation.
+
+ The TOE user is considered to be the focal point in the user
+ organisation that is responsible for receiving and
+ implementing fixes to security flaws. This is not
+ necessarily an individual user, but may be an organisational
+ representative who is responsible for the handling of
+ security flaws. The use of the term TOE user recognises that
+ different organisations have different procedures for
+ handling flaw reporting, which may be done either by an
+ individual user, or by a central administrative body.
+
+ The flaw remediation procedures should describe the methods
+ for dealing with all types of flaws encountered. These flaws
+ may be reported by the developer, by users of the TOE, or by
+ other parties with familiarity with the TOE. Some flaws may
+ not be reparable immediately. There may be some occasions
+ where a flaw cannot be fixed and other (e.g. procedural)
+ measures must be taken. The documentation provided should
+ cover the procedures for providing the operational sites
+ with fixes, and providing information on flaws where fixes
+ are delayed (and what to do in the interim) or when fixes
+ are not possible.
+
+ Changes applied to a TOE after its release render it
+ unevaluated; although some information from the original
+ evaluation may still apply. The phrase ``release of the
+ TOE'' used in this family therefore refers to a version of a
+ product that is a release of a certified TOE, to which
+ changes have been applied.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE users.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation.
+
+
+
+
+ The developer shall document and provide flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+ While these requirements do not mandate that there be a
+ publicised means for TOE users to report security flaws,
+ they do mandate that all security flaws that are
+ reported be tracked. That is, a reported security flaw
+ cannot be ignored simply because it comes from outside
+ the developer's organisation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACK DOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer. Flaw remediation guidance from the developer to
+ the TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, and for assurance that the corrections introduce no
+ new security flaws.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document and provide flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that they describe procedures
+ for the developer to accept reports of security flaws or
+ requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure every reported flaw is
+ corrected.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is corrected. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+
+ The procedures describe the process that is taken from
+ the point at which a security flaw is resolved to the
+ point at which the remediation procedures are
+ provided. The procedures for delivering corrective
+ actions should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer, and how to register themselves with the
+ developer so that they may receive these corrective
+ fixes. Flaw remediation guidance from the developer to the
+ TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, for assurance that the corrections introduce no new
+ security flaws, for the establishment of a point of
+ contact for each TOE user, and for the timely issue of
+ corrective actions to TOE users.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document and provide flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The flaw remediation procedures shall include a procedure
+ requiring timely response and the automatic distribution of
+ security flaw reports and the associated corrections to
+ registered users who might be affected by the security flaw.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users may register with the developer, to be
+ eligible to receive security flaw reports and corrections.
+
+
+ The flaw remediation guidance shall identify the specific
+ points of contact for all reports and enquiries about
+ security issues involving the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+ For TOE users who register with the developer (see work
+ unit ), the
+ passive availability of this information is not
+ sufficient. Developers must actively send the
+ information (or a notification of its availability) to
+ registered TOE users.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a means for the developer to
+ receive from TOE user reports of suspected security
+ flaws or requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a timely means of providing
+ the registered TOE users who might be affected with
+ reports about, and associated corrections to, each
+ security flaw.
+
+ The issue of timeliness applies to the issuance of both
+ security flaw reports and the associated
+ corrections. However, these need not be issued at the
+ same time. It is recognised that flaw reports should be
+ generated and issued as soon as an interim solution is
+ found, even if that solution is as drastic as turn off
+ the TOE. Likewise, when a more permanent (and less
+ drastic) solution is found, it should be issued without
+ undue delay.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done in a timely manner.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in automatic distribution of the
+ reports and associated corrections to the registered TOE
+ users who might be affected.
+
+ Automatic distribution does not mean
+ that human interaction with the distribution method is
+ not permitted. In fact, the distribution method could
+ consist entirely of manual procedures, perhaps through a
+ closely monitored procedure with prescribed escalation
+ upon the lack of issue of reports or corrections.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done automatically.
+
+
+
+
+ The evaluator shall examine the flaw remediation procedures to
+ determine that the application of these procedures would help to
+ ensure that every reported flaw is corrected.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is remediated. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+ The procedures describe the process that is taken
+ from the point at which a security flaw is resolved to
+ the point at which the remediation procedures are
+ provided. The procedures for delivering remediation
+ procedures should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it describes a means of
+ enabling the TOE users to register with the
+ developer.
+
+ Enabling the TOE users to register with the
+ developer simply means having a way for each
+ TOE user to provide the developer with a point of
+ contact; this point of contact is to be used to
+ provide the TOE user with information related to
+ security flaws that might affect that TOE user, along
+ with any corrections to the security flaw. Registering
+ the TOE user may be accomplished as part of the
+ standard procedures that TOE users undergo to identify
+ themselves to the developer, for the purposes of
+ registering a software licence, or for obtaining
+ update and other useful information.
+
+ There need not be one registered TOE user per
+ installation of the TOE; it would be sufficient if there
+ were one registered TOE user for an organisation. For
+ example, a corporate TOE user might have a centralised
+ acquisition office for all of its sites. In this case,
+ the acquisition office would be a sufficient point of
+ contact for all of that TOE user's sites, so that all of
+ the TOE user's installations of the TOE have a
+ registered point of contact.
+
+ In either case, it must be possible to associate each
+ TOE that is delivered with an organisation in order to
+ ensure that there is a registered user for each TOE. For
+ organisations that have many different addresses, this
+ assures that there will be no user who is erroneously
+ presumed to be covered by a registered TOE user.
+ It should be noted that TOE users need not
+ register; they must only be provided with a means of
+ doing so. However, users who choose to register must be
+ directly sent the information (or a notification of its
+ availability).
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it identifies specific points
+ of contact for user reports and enquiries about security
+ issues involving the TOE.
+
+ The guidance includes a means whereby registered TOE
+ users can interact with the developer to report
+ discovered security flaws in the TOE or to make
+ enquiries regarding discovered security flaws in the
+ TOE.
+
+
+
+
+
+
+
+ Poorly controlled development and maintenance of the TOE can
+ result in a TOE that does not meet all of its
+ SFRs. Therefore, it is important that a model for the
+ development and maintenance of a TOE be established as early
+ as possible in the TOE's life-cycle.
+
+ Using a model for the development and maintenance of a TOE
+ does not guarantee that the TOE meets all of its SFRs. It is
+ possible that the model chosen will be insufficient or
+ inadequate and therefore no benefits in the quality of the
+ TOE can be observed. Using a life-cycle model that has been
+ approved by a group of experts (e.g. academic experts,
+ standards bodies) improves the chances that the development
+ and maintenance models will contribute to the TOE meeting
+ its SFRs. The use of a life-cycle model including some
+ quantitative valuation adds further assurance in the overall
+ quality of the TOE development process.
+
+
+
+ Life-cycle definition establishes that the engineering
+ practises used by a developer to produce the TOE include the
+ considerations and activities identified in the development
+ process and operational support requirements. Confidence in
+ the correspondence between the requirements and the TOE is
+ greater when quality control and the production of evidence
+ are done on a regular basis as an integral part of the
+ development process and operational support activities. It
+ is not the intent of this component to dictate any specific
+ development process.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements for measurability of the life-cycle
+ model, and for compliance with that model.
+
+
+
+ A life-cycle model encompasses the procedures, tools and
+ techniques used to develop and maintain the TOE. Aspects of
+ the process that may be covered by such a model include
+ design methods, review procedures, project management
+ controls, change control procedures, test methods and
+ acceptance procedures. An effective life-cycle model will
+ address these aspects of the development and maintenance
+ process within an overall management structure that assigns
+ responsibilities and monitors progress.
+
+ There are different types of acceptance situations that are
+ dealt with at different locations in the criteria:
+ acceptance of parts delivered by subcontractors
+ (``integration'') should be treated in this family , acceptance subsequent to
+ internal transportations in , acceptance of parts into the CM system in
+ , and acceptance of the
+ delivered TOE by the consumer in . The first three types may overlap.
+
+ Although life-cycle definition deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, its evaluation adds assurance
+ through an analysis of the life-cycle information for the
+ TOE provided at the time of the evaluation.
+
+ A life-cycle model provides for the necessary control over
+ the development and maintenance of the TOE, if the model
+ enables sufficient minimisation of the danger that the TOE
+ will not meet its security requirement.
+
+ A measurable life-cycle model is a model using some
+ quantitative valuation (arithmetic parameters and/or
+ metrics) of the managed product in order to measure
+ development properties of the product. Typical metrics are
+ source code complexity metrics, defect density (errors per
+ size of code) or mean time to failure. For the security
+ evaluation all those metrics are of relevance, which are
+ used to increase quality by decreasing the probability of
+ faults and thereby in turn increasing assurance in the
+ security of the TOE.
+
+ One should take into account that there exist standardised
+ life cycle models on the one hand (like the waterfall model)
+ and standardised metrics on the other hand (like error
+ density), which may be combined. The CC does not require the
+ life cycle to follow exactly one standard defining both
+ aspects.
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented model of the
+ TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process.
+
+ The description of the life-cycle model should include:
+
+
+ information on the life-cycle phases of the TOE and
+ the boundaries between the subsequent phases;
+
+
+ information on the procedures, tools and techniques
+ used by the developer (e.g. for design, coding,
+ testing, bug-fixing);
+
+
+ overall management structure governing the
+ application of the procedures (e.g. an
+ identification and description of the individual
+ responsibilities for each of the procedures required
+ by the development and maintenance process covered
+ by the life-cycle model);
+
+
+ information on which parts of the TOE are delivered
+ by subcontractors, if subcontractors are involved.
+
+
+
+ does not require the
+ model used to conform to any standard life-cycle
+ model.
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented and measurable
+ model of the TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation;
+
+
+ information about the standard used;
+
+
+ the life-cycle output documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE, that is based
+ on a measurable life-cycle model.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The developer shall measure the TOE development using the
+ measurable life-cycle model.
+
+
+ The developer shall provide life-cycle output documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE, including the
+ details of its arithmetic parameters and/or metrics used to
+ measure the quality of the TOE and/or its development.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The life-cycle output documentation shall provide the
+ results of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process, including the
+ details of its arithmetic parameters and/or metrics used
+ to measure the TOE development.
+
+ The description of the life-cycle model includes:
+
+ information on the life-cycle phases of the TOE and the
+ boundaries between the subsequent phases;
+
+ information on the procedures, tools and techniques used by
+ the developer (e.g. for design, coding, testing,
+ bug-fixing);
+
+ overall management structure governing the application of
+ the procedures (e.g. an identification and description of
+ the individual responsibilities for each of the procedures
+ required by the development and maintenance process covered
+ by the life-cycle model);
+
+ information on which parts of the TOE are delivered by
+ subcontractors, if subcontractors are involved;
+
+ information on the parameters/metrics that are used to
+ measure the TOE development. Metrics standards typically
+ include guides for measuring and producing reliable products
+ and cover the aspects reliability, quality, performance,
+ complexity and cost. For the evaluation all those metrics
+ are of relevance, which are used to increase quality by
+ decreasing the probability of faults and thereby in turn
+ increase assurance in the security of the TOE.
+
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+ For the metrics/measurements used in the life-cycle
+ model, evidence has to be provided that shows how those
+ metrics/measurements usefully contribute to the
+ minimisation of the likelihood of flaws. This can be
+ viewed as the overall goal for measurement in an context. As a consequence the
+ metrics/measurements have to be selected based on their
+ capability to achieve that overall goal or contribute to
+ that. In the first place a metric/measure is suitable
+ with respect to if a
+ correlation between the metric/measure and the number of
+ flaws can be stated with a certain degree of
+ reliability. But also a metric/measure useful for
+ management purposes as for planning and monitoring the
+ TOE development are helpful since badly managed projects
+ are endangered to produce bad quality and to introduce
+ flaws.
+
+ It may be possible to use metrics for quality
+ improvement, for which this use is not obvious. For
+ example a metric to estimate the expected cost of a
+ product development may help quality, if the developer
+ can show that this is used to provide an adequate budget
+ for development projects and that this helps to avoid
+ quality problems arising from resource shortages.
+
+ It is not required that every single step in the life
+ cycle of the TOE is measurable. However the evaluator
+ should see from the description of the measures and
+ procedures that the metrics are appropriate to control
+ the overall quality of the TOE and to minimise possible
+ security flaws by this.
+
+
+
+
+ The evaluator shall examine the life-cycle output
+ documentation to determine that it provides the results
+ of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+ The results of the measurements and the life-cycle
+ progress of the TOE should be in accordance with the
+ life-cycle model.
+
+ The output documentation not only includes numeric values of the
+ metrics but also documents actions taken as a result of the
+ measurements and in accordance with the model. For example there
+ may be a requirement that a certain design phase needs to be
+ repeated, if some error rates measured during testing are
+ outside of a defined threshold. In this case the documentation
+ should show that such action was taken, if indeed the thresholds
+ were not met.
+
+ If the evaluation is conducted in parallel with the
+ development of the TOE it may be possible that quality
+ measurements have not been used in the past. In this
+ case the evaluator should use the documentation of the
+ planned procedures in order to gain confidence that
+ corrective actions are defined if results of quality
+ measurements deviate from some threshold.
+
+
+
+
+
+
+
+ Tools and techniques is an aspect of selecting tools that
+ are used to develop, analyse and implement the TOE. It
+ includes requirements to prevent ill-defined, inconsistent
+ or incorrect development tools from being used to develop
+ the TOE. This includes, but is not limited to, programming
+ languages, documentation, implementation standards, and
+ other parts of the TOE such as supporting runtime
+ libraries.
+
+
+
+ Tools and techniques addresses the need to define the
+ development tools being used to analyse and implement the
+ TOE. It includes requirements concerning the development
+ tools and implementation dependent options of those
+ tools.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements on the description and scope of the
+ implementation standards and the documentation of
+ implementation-dependent options.
+
+
+
+ There is a requirement for well-defined development
+ tools. These are tools that are clearly and completely
+ described. For example, programming languages and computer
+ aided design (CAD) systems that are based on a standard
+ published by standards bodies are considered to be
+ well-defined. Self-made tools would need further
+ investigation to clarify whether they are
+ well-defined.
+
+ The requirement in is
+ especially applicable to programming languages so as to
+ ensure that all statements in the source code have an
+ unambiguous meaning.
+
+ In and , implementation guidelines may be accepted
+ as an implementation standard if they have been approved by
+ some group of experts (e.g. academic experts, standards
+ bodies). Implementation standards are normally public, well
+ accepted and common practise in a specific industry, but
+ developer-specific implementation guidelines may also be
+ accepted as a standard; the emphasis is on the
+ expertise.
+ Tools and techniques distinguishes between the
+ implementation standards applied by the developer () and the implementation
+ standards for ``all parts of the TOE'' () which include third party software,
+ hardware, or firmware. The configuration list introduced in
+ requires that for each TSF
+ relevant configuration item to indicate if it has been
+ generated by the TOE developer or by third party
+ developers.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable
+ results.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the subset of the implementation representation.
+
+
+
+
+ The developer shall provide the documentation identifying each development tool being
+ used for the TOE.
+
+
+ The developer shall document and provide the selected
+ implementation-dependent options of each development tool.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tools is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable results,
+ and whether implementation standards have been
+ applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall provide the documentation identifying each development tool being
+ used for the TOE.
+
+
+ The developer shall document and provide the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe and provide the implementation standards
+ that are being applied by the developer.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is not required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, but only those parts
+ that are developed by the TOE developer himself. The
+ evaluator may consult the configuration list required by
+ the to get the
+ information which parts are developed by the TOE
+ developer, and which by third party developers.
+
+ If the referenced implementation standards are not
+ applied for at least parts of the provided implementation representation,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer and his subcontractors have used
+ well-defined development tools (e.g. programming languages
+ or computer-aided design (CAD) systems) that yield
+ consistent and predictable results, and whether
+ implementation standards have been applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall provide the documentation identifying each development tool being
+ used for the TOE.
+
+
+ The developer shall document and provide the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe and provide the implementation standards
+ that are being applied by the developer and by any
+ third-party providers for all parts of the TOE.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, including third party
+ contributions. This may require the evaluator to visit
+ the sites of contributors. The evaluator may consult the
+ configuration list required by the to see who has developed which part of
+ the TOE.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more other PPs or on packages, that the PP is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ writing an ST or another PP.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+ This standard defines two assurance packages for PP evaluation as follows:
+ Low assurance PP evaluation package;(Standard) PP evaluation package.
+ The assurance components for these packages are defined by table
+ .
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an PP to demonstrate that
+ the PP is sound and internally consistent, and, if the PP is
+ based on one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of a PP. The
+ requirements and methodology for PP evaluation are identical
+ for each PP evaluation, regardless of the EAL (or other set of
+ assurance requirements) that is claimed in the PP. The
+ evaluation methodology in this Clause is based on the
+ requirements on the PP as specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The PP is the description of a TOE type. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ an ST or another PP.
+
+
+
+
+ While evaluating a PP that is based on one or more certified
+ PPs, it may be possible to re-use the fact that these PPs were
+ certified. The potential for re-use of the result of a certified
+ PP is greater if the PP under evaluation does not add threats,
+ OSPs, security objectives and/or security requirements to those
+ of the PP that conformance is being claimed to. If the PP under
+ evaluation contains much more than the certified PP, re-use may
+ not be useful at all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP that conformance is being
+ claimed to contains a set of security requirements, and these
+ were determined to be internally consistent during its
+ evaluation. If the PP under evaluation uses the exact same
+ requirements, the consistency analysis does not have to be
+ repeated during the PP evaluation. If the PP under evaluation
+ adds one or more requirements, or performs operations on these
+ requirements, the analysis will have to be repeated. However, it
+ may be possible to save work in this consistency analysis by
+ using the fact that the original requirements are internally
+ consistent. If the original requirements are internally
+ consistent, the evaluator only has to determine that:
+
+ the set of all new and/or changed requirements is internally
+ consistent, and
+
+ the set of all new and/or changed requirements is consistent
+ with the original requirements.
+
+ The evaluator notes in the ETR each case where analyses
+ are not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way.
+
+ Evaluation of the PP introduction is required to demonstrate
+ that the PP is correctly identified, and that the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The PP introduction describes the TOE in a narrative
+ way.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the PP is correctly identified, and whether the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a PP introduction.
+
+
+ The PP introduction shall contain a PP reference and a TOE
+ overview.
+
+
+ The PP reference shall uniquely identify the PP.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware available to the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the PP introduction
+ contains a PP reference and a TOE overview.
+
+
+
+
+ The evaluator shall examine the PP reference to
+ determine that it uniquely identifies the PP.
+
+ The evaluator determines that the PP reference
+ identifies the PP itself, so that it may be easily
+ distinguished from other PPs, and that it also uniquely
+ identifies each version of the PP, e.g. by including a
+ version number and/or a date of publication.
+
+ The PP should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features expected of the TOE. The TOE overview should
+ enable consumers and potential TOE developers to quickly
+ determine whether the PP is of interest to them.
+
+ The evaluator determines that the overview is clear
+ enough for TOE developers and consumers, and sufficient
+ to give them a general understanding of the intended
+ usage and major security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware available to the TOE.
+
+ While some TOEs may run stand-alone, other TOEs (notably
+ software TOEs) need additional hardware, software or
+ firmware to operate. In this subclause of the PP, the PP
+ author lists all hardware, software, and/or firmware
+ that will be available for the TOE to run on.
+
+ This identification should be detailed enough for
+ potential consumers and TOE developers to determine
+ whether their TOE may operate with the listed hardware,
+ software and firmware.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs and other PPs are to claim conformance with the
+ PP.
+
+
+
+ Conformance claims describes how the Protection Profile
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the PP conforms to the CC, other PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP;
+
+
+ the PP(s) that the PP claims conformance to;
+
+
+ the package(s) that the PP claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The developer shall provide a conformance statement.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the PP claims
+ conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the PP claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ PP to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance statement shall describe the conformance
+ required of any PPs/STs to the PP as strict-PP or
+ demonstrable-PP conformance.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the PP claims
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this PP. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the PP.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the PP.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the PP claims conformance.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+ The evaluator determines that any referenced PPs
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the PP claims conformance.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The relation between the types may be simple: a firewall
+ PP claiming conformance to another firewall PP, or more
+ complex: a smart card PP claiming conformance to a number
+ of other PPs at the same time: a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the PP under evaluation does not claim conformance
+ with another PP, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If the PP to which conformance is being claimed does not
+ have a statement of security problem definition, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether
+
+
+ the threats in the PP under evaluation are a
+ superset of or identical to the threats in the PP to
+ which conformance is being claimed;
+
+
+ the OSPs in the PP under evaluation are a superset
+ of or identical to the OSPs in the PP to which
+ conformance is being claimed;
+
+
+ the assumptions in the PP under evaluation are
+ identical to the assumptions in the PP to which conformance
+ is being claimed;
+
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ problem definition of the PP under evaluation is
+ equivalent or more restrictive than the statement of
+ security problem definition in the PP to which
+ conformance is being claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PPs, with the statement of security
+ objectives in the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether:
+
+ The PP under evaluation contains all security
+ objectives for the TOE of the PP to which
+ conformance is being claimed. Note that it is
+ allowed for the PP under evaluation to have
+ additional security objectives for the TOE;
+ The PP under evaluation contains exactly all
+ security objectives for the operational environment
+ (with one exception in the next bullet). Note that
+ it is not allowed for the PP under evaluation to
+ have additional security objectives for the
+ operational environment;
+ The PP under evaluation may specify that certain
+ objectives for the operational environment in the PP
+ that conformance is being claimed to are security
+ objectives for the TOE in the PP under
+ evaluation. This is a valid exception to the
+ previous bullet.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ objectives in the PP to which conformance is being
+ claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+
+
+ The evaluator shall examine the PP to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the PP
+ under evaluation is a superset of or identical to the
+ statement of security requirements in the PP to which
+ conformance is being claimed (for strict
+ conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ requirements in the PP to which conformance is being
+ claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+
+
+
+ The evaluator shall check that the PP conformance
+ statement states a claim of strict-PP or demonstrable-PP
+ conformance.
+
+
+
+
+
+
+
+ This part of the PP defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or its operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall examine that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and/or threats only, OSPs need not be present in the
+ PP. In this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition and that
+ the division of this problem between the TOE and its
+ operational environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat, the evaluator action
+ related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP, the evaluator action
+ related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ If no security objectives for the operational environment trace back to the assumption,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author. This family is used to determine that these extended
+ components are defined similarly to the existing CC Part 2
+ or CC Part 3 components.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the PP.
+
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the PP, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the PP defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+
+ a member of a new class defined in the PP.
+
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ PP, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the PP author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the PP does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations, the
+ evaluator determines that the extended functional component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the PP does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the PP does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the PP does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the PP does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance to
+ this requirement.
+
+
+
+ The evaluator shall confirm that no extended component may
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component may
+ not be clearly expressed using existing
+ components.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the PP, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is, or whether the SFRs are derived from
+ security objectives for the TOE.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it justifies that the SFRs are suitable to
+ meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the TOE,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ If the SFRs that trace back to a security objective for
+ the TOE have any uncompleted assignments, or uncompleted
+ or restricted selections, the evaluator determines that
+ for every conceivable completion or combination of
+ completions of these operations, the security objective
+ is still met.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+ The evaluator is reminded that any explanation is
+ correct, as long as it is coherent and neither the SARs
+ nor the explanation have obvious inconsistencies with
+ the remainder of the PP.
+ An example of an obvious inconsistency between the
+ SARs and the remainder of the PP would be to have threat
+ agents that are very capable, but an SAR that does not protect against these
+ threat agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an ST, to demonstrate that
+ the ST is sound and internally consistent, and, if the ST is
+ based on one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of an ST. The ST
+ evaluation should be started prior to any TOE evaluation
+ sub-activities since the ST provides the basis and context to
+ perform these sub-activities. The evaluation methodology in
+ this subclause is based on the requirements on the ST as
+ specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The ST describes the security features of a TOE. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+
+
+
+ While evaluating an ST that is based on one or more
+ certified PPs, it may be possible to re-use the fact that
+ these PPs were certified. The potential for re-use of the
+ result of a certified PP is greater if the ST does not add
+ threats, OSPs, assumptions, security objectives and/or
+ security requirements to those of the PP. If the ST
+ contains much more than the certified PP, re-use may not be
+ useful at all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP contains a set of security
+ requirements, and these were determined to be internally
+ consistent during the PP evaluation. If the ST uses the
+ exact same requirements, the consistency analysis does not
+ have to be repeated during the ST evaluation. If the ST adds
+ one or more requirements, or performs operations on these
+ requirements, the analysis will have to be
+ repeated. However, it may be possible to save work in this
+ consistency analysis by using the fact that the original
+ requirements are internally consistent. If the original
+ requirements are internally consistent, the evaluator only
+ has to determine that:
+
+
+ the set of all new and/or changed requirements is
+ internally consistent, and
+
+
+ the set of all new and/or changed requirements is
+ consistent with the original requirements.
+
+
+ The evaluator notes in the ETR each case where analyses are
+ not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way on three levels of abstraction: TOE reference,
+ TOE overview and TOE description.
+
+ Evaluation of the ST introduction is required to demonstrate
+ that the ST and the TOE are correctly identified, that the
+ TOE is correctly described at three levels of abstraction
+ and that these three descriptions are consistent with each
+ other.
+
+
+
+ The ST introduction describes the TOE in a narrative way on
+ three levels of abstraction: TOE reference, TOE overview and
+ TOE description.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the ST and the TOE are correctly identified, whether the
+ TOE is correctly described in a narrative way at three
+ levels of abstraction (TOE reference, TOE overview and TOE
+ description), and whether these three descriptions are
+ consistent with each other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide an ST introduction.
+
+
+ The ST introduction shall contain an ST reference, a TOE
+ reference, a TOE overview and a TOE description.
+
+
+ The ST reference shall uniquely identify the ST.
+
+
+ The TOE reference shall identify the TOE.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware required by the TOE.
+
+
+ The TOE description shall describe the physical scope of the
+ TOE.
+
+
+ The TOE description shall describe the logical scope of the
+ TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the ST introduction
+ contains an ST reference, a TOE reference, a TOE
+ overview and a TOE description.
+
+
+
+
+ The evaluator shall examine the ST reference to
+ determine that it uniquely identifies the ST.
+
+ The evaluator determines that the ST reference
+ identifies the ST itself, so that it may be easily
+ distinguished from other STs, and that it also uniquely
+ identifies each version of the ST, e.g. by including a
+ version number and/or a date of publication.
+
+ In evaluations where a CM system is provided, the
+ evaluator may validate the uniqueness of the reference
+ by checking the configuration list. In the other cases,
+ the ST should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it identifies the TOE.
+
+ The evaluator determines that the TOE reference
+ identifies the TOE, so that it is clear to which TOE the
+ ST refers, and that it also identifies the version of
+ the TOE, e.g. by including a version/release/build
+ number, or a date of release.
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it is not misleading.
+
+ If the TOE is related to one or more well-known
+ products, it is allowed to reflect this in the TOE
+ reference. However, this should not be used to mislead
+ consumers: situations where only a small part of a
+ product is evaluated, yet the TOE reference does not
+ reflect this, are not allowed.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features of the TOE. The TOE overview should enable
+ potential consumers to quickly determine whether the TOE
+ may be suitable for their security needs.
+
+ The TOE overview in an ST for a composed TOE should
+ describe the usage and major security feature of the
+ composed TOE, rather than those of the individual
+ component TOEs.
+
+ The evaluator determines that the overview is clear
+ enough for consumers, and sufficient to give them a
+ general understanding of the intended usage and major
+ security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that the TOE type is not misleading.
+
+ There are situations where the general consumer would
+ expect certain functionality of the TOE because of its
+ TOE type. If this functionality is absent in the TOE,
+ the evaluator determines that the TOE overview
+ adequately discusses this absence.
+
+ There are also TOEs where the general consumer would
+ expect that the TOE should be able to operate in a
+ certain operational environment because of its TOE
+ type. If the TOE is unable to operate in such an
+ operational environment, the evaluator determines that
+ the TOE overview adequately discusses this.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware required by the TOE.
+
+ While some TOEs are able to run stand-alone, other TOEs
+ (notably software TOEs) need additional hardware,
+ software or firmware to operate. If the TOE does not
+ require any hardware, software or firmware, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the TOE overview
+ identifies any additional hardware, software and
+ firmware needed by the TOE to operate. This
+ identification does not have to be exhaustive, but
+ detailed enough for potential consumers of the TOE to
+ determine whether their current hardware, software and
+ firmware support use of the TOE, and, if this is not the
+ case, which additional hardware, software and/or
+ firmware is needed.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the physical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description lists
+ the hardware, firmware, software and guidance parts that
+ constitute the TOE and describes them at a level of
+ detail that is sufficient to give the reader a general
+ understanding of those parts.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any hardware, firmware,
+ software or guidance part is part of the TOE or
+ not.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the logical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description
+ discusses the logical security features offered by the
+ TOE at a level of detail that is sufficient to give the
+ reader a general understanding of those features.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any logical security
+ feature is offered by the TOE or not.
+
+ An ST for a composed TOE may refer out to the
+ description of the logical scope of the component TOEs,
+ provided in the component TOE STs to provide the
+ majority of this description for the composed TOE.
+ However, the evaluator determines that the composed TOE
+ ST clearly discusses which features of the individual
+ components are not within the composed TOE, and
+ therefore not a feature of the composed TOE.
+
+
+
+ The evaluator shall confirm that the TOE reference, the TOE
+ overview, and the TOE description are consistent with each
+ other.
+
+
+ The evaluator shall examine the TOE reference, TOE
+ overview and TOE description to determine that they are
+ consistent with each other.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs are to claim conformance with the PP.
+
+
+
+ Conformance claims describes how the Security Target
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the ST and the TOE conform to the CC and how the ST
+ conforms to PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the PP(s) that the ST claims conformance to;
+
+
+ the package(s) that the ST claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the ST and
+ the TOE claim conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the ST claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ ST to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the ST and the TOE claim
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this ST. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+ For a composed TOE, the evaluator will consider any
+ differences between the version of the CC claimed for a
+ component and the version of the CC claimed for the
+ composed TOE. If the versions differ the evaluator will
+ assess whether the differences between the versions will
+ lead to conflicting claims.
+
+ For instances where the CC conformance claims for the
+ base TOE and dependent TOE are for different major
+ releases of the CC (e.g. one component TOE conformance
+ claim is CC v2.x and the other component TOE conformance
+ claim is CC v3.x), the conformance claim for the
+ composed TOE will be the earlier release of the CC, as
+ the CC is developed with an aim to provide backwards
+ compatibility (although this may not be achieved in the
+ strictest sense, it is understood to be achieved in
+ principle).
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the ST.
+
+ For a composed TOE, the evaluator will consider whether
+ this claim is consistent not only with the CC Part 2,
+ but also with the claims of conformance to CC Part 2 by
+ each of the component TOEs. I.e. if one or more
+ component TOEs claims to be CC Part 2 extended, then the
+ composed TOE should also claim to be CC Part 2
+ extended.
+
+ The CC conformance claim for the composed TOE may be CC
+ Part 2 extended, even though the component TOEs are Part
+ 2 conformant, in the event that additional SFRs are
+ claimed for the base TOE (see composed TOE guidance for
+ )
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the ST.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the ST claims conformance.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that any referenced PPs are
+ unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted. Therefore,
+ conformance to a PP requiring a composite solution may
+ be claimed in an ST for a composed TOE. Conformance to
+ such a PP would not have been possible during the
+ evaluation of the component TOEs, as these components
+ would not have satisfied the composed solution. This is
+ only possible in the instances where the ``composite'' PP
+ permits use of the composition evaluation approach (use
+ of components).
+
+ The ST for a composed TOE will identify the STs of the
+ component TOEs from which the composed ST is comprised.
+ The composed TOE is essentially claiming conformance to
+ the STs of the component TOEs.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the ST claims conformance.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator determines that the component TOE STs from
+ which the composed TOE is derived are also unambiguously
+ identified.
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the ST
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package then the ST
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The relation between the types may be simple: a firewall
+ ST claiming conformance to a firewall PP, or more
+ complex: a smart card ST claiming conformance to a number
+ of PPs at the same time (a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card).
+
+ For a composed TOE, the evaluator will determine whether
+ the conformance claim rationale demonstrates that the
+ TOE types of the component TOEs are consistent with the
+ composed TOE type. This does not mean that both the
+ component and the composed TOE types have to be the
+ same, but rather that the component TOEs are suitable
+ for integration to provide the composed TOE. It should be made clear in the composed TOE ST which SFRs are only included as a result of composition, and were not examined as SFRs in the base and dependent TOE (e.g. EALx) evaluation.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the ST does not claim conformance with a PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the PP does not have a statement of security problem
+ definition, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether:
+
+
+ the threats in the ST are a superset of or identical
+ to the threats in the PP to which conformance is
+ being claimed;
+
+
+ the OSPs in the ST are a superset of or identical to
+ the OSPs in the PP to which conformance is being
+ claimed;
+
+ the assumptions in the ST are identical to the
+ assumptions in the PP to which conformance is being
+ claimed;
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security problem definition of the ST is equivalent or
+ more restrictive than the statement of security problem
+ definition in the PP to which conformance is being
+ claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+ For a composed TOE, the evaluator will consider whether
+ the security problem definition of the composed TOE is
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ Threat statements and OSPs in the composed TOE ST do
+ not contradict those from the component STs.
+
+ Any assumptions made in the component STs are upheld
+ in the composed TOE ST. That is, either the
+ assumption should also be present in the composed
+ ST, or the assumption should be positively addressed
+ in the composed ST. The assumption may be
+ positively addressed through specification of
+ requirements in the composed TOE to provide
+ functionality fulfilling the concern captured in the
+ assumption.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PP, with the statement of security
+ objectives in the PPs to which conformance is being claimed.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP, no
+ conformance claim rationale is required. Instead, the
+ evaluator determines whether:
+
+ The ST contains all security objectives for the
+ TOE of the PP to which conformance is being
+ claimed. Note that it is allowed for the ST under
+ evaluation to have additional security objectives
+ for the TOE;
+ The ST contains exactly all security objectives
+ for the operational environment (with one exception
+ in the next bullet). Note that it is not allowed for
+ the ST under evaluation to have additional security
+ objectives for the operational environment;
+ The ST may specify that certain objectives for
+ the operational environment in the PP that
+ conformance is being claimed to are security
+ objectives for the TOE in the ST. This is a valid
+ exception to the previous bullet.
+
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the ST is equivalent or more restrictive
+ than the statement of security objectives in the PP to
+ which conformance is being claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+ For a composed TOE, the evaluator will consider whether
+ the security objectives of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment are consistent with the
+ statement of security objectives for the TOE in the
+ base TOE ST. It is not expected that the statement
+ of security objectives for the environment within in
+ the dependent TOE ST will cover all aspects of the
+ statement of security objectives for the TOE in the
+ base TOE ST.
+
+ The statement of security objectives in the composed
+ ST is consistent with the statements of security
+ objectives in the STs for the component TOEs.
+
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security objectives of the ST is at least equivalent to
+ the statement of security objectives in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+ The evaluator shall examine the ST to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the ST
+ is a superset of or identical to the statement of
+ security requirements in the PP to which conformance is
+ being claimed (for strict conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is equivalent or more restrictive
+ than the statement of security requirements in the PP to
+ which conformance is being claimed.
+ For guidance on ``equivalent or more restrictive''
+ see CC Part 1 .
+
+
+ For a composed TOE, the evaluator will consider whether
+ the security requirements of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance rationale to determine that:
+
+
+ The statement of security requirements in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security requirements for the
+ environment within in the dependent TOE ST will
+ cover all aspects of the statement of security
+ requirements for the TOE in the base TOE ST, as
+ some SFRs may need to be added to the statement of
+ security requirements in the composed TOE ST.
+ However, the statement of security requirements in
+ the base should support the operation of the dependent
+ component.
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security objectives for the environment
+ within in the dependent TOE ST will cover all
+ aspects of the statement of security requirements
+ for the TOE in the base TOE ST.
+
+ The statement of security requirements in the
+ composed is consistent with the statements of
+ security requirements in the STs for the component
+ TOEs.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is at least equivalent to the
+ statement of security requirements in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+
+
+
+ This part of the ST defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall examine that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and threats only, OSPs need not be present in the ST. In
+ this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition, that the
+ division of this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ If no security objectives for the operational environment trace back to the assumption,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the ST
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended components are defined wherever it is impossible to
+ clearly express requirements using only components from CC
+ Part 2 and/or CC Part 3.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the ST.
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the ST, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the ST defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+ a member of a new class defined in the ST.
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ ST, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the ST author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the ST does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations, the
+ evaluator determines that the extended functional component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the ST does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the ST does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the ST does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the ST does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance
+ with this requirement.
+
+
+
+ The evaluator shall confirm that no extended component can
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component can
+ not be clearly expressed using existing
+ components.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the ST, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and canonical
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that a
+ security requirements rationale is provided which justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+ All subjects, objects,
+ operations, security attributes, external entities and other
+ terms that are used in the SFRs and the SARs shall be
+ defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFRs is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that all SARs are identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it demonstrates that the SFRs are suitable
+ to meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the TOE,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+
+ The evaluator is reminded that any explanation is correct, as
+ long as it is coherent and neither the SARs nor the explanation
+ have obvious inconsistencies with the remainder of the ST.
+
+ An example of an obvious inconsistency between the SARs and the
+ remainder of the ST would be to have threat agents that are very
+ capable, but an SAR that does not
+ protect against these threat agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended assurance requirement
+ specifying an open source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+ The TOE summary specification enables evaluators and
+ potential consumers to gain a general understanding of how
+ the TOE is implemented.
+
+ Evaluation of the TOE summary specification is necessary to
+ determine whether it is adequately described how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass. and whether the TOE
+ summary specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The TOE Summary specification allows evaluators and
+ potential consumers of the TOE to gain a general
+ understanding of how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass.
+
+
+
+ The components in this family are levelled on whether the
+ TOE summary specification only needs to describe how the TOE
+ meets the SFRs, or whether the TOE summary specification
+ also needs to describe how the TOE protects itself against
+ logical tampering and bypass. This additional description
+ may be used in special circumstances where there might be a
+ specific concern regarding the TOE security architecture.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, and
+ whether the TOE summary specification is consistent with
+ other narrative descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each description is to provide
+ potential consumers of the TOE with a high-level view of how the developer intends
+ to satisfy each SFR and that the descriptions therefore should not be overly detailed.
+ Often several SFRs will be implemented in one context; for instance a password
+ authentication mechanism may implement ,
+ and .
+ Therefore usually the TSS will not consist of a long list with texts for each single
+ SFR, but complete groups of SFRs may be covered by one text passage.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, whether
+ the TOE summary specification addresses interference,
+ logical tampering and bypass, and whether the TOE summary
+ specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against interference and logical tampering.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against bypass.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each description is to provide
+ potential consumers of the TOE with a high-level view of how the developer intends
+ to satisfy each SFR and that the descriptions therefore should not be overly detailed.
+ Often several SFRs will be implemented in one context; for instance a password
+ authentication mechanism may implement ,
+ and .
+ Therefore usually the TSS will not consist of a long list with texts for each single
+ SFR, but complete groups of SFRs may be covered by one text passage.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against interference and logical
+ tampering.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against interference and logical
+ tampering and that the descriptions therefore should not
+ be overly detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against bypass.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against bypass and that the
+ descriptions therefore should not be overly
+ detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+ The class ``Tests'' encompasses four families: , ,
+ (i.e. functional testing
+ performed by evaluators), and . Testing provides assurance that the TSF
+ behaves as described (in the functional specification, TOE
+ design, and implementation representation).
+
+ The emphasis in this class is on confirmation that the TSF
+ operates according to its design descriptions. This class does
+ not address penetration testing, which is based upon an
+ analysis of the TSF that specifically seeks to identify
+ vulnerabilities in the design and implementation of the
+ TSF. Penetration testing is addressed separately as an aspect
+ of vulnerability assessment in the class.
+
+ The class separates testing into
+ developer testing and evaluator testing. The and families address the completeness of developer
+ testing. addresses the rigour
+ with which the functional specification is tested; addresses whether testing against
+ other design descriptions (security architecture, TOE design,
+ implementation representation) is required.
+
+ addresses the performing of
+ the tests by the developer and how this testing should be
+ documented. Finally, then
+ addresses evaluator testing: whether the evaluator should
+ repeat part or all of the developer testing and how much
+ independent testing the evaluator should do.
+
+
+
+ Assurance class states testing
+ requirements that demonstrate that the TOE matches its design
+ descriptions as provided in the
+ class.
+
+
+
+ The goal of this activity is to determine whether the TOE
+ behaves as described in the ST and as specified in the
+ evaluation evidence (described in the class). This determination is achieved through
+ some combination of the developer's own functional testing of
+ the TSF () and independent
+ testing the TSF by the evaluator (). At the lowest level of assurance, there is no
+ requirement for developer involvement, so the only testing is
+ conducted by the evaluator, using the limited available
+ information about the TOE. Additional assurance is gained as
+ the developer becomes increasingly involved both in testing
+ and in providing additional information about the TOE, and as
+ the evaluator increases the independent testing
+ activities.
+
+
+
+ Testing of the TSF is conducted by the evaluator and, in most
+ cases, by the developer. The evaluator's testing efforts
+ consist not only of creating and running original tests, but
+ also of assessing the adequacy of the developer's tests and
+ re-running a subset of them.
+
+ The evaluator analyses the developer's tests to determine the
+ extent to which they are sufficient to demonstrate that TSFI
+ (see ) perform as specified,
+ and to understand the developer's approach to
+ testing. Similarly, the evaluator analyses the developer's
+ tests to determine the extent to which they are sufficient to
+ demonstrate the internal behaviour and properties of the
+ TSF.
+ The evaluator also executes a subset of the developer's
+ tests as documented to gain confidence in the developer's test
+ results: the evaluator will use the results of this analysis
+ as an input to independently testing a subset of the TSF. With
+ respect to this subset, the evaluator takes a testing approach
+ that is different from that of the developer, particularly if
+ the developer's tests have shortcomings.
+
+ To determine the adequacy of developer's test documentation or
+ to create new tests, the evaluator needs to understand the
+ desired expected behaviour of the TSF, both internally and as
+ seen at the TSFI, in the context of the SFRs it is to
+ satisfy. The evaluator may choose to divide the TSF and TSFI
+ into subsets according to functional areas of the ST (audit
+ subsystem, audit-related TSFI, authentication module,
+ authentication-related TSFI, etc.) if they were not already
+ divided in the ST, and focus on one subset of the TSF and TSFI
+ at a time, examining the ST requirement and the relevant parts
+ of the development and guidance documentation to gain an
+ understanding of the way the TOE is expected to behave. This
+ reliance upon the development documentation underscores the need
+ for the dependencies on by and .
+
+ The CC has separated coverage and depth from functional tests
+ to increase the flexibility when applying the components of
+ the families. However, the requirements of the families are
+ intended to be applied together to confirm that the TSF
+ operates according to its specification. This tight coupling
+ of families has led to some duplication of evaluator work
+ units across sub-activities. These application notes are used
+ to minimise duplication of text between sub-activities.
+
+
+ Before the adequacy of test documentation can be accurately
+ evaluated, or before new tests can be created, the evaluator
+ has to understand the desired expected behaviour of a
+ security function in the context of the requirements it is
+ to satisfy.
+
+ As mentioned earlier, the evaluator may choose to subset the
+ TSF and TSFI according to SFRs (audit, authentication, etc.)
+ in the ST and focus on one subset at a time. The evaluator
+ examines each ST requirement and the relevant parts of the
+ functional specification and guidance documentation to gain
+ an understanding of the way the related TSFI is expected to
+ behave. Similarly, the evaluator examines the relevant parts
+ of the TOE design and security architecture documentation to
+ gain an understanding of the way the related modules or
+ subsystems of the TSF are expected to behave.
+
+ With an understanding of the expected behaviour, the
+ evaluator examines the test plan to gain an understanding of
+ the testing approach. In most cases, the testing approach
+ will entail a TSFI being stimulated and its responses
+ observed. Externally-visible functionality can be tested
+ directly; however, in cases where functionality is not
+ visible external to the TOE (for example, testing the
+ residual information protection functionality), other means
+ will need to be employed.
+
+
+
+ In cases where it is impractical or inadequate to test
+ specific functionality (where it provides no
+ externally-visible TSFI), the test plan should identify the
+ alternate approach to verify expected behaviour. It is the
+ evaluator's responsibility to determine the suitability of
+ the alternate approach. However, the following should be
+ considered when assessing the suitability of alternate
+ approaches:
+
+
+ an analysis of the implementation representation to
+ determine that the required behaviour should be
+ exhibited by the TOE is an acceptable alternate
+ approach. This could mean a code inspection for a
+ software TOE or perhaps a chip mask inspection for a
+ hardware TOE.
+
+
+ it is acceptable to use evidence of developer
+ integration or module testing, even if the claimed
+ assurance requirements do not include availability of
+ lower level descriptions of the TOE modules (e.g. ) or implementation (). If evidence of developer
+ integration or module testing is used in verifying the
+ expected behaviour of a security functionality, care
+ should be given to confirm that the testing evidence
+ reflects the current implementation of the TOE. If the
+ subsystems or modules have been changed since testing
+ occurred, evidence that the changes were tracked and
+ addressed by analysis or further testing will usually be
+ required.
+
+
+
+ It should be emphasised that supplementing the testing
+ effort with alternate approaches should only be undertaken
+ when both the developer and evaluator determine that there
+ exists no other practical means to test the expected
+ behaviour.
+
+
+
+ Test pre-requisites are necessary to establish the required
+ initial conditions for the test. They may be expressed in
+ terms of parameters that must be set or in terms of test
+ ordering in cases where the completion of one test
+ establishes the necessary pre-requisites for another
+ test. The evaluator must determine that the pre-requisites
+ are complete and appropriate in that they will not bias the
+ observed test results towards the expected test
+ results.
+
+ The test steps and expected results specify the actions and
+ parameters to be applied to the TSFI as well as how the
+ expected results should be verified and what they are. The
+ evaluator must determine that the test steps and expected
+ results are consistent with the descriptions of the TSFI in
+ the functional specification. This means that each
+ characteristic of the TSFI behaviour explicitly described in
+ the functional specification should have tests and expected
+ results to verify that behaviour.
+
+ The overall aim of this testing activity is to determine
+ that each subsystem, module, and TSFI has been sufficiently
+ tested against the behavioural claims in the functional
+ specification, TOE design, and architecture description. At
+ the higher assurance levels, testing also includes bounds
+ testing and negative testing. The test procedures will
+ provide insight as to how the TSFIs, modules, and subsystems
+ have been exercised by the developer during testing. The
+ evaluator uses this information when developing additional
+ tests to independently test the TSF.
+
+
+
+
+
+ This family establishes that the TSF has been tested against
+ its functional specification. This is achieved through an
+ examination of developer evidence of correspondence.
+
+
+
+ Coverage deals with the completeness of the functional tests
+ performed by the developer on the TOE. It addresses the
+ extent to which the TSF is tested.
+
+
+
+ The components in this family are levelled on the basis of
+ specification.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to establish that some
+ of the TSFIs have been tested.
+
+
+
+ In this component the developer shows how tests in the
+ test documentation correspond to TSFIs in the functional
+ specification. This can be achieved by a statement of
+ correspondence, perhaps using a table.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+ The coverage analysis provided by the developer is
+ required to show the correspondence between the tests
+ provided as evaluation evidence and the functional
+ specification. However, the coverage analysis need not
+ demonstrate that all TSFI have been tested, or that all
+ externally-visible interfaces to the TOE have been
+ tested. Such shortcomings are considered by the evaluator
+ during the independent testing () sub-activity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage evidence.
+
+
+
+
+ The developer shall provide evidence of the test coverage.
+
+
+ The evidence of the test coverage shall show the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage evidence
+ to determine that the correspondence between the tests
+ identified in the test documentation and the TSFIs
+ described in the functional specification is
+ accurate.
+
+ Correspondence may take the form of a table or
+ matrix. The coverage evidence required for this
+ component will reveal the extent of coverage, rather
+ than to show complete coverage. In cases where coverage
+ is shown to be poor the evaluator should increase the
+ level of independent testing to compensate.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to confirm that all of
+ the TSFIs have been tested.
+
+
+
+ In this component the developer confirms that tests in the
+ test documentation correspond to all of the TSFIs in the
+ functional specification. This can be achieved by a
+ statement of correspondence, perhaps using a table, but
+ the developer also provides an analysis of the test
+ coverage.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested all of the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage analysis.
+
+
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the tests
+ in the test documentation and the interfaces in the
+ functional specification is accurate.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ interfaces presented in the test coverage analysis has
+ to be unambiguous.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the testing approach for each interface
+ demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that the test prerequisites, test steps and
+ expected result(s) adequately test each
+ interface.
+
+ Guidance on this work units, as it pertains to the
+ functional specification, can be found in:
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the
+ interfaces in the functional specification and the tests
+ in the test documentation is complete.
+
+ All TSFIs that are described in the functional
+ specification have to be present in the test coverage
+ analysis and mapped to tests in order for completeness
+ to be claimed, although exhaustive specification testing
+ of interfaces is not required. Incomplete coverage would
+ be evident if an interface was identified in the
+ functional specification and no test was mapped to
+ it.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to confirm that the
+ developer performed exhaustive tests of all interfaces in
+ the functional specification.
+
+ The objective of this component is to confirm that all
+ parameters of all of the TSFIs have been tested.
+
+
+
+ In this component the developer is required to show how
+ tests in the test documentation correspond to all of the
+ TSFIs in the functional specification. This can be
+ achieved by a statement of correspondence, perhaps using a
+ table, but in addition the developer is required to
+ demonstrate that the tests exercise all of the parameters
+ of all TSFIs. This additional requirement includes bounds
+ testing (i.e. verifying that errors are generated when
+ stated limits are exceeded) and negative testing
+ (e.g. when access is given to User A, verifying not only
+ that User A now has access, but also that User B did not
+ suddenly gain access). This kind of testing is not,
+ strictly speaking, exhaustive because not
+ every possible value of the parameters is expected to be
+ checked.
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been completely
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The components in this family deal with the level of detail
+ to which the TSF is tested by the developer. Testing of the
+ TSF is based upon increasing depth of information derived
+ from additional design representations and descriptions (TOE
+ design, implementation representation, and security
+ architecture description).
+
+ The objective is to counter the risk of missing an error in
+ the development of the TOE. Testing that exercises specific
+ internal interfaces can provide assurance not only that the
+ TSF exhibits the desired external security behaviour, but
+ also that this behaviour stems from correctly operating
+ internal functionality.
+
+
+
+ Depth deals with the level of detail to which the developer
+ tests the TSF. Testing is based upon increasing depth of
+ information derived from analysis of the TSF
+ representations.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing detail provided in the TSF representations, from
+ the TOE design to the implementation representation. This
+ levelling reflects the TSF representations presented in the
+ class.
+
+
+
+ The TOE design describes the internal components
+ (e.g. subsystems) and, perhaps, modules of the TSF, together
+ with a description of the interfaces among these components and
+ modules. Evidence of testing of this TOE design must show that
+ the internal interfaces have been exercised and seen to behave
+ as described. This may be achieved through testing via the
+ external interfaces of the TSF, or by testing of the TOE
+ subsystem or module interfaces in isolation, perhaps employing a
+ test harness. In cases where some aspects of an internal
+ interface cannot be tested via the external interfaces, there
+ should either be justification that these aspects need not be
+ tested, or the internal interface needs to be tested
+ directly. In the latter case the TOE design needs to be
+ sufficiently detailed in order to facilitate direct
+ testing.
+
+ In cases where the description of the TSF's architectural
+ soundness (in ) cites
+ specific mechanisms, the tests performed by the developer
+ must show that the mechanisms have been exercised and seen
+ to behave as described.
+
+ At the highest component of this family, the testing is
+ performed not only against the TOE design, but also against
+ the implementation representation.
+
+
+
+
+
+
+
+ The subsystem descriptions of the TSF provide a high-level
+ description of the internal workings of the TSF. Testing
+ at the level of the TOE subsystems provides assurance that
+ the TSF subsystems behave and interact as described in the
+ TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSF subsystems against the
+ TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the descriptions of the
+ behaviour of TSF subsystems and of their interactions is
+ included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ When is combined with a component of , which includes descriptions at the module level
+ (e.g. ), the level of detail needed to map
+ the test cases to the behaviour of the subsystems may require
+ information from the module description to be used. This is
+ because allows the description of details
+ to be shifted from the subsystem level to the module level, or
+ even to omit the subsystems altogether.
+ In any case, the required level of detail in the provided
+ reference to the tested behaviour can be defined as ``the level
+ of detail required for the description of subsystem behaviour as
+ defined by (in particular work unit )''. It states that a detailed description of
+ the behaviour typically discusses how the functionality is
+ provided, in terms of what key data and data structures re
+ present; what control relationships exist within a subsytem and
+ how these elements work together to provide the SFR-enforcing
+ behaviour.
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ When is combined with a component of , which includes descriptions at the module level
+ (e.g. ), the level of detail needed to map
+ the test cases to the behaviour of the subsystems may require
+ information from the module description to be used. This is
+ because allows the description of details
+ to be shifted from the subsystem level to the module level, or
+ even to omit the subsystems altogether.
+ In any case, the required level of detail in the provided
+ reference to the tested behaviour can be defined as ``the level
+ of detail required for the description of subsystem behaviour as
+ defined by (in particular work unit )''. It states that a detailed description of
+ the behaviour typically discusses how the functionality is
+ provided, in terms of what key data and data structures re
+ present; what control relationships exist within a subsytem and
+ how these elements work together to provide the SFR-enforcing
+ behaviour.
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ When is combined with a component of , which includes descriptions at the module level
+ (e.g. ), the level of detail needed to map
+ the test cases to the behaviour of the subsystems may require
+ information from the module description to be used. This is
+ because allows the description of details
+ to be shifted from the subsystem level to the module level, or
+ even to omit the subsystems altogether.
+ In any case, the required level of detail in the provided
+ reference to the tested behaviour can be defined as ``the level
+ of detail required for the description of subsystem behaviour as
+ defined by (in particular work unit )''. It states that a detailed description of
+ the behaviour typically discusses how the functionality is
+ provided, in terms of what key data and data structures re
+ present; what control relationships exist within a subsytem and
+ how these elements work together to provide the SFR-enforcing
+ behaviour.
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to the subsystem behaviour
+ or interaction description in the TOE design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the SFR-enforcing
+ modules, of the TSF. Testing at this level of TOE
+ description provides assurance that the TSF subsystems and
+ SFR-enforcing modules behave and interact as described in
+ the TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has tested all the TSF subsystems and SFR-enforcing
+ modules against the TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation and
+ the TSF subsystems and SFR-enforcing modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the SFR-enforcing modules in the TOE design have been
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of
+ SFR-enforcing modules are included within the test
+ documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms at the modular
+ level, this work unit also verifies the correspondence
+ between the tests and the descriptions of the behaviour
+ of such mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ SFR-enforcing modules presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to the interfaces of SFR-enforcing modules.
+
+
+
+
+ The evaluator shall examine the test plan, test prerequisites,
+ test steps and expected result(s) to determine that the testing
+ approach for each SFR-enforcing module interface demonstrates
+ the expected behaviour of that interface.
+
+ While work unit addresses
+ expected behaviour of subsystems, this work unit addresses
+ expected behaviour of the SFR-enforcing module interfaces that
+ are covered by .
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to the subsystem behaviour
+ or interaction description in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all interfaces of SFR-enforcing modules
+ are tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of SFR-enforcing modules that are provided in the TOE
+ design have to be tested. Incomplete depth of testing
+ would be evident if any interface of any SFR-enforcing
+ modules was identified in the TOE design and no tests
+ could be attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of an SFR-enforcing module in the TOE
+ design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description.
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has tested the all the TSF subsystems and modules
+ against the TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that all
+ TSF modules in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are provided, the behaviour
+ of those subsystems may be performed directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ If TSF subsystem interfaces are provided, the
+ interactions with other subsystems may be performed
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of TSF modules
+ are included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for each TSF module
+ interface demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to the subsystem behaviour
+ or interaction description in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to determine
+ that all interfaces of all TSF modules are tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of TSF modules that are provided in the TOE design have
+ to be tested. Incomplete depth of testing would be
+ evident if any interface of any TSF module was
+ identified in the TOE design and no tests could be
+ attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of a TSF module in the TOE design.
+
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description, and in accordance with the
+ implementation representation.
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all modules in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the TSF operates in accordance with its implementation
+ representation.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ Functional testing performed by the developer provides
+ assurance that the tests in the test documentation are
+ performed and documented correctly. The correspondence of
+ these tests to the design descriptions of the TSF is
+ achieved through the and
+ families.
+
+ This family contributes to providing assurance that the
+ likelihood of undiscovered flaws is relatively small.
+
+ The families , and are used in combination to define the evidence
+ of testing to be supplied by a developer. Independent
+ functional testing by the evaluator is specified by .
+
+
+
+ Functional testing establishes that the tests performed by
+ the developer are performed and documented correctly.
+
+
+
+ This family contains two components, the higher requiring
+ that ordering dependencies are analysed.
+
+
+
+ Procedures for performing tests are expected to provide
+ instructions for using test programs and test suites,
+ including the test environment, test conditions, test data
+ parameters and values. The test procedures should also show
+ how the test results are derived from the test
+ inputs.
+
+ Ordering dependencies are relevant when the successful
+ execution of a particular test depends upon the existence of
+ a particular state. For example, this might require that
+ test A be executed immediately before test B, since the
+ state resulting from the successful execution of test A is a
+ prerequisite for the successful execution of test B. Thus,
+ failure of test B could be related to a problem with the
+ ordering dependencies. In the above example, test B could
+ fail because test C (rather than test A) was executed
+ immediately before it, or the failure of test B could be
+ related to a failure of test A.
+
+
+
+
+
+ The objective is for the developer to demonstrate that the
+ tests in the test documentation are performed and
+ documented correctly.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented the tests
+ in the test documentation.
+
+
+
+ The extent to which the test documentation is required to
+ cover the TSF is dependent upon the coverage assurance
+ component.
+
+ For the developer tests provided, the evaluator determines
+ whether the tests are repeatable, and the extent to which
+ the developer's tests can be used for the evaluator's
+ independent testing effort. Any TSFI for which the
+ developer's test results indicate that it might not
+ perform as specified should be tested independently by the
+ evaluator to determine whether or not it does.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation.
+
+
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the test documentation
+ includes test plans, expected test results and actual
+ test results.
+
+ The evaluator checks that test plans, expected tests
+ results and actual test results are included in the test
+ documentation.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that it describes the scenarios for performing each
+ test.
+
+ The evaluator determines that the test plan provides
+ information about the test configuration being used:
+ both on the configuration of the TOE and on any test
+ equipment being used. This information should be
+ detailed enough to ensure that the test configuration is
+ reproducible.
+
+ The evaluator also determines that the test plan
+ provides information about how to execute the test: any
+ necessary automated set-up procedures (and whether they
+ require privilege to run), inputs to be applied, how
+ these inputs are applied, how output is obtained, any
+ automated clean-up procedures (and whether they require
+ privilege to run), etc. This information should be
+ detailed enough to ensure that the test is
+ reproducible.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the TOE test configuration is consistent with the
+ ST.
+
+ The TOE referred to in the developer's test plan should
+ have the same unique reference as established by the
+ sub-activities and
+ identified in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The evaluator verifies
+ that all test configurations identified in the developer
+ test documentation are consistent with the ST. For
+ example, the ST might define configuration options that
+ must be set, which could have an impact upon what
+ constitutes the TOE by including or excluding additional
+ portions. The evaluator verifies that all such
+ variations of the TOE are considered.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+ If this work unit is applied to a component TOE that
+ might be used/integrated in a composed TOE (see ), the following will apply. In
+ the instances that the component TOE under evaluation
+ depends on other components in the operational
+ environment to support their operation, the developer
+ may wish to consider using the other component(s) that
+ will be used in the composed TOE to fulfil the
+ requirements of the operational environment as one of
+ the test configurations. This will reduce the amount an
+ additional testing that will be required for the
+ composed TOE evaluation.
+
+
+
+
+ The evaluator shall examine the test plans to determine
+ that sufficient instructions are provided for any
+ ordering dependencies.
+
+ Some steps may have to be performed to establish initial
+ conditions. For example, user accounts need to be added
+ before they can be deleted. An example of ordering
+ dependencies on the results of other tests is the need
+ to perform actions in a test that will result in the
+ generation of audit records, before performing a test to
+ consider the searching and sorting of those audit
+ records. Another example of an ordering dependency
+ would be where one test case generates a file of data to
+ be used as input for another test case.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that all expected tests results are
+ included.
+
+ The expected test results are needed to determine
+ whether or not a test has been successfully
+ performed. Expected test results are sufficient if they
+ are unambiguous and consistent with expected behaviour
+ given the testing approach.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall check that the actual test results
+ in the test documentation are consistent with the
+ expected test results in the test documentation.
+
+ A comparison of the actual and expected test results
+ provided by the developer will reveal any
+ inconsistencies between the results. It may be that a
+ direct comparison of actual results cannot be made until
+ some data reduction or synthesis has been first
+ performed. In such cases, the developer's test
+ documentation should describe the process to reduce or
+ synthesise the actual data.
+
+ For example, the developer may need to test the contents
+ of a message buffer after a network connection has
+ occurred to determine the contents of the buffer. The
+ message buffer will contain a binary number. This binary
+ number would have to be converted to another form of
+ data representation in order to make the test more
+ meaningful. The conversion of this binary representation
+ of data into a higher-level representation will have to
+ be described by the developer in enough detail to allow
+ an evaluator to perform the conversion process
+ (i.e. synchronous or asynchronous transmission, number
+ of stop bits, parity, etc.).
+
+ It should be noted that the description of the process
+ used to reduce or synthesise the actual data is used by
+ the evaluator not to actually perform the necessary
+ modification but to assess whether this process is
+ correct. It is up to the developer to transform the
+ expected test results into a format that allows an easy
+ comparison with the actual test results.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall report the developer testing effort,
+ outlining the testing approach, configuration, depth and
+ results.
+
+ The developer testing information recorded in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing of the TOE by the developer. The intent
+ of providing this information is to give a meaningful overview
+ of the developer testing effort. It is not intended that the
+ information regarding developer testing in the ETR be an exact
+ reproduction of specific test steps or results of individual
+ tests. The intention is to provide enough detail to allow other
+ evaluators and evaluation authorities to gain some insight about the
+ developer's testing approach, amount of testing performed, TOE
+ test configurations, and the overall results of the developer
+ testing.
+
+ Information that would typically be found in the ETR
+ subclause regarding the developer testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested,
+ including whether any privileged code was required
+ to set up the test or clean up afterwards;
+
+
+ testing approach. An account of the overall
+ developer testing strategy employed;
+
+
+ testing results. A description of the overall
+ developer testing results.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ developer testing effort.
+
+
+
+
+
+
+
+
+ The objectives are for the developer to demonstrate that
+ the tests in the test documentation are performed and
+ documented correctly, and to ensure that testing is
+ structured such as to avoid circular arguments about the
+ correctness of the interfaces being tested.
+
+
+
+ Although the test procedures may state pre-requisite
+ initial test conditions in terms of ordering of tests,
+ they may not provide a rationale for the ordering. An
+ analysis of test ordering is an important factor in
+ determining the adequacy of testing, as there is a
+ possibility of faults being concealed by the ordering of
+ tests.
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The test documentation shall include an analysis of the test
+ procedure ordering dependencies.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The objectives of this family are built upon the assurances
+ achieved in the , , and
+ families by verifying the developer testing and performing
+ additional tests by the evaluator.
+
+
+
+ Independent testing specifies the degree to which the
+ testing of the TSF must be performed by a party other than
+ the developer (e.g. a third party). This family adds value
+ by the introduction of tests that are not part of the
+ developer's tests.
+
+
+
+ Levelling is based upon the amount of developer test
+ documentation and test support and the amount of evaluator
+ testing.
+
+
+
+ This family deals with the degree to which there is
+ independent functional testing of the TSF. Independent
+ functional testing may take the form of repeating the
+ developer's functional tests (in whole or in part) or of
+ extending the scope or the depth of the developer's
+ tests. These activities are complementary, and an
+ appropriate mix must be planned for each TOE, which takes
+ into account the availability and coverage of test results,
+ and the functional complexity of the TSF.
+
+ Sampling of developer tests is intended to provide
+ confirmation that the developer has carried out his planned
+ test programme on the TSF, and has correctly recorded the
+ results. The size of sample selected will be influenced by
+ the detail and quality of the developer's functional test
+ results. The evaluator will also need to consider the scope
+ for devising additional tests, and the relative benefit that
+ may be gained from effort in these two areas. It is
+ recognised that repetition of all developer tests may be
+ feasible and desirable in some cases, but may be very
+ arduous and less productive in others. The highest component
+ in this family should therefore be used with
+ caution. Sampling will address the whole range of test
+ results available, including those supplied to meet the
+ requirements of both and
+ .
+
+ There is also a need to consider the different
+ configurations of the TOE that are included within the
+ evaluation. The evaluator will need to assess the
+ applicability of the results provided, and to plan his own
+ testing accordingly.
+
+ The suitability of the TOE for testing is based on the
+ access to the TOE, and the supporting documentation and
+ information required (including any test software or tools)
+ to run tests. The need for such support is addressed by the
+ dependencies to other assurance families.
+
+ Additionally, suitability of the TOE for testing may be
+ based on other considerations. For example, the version of
+ the TOE submitted by the developer may not be the final
+ version.
+
+ The term interfaces refers to interfaces
+ described in the functional specification and TOE design,
+ and parameters passed through invocations identified in the
+ implementation representation. The exact set of interfaces
+ to be used is selected through and the
+ components.
+
+ References to a subset of the interfaces are intended to
+ allow the evaluator to design an appropriate set of tests
+ which is consistent with the objectives of the evaluation
+ being conducted.
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents.
+
+
+
+ This component does not address the use of developer test
+ results. It is applicable where such results are not
+ available, and also in cases where the developer's testing
+ is accepted without validation. The evaluator is required
+ to devise and conduct tests with the objective of
+ confirming that the TOE operates in accordance with its
+ design representations, including but not limited to the
+ functional specification. The approach is to gain
+ confidence in correct operation through representative
+ testing, rather than to conduct every possible test. The
+ extent of testing to be planned for this purpose is a
+ methodology issue, and needs to be considered in the
+ context of a particular TOE and the balance of other
+ evaluation activities.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSFI, whether the
+ TOE behaves as specified in the functional specification
+ and guidance documentation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer should have the same
+ unique reference as established by the sub-activities and identified
+ in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state.
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall test a subset of the TSF to confirm that
+ the TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of the
+ interfaces. In other cases this may not be
+ cost-effective, and sampling is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of the interface. Complex interfaces may
+ require complex tests that impose onerous
+ requirements on the developer or evaluator, which
+ may not be conducive to cost-effective
+ evaluations. Conversely, they are a likely area to
+ find errors and are good candidates for the
+ subset. The evaluator will need to strike a balance
+ between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST and the functional specification, the
+ evaluator has to determine the most feasible way to test
+ the interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection, if the
+ implementation representation is available);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the behaviour of the
+ interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing activity during the evaluation. The
+ intent of providing this information is to give a meaningful
+ overview of the testing effort. It is not intended that the
+ information regarding testing in the ETR be an exact
+ reproduction of specific test instructions or results of
+ individual tests. The intention is to provide enough detail to
+ allow other evaluators and evaluation authorities to gain some insight about
+ the testing approach chosen, amount of testing performed, TOE
+ test configurations, and the overall results of the testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested;
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size;
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset;
+
+
+ interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset;
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ confirms that the developer performed some tests of some
+ interfaces in the functional specification.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ This component contains a requirement that the evaluator
+ has available test results from the developer to
+ supplement the programme of testing. The evaluator will
+ repeat a sample of the developer's tests to gain
+ confidence in the results obtained. Having established
+ such confidence the evaluator will build upon the
+ developer's testing by conducting additional tests that
+ exercise the TOE in a different manner. By using a
+ platform of validated developer test results the evaluator
+ is able to gain confidence that the TOE operates correctly
+ in a wider range of conditions than would be possible
+ purely using the developer's own efforts, given a fixed
+ level of resource. Having gained confidence that the
+ developer has tested the TOE, the evaluator will also have
+ more freedom, where appropriate, to concentrate testing in
+ areas where examination of documentation or specialist
+ knowledge has raised particular concerns.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSF, whether the TOE
+ behaves as specified in the design documentation, and to
+ gain confidence in the developer's test results by
+ performing a sample of the developer's tests.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design description;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the configuration management documentation;
+
+
+ the test documentation;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state.
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+
+ The evaluator shall examine the set of resources provided by the developer
+ to determine that they are equivalent to the set of resources used by the
+ developer to functionally test the TSF.
+
+ The set of resource used by the developer is documented
+ in the developer test plan, as considered in the family. The resource set may
+ include laboratory access and special test equipment,
+ among others. Resources that are not identical to those
+ used by the developer need to be equivalent in terms of
+ any impact they may have on test results.
+
+
+
+ The evaluator shall execute a sample of tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall conduct testing using a sample of
+ tests found in the developer test plan and
+ procedures.
+
+ The overall aim of this work unit is to perform a
+ sufficient number of the developer tests to confirm the
+ validity of the developer's test results. The evaluator
+ has to decide on the size of the sample, and the
+ developer tests that will compose the sample (see ).
+
+ All the developer tests can be traced back to specific
+ interfaces. Therefore, the factors to consider in the
+ selection of the tests to compose the sample are similar
+ to those listed for subset selection in work-unit . Additionally, the
+ evaluator may wish to employ a random sampling method to
+ select developer tests to include in the sample.
+
+
+
+ The evaluator shall check that all the actual test
+ results are consistent with the expected test
+ results.
+
+ Inconsistencies between the developer's expected test
+ results and actual test results will compel the
+ evaluator to resolve the discrepancies. Inconsistencies
+ encountered by the evaluator could be resolved by a
+ valid explanation and resolution of the inconsistencies
+ by the developer.
+
+ If a satisfactory explanation or resolution can not be reached,
+ the evaluator's confidence in the developer's test results may be
+ lessened and it may be necessary for the evaluator to increase
+ the sample size to the extent that the subset identified in work unit
+ is adequately tested:
+ deficiencies with the developer's tests need to result in either
+ corrective action to the TOE by the developer (e.g., if the inconsistency
+ is caused by incorrect behaviour) or to the developer's tests (e.g., if the
+ inconsistency is caused by an incorrect test), or in the production of new
+ tests by the evaluator.
+
+
+
+ The evaluator shall test a subset of the TSF to confirm that the
+ TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The developer test evidence. The developer test
+ evidence consists of: the test documentation, the
+ available test coverage analysis, and the available
+ depth of testing analysis. The developer test
+ evidence will provide insight as to how the TSF has
+ been exercised by the developer during testing. The
+ evaluator applies this information when developing
+ new tests to independently test the
+ TOE. Specifically the evaluator should consider:
+
+
+ augmentation of developer testing for
+ interfaces. The evaluator may wish to perform
+ more of the same type of tests by varying
+ parameters to more rigorously test the
+ interface.
+
+
+ supplementation of developer testing strategy
+ for interfaces. The evaluator may wish to vary
+ the testing approach of a specific interface by
+ testing it using another test strategy.
+
+
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of them. In other
+ cases this may not be cost-effective, and sampling
+ is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Rigour of developer testing of the interfaces. Those
+ interfaces that the evaluator determines require
+ additional testing should be included in the test
+ subset.
+
+
+ Developer test results. If the results of developer
+ tests cause the evaluator to doubt that an interface
+ is not properly implemented, then the evaluator
+ should include such interfaces in the test subset.
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of interfaces. Interfaces that require
+ complex implementation may require complex tests
+ that impose onerous requirements on the developer or
+ evaluator, which may not be conducive to
+ cost-effective evaluations. Conversely, they are a
+ likely area to find errors and are good candidates
+ for the subset. The evaluator will need to strike a
+ balance between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST, the functional specification, and the
+ TOE design description, the evaluator has to determine
+ the most feasible way to test the
+ interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour of that interface.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing activity during the evaluation. The
+ intent of providing this information is to give a meaningful
+ overview of the testing effort. It is not intended that the
+ information regarding testing in the ETR be an exact
+ reproduction of specific test instructions or results of
+ individual tests. The intention is to provide enough detail to
+ allow other evaluators and evaluation authorities to gain some insight about
+ the testing approach chosen, amount of evaluator testing
+ performed, amount of developer tests performed, TOE test
+ configurations, and the overall results of the testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested.
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size.
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset.
+
+
+ Interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset.
+
+
+ developer tests performed. The amount of developer
+ tests performed and a brief description of the
+ criteria used to select the tests.
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate
+ that the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ includes repeating all of the developer tests.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ In this component the evaluator must repeat all of the
+ developer's tests as part of the programme of testing. As
+ in the previous component the evaluator will also conduct
+ tests that aim to exercise the TSF in a different manner
+ from that achieved by the developer. In cases where
+ developer testing has been exhaustive, there may remain
+ little scope for this.
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall execute all tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall test the TSF to confirm that the entire
+ TSF operates as specified.
+
+
+
+
+
+
+
+ The class addresses the
+ possibility of exploitable vulnerabilities introduced in the
+ development or the operation of the TOE.
+
+
+
+ Assurance class defines
+ requirements directed at the identification of exploitable
+ vulnerabilities. Specifically, it addresses those
+ vulnerabilities introduced in the development, operation,
+ misuse, or incorrect configuration of the TOE.
+
+
+
+ Generally, the vulnerability assessment activity covers various
+ vulnerabilities in the development and operation of the
+ TOE. Development vulnerabilities take advantage of some property
+ of the TOE which was introduced during its development,
+ e.g. defeating the TSF self protection through tampering, direct
+ attack or monitoring of the TSF, defeating the TSF domain
+ separation through monitoring or direct attack the TSF, or
+ defeating non-bypassability through circumventing (bypassing)
+ the TSF. Operational vulnerabilities take advantage of
+ weaknesses in non-technical countermeasures to violate the TOE
+ SFRs, e.g. misuse or incorrect configuration. Misuse
+ investigates whether the TOE can be configured or used in a
+ manner that is insecure, but that an administrator or user of
+ the TOE would reasonably believe to be secure.
+
+ Assessment of development vulnerabilities is covered by the
+ assurance family . Basically,
+ all development vulnerabilities can be considered in the
+ context of due to the fact,
+ that this family allows application of a wide range of
+ assessment methodologies being unspecific to the kind of an
+ attack scenario. These unspecific assessment methodologies
+ comprise, among other, also the specific methodologies for
+ those TSF where covert channels are to be considered (a
+ channel capacity estimation can be done using informal
+ engineering measurements, as well as actual test measurements)
+ or can be overcome by the use of sufficient resources in the
+ form of a direct attack (underlying technical concept of those
+ TSF is based on probabilistic or permutational mechanisms; a
+ qualification of their security behaviour and the effort
+ required to overcome them can be made using a quantitative or
+ statistical analysis).
+
+ If there are security objectives specified in the ST to either
+ to prevent one user of the TOE from observing activity
+ associated with another user of the TOE, or to ensure that
+ information flows cannot be used to achieve enforced illicit
+ data signals, covert channel analysis should be considered
+ during the conduct of the vulnerability analysis. This is often
+ reflected by the inclusion of
+ and multilevel access control policies specified through and/or requirements in the ST.
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the exploitability of flaws or weaknesses in the TOE
+ in the operational environment. This determination is based
+ upon analysis of the evaluation evidence and a search of
+ publicly available material by the evaluator and is supported
+ by evaluator penetration testing.
+
+
+
+
+ Vulnerability analysis is an assessment to determine whether
+ potential vulnerabilities identified, during the evaluation
+ of the development and anticipated operation of the TOE or
+ by other methods (e.g. by flaw hypotheses or quantitative or
+ statistical analysis of the security behaviour of the
+ underlying security mechanisms), could allow attackers to
+ violate the SFRs.
+
+ Vulnerability analysis deals with the threats that an
+ attacker will be able to discover flaws that will allow
+ unauthorised access to data and functionality, allow the
+ ability to interfere with or alter the TSF, or interfere
+ with the authorised capabilities of other users.
+
+
+
+ Vulnerability analysis consists of the identification of
+ flaws potentially introduced in the different refinement
+ steps of the development (development vulnerabilities) or
+ through the application of the guidance in operation of the
+ TOE (operational vulnerabilities). It results in the
+ definition of penetration tests through the collection of
+ the necessary information concerning: (1) the completeness
+ of the TSF (does the TSF counter all the postulated
+ threats?), (2) the dependencies between all SFRs and (3)
+ whether any of the SFRs can be undermined through unexpected
+ behaviour of the TOE. These potential vulnerabilities are
+ assessed through penetration testing to determine whether
+ they could, in practise, be exploitable to compromise the
+ security of the TOE.
+
+ The characteristics of different levels of attack potential
+ are discussed in CEM .
+
+
+
+ Levelling is based on an increasing rigour of vulnerability
+ analysis by the evaluator and increased levels of attack
+ potential required by an attacker to identify and exploit
+ the potential vulnerabilities.
+
+
+
+
+
+
+
+ A vulnerability survey of information available in the
+ public domain is performed by the evaluator to ascertain
+ potential vulnerabilities that may be easily found by an
+ attacker.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has easily
+ identifiable exploitable vulnerabilities.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during the conduct of other parts of the
+ evaluation.
+
+ The use of the term guidance in this sub-activity refers
+ to the operational guidance and the preparative
+ guidance.
+
+ Potential vulnerabilities may be in information that is
+ publicly available, or not, and may require skill to
+ exploit, or not. These two aspects are related, but are
+ distinct. It should not be assumed that, simply because a
+ potential vulnerability is identifiable from information
+ that is publicly available, it can be easily
+ exploited.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the guidance documentation;
+
+
+ the TOE suitable for testing;
+
+
+ information publicly available to support the
+ identification of potential vulnerabilities.
+
+
+
+ Other input for this sub-activity is:
+
+
+ current information regarding potential
+ vulnerabilities (e.g. from an evaluation authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information, which
+ should be considered, e.g. mailing lists and security
+ forums on the world wide web that report known
+ vulnerabilities in specified technologies.
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks effectively operates to substantially
+ enhance the attack potential of a given attacker. The
+ accessibility of vulnerability information and
+ sophisticated attack tools on the Internet makes it more
+ likely that this information will be used in attempts to
+ identify potential vulnerabilities in the TOE and
+ exploit them. Modern search tools make such information
+ easily available to the evaluator, and the determination
+ of resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the information
+ publicly available. However, in this type of search, the
+ evaluator may not be able to describe the steps in
+ identifying potential vulnerabilities before the outset
+ of the examination, as the approach may evolve as a
+ result of findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses;
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing Basic
+ attack potential.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during other parts of the evaluation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the TOE using the guidance documentation,
+ functional specification, TOE design and security
+ architecture description to identify potential
+ vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a search of ST, guidance
+ documentation, functional specification, TOE design and
+ security architecture description evidence to identify
+ possible potential vulnerabilities in the TOE.
+
+ A search of the evidence should be completed whereby
+ specifications and documentation for the TOE are
+ analysed and then potential vulnerabilities in the TOE
+ are hypothesised, or speculated. The list of
+ hypothesised potential vulnerabilities is then
+ prioritised on the basis of the estimated probability
+ that a potential vulnerability exists and, assuming an
+ exploitable vulnerability does exist the attack
+ potential required to exploit it, and on the extent of
+ control or compromise it would provide. The prioritised
+ list of potential vulnerabilities is used to direct
+ penetration testing against the TOE.
+
+ The security architecture description provides the
+ developer vulnerability analysis, as it documents how
+ the TSF protects itself from interference from untrusted
+ subjects and prevents the bypass of security enforcement
+ functionality. Therefore, the evaluator should use this
+ description of the protection of the TSF as a basis for
+ the search for possible ways to undermine the
+ TSF.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the security
+ architecture description in the search for vulnerabilities (as
+ detailed in ), testing should
+ be performed to confirm the architectural properties. This is
+ likely to require negative tests attempting to disprove the
+ properties of the security architecture. In developing the
+ strategy for penetration testing, the evaluator will ensure that
+ each of the major characteristics of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ Basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Enhanced-Basic, Moderate or
+ High attack potential do not result in a failure of this
+ evaluator action. Where analysis supports the
+ hypothesis, these need not be considered further as an
+ input to penetration testing. However, such
+ vulnerabilities are reported in the ETR as residual
+ vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic attack potential and
+ resulting in a violation of the security objectives
+ should be the highest priority potential vulnerabilities
+ comprising the list used to direct penetration testing
+ against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than an Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Enhanced-Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Enhanced-Basic attack potential.
+
+
+
+ During the conduct of evaluation activities the evaluator
+ may also identify areas of concern. These are specific
+ portions of the TOE evidence that the evaluator has some
+ reservation about, although the evidence meets the
+ requirements for the activity with which the evidence is
+ associated. For example, a particular interface
+ specification looks particularly complex, and therefore
+ may be prone to error either in the development of the TOE
+ or in the operation of the TOE. There is no potential
+ vulnerability apparent at this stage, further
+ investigation is required. This is beyond the bounds of
+ encountered, as further investigation is required.
+
+ The focused approach to the identification of potential
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. Further
+ guidance on focused vulnerability analysis can be found in
+ Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation subset selected;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the identification of possible potential vulnerabilities;
+
+ the results of the testing of the basic design.
+
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent, focused vulnerability analysis of the
+ TOE using the guidance documentation, functional specification, TOE design, security
+ architecture description and implementation representation to identify potential
+ vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a focused search of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ A flaw hypothesis methodology needs to be used whereby
+ specifications and development and guidance evidence are
+ analysed and then potential vulnerabilities in the TOE are
+ hypothesised, or speculated.
+
+ The evaluator uses the knowledge of the TOE design and operation
+ gained from the TOE deliverables to conduct a flaw hypothesis to
+ identify potential flaws in the development of the TOE and
+ potential errors in the specified method of operation of the
+ TOE.
+
+ The security architecture description provides the developer
+ vulnerability analysis, as it documents how the TSF protects
+ itself from interference from untrusted subjects and prevents
+ the bypass of security enforcement functionality. Therefore, the
+ evaluator should build upon the understanding of the TSF
+ protection gained from the analysis of this evidence and then
+ develop this in the knowledge gained from other development
+ evidence.
+
+
+ The approach taken is directed by areas of concern
+ identified during examination of the evidence during the
+ conduct of evaluation activities and ensuring a
+ representative sample of the development and guidance
+ evidence provided for the evaluation is searched.
+
+ For guidance on sampling see Annex . This guidance
+ should be considered when selecting the subset, giving
+ reasons for:
+
+
+ the approach used in selection;
+
+
+ qualification that the evidence to be examined
+ supports that approach.
+
+
+
+ The areas of concern may relate to the sufficiency of
+ specific protection features detailed in the security
+ architecture description.
+
+ The evidence to be considered during the vulnerability analysis
+ may be linked to the evidence the attacker is assumed to be able
+ to obtain. For example, the developer may protect the TOE design
+ and implementation representations, so the only information
+ assumed to be available to an attacker is the functional
+ specification and guidance (publicly available). So, although
+ the objectives for assurance in the TOE ensure the TOE design
+ and implementation representation requirements are met, these
+ design representations may only be searched to further
+ investigate areas of concerns.
+
+ On the other hand, if the source is publicly available it would
+ be reasonable to assume that the attacker has access to the
+ source and can use this in attempts to attack the
+ TOE. Therefore, the source should be considered in the focused
+ examination approach.
+
+ The following indicates examples for the selection of
+ the subset of evidence to be considered:
+
+
+ For an evaluation where all levels of design
+ abstraction from functional specification to
+ implementation representation are provided,
+ examination of information in the functional
+ specification and the implementation representation
+ may be selected, as the functional specification
+ provides detail of interfaces available to an
+ attacker, and the implementation representation
+ incorporates the design decisions made at all other
+ design abstractions. Therefore, the TOE design
+ information will be considered as part of the
+ implementation representation.
+
+
+ Examination of a particular subset of information in
+ each of the design representations provided for the
+ evaluation.
+
+
+ Coverage of particular SFRs through each of the
+ design representations provided for the evaluation.
+
+
+ Examination of each of the design representations
+ provided for the evaluation, considering different
+ SFRs within each design representations.
+
+
+ Examination of aspects of the evidence provided for
+ the evaluation relating to current potential
+ vulnerability information the evaluator has received
+ (e.g. from a scheme).
+
+
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach; applying a system to the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered and the
+ hypothesis that is to be created.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be searched to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examine in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Enhanced-Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the security
+ architecture description in the search for vulnerabilities (as
+ detailed in ), testing should
+ be performed to confirm the architectural properties. If
+ requirements from are included in
+ the SARs, the developer testing evidence will include testing
+ performed to confirm the correct implementation of any specific
+ mechanisms detailed in the security architecture
+ description. However, the developer testing will not necessarily
+ include testing of all aspects of the architectural properties
+ that protect the TSF, as much of this testing will be negative
+ testing in nature, attempting to disprove the properties. In
+ developing the strategy for penetration testing, the evaluator
+ will ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ It will probably be practical to carry out penetration
+ test using a series of test cases, where each test case
+ will test for a specific potential vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Moderate or High attack
+ potential do not result in a failure of this evaluator
+ action. Where analysis supports the hypothesis, these
+ need not be considered further as an input to
+ penetration testing. However, such vulnerabilities are
+ reported in the ETR as residual vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic or Enhanced-Basic attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which an Enhanced-Basic attack potential is
+ required to effect an attack. However, as a result of
+ evaluation expertise, the evaluator may discover a
+ potential vulnerability that is exploitable only by an
+ attacker with greater than Enhanced-Basic attack
+ potential. Such vulnerabilities are to be reported in
+ the ETR as residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming an Enhanced-Basic attack
+ potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing an Enhanced-Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Moderate attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Moderate.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Moderate.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Moderate attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the identification of possible potential vulnerabilities;
+
+ the results of the testing of the basic design.
+
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will describe the approach to be taken to
+ identify potential vulnerabilities in the publicly
+ available material, detailing the search to be
+ performed. This may be driven by factors such as areas
+ of concern identified by the evaluator, linked to the
+ evidence the attacker is assumed to be able to obtain.
+ However, it is recognised that in this type of search
+ the approach may further evolve as a result of findings
+ during the search. Therefore, the evaluator will also
+ report any actions taken in addition to those described
+ in the approach to further investigate issues thought to
+ lead to potential vulnerabilities, and will report the
+ evidence examined in completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct a methodical analysis of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ Guidance on methodical vulnerability analysis is
+ provided in Annex .
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach. A system is to be applied in the
+ examination. The evaluator is to describe the method to
+ be used in terms of the manner in which this information
+ is to be considered and the hypothesis that is to be
+ created.
+
+ A flaw hypothesis methodology needs to be used whereby the ST,
+ development (functional specification, TOE design and
+ implementation representation) and guidance evidence are
+ analysed and then vulnerabilities in the TOE are hypothesised,
+ or speculated.
+
+ The evaluator uses the knowledge of the TOE design and operation
+ gained from the TOE deliverables to conduct a flaw hypothesis to
+ identify potential flaws in the development of the TOE and
+ potential errors in the specified method of operation of the
+ TOE.
+
+ The security architecture description provides the developer
+ vulnerability analysis, as it documents how the TSF protects
+ itself from interference from untrusted subjects and prevents
+ the bypass of security enforcement functionality. Therefore, the
+ evaluator should build upon the understanding of the TSF
+ protection gained from the analysis of this evidence and then
+ develop this in the knowledge gained from other development
+ evidence.
+
+ The approach taken to the methodical search for vulnerabilities
+ is to consider any areas of concern identified in the results of
+ the evaluator's assessment of the development and guidance
+ evidence. However, the evaluator should also consider each
+ aspect of the security architecture analysis to search for any
+ ways in which the protection of the TSF can be undermined. It
+ may be helpful to structure the methodical analysis on the basis
+ of the material presented in the security architecture
+ description, introducing concerns from other evidence as appropriate. The analysis can then be
+ further developed to ensure all other material from the evidence is considered.
+
+ The following provide some examples of hypotheses that
+ may be created when examining the evidence:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that 'all interface
+ specifications in the evidence provided will be searched
+ to hypothesise potential vulnerabilities' and go on to
+ explain the methods used in the hypothesis.
+
+ In addition, areas of concern the evaluator has identified
+ during examination of the evidence during the conduct of
+ evaluation activities. Areas of concern may also be identified
+ during the conduct of other work units associated with this
+ component, in particular ,
+ and where the development and conduct of penetration
+ tests may identify further areas of concerns for investigation,
+ or potential vulnerabilities.
+
+ However, examination of only a subset of the development
+ and guidance evidence or their contents is not permitted
+ in this level of rigour. The approach description should
+ provide a demonstration that the methodical approach
+ used is complete, providing confidence that the approach
+ used to search the deliverables has considered all of
+ the information provided in those deliverables.
+
+ This approach to identification of potential vulnerabilities is
+ to take an ordered and planned approach; applying a system to
+ the examination. The evaluator is to describe the method to be
+ used in terms of how the evidence will be considered; the manner
+ in which this information is to be considered and the hypothesis
+ that is to be created. This approach should be agreed with the
+ evaluation authority, and the evaluation authority may
+ provide detail of any additional approaches the evaluator should
+ take to the vulnerability analysis and identify any additional
+ information that should be considered by the evaluator.
+
+ Although a system to identifying potential
+ vulnerabilities is predefined, the identification
+ process may still be iterative, where the identification
+ of one potential vulnerability may lead to identifying
+ another area of concern that requires further
+ investigation.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing Moderate attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the
+ security architecture description in the search for
+ vulnerabilities (as detailed in ), testing should be performed to confirm the
+ architectural properties. If requirements from are included in the SARs, the
+ developer testing evidence will include testing
+ performed to confirm the correct implementation of any
+ specific mechanisms detailed in the security
+ architecture description. However, the developer testing
+ will not necessarily include testing of all aspects of
+ the architectural properties that protect the TSF, as
+ much of this testing will be negative testing in nature,
+ attempting to disprove the properties. In developing the
+ strategy for penetration testing, the evaluator will
+ ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Moderate (or less) attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Moderate attack potential is required
+ to effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Moderate attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI;
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Moderate attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than a High attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than High.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of High.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing High
+ attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+ If the TOE SFRs include and
+ requirements such that
+ actions and data of one subject cannot be observed and
+ linked with another subject, the evaluator should consider
+ performing a covert channel analysis. This will build
+ upon the design evidence provided by the developer in
+ satisfaction of and requirements. The design evidence
+ will include details of how the TOE architecture prevents
+ observation by subjects of actions performed by other
+ subjects. the evaluator should seek guidance from the
+ evaluation authority on the conduct of such a covert
+ channel analysis.
+
+ The analysis of the guidance documentation is to include
+ consideration of whether it is possible to unknowingly
+ configure the TOE insecurely. Therefore, the analysis will
+ consider warning prompts provided by the TOE when
+ configuration options are selected by the user that may
+ render the TOE in an insecure state, not just in the
+ guidance but also in the use of the TOE. An example may be
+ when access control rules are amended from a remote
+ administration console, which will not take effect until
+ the TOE has been restarted. The evaluator will determine
+ whether the TOE issues a suitable warning when the changes
+ are made to ensure the user is aware that a restart must
+ be completed before the changes take effect.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing High attack potential.
+
+
+
+
+
+
+
+ EAL1 is applicable where some confidence in correct operation
+ is required, but the threats to security are not viewed as
+ serious. It will be of value where independent assurance is
+ required to support the contention that due care has been
+ exercised with respect to the protection of personal or
+ similar information.
+
+ EAL1 requires only a limited security target. It is sufficient
+ to simply state the SFRs that the TOE must meet, rather than
+ deriving them from threats, OSPs and assumptions through
+ security objectives.
+
+ EAL1 provides an evaluation of the TOE as made available to
+ the customer, including independent testing against a
+ specification, and an examination of the guidance
+ documentation provided. It is intended that an EAL1 evaluation
+ could be successfully conducted without assistance from the
+ developer of the TOE, and for minimal outlay.
+
+ An evaluation at this level should provide evidence that the
+ TOE functions in a manner consistent with its
+ documentation.
+
+
+
+ EAL1 provides a basic level of assurance by a limited security
+ target and an analysis of the SFRs in that ST using a
+ functional and interface specification and guidance
+ documentation, to understand the security behaviour.
+
+ The analysis is supported by a search for potential
+ vulnerabilities in the public domain and independent testing
+ (functional and penetration) of the TSF.
+
+ EAL1 also provides assurance through unique identification of
+ the TOE and of the relevant evaluation documents.
+
+ This EAL provides a meaningful increase in assurance over
+ unevaluated IT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL2 requires the co-operation of the developer in terms of
+ the delivery of design information and test results, but
+ should not demand more effort on the part of the developer
+ than is consistent with good commercial practise. As such it
+ should not require a substantially increased investment of
+ cost or time.
+
+ EAL2 is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record. Such a
+ situation may arise when securing legacy systems, or where
+ access to the developer may be limited.
+
+
+
+ EAL2 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation and a basic
+ description of the architecture of the TOE, to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, selective independent confirmation of the
+ developer test results, and a vulnerability analysis (based
+ upon the functional specification, TOE design, security architecture
+ description and guidance evidence provided) demonstrating
+ resistance to penetration attackers with a basic attack
+ potential.
+
+ EAL2 also provides assurance through use of a configuration
+ management system and evidence of secure delivery
+ procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL1 by requiring developer testing, a vulnerability analysis
+ (in addition to the search of the public domain), and
+ independent testing based upon more detailed TOE
+ specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL3 permits a conscientious developer to gain maximum
+ assurance from positive security engineering at the design
+ stage without substantial alteration of existing sound
+ development practises.
+
+ EAL3 is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the TOE and
+ its development without substantial re-engineering.
+
+
+
+ EAL3 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation, and an
+ architectural description of the design of the TOE, to
+ understand the security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent
+ confirmation of the developer test results, and a
+ vulnerability analysis (based upon the functional
+ specification, TOE design, security architecture description and guidance
+ evidence provided) demonstrating resistance to penetration
+ attackers with a basic attack potential.
+
+ EAL3 also provides assurance through the use of development
+ environment controls, TOE configuration management, and
+ evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL2 by requiring more complete testing coverage of the
+ security functionality and mechanisms and/or procedures that
+ provide some confidence that the TOE will not be tampered with
+ during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL4 permits a developer to gain maximum assurance from
+ positive security engineering based on good commercial
+ development practises which, though rigorous, do not require
+ substantial specialist knowledge, skills, and other
+ resources. EAL4 is the highest level at which it is likely to
+ be economically feasible to retrofit to an existing product
+ line.
+
+ EAL4 is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity TOEs
+ and are prepared to incur additional security-specific
+ engineering costs.
+
+
+
+ EAL4 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the basic modular design of the TOE, and a
+ subset of the implementation, to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent confirmation
+ of the developer test results, and a vulnerability analysis (based upon
+ the functional specification, TOE design, implementation
+ representation, security architecture description and guidance
+ evidence provided) demonstrating resistance to penetration
+ attackers with an Enhanced-Basic attack potential.
+
+ EAL4 also provides assurance through the use of development
+ environment controls and additional TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from EAL3
+ by requiring more design description, the implementation
+ representation for the entire TSF, and improved mechanisms
+ and/or procedures that provide confidence that the TOE will not
+ be tampered with during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL5 permits a developer to gain maximum assurance from
+ security engineering based upon rigorous commercial
+ development practises supported by moderate application of
+ specialist security engineering techniques. Such a TOE will
+ probably be designed and developed with the intent of
+ achieving EAL5 assurance. It is likely that the additional
+ costs attributable to the EAL5 requirements, relative to
+ rigorous development without the application of specialised
+ techniques, will not be large.
+
+ EAL5 is therefore applicable in those circumstances where
+ developers or users require a high level of independently
+ assured security in a planned development and require a
+ rigorous development approach without incurring unreasonable
+ costs attributable to specialist security engineering
+ techniques.
+
+
+
+ EAL5 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the design of the TOE, and the implementation,
+ to understand the security behaviour. A modular TSF design is
+ also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a moderate attack potential.
+
+ EAL5 also provides assurance through the use of a development
+ environment controls, and comprehensive TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from EAL4
+ by requiring semiformal design descriptions, a more structured
+ (and hence analysable) architecture, and improved mechanisms
+ and/or procedures that provide confidence that the TOE will not
+ be tampered with during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL6 permits developers to gain high assurance from
+ application of security engineering techniques to a rigorous
+ development environment in order to produce a premium TOE for
+ protecting high value assets against significant risks.
+
+ EAL6 is therefore applicable to the development of security
+ TOEs for application in high risk situations where the value
+ of the protected assets justifies the additional costs.
+
+
+
+ EAL6 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and the implementation to understand the
+ security behaviour. Assurance is additionally gained through a
+ formal model of select TOE security policies and a semiformal
+ presentation of the functional specification and TOE design. A
+ modular, layered and simple TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a high attack potential.
+
+ EAL6 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL5 by requiring more comprehensive analysis, a structured
+ representation of the implementation, more architectural
+ structure (e.g. layering), more comprehensive independent
+ vulnerability analysis, and improved configuration management
+ and development environment controls.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL7 is applicable to the development of security TOEs for
+ application in extremely high risk situations and/or where the
+ high value of the assets justifies the higher costs. Practical
+ application of EAL7 is currently limited to TOEs with tightly
+ focused security functionality that is amenable to extensive
+ formal analysis.
+
+
+
+ EAL7 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and a structured presentation of the
+ implementation to understand the security behaviour. Assurance
+ is additionally gained through a formal model of select TOE
+ security policies and a semiformal presentation of the
+ functional specification and TOE design. A modular, layered
+ and simple TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design and implementation representation,
+ complete independent confirmation of the developer test
+ results, and an independent vulnerability analysis
+ demonstrating resistance to penetration attackers with a high
+ attack potential.
+
+ EAL7 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL6 by requiring more comprehensive analysis using formal
+ representations and formal correspondence, and comprehensive
+ testing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-A is applicable when a composed TOE is integrated and
+ confidence in the correct security operation of the resulting
+ composite is required. This requires the cooperation of the
+ developer of the dependent component in terms of delivery of
+ design information and test results from the dependent
+ component certification, without requiring the involvement of
+ the base component developer.
+
+ CAP-A is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record.
+
+
+
+ CAP-A provides assurance by analysis of a security target for
+ the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation) and a
+ specification for the interfaces between the component TOEs in
+ the composed TOE to understand the security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information,
+ evidence of developer testing based on the reliance
+ information, development information and composition
+ rationale, and selective independent confirmation of the
+ developer test results. The analysis is also supported by a
+ vulnerability review of the composed TOE by the
+ evaluator.
+
+ CAP-A also provides assurance through unique identification of
+ the composed TOE (i.e. IT TOE and guidance
+ documentation).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-B permits a conscientious developer to gain maximum
+ assurance from understanding, at a subsystem level, the
+ affects of interactions between component TOEs integrated in
+ the composed TOE, whilst minimising the demand of involvement
+ of the base component developer.
+
+ CAP-B is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the composed
+ TOE and its development without substantial
+ re-engineering.
+
+
+
+ CAP-B provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF subsystems) contained in
+ the composed development information to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now also including TOE design), evidence of developer testing
+ based on the reliance information, development information and
+ composition rationale, and selective independent confirmation
+ of the developer test results. The analysis is also supported
+ by a vulnerability analysis of the composed TOE by the
+ evaluator demonstrating resistance to attackers with basic
+ attack potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-A by requiring more complete testing coverage of the
+ security functionality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-C permits a developer to gain maximum assurance from
+ positive analysis of the interactions between the components
+ of the composed TOE, which, though rigorous, do not require
+ full access to all evaluation evidence of the base
+ component.
+
+ CAP-C is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity
+ composed TOEs and are prepared to incur additional
+ security-specific engineering costs.
+
+
+
+ CAP-C provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF modules) contained in the
+ composed development information to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now including TOE design), evidence of developer testing based
+ on the reliance information, development information and
+ composition rationale, and selective independent confirmation of
+ the developer test results. The analysis is also supported by a
+ vulnerability analysis of the composed TOE by the evaluator
+ demonstrating resistance to attackers with Enhanced-Basic attack
+ potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-B by requiring more design description and demonstration
+ of resistance to a higher attack potential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/c5dec/assets/database/SecurityControls/cc3R4.xml b/c5dec/assets/database/SecurityControls/cc3R4.xml
new file mode 100644
index 0000000..e663443
--- /dev/null
+++ b/c5dec/assets/database/SecurityControls/cc3R4.xml
@@ -0,0 +1,53993 @@
+
+
+
+
+
+
+
+
+ For the purposes of this document, the terms, definitions,
+ symbols and abbreviated terms given in CC Part 1 apply.
+
+
+
+ Security assurance components, as defined in this CC Part 3, are
+ the basis for the security assurance requirements expressed in a
+ Protection Profile (PP) or a Security Target (ST).
+
+ These requirements establish a standard way of expressing the
+ assurance requirements for TOEs. This CC Part 3 catalogues the
+ set of assurance components, families and classes. This CC Part
+ 3 also defines evaluation criteria for PPs and STs and presents
+ evaluation assurance levels that define the predefined CC scale
+ for rating assurance for TOEs, which is called the Evaluation
+ Assurance Levels (EALs).
+
+ The audience for this CC Part 3 includes consumers, developers,
+ and evaluators of secure IT products. CC Part 1 Clause provides additional information
+ on the target audience of the CC, and on the use of the CC by
+ the groups that comprise the target audience. These groups may
+ use this part of the CC as follows:
+
+
+ Consumers, who use this CC Part 3 when selecting components
+ to express assurance requirements to satisfy the security
+ objectives expressed in a PP or ST, determining required
+ levels of security assurance of the TOE.
+
+
+ Developers, who respond to actual or perceived consumer
+ security requirements in constructing a TOE, reference this
+ CC Part 3 when interpreting statements of assurance
+ requirements and determining assurance approaches of TOEs.
+
+
+ Evaluators, who use the assurance requirements defined in
+ this part of the CC as mandatory statement of evaluation
+ criteria when determining the assurance of TOEs and when
+ evaluating PPs and STs.
+
+
+
+
+
+
+ Clause describes the paradigm
+ used in the security assurance requirements of CC Part
+ 3.
+
+ Clause describes the
+ presentation structure of the assurance classes, families,
+ components, evaluation assurance levels along with their
+ relationships, and the structure of the composed assurance
+ packages. It also characterises the assurance classes and
+ families found in Clauses through
+ .
+
+ Clause provides detailed
+ definitions of the EALs.
+
+ Clause provides detailed
+ definitions of the CAPs.
+
+ Clauses through provide the detailed definitions of the CC Part 3
+ assurance classes.
+
+ provides further
+ explanations and examples of the concepts behind the
+ Development class.
+
+ provides an explanation of
+ the concepts behind composed TOE evaluations and the
+ Composition class.
+
+ provides
+ a summary of the dependencies between the assurance
+ components.
+
+ provides a cross
+ reference between PPs and the families and components of the
+ class.
+
+ provides a cross reference
+ between the EALs and the assurance components.
+
+ provides a cross reference
+ between the CAPs and the assurance components.
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CC-1
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 1: Introduction and general model.
+
+
+
+ CC-2
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 2: Functional security components.
+
+
+
+
+
+ This CC Part 3 defines the assurance requirements of the CC. It
+ includes the evaluation assurance levels (EALs) that define a
+ scale for measuring assurance for component TOEs, the composed
+ assurance packages (CAPs) that define a scale for measuring
+ assurance for composed TOEs, the individual assurance components
+ from which the assurance levels and packages are composed, and
+ the criteria for evaluation of PPs and STs.
+
+
+
+ The goal of this annex is to explain the concepts behind
+ composition evaluations and the
+ criteria. This annex does not define the criteria; this definition can be found in clause
+ .
+
+
+ The IT market is, on the whole, made up of vendors offering a
+ particular type of product/technology. Although there is some
+ overlap, where a PC hardware vendor may also offer application
+ software and/or operating systems or a chip manufacturer may
+ also develop a dedicated operating system for their own
+ chipset, it is often the case that an IT solution is
+ implemented by a variety of vendors.
+
+ There is sometimes a need for assurance in the combination
+ (composition) of components in addition to the assurance of
+ the individual components. Although there is cooperation
+ between these vendors, in the dissemination of certain
+ material required for the technical integration of the
+ components, the agreements rarely stretch to the extent of
+ providing detailed design information and development
+ process/procedure evidence. This lack of information from the
+ developer of a component on which another component relies
+ means that the dependent component developer does not have
+ access to the type of information necessary to perform an
+ evaluation of both the dependent and base components at EAL2
+ or above. Therefore, while an evaluation of the dependent
+ component can still be performed at any assurance level, to
+ compose components with assurance at EAL2 or above it is
+ necessary to reuse the evaluation evidence and results of
+ evaluations performed for the component developer.
+
+ It is intended that the criteria
+ are applicable in the situation where one IT entity is
+ dependent on another for the provision of security
+ services. The entity providing the services is termed the
+ ``base component'', and that receiving the services is termed
+ the ``dependent component''. This relationship may exist in a
+ number of contexts. For example, an application (dependent
+ component) may use services provided by an operating system
+ (base component). Alternatively, the relationship may be
+ peer-to-peer, in the sense of two linked applications, either
+ running in a common operating system environment, or on
+ separate hardware platforms. If there is a dominant peer
+ providing the services to the minor peer, the dominant peer is
+ considered to be the base component and the minor peer the
+ dependent component. If the peers provide services to each
+ other in a mutual manner, each peer will be considered to be
+ the base component for the services offered and dependent
+ component for the services required. This will require
+ iterations of the components
+ applying all requirements to each type of component
+ peer.
+
+ The criteria are also intended to be more broadly applicable,
+ stepwise (where a composed TOE comprised of a dependent
+ component and a base component itself becomes the base
+ component of another composed TOE), in more complex
+ relationships, but this may require further
+ interpretation.
+
+ It is still required for composed TOE evaluations that the
+ individual components are evaluated independently, as the
+ composition evaluation builds on the results of the individual
+ component evaluations. The evaluation of the dependent
+ component may still be in progress when the composed TOE
+ evaluation commences. However, the dependent component
+ evaluation must complete before the composed TOE evaluation
+ completes.
+
+ The composed evaluation activities may take place at the same
+ time as the dependent component evaluation. This is due to two
+ factors:
+
+
+ Economic/business drivers - the dependent component
+ developer will either be sponsoring the composition
+ evaluation activities or supporting these activities as
+ the evaluation deliverables from the dependent component
+ evaluation are required for composed evaluation
+ activities.
+
+ Technical drivers - the components consider whether the
+ requisite assurance is provided by the base component
+ (e.g. considering the changes to the base component since
+ completion of the component evaluation) with the
+ understanding that the dependent component has recently
+ undergone (is undergoing) component evaluation and all
+ evaluation deliverables associated with the evaluation are
+ available. Therefore, there are no activities during
+ composition requesting the dependent component evaluation
+ activities to be re-verified. Also, it is verified that
+ the base component forms (one of) the test configurations
+ for the testing of the dependent component during the
+ dependent component evaluation, leaving to consider the base component in this
+ configuration.
+
+ The evaluation evidence from the evaluation of the dependent
+ component is required input into the composed TOE evaluation
+ activities. The only evaluation material from the evaluation
+ of the base component that is required as input into the
+ composed TOE evaluation activities:
+
+
+ Residual vulnerabilities in the base component, as
+ reported during the base component evaluation. This is
+ required for the
+ activities.
+
+ No other evaluation evidence from the base component
+ activities should be required for the composed TOE evaluation,
+ as the evaluation results from the component evaluation of the
+ base component should be reused. Additional information about
+ the base component may be required if the composed TOE TSF
+ includes more of the base component than was considered to be
+ TSF during component evaluation of the base component.
+
+ The component evaluation of the base and dependent components
+ are assumed to be complete by the time final verdicts are
+ assigned for the components.
+
+ The components only consider
+ resistance against an attacker with an attack potential up to
+ Enhanced-Basic. This is due to the level of design information
+ that can be provided of how the base component provides the
+ services on which the dependent component relies through
+ application of the
+ activities. Therefore, the confidence arising from composed TOE
+ evaluations using CAPs is limited to a level similar to that
+ obtained from EAL4 component TOE evaluations. Although
+ assurance in the components that comprise the composed TOE may
+ be higher than EAL4.
+
+
+
+ An ST will be submitted by the developer for the evaluation of
+ the composed (base component + dependent component) TOE. This
+ ST will identify the assurance package to be applied to the
+ composed TOE, providing assurance in the composed entity by
+ drawing upon the assurance gained in the component
+ evaluations.
+
+ The purpose of considering the composition of components
+ within an ST is to validate the compatibility of the
+ components from the point of view of both the environment and
+ the requirements, and also to assess that the composed TOE ST
+ is consistent with the component STs and the security policies
+ expressed within them. This includes determining that the
+ component STs and the security policies expressed within them
+ are compatible.
+
+ The composed TOE ST may refer out to the content of the
+ component STs, or the ST author may chose to reiterate the
+ material of the component STs within the composed TOE ST
+ providing a rationale of how the component STs are represented
+ in the composed TOE ST.
+
+ During the conduct of the
+ evaluation activities for a composed TOE ST the evaluator
+ determines that the component STs are accurately represented
+ in the composed TOE ST. This is achieved through determining
+ that the composed TOE ST demonstrably conforms to the
+ component TOE STs. Also, the evaluator will need to determine
+ that the dependencies of the dependent component on the
+ operational environment are adequately fulfilled in the
+ composed TOE.
+
+ The composed TOE description will describe the composed
+ solution. The logical and physical scope and boundary of the
+ composed solution will be described, and the logical
+ boundary(ies) between the components will also be
+ identified. The description will identify the security
+ functionality to be provided by each component.
+
+ The statement of SFRs for the composed TOE will identify which
+ component is to satisfy an SFR. If an SFR is met by both
+ components, then the statement will identify which component
+ meets the different aspects of the SFR. Similarly the composed
+ TOE Summary Specification will identify which component
+ provides the security functionality described.
+
+ The package of requirements
+ applied to the composed TOE ST should be consistent with the
+ package of requirements used in
+ the component evaluations.
+
+ Reuse of evaluation results from the evaluation of component
+ STs can be made in the instances that the composed TOE ST
+ directly refers to the component STs. e.g. if the composed TOE
+ ST refers to a component ST for part of its statement of SFRs,
+ the evaluator can understand that the requirement for the
+ completion of all assignment and selection operations (as
+ stated in .*.3C has been
+ satisfied in the component evaluations.
+
+
+
+ The TSF of the base component is often defined without
+ knowledge of the dependencies of the possible applications
+ with which it may by composed. The TSF of this base component
+ is defined to include all parts of the base component that
+ have to be relied upon for enforcement of the base component
+ SFRs. This will include all parts of the base component
+ required to implement the base component SFRs.
+
+ The TSFI of this base component represents the interfaces
+ provided by the TSF to the external entities defined in the
+ statement of SFRs to invoke a service of the TSF. This
+ includes interfaces to the human user and also interfaces to
+ external IT entities. However, the TSFI only includes those
+ interfaces to the TSF, and therefore is not necessarily an
+ exhaustive interface specification of all possible interfaces
+ available between an external entity and the base
+ component. The base component may present interfaces to
+ services that were not considered security-relevant, either
+ because of the inherent purpose of the service (e.g., adjust
+ type font) or because associated CC SFRs are not being claimed
+ in the base component's ST (e.g. the login interface when no
+ SFRs are claimed).
+
+ The functional interfaces provided by the base component are
+ in addition to the security interfaces (TSFIs), and are not
+ required to be considered during the base component
+ evaluation. These often include interfaces that are used by a
+ dependent component to invoke a service provided by the base
+ component.
+
+ The base component may include some indirect interfaces
+ through which TSFIs may be called, e.g. APIs that can be used
+ to invoke a service of the TSF, which were not considered
+ during the evaluation of the base component.
+
+
+ The dependent component, which relies on the base component,
+ is similarly defined: interfaces to external entities defined
+ in the SFRs of the component ST are categorised as TSFI and
+ are examined in .
+
+ Any call out from the dependent TSF to the environment in
+ support of an SFR will indicate that the dependent TSF
+ requires some service from the environment in order to satisfy
+ the enforcement of the stated dependent component SFRs. Such a
+ service is outside the dependent component boundary and the
+ base component is unlikely to be defined in the dependent ST
+ as an external entity. Hence, the calls for services made out
+ by the dependent TSF to its underlying platform (the base
+ component) will not be analysed as part of the activities. These dependencies on
+ the base component are expressed in the dependent component ST
+ as security objectives for the environment.
+
+ This abstraction of the dependent component and the interfaces
+ is shown in Figure
+ below.
+
+
+ When considering the composition of the base component and the
+ dependent component, if the dependent component's TSF requires
+ services from the base component to support the implementation
+ of the SFR, the interface to the service will need to be
+ defined. If that service is provided by the base component's
+ TSF, then that interface should be a TSFI of the base
+ component and will therefore already be defined within the
+ functional specification of the base component.
+
+ If, however, the service called by the dependent component's
+ TSF is not provided by the TSF of the base component (i.e., it
+ is implemented in the non-TSF portion of the base component or
+ possibly even in the non-TOE portion of the base component
+ (not illustrated in Figure ), there is unlikely to be a TSFI of the base
+ component relating to the service, unless the service is
+ mediated by the TSF of the base component. The interfaces to
+ these services from the dependent component to the operational
+ environment are considered in the family .
+
+ The non-TSF portion of the base component is drawn into the
+ TSF of the composed TOE due to the dependencies the dependent
+ component has on the base component to support the SFRs of the
+ dependent component. Therefore, in such cases, the TSF of the
+ composed TOE would be larger than simply the sum of the
+ components' TSFs.
+
+
+ It may be the case that the base component TSFI is being
+ called in a manner that was unforeseen in the base component
+ evaluation. Hence there would be a requirement for further
+ testing of the base component TSFI.
+
+ The possible interfaces are further described in the following
+ diagram (Figure ) and
+ supporting text.
+
+
+
+
+ Arrows going into 'dependent component-a'
+ (A and B) = where the component expects the environment to
+ respond to a service request (responding to calls out from
+ dependent component to the environment);
+
+ Arrows coming out of 'base component-b'
+ (C and D) = interfaces of services provided by the base
+ component to the environment;
+
+ Broken lines between components = types of communication
+ between pairs of interfaces;
+
+ The other (grey) arrows = interfaces that are described by
+ the given criteria.
+
+ The following is a simplification, but explains the
+ considerations that need to be made.
+
+ There are components a ('dependent component-a') and b ('base
+ component-b'): the arrows coming out of TSF-a
+ are services provided by TSF-a and are therefore TSFIs(a);
+ likewise, the arrows coming out of TSF-b
+ (``C'') are TSFIs(b). These are each detailed in their
+ respective functional specs. component-a is such that it
+ requires services from its environment: those needed by the
+ TSF(a) are labelled ``A''; the other (not related to TSF-a)
+ services are labelled ``B''.
+
+ When component-a and component-b are combined, there are four
+ possible combinations of {services needed by component-a} and
+ {services provided by component-b}, shown as broken lines
+ (types of communication between pairs of interfaces). Any set
+ of these might exist for a particular composition:
+
+
+ TSF-a needs those services that are provided by TSF-b ("A" is connected to "C"):
+ this is straightforward: the details about "C" are in the FSP for component-b.
+ In this instance the interfaces should all be defined in the functional specifications for
+ the component-b.
+
+
+ Non-TSF-a needs those services that are provided by TSF-b
+ (``B'' is connected to ``C''): this is straightforward
+ (again, the details about ``C'' are in the FSP for
+ component-b), but unimportant: security-wise.
+
+ Non-TSF-a needs those services that are provided by
+ non-TSF-b (``B'' is connected to ``D''): we have no
+ details about D, but there are no security implications
+ about the use of these interfaces, so they do not need to
+ be considered in the evaluation, although they are likely
+ to be an integration issue for the developer.
+
+ TSF-a needs those services that are provided by non-TSF-b
+ (``A'' is connected to ``D''): this would arise when
+ component-a and component-b have different senses of what
+ a ``security service'' is. Perhaps component-b is making
+ no claims about I&A (has no
+ SFRs in its ST), but component-a needs authentication
+ provided by its environment. There are no details about
+ the ``D'' interfaces available (they are not TSFI (b), so
+ they are not in component-b's FSP).
+
+ Note: if the kind of interaction described in case d above
+ exists, then the TSF of the composed TOE would be TSF-a + TSF-b
+ + Non-TSF-b. Otherwise, the TSF of the composed TOE would be
+ TSF-a + TSF-b.
+
+ Interfaces types 2 and 4 of Figure are not directly relevant to the evaluation of
+ the composed TOE. Interfaces 1 and 3 will be considered during
+ the application of different families:
+
+
+ (for component-b) will
+ describe the C interfaces.
+
+ will describe the A
+ interfaces.
+
+ will describe the C
+ interfaces for connection type 1 and the D interfaces for
+ connection type 3.
+
+ A typical example where composition may be applied is a
+ database management system (DBMS) that relies upon its
+ underlying operating system (OS). During the evaluation of
+ the DBMS component, there will be an assessment made of the
+ security properties of that DBMS (to whatever degree of rigour
+ is dictated by the assurance components used in the
+ evaluation): its TSF boundary will be identified, its
+ functional specification will be assessed to determine whether
+ it describes the interfaces to the security services provided
+ by the TSF, perhaps additional information about the TSF (its
+ design, architecture, internal structure) will be provided,
+ the TSF will be tested, aspects of its life-cycle and its
+ guidance documentation will be assessed, etc.
+
+ However, the DBMS evaluation will not call for any evidence
+ concerning the dependency the DBMS has on the OS. The ST of
+ the DBMS will most likely state assumptions about the OS in
+ its Assumptions subclause and state security objectives for the
+ OS in its Environment subclause. The DBMS ST may even
+ instantiate those objectives for the environment in terms of
+ SFRs for the OS. However, there will be no specification for
+ the OS that mirrors the detail in the functional
+ specification, architecture description, or other evidence as for the DBMS. will fulfil that need.
+
+ describes the interfaces of
+ the dependent TOE that make the calls to the base component
+ for the provision of services. These are the interfaces to
+ which the base component is to respond. The interface
+ descriptions are provided from the dependent component's
+ viewpoint.
+
+ describes the interfaces
+ provided by the base component, which respond to the dependent
+ component service requests. These interfaces are mapped to the
+ relevant dependent component interfaces that are identified in
+ the reliance information. (The completeness of this mapping,
+ whether the base component interfaces described represent all
+ dependent component interfaces, is not verified here, but in
+ ). At the higher levels of
+ the subsystems providing the
+ interfaces are described.
+
+ Any interfaces required by the dependent component that have
+ not been described for the base component are reported in the
+ rationale for . The rationale
+ also reports whether the interfaces of the base component on
+ which the dependent component relies were considered within
+ the base component evaluation. For any interfaces that were
+ not considered in the base component evaluation, a rationale
+ is provided of the impact of using the interface on the base
+ component TSF.
+
+
+
+
+ This annex contains ancillary material to further explain and
+ provide additional examples for the topics brought up in
+ families of the class.
+
+
+ A security architecture is a set of properties that the TSF
+ exhibits; these properties include self-protection, domain
+ separation, and non-bypassability. Having these properties
+ provides a basis of confidence that the TSF is providing its
+ security services. This annex provides additional material on
+ these properties, as well as discussion on contents of a
+ security architecture description.
+
+ The remainder of this subclause first explains these properties,
+ then discusses the kinds of information that are needed to
+ describe how the TSF exhibits those properties.
+
+ Self-protection refers to the ability of
+ the TSF to protect itself from manipulation from external
+ entities that may result in changes to the TSF. Without these
+ properties, the TSF might be disabled from performing its
+ security services.
+
+ It is oftentimes the case that a TOE uses services or
+ resources supplied by other IT entities in order to perform
+ its functions (e.g. an application that relies upon its
+ underlying operating system). In these cases, the TSF does
+ not protect itself entirely on its own, because it depends
+ on the other IT entities to protect the services it
+ uses.
+ Domain separation is a property whereby the TSF
+ creates separate security domains for each
+ untrusted active entity to operate on its resources, and then
+ keeps those domains separated from one another so that no entity
+ can run in the domain of any other. For example, an operating
+ system TOE supplies a domain (address space, per-process
+ environment variables) for each process associated with
+ untrusted entities.
+
+ For some TOEs such domains do not exist because all of the
+ actions of the untrusted entities are brokered by the TSF. A
+ packet-filter firewall is an example of such a TOE, where
+ there are no untrusted entity domains; there are only data
+ structures maintained by the TSF. The existence of domains,
+ then, is dependant upon 1) the type of TOE and 2) the SFRs
+ levied on the TOE. In the cases where the TOE does provide
+ domains for untrusted entities, this family requires that
+ those domains are isolated from one another such that
+ untrusted entities in one domain are prevented from
+ tampering (affecting without brokering by the TSF) from
+ another untrusted entity's domain.
+
+ Non-bypassability is a property that the
+ security functionality of the TSF (as specified by the SFRs)
+ is always invoked and cannot be circumvented when
+ appropriate for that specific mechanism. For example, if
+ access control to files is specified as a capability of the
+ TSF via an SFR, there must be no interfaces through which
+ files can be accessed without invoking the TSF's access
+ control mechanism (an interface through which a raw disk
+ access takes place might be an example of such an
+ interface).
+
+ As is the case with self-protection, the very nature of some
+ TOEs might depend upon their environments to play a role in
+ non-bypassability of the TSF. For example, a security
+ application TOE requires that it be invoked by the
+ underlying operating system. Similarly, a firewall depends
+ upon the fact that there are no direct connections between
+ the internal and external networks and that all traffic
+ between them must go through the firewall.
+
+
+ The security architecture description explains how the
+ properties described above are exhibited by the TSF. It
+ describes how domains are defined and how the TSF keeps them
+ separate. It describes what prevents untrusted processes
+ from getting to the TSF and modifying it. It describes what
+ ensures that all resources under the TSF's control are
+ adequately protected and that all actions related to the
+ SFRs are mediated by the TSF. It explains any role the
+ environment plays in any of these (e.g. presuming it gets
+ correctly invoked by its underlying environment, how are its
+ security functions invoked?).
+
+ The security architecture description presents the TSF's
+ properties of self-protection, domain separation, and
+ non-bypassability in terms of the decomposition descriptions.
+ The level of this description is commensurate with the TSF
+ description required by the ,
+ and requirements that are being claimed. For example, if
+ is the only TSF description
+ available, it would be difficult to provide any meaningful
+ security architecture description because none of the details of
+ any internal workings of the TSF would be available.
+
+ However, if the TOE design were also available, even at the most
+ basic level (), there would be
+ some information available concerning the subsystems that make
+ up the TSF, and there would be a description of how they work to
+ implement self-protection, domain separation, and
+ non-bypassability. For example, perhaps all user interaction
+ with the TOE is constrained through a process that acts on that
+ user's behalf, adopting all of the user's security attributes;
+ the security architecture description would describe how such a
+ process comes into being, how the process's behaviour is
+ constrained by the TSF (so it cannot corrupt the TSF), how all
+ actions of that process are mediated by the TSF (thereby
+ explaining why the TSF cannot be bypassed), etc.
+
+ If the available TOE design is more detailed (e.g. at the
+ modular level), or the implementation representation is also
+ available, then the security architecture description would be
+ correspondingly more detailed, explaining how the user's process
+ communicate with the TSF processes, how different requests are
+ processed by the TSF, what parameters are passed, what
+ programmatic protections (buffer overflow prevention, parameter
+ bounds checking, time of check/time of use checking, etc.) are
+ in place. Similarly, a TOE whose ST claimed the component would go into
+ implementation-specific detail.
+
+ The explanations provided in the security architecture
+ description are expected to be of sufficient detail that one
+ would be able to test their accuracy. That is, simple
+ assertions (e.g. "The TSF keeps domains separate'') provide
+ no useful information to convince the reader that the TSF
+ does indeed create and separate domains.
+
+ In cases where the TOE exhibits domain separation entirely on
+ its own, there would be a straightforward description of how
+ this is attained. The security architecture description would
+ explain the different kinds of domains that are defined by the
+ TSF, how they are defined (i.e. what resources are allocated
+ to each domain), how no resources are left unprotected, and
+ how the domains are kept separated so that active entities in
+ one domain cannot tamper with resources in another
+ domain.
+ For cases where the TOE depends upon other IT entities to play
+ a role in domain separation, that sharing of roles must be made
+ clear. For example, a TOE that is solely application software
+ relies upon the underlying operating system to correctly
+ instantiate the domains that the TOE defines; if the TOE
+ defines separate processing space, memory space, etc, for each
+ domain, it depends upon the underlying operating system to
+ operate correctly and benignly (e.g. allow the process to
+ execute only in the execution space that is requested by the
+ TOE software).
+ For example, mechanisms that implement domain separation
+ (e.g., memory management, protected processing modes provided
+ by the hardware, etc.) would be identified and described. Or,
+ the TSF might implement software protection constructs or
+ coding conventions that contribute to implementing separation
+ of software domains, perhaps by delineating user address space
+ from system address space.
+ The vulnerability analysis and testing (see ) activities will likely include attempts to defeat
+ the described TSF domain separation through the use of
+ monitoring or direct attack the TSF.
+
+
+ In cases where the TOE exhibits self-protection entirely
+ on its own, there would be a straightforward description
+ of how this self-protection is attained. Mechanisms that
+ provide domain separation to define a TSF domain that is
+ protected from other (user) domains would be identified
+ and described.
+
+ For cases where the TOE depends upon other IT entities to
+ play a role in protecting itself, that sharing of roles
+ must be made clear. For example, a TOE that is solely
+ application software relies upon the underlying operating
+ system to operate correctly and benignly; the application
+ cannot protect itself against a malicious operating system
+ that subverts it (for example, by overwriting its
+ executable code or TSF data).
+
+ The security architecture description also covers how user input
+ is handled by the TSF in such a way that the TSF does not
+ subject itself to being corrupted by that user input. For
+ example, the TSF might implement the notion of privilege and
+ protect itself by using privileged-mode routines to handle user
+ data. The TSF might make use of processor-based separation
+ mechanisms (e.g. privilege levels or rings) to separate TSF
+ code and data from user code and data. The TSF might implement
+ software protection constructs or coding conventions that
+ contribute to implementing separation of software, perhaps by
+ delineating user address space from system address space.
+
+ For TOEs that start up in a low-function mode (for
+ example, a single-user mode accessible only to installers
+ or administrators) and then transition to the evaluated
+ secure configuration (a mode whereby untrusted users are
+ able to login and use the services and resources of the
+ TOE), the security architecture description also includes
+ an explanation of how the TSF is protected against this
+ initialisation code that does not run in the evaluated
+ configuration. For such TOEs, the security architecture
+ description would explain what prevents those services
+ that should be available only during initialisation
+ (e.g. direct access to resources) from being accessible in
+ the evaluated configuration. It would also explain what
+ prevents initialisation code from running while the TOE is
+ in the evaluated configuration.
+
+ There must also be an explanation of how the trusted
+ initialisation code will maintain the integrity of the TSF
+ (and of its initialisation process) such that the
+ initialisation process is able to detect any modification
+ that would result in the TSF being spoofed into believe it
+ was in an initial secure state.
+
+ The vulnerability analysis and testing (see ) activities will likely include
+ attempts to defeat the described TSF self protection
+ through the use of tampering, direct attack, or monitoring
+ of the TSF.
+
+
+ The property of non-bypassability is concerned with
+ interfaces that permit the bypass of the enforcement
+ mechanisms. In most cases this is a consequence of the
+ implementation, where if a programmer is writing an
+ interface that accesses or manipulates an object, it is
+ that programmer's responsibility to use interfaces that
+ are part of the SFR enforcement mechanism for the object
+ and not to try to circumvent those interfaces. For the
+ description pertaining to non-bypassability, then, there
+ are two broad areas that have to be covered.
+
+ The first consists of those interfaces to the SFR-enforcement.
+ The property for these interfaces is that they contain no
+ operations or modes that allow them to be used to bypass the
+ TSF. It is likely that the evidence for and can be used in
+ large part to make this determination. Because non-bypassability
+ is the concern, if only certain operations available through
+ these TSFIs are documented (because they are SFR-enforcing) and
+ others are not, the developer should consider whether additional
+ information (to that presented in
+ and ) is necessary to make a
+ determination that the
+ SFR-supporting and SFR-non-interfering
+ operations of the TSFI do not afford an
+ untrusted entity the ability to bypass the policy being
+ enforced. If such information is necessary, it is included
+ in the security architecture description.
+
+ The second area of non-bypassability is concerned with
+ those interfaces whose interactions are not associated
+ with SFR-enforcement. Depending on the and components
+ claimed, some information about these interfaces may or
+ may not exist in the functional specification and TOE
+ design documentation. The information presented for such
+ interfaces (or groups of interfaces) should be sufficient
+ so that a reader can make a determination (at the level of
+ detail commensurate with the rest of the evidence supplied
+ in the class) that the
+ enforcement mechanisms cannot be bypassed.
+
+ The property that the security functionality cannot be
+ bypassed applies to all security functionality
+ equally. That is, the design description should cover
+ objects that are protected under the SFRs (e.g. _* components) and functionality
+ (e.g., audit) that is provided by the TSF. The description
+ should also identify the interfaces that are associated
+ with security functionality; this might make use of the
+ information in the functional specification. This
+ description should also describe any design constructs,
+ such as object managers, and their method of use. For
+ instance, if routines are to use a standard macro to
+ produce an audit record, this convention is a part of the
+ design that contributes to the non-bypassability of the
+ audit mechanism. It is important to note that
+ non-bypassability in this context is not an
+ attempt to answer the question ``could a part of the TSF
+ implementation, if malicious, bypass the security
+ functionality'', but rather to document how the
+ implementation does not bypass the security
+ functionality.
+
+ The vulnerability analysis and testing (see ) activities will likely include
+ attempts to defeat the described non-bypassability by
+ circumventing the TSF.
+
+
+
+
+ The purpose in specifying the TSFIs is to provide the
+ necessary information to conduct testing; without knowing the
+ possible means interact with the TSF, one cannot adequately
+ test the behaviour of the TSF.
+
+ There are two parts to specifying the TSFIs: identifying them
+ and describing them. Because of the diversity of possible
+ TOEs, and of different TSFs therein, there is no standard set
+ of interfaces that constitute ``TSFIs''. This annex provides
+ guidance on the factors that determine which interfaces are
+ TSFIs.
+
+
+ In order to identify the interfaces to the TSF, the parts of the
+ TOE that make up the TSF must first be identified. This
+ identification is actually a part of the analysis, but is also performed implicitly
+ (through identification and description of the TSFI) by the
+ developer in cases where is not
+ included in the assurance package. In this analysis, a portion
+ of the TOE must be considered to be in the TSF if it contributes
+ to the satisfaction of an SFR in the ST (in whole or in
+ part). This includes, for example, everything in the TOE that
+ contributes to TSF run-time initialisation, such as software
+ that runs prior to the TSF being able to protect itself because
+ enforcement of the SFRs has not yet begun (e.g., while booting
+ up). Also included in the TSF are all parts of the TOE that
+ contribute to the architectural principles of TSF
+ self-protection, domain separation, and non-bypassability (see
+ ).
+
+ Once the TSF has been defined, the TSFI are identified.
+ The TSFI consists of all means by which external entities (or
+ subjects in the TOE but outside of the TSF) supply data to the TSF,
+ receive data from the TSF and invoke services from the TSF.
+ These service invocations and responses are the means of crossing
+ the TSF boundary. While many of these are readily apparent, others
+ might not be as obvious. The question that should be asked when
+ determining the TSFIs is: ``How can a potential attacker interact
+ with the TSF in an attempt to subvert the SFRs?'' The following
+ discussions illustrate the application of the TSFI definition in
+ different contexts.
+
+
+ In TOEs such as smart cards, where the adversary has not
+ only logical access to the TOE, but also complete physical
+ access to the TOE, the TSF boundary is the physical
+ boundary. Therefore, the exposed electrical interfaces
+ are considered TSFI because their manipulation could
+ affect the behaviour of the TSF. As such, all these
+ interfaces (electrical contacts) need to be described:
+ various voltages that might be applied, etc.
+
+
+
+ The TSFIs of a TOE that performs protocol processing would
+ be those protocol layers to which a potential attacker has
+ direct access. This need not be the entire protocol stack,
+ but it might be.
+
+ For example, if the TOE were some sort of a network
+ appliance that allowed potential attackers to affect every
+ level of the protocol stack (i.e. to send arbitrary
+ signals, arbitrary voltages, arbitrary packets, arbitrary
+ datagrams, etc.), then the TSF boundary exists at each
+ layer of the stack. Therefore, the functional
+ specification would have to address every protocol at
+ every layer of the stack.
+
+ If, however, the TOE were a firewall that protects an
+ internal network from the Internet, a potential attacker
+ would have no means of directly manipulating the voltages
+ that enter the TOE; any extreme voltages would simply not
+ be passed though the Internet. That is, the attacker would
+ have access only to those protocols at the Internet layer
+ or above. The TSF boundary exists at each layer of the
+ stack. Therefore, the functional specification would have
+ to address only those protocols at or above the Internet
+ layer: it would describe each of the different
+ communication layers at which the firewall is exposed in
+ terms of what constitutes well-formed input for what might
+ appear on the line, and the result of both well-formed and
+ malformed inputs. For example, the description of the
+ Internet protocol layer would describe what constitutes a
+ well-formed IP packet and what happens when both
+ correctly-formed and malformed packets are
+ received. Likewise, the description of the TCP layer would
+ describe a successful TCP connection and what happens both
+ when successful connections are established and when
+ connections cannot be established or are inadvertently
+ dropped. Presuming the firewall's purpose is to filter
+ application-level commands (like FTP or telnet), the
+ description of the application layer would describe the
+ application-level commands that are recognised and
+ filtered by the firewall, as well as the results of
+ encountering unknown commands.
+
+ The descriptions of these layers would likely reference
+ published communication standards (telnet, FTP, TCP, etc.)
+ that are used, noting which user-defined options are
+ chosen.
+
+
+
+
+
+
+ ``Wrappers'' translate complex series of interactions into
+ simplified common services, such as when Operating Systems
+ create APIs for use by applications (as shown in Figure
+ ). Whether the TSFIs
+ would be the system calls or the APIs depends upon what is
+ available to the application: if the application can use
+ the system calls directly, then the system calls are the
+ TSFIs. If, however, there were something that prohibits
+ their direct use and requires all communication through
+ the APIs, then the APIs would be the TSFIs.
+
+ A Graphical User interface is similar: it translates
+ between machine-understandable commands and user-friendly
+ graphics. Similarly, the TSFIs would be the commands if
+ users have access to them, or the graphics (pull-down
+ menus, check-boxes, text fields) if the users are
+ constrained to using them.
+
+ It is worth noting that, in both of these examples, if the
+ user is prohibited from using the more primitive
+ interfaces (i.e. the system calls or the commands), the
+ description of this restriction and of its enforcement
+ would be included in the Security Architecture Description
+ (see ). Also, the wrapper would be
+ part of the TSF.
+
+
+
+ For a given TOE, not all of the interfaces may be
+ accessible. That is, the security
+ objectives for the operational environment (in the
+ Security Target) may prevent access to these interfaces or
+ limit access in such a way that they are practically
+ inaccessible. Such interfaces would not be considered
+ TSFIs. Some examples:
+
+ If the security objectives for the operational
+ environment for the stand-alone firewall state that
+ ``the firewall will be operational in a server room
+ environment to which only trusted and trained
+ personnel will have access, and which will be equipped
+ with an interruptible power supply (against power
+ failure)'', physical and power interfaces will not be
+ accessible, since trusted and trained personnel will
+ not attempt to dismantle the firewall and/or disable
+ its power supply. If the security
+ objectives for the operational environment for the
+ software firewall (application) state that ``the OS
+ and the hardware will provide a security domain for
+ the application free from tampering by other
+ programs'', the interfaces through which the firewall
+ can be accessed by other applications on the OS
+ (e.g. deleting or modifying the firewall executable,
+ direct reading or writing to the memory space of the
+ firewall) will not be accessible, since the
+ OS/hardware part of the operational environment makes
+ this interface inaccessible.If the
+ security objectives for the operational environment
+ for the software firewall additionally state that the
+ OS and hardware will faithfully execute the commands
+ of the TOE, and will not tamper with the TOE in any
+ manner, interfaces through which the firewall obtains
+ primitive functionality from the OS and hardware
+ (executing machine code instructions, OS APIs, such as
+ creating, reading, writing or deleting files,
+ graphical APIs etc.) will not be accessible, since the
+ OS/hardware are the only entities that can access that
+ interface, and they are completely
+ trusted. For all of these examples,
+ these inaccessible interfaces would not be
+ TSFIs.
+
+
+
+ Figure
+ illustrates a complex TOE: a database management system that
+ relies on hardware and software that is outside the TOE
+ boundary (referred to as the IT environment
+ in the rest of this discussion). To simplify this example,
+ the TOE is identical to the TSF. The
+ shaded boxes represent the TSF, while the unshaded boxes
+ represent IT entities in the environment. The TSF comprises
+ the database engine and management GUIs (represented by the
+ box labelled DB) and a kernel module that
+ runs as part of the OS that performs some security function
+ (represented by the box labelled PLG). The
+ TSF kernel module has entry points defined by the OS
+ specification that the OS will call to invoke some function
+ (this could be a device driver, or an authentication module,
+ etc.). The key is that this pluggable kernel module is
+ providing security services specified by functional
+ requirements in the ST.
+
+
+
+
+ The IT environment consists of the operating system itself
+ (represented by the box labelled OS), as
+ well as an external server (labelled SRV).
+ This external server, like the OS, provides a service that
+ the TSF depends on, and thus needs to be in the IT
+ environment. Interfaces in the figure are labelled
+ Ax for TSFI, and Bx for
+ other interfaces that would be documented in . Each of these groups of interfaces is now
+ discussed.
+
+ Interface group A1 represents the most obvious set of TSFI.
+ These are interfaces used by users to directly access the
+ database and its security functionality and
+ resources.
+
+ Interface group A2 represent the TSFI that the OS invokes to
+ obtain the functionality provided by the pluggable module.
+ These are contrasted with interface group B3, which
+ represent calls that the pluggable module makes to obtain
+ services from the IT environment.
+
+ Interface group A3 represent TSFI that pass through the IT
+ environment. In this case, the DBMS communicates over the
+ network using a proprietary application-level
+ protocol. While the IT environment is responsible for
+ providing various supporting protocols (e.g., Ethernet, IP,
+ TCP), the application layer protocol that is used to obtain
+ services from the DBMS is a TSFI and must be documented as
+ such. The dotted line indicates return values/services from
+ the TSF over the network connection.
+
+ The interfaces labelled Bx represent
+ interfaces to functionality in the IT Environment. These
+ interfaces are not TSFI and need only be discussed and
+ analysed when the TOE is being used in a composite
+ evaluation as part of the activities associated with the
+ class.
+
+
+
+ The Example firewall is used between an internal network and
+ an external network. It verifies the source address of data
+ received (to ensure that external data is not attempting to
+ masquerade as originating from the internal data); if it
+ detects any such attempts, it saves the offending attempt to
+ the audit log. The administrator connects to the firewall by
+ establishing a telnet connection to the firewall from the
+ internal network. Administrator actions consist of
+ authenticating, changing passwords, reviewing the audit log,
+ and setting or changing the addresses of the internal and
+ external networks.
+
+ The Example firewall presents the following interfaces to
+ the internal network:
+
+ IP datagrams
+ Administrator Commands and the
+ following interfaces to the external network:
+
+ IP datagrams
+ Interfaces Descriptions: IP
+ Datagrams
+ The datagrams are in the format specified by RFC 791.
+
+ Purpose - to transmit blocks of data (``datagrams'')
+ from source hosts to destination hosts identified by
+ fixed length addresses; also provides for fragmentation
+ and reassembly of long datagrams, if necessary, for
+ transmission through small-packet networks.
+ Method of Use - they arrive from the lower-level
+ (e.g. data link) protocol.
+ Parameters - the following fields of the IP datagram
+ header: source address, destination address,
+ don't-fragment flag.
+ Parameter description - [As defined by RFC 791,
+ subclause 3.1 (``Internet Header Format'')]
+ Actions - Transmits datagrams that are not
+ masquerading; fragments large datagrams if necessary;
+ reassembles fragments into datagrams.
+ Error messages - (none). No reliability guaranteed
+ (reliability to be provided by upper-level protocols)
+ Undeliverable datagrams (e.g. must be fragmented for
+ transmission, but don't-fragment flag is set)
+ dropped.
+ Interfaces Descriptions: Administrator
+ Commands
+ The administrator commands provide a means for the
+ administrator to interact with the firewall. These commands
+ and responses ride atop a telnet (RFC 854) connection
+ established from any host on the internal network. Available
+ commands are:
+
+ Passwd
+
+ Purpose - sets administrator password
+ Method of Use - Passwd
+ <password>
+ Parameters - password
+ Parameter description - value of new
+ password
+ Actions - changes password to new value
+ supplied. There are no restrictions.
+ Error messages - none.
+
+ Readaudit
+
+ Purpose - presents the audit log to the
+ administrator
+ Method of Use - Readaudit
+ Parameters - none
+ Parameter description - none
+ Actions - provides the text of the audit
+ log
+ Error messages - none.
+
+ Setintaddr
+
+ Purpose - sets the address of the internal
+ address.
+ Method of Use - Setintaddr
+ <address>
+ Parameters - address
+ Parameter description - first three fields of an
+ IP address (as defined in RFC 791). For example:
+ 123.123.123.
+ Actions - changes the internal value of the
+ variable defining the internal network, the value of
+ which is used to judge attempted masquerades.
+ Error messages - ``address in use'': indicates
+ the identified internal network is the same as the
+ external network.
+
+ Setextaddr
+
+ Purpose - sets the address of the external address
+ Method of Use - Setextaddr
+ <address>
+ Parameters - address
+ Parameter description - first three fields of an
+ IP address (as defined in RFC 791). For example:
+ 123.123.123.
+ Actions - changes the internal value of the
+ variable defining the external network.
+ Error messages - ``address in use'': indicates
+ the identified external network is the same as the
+ internal network.
+
+
+
+
+
+
+ The wide variety of TOEs makes it impossible to codify
+ anything more specific than ``well-structured'' or ``minimum
+ complexity''. Judgements on structure and complexity are
+ expected to be derived from the specific technologies used in
+ the TOE. For example, software is likely to be considered
+ well-structured if it exhibits the characteristics cited in
+ the software engineering disciplines.
+
+ This annex provides supplementary material on assessing the
+ structure and complexity of procedure-based software portions
+ of the TSF. This material is based on information readily
+ available in software engineering literature. For other kinds
+ of internals (e.g. hardware, non-procedural software such as
+ object-oriented code, etc.), corresponding literature on good
+ practises should be consulted.
+
+
+ The structure of procedural software is traditionally
+ assessed according to its
+ modularity. Software written with a modular
+ design aids in achieving understandability by clarifying
+ what dependencies a module has on other modules
+ (coupling) and by including in a module
+ only tasks that are strongly related to each other
+ (cohesion). The use of modular design
+ reduces the interdependence between elements of the TSF and
+ thus reduces the risk that a change or error in one module
+ will have effects throughout the TOE. Its use enhances
+ clarity of design and provides for increased assurance that
+ unexpected effects do not occur. Additional desirable
+ properties of modular decomposition are a reduction in the
+ amount of redundant or unneeded code.
+
+ Minimising the amount of functionality in the TSF allows the
+ evaluator as well as the developer to focus only on that
+ functionality which is necessary for SFR enforcement,
+ contributing further to understandability and further
+ lowering the likelihood of design or implementation
+ errors.
+
+ The incorporation of modular decomposition, layering and
+ minimisation into the design and implementation process must
+ be accompanied by sound software engineering
+ considerations. A practical, useful software system will
+ usually entail some undesirable coupling among modules, some
+ modules that include loosely-related functions, and some
+ subtlety or complexity in a module's design. These
+ deviations from the ideals of modular decomposition are
+ often deemed necessary to achieve some goal or constraint,
+ be it related to performance, compatibility, future planned
+ functionality, or some other factors, and may be acceptable,
+ based on the developer's justification for them. In applying
+ the requirements of this class, due consideration must be
+ given to sound software engineering principles; however, the
+ overall objective of achieving understandability must be
+ achieved.
+
+
+ Cohesion is the manner and degree to which the tasks
+ performed by a single software module are related to one
+ another; types of cohesion include coincidental,
+ communicational, functional, logical, sequential, and
+ temporal. These types of cohesion are characterised below,
+ listed in the order of decreasing desirability.
+
+ functional cohesion - a module
+ with functional cohesion performs activities related
+ to a single purpose. A functionally cohesive module
+ transforms a single type of input into a single type
+ of output, such as a stack manager or a queue
+ manager.
+ sequential cohesion - a module
+ with sequential cohesion contains functions each of
+ whose output is input for the following function in
+ the module. An example of a sequentially cohesive
+ module is one that contains the functions to write
+ audit records and to maintain a running count of the
+ accumulated number of audit violations of a specified
+ type.
+ communicational cohesion - a
+ module with communicational cohesion contains
+ functions that produce output for, or use output from,
+ other functions within the module. An example of a
+ communicationally cohesive module is an access check
+ module that includes mandatory, discretionary, and
+ capability checks.
+ temporal cohesion - a module
+ with temporal cohesion contains functions that need to
+ be executed at about the same time. Examples of
+ temporally cohesive modules include initialisation,
+ recovery, and shutdown modules.
+ logical (or
+ procedural) cohesion - a module with
+ logical cohesion performs similar activities on
+ different data structures. A module exhibits logical
+ cohesion if its functions perform related, but
+ different, operations on different inputs.
+ coincidental cohesion - a
+ module with coincidental cohesion performs unrelated,
+ or loosely related, activities.
+
+
+
+ Coupling is the manner and degree of interdependence
+ between software modules; types of coupling include call,
+ common and content coupling. These types of coupling are
+ characterised below, listed in the order of decreasing
+ desirability:
+
+ call: two modules are call coupled if they
+ communicate strictly through the use of their
+ documented function calls; examples of call coupling
+ are data, stamp, and control, which are defined below.
+
+ data: two modules are data
+ coupled if they communicate strictly through the
+ use of call parameters that represent single data
+ items.
+ stamp: two modules are stamp
+ coupled if they communicate through the use of
+ call parameters that comprise multiple fields or
+ that have meaningful internal structures.
+ control: two modules are
+ control coupled if one passes information that is
+ intended to influence the internal logic of the
+ other.
+
+ common: two modules are common
+ coupled if they share a common data area or a common
+ system resource. Global variables indicate that
+ modules using those global variables are common
+ coupled. Common coupling through global variables is
+ generally allowed, but only to a limited degree. For
+ example, variables that are placed into a global area,
+ but are used by only a single module, are
+ inappropriately placed, and should be removed. Other
+ factors that need to be considered in assessing the
+ suitability of global variables are:
+
+ The number of modules that modify a global
+ variable: In general, only a single module should
+ be allocated the responsibility for controlling
+ the contents of a global variable, but there may
+ be situations in which a second module may share
+ that responsibility; in such a case, sufficient
+ justification must be provided. It is unacceptable
+ for this responsibility to be shared by more than
+ two modules. (In making this assessment, care
+ should be given to determining the module actually
+ responsible for the contents of the variable; for
+ example, if a single routine is used to modify the
+ variable, but that routine simply performs the
+ modification requested by its caller, it is the
+ calling module that is responsible, and there may
+ be more than one such module). Further, as part
+ of the complexity determination, if two modules
+ are responsible for the contents of a global
+ variable, there should be clear indications of how
+ the modifications are coordinated between
+ them.
+ The number of modules that reference a global
+ variable: Although there is generally no limit on
+ the number of modules that reference a global
+ variable, cases in which many modules make such a
+ reference should be examined for validity and
+ necessity.
+
+ content: two modules are content
+ coupled if one can make direct reference to the
+ internals of the other (e.g. modifying code of, or
+ referencing labels internal to, the other module).
+ The result is that some or all of the content of one
+ module are effectively included in the other. Content
+ coupling can be thought of as using unadvertised
+ module interfaces; this is in contrast to call
+ coupling, which uses only advertised module
+ interfaces.
+
+
+
+
+ Complexity is the measure of the decision points and logical
+ paths of execution that code takes. Software engineering
+ literature cites complexity as a negative characteristic of
+ software because it impedes understanding of the logic and
+ flow of the code. Another impediment to the understanding of
+ code is the presence of code that is unnecessary, in that it
+ is unused or redundant.
+
+ The use of layering to separate levels of abstraction and
+ minimise circular dependencies further enables a better
+ understanding of the TSF, providing more assurance that the
+ TOE security functional requirements are accurately and
+ completely instantiated in the implementation.
+
+ Reducing complexity also includes reducing or eliminating
+ mutual dependencies, which pertains both to modules in a
+ single layer and to those in separate layers. Modules that
+ are mutually dependent may rely on one another to formulate
+ a single result, which could result in a deadlock condition,
+ or worse yet, a race condition (e.g., time of check vs. time
+ of use concern), where the ultimate conclusion could be
+ indeterminate and subject to the computing environment at
+ the given instant in time.
+
+ Design complexity minimisation is a key characteristic of a
+ reference validation mechanism, the purpose of which is to
+ arrive at a TSF that is easily understood so that it can be
+ completely analysed. (There are other important
+ characteristics of a reference validation mechanism, such as
+ TSF self-protection and non-bypassability; these other
+ characteristics are covered by requirements in the family.)
+
+
+
+
+ This Subclause provides additional guidance on the TDS family,
+ and its use of the terms ``subsystem'' and ``module''. This is
+ followed by a discussion of how, as more-detailed becomes
+ available, the requirement for the less-detailed is
+ reduced.
+
+ Figure
+ shows that, depending on the complexity of the TSF, the
+ design may be described in terms of subsystems
+ and modules (where subsystems are at a
+ higher level of abstraction than modules); or it may just be
+ described in terms of one level of abstraction (e.g.,
+ subsystems at lower assurance levels,
+ modules at higher levels). In cases where a
+ lower level of abstraction (modules) is presented,
+ requirements levied on higher-level abstractions
+ (subsystems) are essentially met by default. This concept is
+ further elaborated in the discussion on subsystems and
+ modules below.
+
+
+ The developer is expected to describe the design of the TOE
+ in terms of subsystems. The term
+ ``subsystem'' was chosen to be specifically vague so that it
+ could refer to units appropriate to the TOE (e.g.,
+ subsystems, modules). subsystems can even be uneven in
+ scope, as long as the requirements for description of
+ subsystems are met.
+
+ The first use of subsystems is to distinguish the TSF boundary;
+ that is, the portions of the TOE that comprise the TSF. In
+ general, a subsystem is part of the TSF if it has the capability
+ (whether by design or implementation) to affect the correct
+ operation of any of the SFRs. For example, for software that
+ depends on different hardware execution modes to provide domain
+ separation (see ) where
+ SFR-enforcing code is executed in one domain, then all
+ subsystems that execute in that domain would be considered part
+ of the TSF. Likewise, if a server outside that domain
+ implemented an SFR (e.g. enforced an access control policy over
+ objects it managed), then it too would be considered part of the
+ TSF.
+
+ The second use of subsystems is to provide a structure for
+ describing the TSF at a level of description that, while
+ describing how the TSF works, does not necessarily contain
+ low-level implementation detail found in module descriptions
+ (discussed later). subsystems are described at either a high
+ level (lacking an abundance of implementation detail) or a
+ detailed level (providing more insight into the
+ implementation). The level of description provided for a
+ subsystem is determined by the degree to which that
+ subsystem is responsible for implementing an SFR.
+
+ An SFR-enforcing subsystem is a subsystem
+ that provides mechanisms for enforcing an element of any SFR,
+ or directly supports a subsystem that is responsible
+ for enforcing an SFR. If a subsystem provides (implements)
+ an SFR-enforcing TSFI, then the subsystem is
+ SFR-enforcing.
+
+ Subsystems can also be identified as
+ SFR-supporting and
+ SFR-non-interfering. An SFR-supporting
+ subsystem is one that is depended on by an SFR-enforcing
+ subsystem in order to implement an SFR, but does not play as
+ direct a role as an SFR-enforcing subsystem. An
+ SFR-non-interfering subsystem is one that is not depended
+ upon, in either a supporting or enforcing role, to implement
+ an SFR.
+
+
+
+ A module is generally a relatively small architectural unit
+ that can be characterised in terms of the properties
+ discussed in . When both
+ (or above) requirements
+ and requirements are
+ present in a PP or ST, a ``module'' in terms of the requirements refers to the same
+ entity as a ``module'' for the requirements. Unlike subsystems, modules
+ describe the implementation in a level of detail that can
+ serve as a guide to reviewing the implementation
+ representation.
+
+ It is important to note that, depending on the TOE, modules
+ and subsystems may refer to the same abstraction. For and (which do not require description at the
+ module level) the subsystem description provides the lowest
+ level detail available about the TSF. For (which require module
+ descriptions) these descriptions provide the lowest level of
+ detail, while the subsystem descriptions (if they exist as
+ separate entities) merely serve to put to the module
+ descriptions in context. That is, it is not necessary to
+ provide detailed subsystem descriptions if module
+ descriptions exist. In TOEs that are sufficiently simple, a
+ separate ``subsystem description'' is not necessary; the
+ requirements can be met through documentation provided by
+ modules. For complex TOEs, the purpose of the subsystem
+ description (with respect to the TSF) is to provide the
+ reader context so they can focus their analysis
+ appropriately. This difference is illustrated in Figure
+ .
+
+ An SFR-enforcing module is a module that completely or partially implements
+ a security functional requirement (SFR) in the ST. Such modules may
+ implement an SFR-enforcing TSFI, but some functionality expressed in an SFR (for example,
+ audit and object re-use functionality) may not be directly tied to a single TSFI. As was
+ the case with subsystems, SFR-supporting modules are those modules that are depended upon by
+ an SFR-enforcing module, but are not responsible for directly implementing an SFR.
+ SFR-non-interfering modules are those modules that do not deal, directly or indirectly,
+ with the enforcement of SFRs.
+
+ It is important to note that the determination of what
+ ``directly implements'' means is somewhat subjective. In the
+ narrowest sense of the term, it could be interpreted to mean
+ the one or two lines of code that actually perform a
+ comparison, zeroing operation, etc. that implements a
+ requirement. A broader interpretation might be that it
+ includes the module that is invoked in response to a
+ SFR-enforcing TSFI, and all modules that may be invoked in
+ turn by that module (and so on until the completion of the
+ call). Neither of these interpretations is particularly
+ satisfying, since the narrowness of the first interpretation
+ may lead to important modules being incorrectly categorised
+ as SFR supporting, while the second leads to modules that
+ are actually not SFR-enforcing being classified as
+ such.
+
+ A description of a module should be such that one could create an implementation of the
+ module from the description, and the resulting implementation would be 1) identical to
+ the actual TSF implementation in terms of the interfaces presented, 2) identical in the
+ use of interfaces that are mentioned in the design, and 3) functionally equivalent to the
+ description of the purpose of the TSF module. For instance, RFC 793
+ provides a high-level description of the TCP protocol. It is necessarily implementation
+ independent. While it provides a wealth of detail, it is
+ not
+ a suitable design description because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC, and implementation choices
+ (for example, the use of global data vs. local data in various parts of the implementation)
+ may have an impact on the analysis that is performed. The design description of the TCP
+ module would list the interfaces presented by the implementation (rather than just those
+ defined in RFC 793), as well as an algorithm description of the processing associated with
+ the modules implementing TCP (assuming they were part of the TSF).
+
+ In the design, modules are described in detail in terms
+ of the function they provide (the purpose); the interfaces
+ they present (when required by the criteria); the return
+ values from such interfaces; the interfaces (presented by other modules)
+ they use (provided those interfaces are required to be also described);
+ and a description of how they provide their functionality using a
+ technique appropriate to the method used to implement the module.
+
+ The purpose of a module should be described indicating what
+ function the module is providing. It should be sufficient so
+ that the reader could get a general idea of what the
+ module's function is in the architecture.
+
+ The interfaces presented by a module are those interfaces used by
+ other modules to invoke the functionality provided. Interfaces include both
+ explicit interfaces (e.g., a calling sequence invoked by
+ other modules) as well as implicit interfaces (e.g., global
+ data manipulated by the module). Interfaces are described in terms of how
+ they are invoked, and any values that are returned. This description would
+ include a list of parameters, and descriptions of these parameters. If a parameter
+ were expected to take on a set of values (e.g., a ``flag'' parameter), the complete set
+ of values the parameter could take on that would have an effect on module processing
+ would be specified. Likewise, parameters representing data structures are described
+ such that each field of the data structure is identified and described.
+ Global data should be described to the extent required to understand their purpose.
+ The level of description required for a global data structure needs to be identical
+ to the one for module interfaces, where the input parameter and return values correspond
+ to the individual fields and their possible values in the data structure. Global data
+ structures may be described separate from the modules that manipulate or read them as
+ long as the design of the modules contain sufficient information about the global data
+ structures updated or the information extracted from global data structures.
+
+ Note that different programming languages may have
+ additional ``interfaces'' that would be non-obvious; an
+ example would be operator/function overloading in C++. This
+ ``implicit interface'' in the class description would also
+ be described as part of the module design. Note that
+ although a module could present only one interface, it is
+ more common that a module presents a small set of related
+ interfaces.
+
+ When it is required to describe the interfaces used by a module, it must be
+ clear from either the design description of the module or the purpose of the
+ module called, what service is expected from the module called. For example if
+ Module A is being described, and it uses Module B's bubble sort routine, the
+ description of the interaction between modules must allow to identify why
+ Module B's bubble sort routine is called and what this call contributes to the
+ implementation of the SFRs. The interface and purpose of Module B's bubble sort
+ routine must be described as part of the interfaces of Module B (provided the
+ level of ADV_TDS and the classification of Module B require a description its
+ interfaces) and so Module A just needs to identify what data it needs to have
+ sorted using this routine. An adequate description would be: "Module A invokes
+ Module B's interface double_bubble() to sort the usernames in
+ alphabetical order".
+ Note that if this sorting of the user names is not important for the enforcement of
+ any SFR (e. g. it is just done to speed up things and an algorithmically identical
+ implementation of Module A could also avoid to have the usernames sorted), the use of
+ Module B's bubble sort routine is not SFR-enforcing and it is suffcient to explain in
+ the description of Module A that the usernames are sorted in alphabetical order to
+ enhance performance. Module B may be classified as "SFR-supporting" only and the level
+ of ADV_TDS chosen indicates if the interfaces of SFR-supporting modules need to be
+ described or if its is sufficient to just describe the purpose of Module B.
+
+ As discussed previously, the algorithmic description of the
+ module should describe in an algorithmic fashion the
+ implementation of the module. This can be done in
+ pseudo-code, through flow charts, or (at ) informal text. It discusses
+ how the module inputs and called functions are used to
+ accomplish the module's function. It notes changes to global
+ data, system state, and return values produced by the
+ module. It is at the level of detail that an implementation
+ could be derived that would be very similar to the actual
+ implementation of the TOE.
+
+ It should be noted that source code does not meet the module
+ documentation requirements. Although the module design
+ describes the implementation, it is not the
+ implementation. The comments surrounding the source code
+ might be sufficient documentation if they provide an
+ explanation of the intent of the source code. In-line
+ comments that merely state what each line of code is doing
+ are useless because they provide no explanation of what the
+ module is meant to accomplish.
+
+ In the elements below, the labels (SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering) discussed for
+ subsystems and modules are used to describe the amount and
+ type of information that needs to be made available by the
+ developer. The elements have been structured so that there
+ is no expectation that the developer provide
+ only the information specified. That is, if
+ the developer's documentation of the TSF provides the
+ information in the requirements below, there is no
+ expectation that the developer update their documentation
+ and label subsystems and modules as SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering. The primary purpose
+ of this labelling is to allow developers with less mature
+ development methodologies (and associated artifacts, such as
+ detailed interface and design documentation) to provide the
+ necessary evidence without undue cost.
+
+
+
+ Because there is subjectivity in determining what is
+ SFR-enforcing vs. SFR-supporting (and in some cases, even
+ determining what is SFR-non-interfering) the following
+ paradigm has been adopted in this family. In early
+ components of the family, the developer makes a
+ determination about the classification of the subsystems
+ into SFR-enforcing, etc., supplying the appropriate
+ information, and there is little additional evidence for the
+ evaluator to examine to support this claim. As the level of
+ desired assurance increases, while the developer still makes
+ a classification determination, the evaluator obtains more
+ and more evidence that is used to confirm the developer's
+ classification.
+
+ In order to focus the evaluator's analysis on the SFR-related
+ portions of the TOE, especially at lower levels of assurance,
+ the components of the family are levelled such that initially
+ detailed information is required only for SFR-enforcing
+ architectural entities. As the level of assurance increases,
+ more information is required for SFR-supporting and (eventually)
+ SFR-non-interfering entities. It should be noted that even when
+ complete information is required, it is not required that all of
+ this information be analysed in the same level of detail. The
+ focus should be in all cases on whether the
+ necessary information has been provided and
+ analysed.
+
+ Table summarises the
+ information required at each of the family components for the
+ architectural entities to be described.
+
+
+
+
+
+ TSF subsystem
+ TSF Module
+
+
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+
+
+
+
+
+ (informal
+ presentation)
+
+ structure, summary of SFR-Enf. behaviour, interactions
+
+ designation support
+ designation support means that
+ only documentation sufficient to support the
+ classification of the subsystem / module is
+ needed.
+
+ designation support
+
+
+
+
+
+
+ (informal
+ presentation)
+
+ structure, detailed description of SFR-Enf. behaviour,
+ summary of other behaviour, interactions
+
+
+ structure, summary of other behaviour, interactions
+
+ designation support, interactions
+
+
+
+
+
+
+
+ (informal
+ presentation)description,
+ interactionsdescription, interactions
+ description, interactions
+
+ purpose, SFR interfacesSFR interfaces means that the module description contains,
+ for each SFR-related interface, the returned values and the called interfaces
+ to other modules.
+ interaction, purpose
+ interaction, purpose
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, SFR interfaces
+
+
+ purpose, SFR interfaces
+
+ interaction, purpose
+
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, all interfacesAll interfaces means that the module description contains,
+ for each interface, the returned values and the called interfaces to other
+ modules.
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+
+
+ (semiformal
+ presentation; additional formal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+
+
+ Description Detail Levelling
+
+
+
+
+
+ Formal methods provide a mathematical representation of the
+ TSF and its behaviour and are required by the , , and
+ components. There are two aspects of formal methods: the
+ specification language that is used for
+ formal expression, and the theorem prover
+ that mathematically proves the completeness and correctness of
+ the formal specification.
+
+ A formal specification is expressed within a formal system
+ based upon well-established mathematical concepts. These
+ mathematical concepts are used to define well-defined
+ semantics, syntax and rules of inference. A formal system is
+ an abstract system of identities and relations that can be
+ described by specifying a formal alphabet, a formal language
+ over that alphabet which is based on a formal syntax, and a
+ set of formal rules of inference for constructing derivations
+ of sentences in the formal language.
+
+ The evaluator should examine the identified formal systems to
+ make sure that:
+
+ The semantics, syntax and inference rules of the
+ formal system are defined or a definition is
+ referenced.
+ Each formal system is accompanied by explanatory text
+ that provides defined semantics so that:
+
+ the explanatory text provides defined meanings of
+ terms, abbreviations and acronyms that are used in a
+ context other than that accepted by normal
+ usage,
+ the use of a formal system and semiformal notation
+ use is accompanied by supporting explanatory text in
+ informal style appropriate for unambiguous
+ meaning,
+ the formal system is able to express rules and
+ characteristics of applicable SFPs,
+ security functionality and interfaces (providing
+ details of effects, exceptions and error messages) of
+ TSF, their subsystems or modules to be specified for
+ the assurance family for which the notations are
+ used.
+ the notation provides rules to determine the
+ meaning of syntactical valid constructs.
+
+ Each formal system uses a formal syntax that provides
+ rules to unambiguously recognise constructs.
+ Each formal system provides proof rules which
+
+ support logical reasoning of well-established
+ mathematical concepts,
+ help to prevent derivation of
+ contradictions
+
+ If the developer uses a formal system which is already accepted
+ by the evaluation authority the evaluator can rely on the level
+ of formality and strength of the system and focus on the
+ instantiation of the formal system to the TOE specifications and
+ correspondence proofs.
+
+ The formal style supports mathematical proofs of the security
+ properties based on the security features, the consistency of
+ refinements and the correspondence of the representations.
+ Formal tool support seems adequate whenever manual derivations
+ would otherwise become long winded and
+ incomprehensible. Formal tools are also apt to reduce the
+ error probability inherent in manual derivations.
+
+ Examples of formal systems:
+
+ The Z specification language is highly
+ expressive, and supports many different methods or styles
+ of formal specification. The use of Z has been
+ predominantly for model-oriented specification, using
+ schemas to formally specify
+ operations. See for more
+ information.
+ ACL2 is an open-source formal system
+ comprising a LISP-based specification language and a
+ theorem prover. See for
+ further information.
+ Isabelle is a popular generic theorem
+ proving environment that allows mathematical formulae to
+ be expressed in a formal language and provides tools for
+ proving those formulae within a logical calculus (see
+ e.g. for
+ additional information)
+ The B method is a formal system based
+ on the propositional calculus, the first order predicate
+ calculus with inference rules and set theory (see
+ e.g. for further
+ information).
+
+
+
+
+ The dependencies documented in the components of Clauses and - are the direct dependencies between the
+ assurance components.
+
+ The following dependency tables for assurance components show
+ their direct, indirect and optional dependencies. Each of the
+ components that is a dependency of some assurance component is
+ allocated a column. Each assurance component is allocated a
+ row. The value in the table cell indicate whether the column
+ label component is directly required (indicated by a cross
+ ``X'') or indirectly required (indicated by a dash ``-''), by
+ the row label component. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+ The purpose of this Clause is to document the philosophy that
+ underpins the CC approach to assurance. An understanding of this
+ Clause will permit the reader to understand the rationale behind
+ the CC Part 3 assurance requirements.
+
+
+ The CC philosophy is that the threats to security and
+ organisational security policy commitments should be clearly
+ articulated and the proposed security measures be demonstrably
+ sufficient for their intended purpose.
+
+ Furthermore, measures should be adopted that reduce the
+ likelihood of vulnerabilities, the ability to exercise
+ (i.e. intentionally exploit or unintentionally trigger) a
+ vulnerability, and the extent of the damage that could occur
+ from a vulnerability being exercised. Additionally, measures
+ should be adopted that facilitate the subsequent
+ identification of vulnerabilities and the elimination,
+ mitigation, and/or notification that a vulnerability has been
+ exploited or triggered.
+
+
+
+ The CC philosophy is to provide assurance based upon an
+ evaluation (active investigation) of the IT product that is to
+ be trusted. Evaluation has been the traditional means of
+ providing assurance and is the basis for prior evaluation
+ criteria documents. In aligning the existing approaches, the
+ CC adopts the same philosophy. The CC proposes measuring the
+ validity of the documentation and of the resulting IT product
+ by expert evaluators with increasing emphasis on scope, depth,
+ and rigour.
+
+ The CC does not exclude, nor does it comment upon, the
+ relative merits of other means of gaining assurance. Research
+ continues with respect to alternative ways of gaining
+ assurance. As mature alternative approaches emerge from these
+ research activities, they will be considered for inclusion in
+ the CC, which is so structured as to allow their future
+ introduction.
+
+
+ It is assumed that there are threat agents that will
+ actively seek to exploit opportunities to violate security
+ policies both for illicit gains and for well-intentioned,
+ but nonetheless insecure actions. Threat agents may also
+ accidentally trigger security vulnerabilities, causing harm
+ to the organisation. Due to the need to process sensitive
+ information and the lack of availability of sufficiently
+ trusted products, there is significant risk due to failures
+ of IT. It is, therefore, likely that IT security breaches
+ could lead to significant loss.
+
+ IT security breaches arise through the intentional
+ exploitation or the unintentional triggering of
+ vulnerabilities in the application of IT within business
+ concerns.
+
+ Steps should be taken to prevent vulnerabilities arising in
+ IT products. To the extent feasible, vulnerabilities should
+ be:
+
+
+ eliminated -- that is, active steps should be taken to
+ expose, and remove or neutralise, all exercisable
+ vulnerabilities;
+
+
+ minimised -- that is, active steps should be taken to
+ reduce, to an acceptable residual level, the potential
+ impact of any exercise of a vulnerability;
+
+
+ monitored -- that is, active steps should be taken to
+ ensure that any attempt to exercise a residual
+ vulnerability will be detected so that steps can be
+ taken to limit the damage.
+
+
+
+
+
+ Vulnerabilities can arise through failures in:
+
+
+ requirements -- that is, an IT product may possess all
+ the functions and features required of it and still
+ contain vulnerabilities that render it unsuitable or
+ ineffective with respect to security;
+
+
+ development -- that is, an IT product does not meet its
+ specifications and/or vulnerabilities have been
+ introduced as a result of poor development standards or
+ incorrect design choices;
+
+
+ operation -- that is, an IT product has been constructed
+ correctly to a correct specification but vulnerabilities
+ have been introduced as a result of inadequate controls
+ upon the operation.
+
+
+
+
+
+ Assurance is grounds for confidence that an IT product meets
+ its security objectives. Assurance can be derived from
+ reference to sources such as unsubstantiated assertions,
+ prior relevant experience, or specific experience. However,
+ the CC provides assurance through active
+ investigation. Active investigation is an evaluation of the
+ IT product in order to determine its security
+ properties.
+
+
+
+ Evaluation has been the traditional means of gaining
+ assurance, and is the basis of the CC approach. Evaluation
+ techniques can include, but are not limited to:
+
+
+ analysis and checking of process(es) and procedure(s);
+
+
+ checking that process(es) and procedure(s) are being
+ applied;
+
+
+ analysis of the correspondence between TOE design
+ representations;
+
+
+ analysis of the TOE design representation against the
+ requirements;
+
+
+ verification of proofs;
+
+
+ analysis of guidance documents;
+
+
+ analysis of functional tests developed and the results
+ provided;
+
+
+ independent functional testing;
+
+
+ analysis for vulnerabilities (including flaw
+ hypothesis);
+
+
+ penetration testing.
+
+
+
+
+
+
+ The CC philosophy asserts that greater assurance results from
+ the application of greater evaluation effort, and that the
+ goal is to apply the minimum effort required to provide the
+ necessary level of assurance. The increasing level of effort
+ is based upon:
+
+
+ scope -- that is, the effort is greater because a larger
+ portion of the IT product is included;
+
+
+ depth -- that is, the effort is greater because it is
+ deployed to a finer level of design and implementation
+ detail;
+
+
+ rigour -- that is, the effort is greater because it is
+ applied in a more structured, formal manner.
+
+
+
+
+
+
+ This annex provides an explanation of the criteria and examples of their application. This
+ annex does not define the criteria;
+ this definition can be found in CC Part 3 Section .
+
+ This annex consists of 2 major parts:
+
+
+ Guidance for completing an independent vulnerability
+ analysis. This is summarised in section , and described in more
+ detail in section
+ . These sections describe how an evaluator should approach
+ the construction of an independent Vulnerability Analysis.
+
+
+ How to characterise and use assumed Attack Potential of an
+ attacker. This is described in sections to . These sections provide an example of describe
+ how an attack potential can be characterised and should be
+ used, and provide examples.
+
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the existence and exploitability of flaws or
+ weaknesses in the TOE in the operational environment. This
+ determination is based upon analysis performed by the
+ evaluator, and is supported by evaluator testing.
+
+ At the lowest levels of the
+ evaluator simply performs a search of publicly available
+ information to identify any known weaknesses in the TOE, while
+ at the higher levels the evaluator performs a structured
+ analysis of the TOE evaluation evidence.
+
+ There are three main factors in performing a vulnerability
+ analysis, namely:
+
+ the identification of potential vulnerabilities;
+
+ assessment to determine whether the identified potential
+ vulnerabilities could allow an attacker with the relevant
+ attack potential to violate the SFRs.
+
+ penetration testing to determine whether the identified
+ potential vulnerabilities are exploitable in the operational
+ environment of the TOE.
+
+
+ The identification of vulnerabilities can be further
+ decomposed into the evidence to be searched and how hard to
+ search that evidence to identify potential vulnerabilities. In
+ a similar manner, the penetration testing can be further
+ decomposed into analysis of the potential vulnerability to
+ identify attack methods and the demonstration of the attack
+ methods.
+
+ These main factors are iterative in nature, i.e. penetration
+ testing of potential vulnerabilities may lead to the
+ identification of further potential vulnerabilities. Hence,
+ these are performed as a single vulnerability analysis
+ activity.
+
+
+
+ The evaluator vulnerability analysis is to determine that the
+ TOE is resistant to penetration attacks performed by an
+ attacker possessing a Basic (for and ),
+ Enhanced-Basic (for ),
+ Moderate (for ) or High (for
+ ) attack potential. The
+ evaluator first assesses the exploitability of all identified
+ potential vulnerabilities. This is accomplished by conducting
+ penetration testing. The evaluator should assume the role of
+ an attacker with a Basic (for
+ and ), Enhanced-Basic (for
+ ), Moderate (for ) or High (for ) attack potential when attempting to penetrate the
+ TOE.
+
+ The evaluator considers potential vulnerabilities encountered
+ by the evaluator during the conduct of other evaluation
+ activities. The evaluator penetration testing determining TOE
+ resistance to these potential vulnerabilities should be
+ performed assuming the role of an attacker with a Basic (for
+ and ), Enhanced-Basic (for ), Moderate (for )
+ or High (for ) attack
+ potential.
+
+ However, vulnerability analysis should not be performed as an
+ isolated activity. It is closely linked with and . The evaluator
+ performs these other evaluation activities with a focus on
+ identifying potential vulnerabilities or ``areas of
+ concern''. Therefore, evaluator familiarity with the generic
+ vulnerability guidance (provided in Section ) is required.
+
+
+ The following five categories provide discussion of generic
+ vulnerabilities.
+
+
+ Bypassing includes any means by which an attacker could
+ avoid security enforcement, by:
+
+
+ exploiting the capabilities of interfaces to the TOE,
+ or of utilities which can interact with the TOE;
+
+
+ inheriting privileges or other capabilities that
+ should otherwise be denied;
+
+
+ (where confidentiality is a concern) reading sensitive
+ data stored or copied to inadequately protected areas.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on exploiting the capabilities of
+ interfaces or utilities generally take advantage of
+ the absence of the required security enforcement on
+ those interfaces. For example, gaining access to
+ functionality that is implemented at a lower level
+ than that at which access control is
+ enforced. Relevant items include:
+
+
+ changing the predefined sequence of invocation of
+ TSFI;
+
+
+ invoking an additional TSFI;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using implementation detail introduced in less
+ abstract representations;
+
+
+ using the delay between time of access check and
+ time of use.
+
+
+
+
+ Changing the predefined sequence of invocation of
+ components should be considered where there is an
+ expected order in which interfaces to the TOE
+ (e.g. user commands) are called to invoke a TSFI
+ (e.g. opening a file for access and then reading data
+ from it). If a TSFI is invoked through one of the TOE
+ interfaces (e.g. an access control check), the
+ evaluator should consider whether it is possible to
+ bypass the control by performing the call at a later
+ point in the sequence or by missing it out altogether.
+
+
+ Executing an additional component (in the predefined
+ sequence) is a similar form of attack to the one
+ described above, but involves the calling of some
+ other TOE interface at some point in the sequence. It
+ can also involve attacks based on interception of
+ sensitive data passed over a network by use of network
+ traffic analysers (the additional component here being
+ the network traffic analyser).
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes using an unrelated TOE
+ interface to bypass the TSF by using it to achieve a
+ purpose that it was not designed or intended to
+ achieve. Covert channels are an example of this type
+ of attack (see for further discussion of covert
+ channels). The use of undocumented interfaces, which
+ may be insecure, also falls into this category. Such
+ interfaces may include undocumented support and help
+ facilities.
+
+
+ Using implementation detail introduced in lower
+ representations may allow an attacker to take
+ advantage of additional functions, resources or
+ attributes that are introduced to the TOE as a
+ consequence of the refinement process. Additional
+ functionality may include test harness code contained
+ in software modules and back-doors introduced during
+ the implementation process.
+
+
+ Using the delay between time of check and time of use
+ includes scenarios where an access control check is
+ made and access granted, and an attacker is
+ subsequently able to create conditions in which, had
+ they applied at the time the access check was made,
+ would have caused the check to fail. An example would
+ be a user creating a background process to read and
+ send highly sensitive data to the user's terminal, and
+ then logging out and logging back in again at a lower
+ sensitivity level. If the background process is not
+ terminated when the user logs off, the MAC checks
+ would have been effectively bypassed.
+
+
+ Attacks based on inheriting privileges are generally
+ based on illicitly acquiring the privileges or
+ capabilities of some privileged component, usually by
+ exiting from it in an uncontrolled or unexpected
+ manner. Relevant items include:
+
+
+ executing data not intended to be executable, or
+ making it executable;
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Executing data not intended to be executable, or
+ making it executable includes attacks involving
+ viruses (e.g. putting executable code or commands in a
+ file which are automatically executed when the file is
+ edited or accessed, thus inheriting any privileges the
+ owner of the file has).
+
+
+ Generating unexpected input for a component can have
+ unexpected effects which an attacker could take
+ advantage of. For example, if the TSF could be
+ bypassed if a user gains access to the underlying
+ operating system, it may be possible to gain such
+ access following the login sequence by exploring the
+ effect of hitting various control or escape sequences
+ whilst a password is being authenticated.
+
+
+ Invalidating assumptions and properties on which lower
+ level components rely includes attacks based on
+ breaking out of the constraints of an application to
+ gain access to an underlying operating system in order
+ to bypass the TSF of an application. In this case the
+ assumption being invalidated is that it is not
+ possible for a user of the application to gain such
+ access. A similar attack can be envisaged against an
+ application on an underlying database management
+ system: again the TSF could be bypassed if an attacker
+ can break out of the constraints of the application.
+
+
+ Attacks based on reading sensitive data stored in
+ inadequately protected areas (applicable where
+ confidentiality is a concern) include the following
+ issues which should be considered as possible means of
+ gaining access to sensitive data:
+
+
+ disk scavenging;
+
+
+ access to unprotected memory;
+
+
+ exploiting access to shared writable files or
+ other shared resources (e.g. swap files);
+
+
+ Activating error recovery to determine what access
+ users can obtain. For example, after a crash an
+ automatic file recovery system may employ a lost
+ and found directory for headerless files, which
+ are on disk without labels. If the TOE implements
+ mandatory access controls, it is important to
+ investigate at what security level this directory
+ is kept (e.g. at system high), and who has access
+ to this directory.
+
+
+
+
+
+ There are a number of different methods through which an
+ evaluator may identify a back-door, including two main
+ techniques. Firstly, by the evaluator inadvertently
+ identifying during testing an interface that can be
+ misused. Secondly, through testing each external
+ interface of the TSF in a debugging mode to identify any
+ modules that are not called as a part of testing the
+ documented interfaces and then inspecting the code that is
+ not called to consider whether it is a back-door.
+
+ For a software TOE where and or
+ higher components are included in the assurance package,
+ the evaluator may consider during their analysis of the
+ tools the libraries and packages that are linked by the
+ compiler at compilation stage to determine that back-doors
+ are not introduced at this stage.
+
+
+
+ Tampering includes any attack based on an attacker
+ attempting to influence the behaviour of the TSF
+ (i.e. corruption or de-activation), for example by:
+
+
+ accessing data on whose confidentiality or integrity
+ the TSF relies;
+
+
+ forcing the TOE to cope with unusual or unexpected
+ circumstances;
+
+
+ disabling or delaying security enforcement;
+
+
+ physical modification the TOE.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on accessing data, whose confidentiality
+ or integrity are protected, include:
+
+
+ reading, writing or modifying internal data
+ directly or indirectly;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using interfaces between components that are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Reading, writing or modifying internal data directly
+ or indirectly includes the following types of attack
+ which should be considered:
+
+
+ reading ``secrets'' stored internally, such as
+ user passwords;
+
+
+ spoofing internal data that security enforcing
+ mechanisms rely upon;
+
+
+ modifying environment variables (e.g. logical
+ names), or data in configuration files or
+ temporary files.
+
+
+
+ It may be possible to deceive a trusted process into
+ modifying a protected file that it wouldn't normally
+ access.
+
+
+ The evaluator should also consider the following
+ ``dangerous features'':
+
+
+ source code resident on the TOE along with a
+ compiler (for instance, it may be possible to
+ modify the login source code);
+
+
+ an interactive debugger and patch facility (for
+ instance, it may be possible to modify the
+ executable image);
+
+
+ the possibility of making changes at device
+ controller level, where file protection does not
+ exist;
+
+
+ diagnostic code which exists in the source code
+ and that may be optionally included;
+
+
+ developer's tools left in the TOE.
+
+
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes (for example), where the
+ TOE is an application built upon an operating system,
+ users exploiting knowledge of a word processor package
+ or other editor to modify their own command file
+ (e.g. to acquire greater privileges).
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction includes
+ attacks exploiting shared access to resources, where
+ modification of a resource by one component can
+ influence the behaviour of another (trusted)
+ component, e.g. at source code level, through the use
+ of global data or indirect mechanisms such as shared
+ memory or semaphores.
+
+
+ Attacks based on forcing the TOE to cope with unusual
+ or unexpected circumstances should always be
+ considered. Relevant items include:
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Generating unexpected input for a component includes
+ investigating the behaviour of the TOE when:
+
+
+ command input buffers overflow (possibly
+ ``crashing the stack'' or overwriting other
+ storage, which an attacker may be able to take
+ advantage of, or forcing a crash dump that may
+ contain sensitive information such as clear-text
+ passwords);
+
+
+ invalid commands or parameters are entered
+ (including supplying a read-only parameter to an
+ interface which expects to return data via that
+ parameter and supplying improperly formatted input
+ that should fail parsing such as SQL-injection,
+ format strings);
+
+
+ an end-of-file marker (e.g. CTRL-Z or CTRL-D) or
+ null character is inserted in an audit trail.
+
+
+
+
+ Invalidating assumptions and properties on which
+ lower-level components rely includes attacks taking
+ advantage of errors in the source code where the code
+ assumes (explicitly or implicitly) that security
+ relevant data is in a particular format or has a
+ particular range of values. In these cases the
+ evaluator should determine whether they can invalidate
+ such assumptions by causing the data to be in a
+ different format or to have different values, and if
+ so whether this could confer advantage to an attacker.
+
+
+ The correct behaviour of the TSF may be dependent on
+ assumptions that are invalidated under extreme
+ circumstances where resource limits are reached or
+ parameters reach their maximum value. The evaluator
+ should consider (where practical) the behaviour of the
+ TOE when these limits are reached, for example:
+
+
+ changing dates (e.g. examining how the TOE behaves
+ when a critical date threshold is passed);
+
+
+ filling disks;
+
+
+ exceeding the maximum number of users;
+
+
+ filling the audit log;
+
+
+ saturating security alarm queues at a console;
+
+
+ overloading various parts of a multi-user TOE
+ which relies heavily upon communications
+ components;
+
+
+ swamping a network, or individual hosts, with
+ traffic;
+
+
+ filling buffers or fields.
+
+
+
+
+ Attacks based on disabling or delaying security
+ enforcement include the following items:
+
+
+ using interrupts or scheduling functions to
+ disrupt sequencing;
+
+
+ disrupting concurrence;
+
+
+ using interfaces between components which are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Using interrupts or scheduling functions to disrupt
+ sequencing includes investigating the behaviour of the
+ TOE when:
+
+
+ a command is interrupted (with CTRL-C, CTRL-Y,
+ etc.);
+
+
+ a second interrupt is issued before the first is
+ acknowledged.
+
+
+
+
+ The effects of terminating security critical processes
+ (e.g. an audit daemon) should be explored. Similarly,
+ it may be possible to delay the logging of audit
+ records or the issuing or receipt of alarms such that
+ it is of no use to an administrator (since the attack
+ may already have succeeded).
+
+
+ Disrupting concurrence includes investigating the
+ behaviour of the TOE when two or more subjects attempt
+ simultaneous access. It may be that the TOE can cope
+ with the interlocking required when two subjects
+ attempt simultaneous access, but that the behaviour
+ becomes less well defined in the presence of further
+ subjects. For example, a critical security process
+ could be put into a resource-wait state if two other
+ processes are accessing a resource which it requires.
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction may provide a
+ means of delaying a time-critical trusted process.
+
+
+ Physical attacks can be categorised into physical
+ probing, physical manipulation, physical modification,
+ and substitution.
+
+
+ Physical probing by penetrating the TOE targeting
+ internals of the TOE, e.g. reading at internal
+ communication interfaces, lines or memories.
+
+
+ Physical manipulation can be with the TOE
+ internals aiming at internal modifications of the
+ TOE (e.g. by using optical fault induction as an
+ interaction process), at the external interfaces
+ of the TOE (e.g. by power or clock glitches) and
+ at the TOE environment (e.g. by modifying
+ temperature).
+
+
+ Physical modification of TOE internal security
+ enforcing attributes to inherit privileges or
+ other capabilities that should be denied in
+ regular operation. Such modifications can be
+ caused, e.g., by optical fault induction. Attacks
+ based on physical modification may also yield a
+ modification of the TSF itself, e.g. by causing
+ faults at TOE internal program data transfers
+ before execution. Note, that such kind of
+ bypassing by modifying the TSF itself can
+ jeopardise every TSF unless there are other
+ measures (possibly environmental measures) that
+ prevent an attacker from gaining physical access
+ to the TOE.
+
+
+ Physical substitution to replace the TOE with
+ another IT entity, during delivery or operation of
+ the TOE. Substitution during delivery of the TOE
+ from the development environment to the user
+ should be prevented through application of secure
+ delivery procedures (such as those considered
+ under ). Substitution of the TOE during
+ operation may be considered through a combination
+ of user guidance and the operational environment,
+ such that the user is able to be confident that
+ they are interacting with the TOE.
+
+
+
+
+
+
+
+ Direct attack includes the identification of any
+ penetration tests necessary to test the strength of
+ permutational or probabilistic mechanism and other
+ mechanisms to ensure they withstand direct attack.
+
+ For example, it may be a flawed assumption that a
+ particular implementation of a pseudo-random number
+ generator will possess the required entropy necessary to
+ seed the security mechanism.
+
+ Where a probabilistic or permutational mechanism relies on
+ selection of security attribute value (e.g. selection of
+ password length) or entry of data by a human user
+ (e.g. choice of password), the assumptions made should
+ reflect the worst case.
+
+ Probabilistic or permutational mechanisms should be
+ identified during examination of evaluation evidence
+ required as input to this sub-activity (security target,
+ functional specification, TOE design and implementation
+ representation subset) and any other TOE (e.g. guidance)
+ documentation may identify additional probabilistic or
+ permutational mechanisms.
+
+ Where the design evidence or guidance includes assertions
+ or assumptions (e.g. about how many authentication
+ attempts are possible per minute), the evaluator should
+ independently confirm that these are correct. This may be
+ achieved through testing or through independent
+ analysis.
+
+ Direct attacks reliant upon a weakness in a cryptographic
+ algorithm should not be considered under , as this is outside the scope
+ of the CC. Correctness of the implementation of the
+ cryptographic algorithm is considered during the and
+ activities.
+
+
+
+ Information is an abstract view on relation between the
+ properties of entities, i.e. a signal contains information
+ for a system, if the TOE is able to react to this
+ signal. The TOE resources processes and stores information
+ represented by user data. Therefore:
+
+
+ information may flow with the user data between
+ subjects by internal TOE transfer or export from the TOE;
+
+
+ information may be generated and passed to other user
+ data;
+
+
+ information may be gained through monitoring the
+ operations on data representing the information.
+
+
+
+ The information represented by user data may be
+ characterised by security attributes like ``classification
+ level'' having values, for example unclassified,
+ confidential, secret, top secret, to control operations to
+ the data. This information and therefore the security
+ attributes may be changed by operations e.g. may describe decrease of the
+ level by ``sanitarisation'' or increase of level by
+ combination of data. This is one aspects of an information
+ flow analysis focused on controlled operations of
+ controlled subjects on controlled objects.
+
+ The other aspect is the analysis of illicit
+ information flow. This aspect is more
+ general than the direct access to objects containing user
+ data addressed by the
+ family. An unenforced
+ signalling channel carrying information under control of
+ the information flow control policy can also be caused by
+ monitoring of the processing of any object containing or
+ related to this information (e.g. side channels). An
+ enforced signalling channels
+ may be identified in terms of the subjects manipulating
+ resources and the subject or user that observe such
+ manipulation. Classically, covert channels have been
+ identified as timing or storage channels, according to the
+ resource being modified or modulated. As for other
+ monitoring attacks, the use of the TOE is in accordance
+ with the SFRs.
+
+ Covert channels are normally applicable in the case when
+ the TOE has unobservability AND multi-level separation
+ policy requirements. Covert channels may be routinely
+ spotted during vulnerability analysis and design
+ activities, and should therefore be tested. However,
+ generally such monitoring attacks are only identified
+ through specialised analysis techniques commonly referred
+ to as ``covert channel analysis''. These techniques have
+ been the subject of much research and there are many
+ papers published on this subject. Guidance for the
+ conduct of covert channel analysis should be sought from
+ the evaluation authority.
+
+ Unenforced information flow monitoring
+ attacks include passive analysis techniques aiming at
+ disclosure of sensitive internal data of the TOE by
+ operating the TOE in the way that corresponds to the
+ guidance documents.
+
+ Side Channel Analysis includes crypt analytical techniques
+ based on physical leakage of the TOE. Physical leakage can
+ occur by timing information, power consumption or power
+ emanation during computation of a TSF. Timing information
+ can be collected also by a remote-attacker (having network
+ access to the TOE), power based information channels
+ requires that the attacker is in the near-by environment
+ of the TOE.
+
+ Eavesdropping techniques include interception of all forms
+ of energy, e.g., electromagnetic or optical emanation of
+ computer displays, not necessarily in the near-field of
+ the TOE.
+
+ Monitoring also includes exploits of protocol flaws, e.g.,
+ an attack on SSL implementation.
+
+
+
+ Misuse may arise from:
+
+
+ incomplete guidance documentation;
+
+
+ unreasonable guidance;
+
+
+ unintended misconfiguration of the TOE;
+
+
+ forced exception behaviour of the TOE.
+
+
+
+ If the guidance documentation is incomplete the user may
+ not know how to operate the TOE in accordance with the
+ SFRs. The evaluator should apply familiarity with the TOE
+ gained from performing other evaluation activities to
+ determine that the guidance is complete. In particular,
+ the evaluator should consider the functional
+ specification. The TSF described in this document should
+ be described in the guidance as required to permit secure
+ administration and use through the TSFI available to human
+ users. In addition, the different modes of operation
+ should be considered to ensure that guidance is provided
+ for all modes of operation.
+
+ The evaluator may, as an aid, prepare an informal mapping
+ between the guidance and these documents. Any omissions in
+ this mapping may indicate incompleteness.
+
+ The guidance is considered to be unreasonable if it makes
+ demands on the TOE's usage or operational environment that
+ are inconsistent with the ST or unduly onerous to maintain
+ security.
+
+ A TOE may use a variety of ways to assist the consumer in
+ effectively using that TOE in accordance with the SFRs and
+ prevent unintentional misconfiguration. A TOE may employ
+ functionality (features) to alert the consumer when the
+ TOE is in a state that is inconsistent with the SFRs,
+ whilst other TOEs may be delivered with enhanced guidance
+ containing suggestions, hints, procedures, etc. on using
+ the existing security features most effectively; for
+ instance, guidance on using the audit feature as an aid
+ for detecting when the SFRs are being compromised; namely
+ insecure.
+
+ The evaluator considers the TOE's functionality, its
+ purpose and security objectives for the operational
+ environment to arrive at a conclusion of whether or not
+ there is reasonable expectation that use of the guidance
+ would permit transition into an insecure state to be
+ detected in a timely manner.
+
+ The potential for the TOE to enter into insecure states
+ may be determined using the evaluation deliverables, such
+ as the ST, the functional specification and any other
+ design representations provided as evidence for components
+ included in the assurance package for the TOE (e.g. the
+ TOE/TSF design specification if a component from is included).
+
+ Instances of forced exception behaviour of the TSF could
+ include, but are not limited to, the following:
+
+
+ behaviour of the TOE when start-up, close-down or error
+ recovery is activated;
+
+
+ behaviour of the TOE under extreme circumstances
+ (sometimes termed overload or asymptotic behaviour),
+ particularly where this could lead to the
+ de-activation or disabling of parts of the TSF;
+
+
+ any potential for unintentional misconfiguration or
+ insecure use arising from attacks noted in the section
+ on tampering above.
+
+
+
+
+
+
+ Potential vulnerabilities may be identified by the evaluator
+ during different activities. They may become apparent during
+ an evaluation activity or they may be identified as a result
+ of analysis of evidence to search for
+ vulnerabilities.
+
+
+ The encountered identification of vulnerabilities is where
+ potential vulnerabilities are identified by the evaluator
+ during the conduct of evaluation activities, i.e. the
+ evidence are not being analysed with the express aim of
+ identifying potential vulnerabilities.
+
+ The encountered method of identification is dependent on the
+ evaluator's experience and knowledge; which is monitored and
+ controlled by the evaluation authority. It is not reproducible
+ in approach, but will be documented to ensure repeatability of
+ the conclusions from the reported potential
+ vulnerabilities.
+
+ There are no formal analysis criteria required for this
+ method. Potential vulnerabilities are identified from the
+ evidence provided as a result of knowledge and
+ experience. However, this method of identification is not
+ constrained to any particular subset of evidence.
+
+ Evaluator is assumed to have knowledge of the TOE-type
+ technology and known security flaws as documented in the
+ public domain. The level of knowledge assumed is that
+ which can be gained from a security e-mail list relevant
+ to the TOE type, the regular bulletins (bug, vulnerability
+ and security flaw lists) published by those organisations
+ researching security issues in products and technologies
+ in widespread use. This knowledge is not expected to
+ extend to specific conference proceedings or detailed
+ theses produced by university research for or . However, to ensure the knowledge applied is
+ up to date, the evaluator may need to perform a search of
+ public domain material.
+
+ For to the search of publicly
+ available information is expected to include conference
+ proceeding and theses produced during research activities
+ by universities and other relevant organisations.
+
+ Examples of how these may arise (how the evaluator may
+ encounter potential vulnerabilities):
+
+
+ while the evaluator is examining some evidence, it
+ sparks a memory of a potential vulnerability
+ identified in a similar product type, that the
+ evaluator believes to also be present in the TOE under
+ evaluation;
+
+
+ while examining some evidence, the evaluator spots a
+ flaw in the specification of an interface, that
+ reflects a potential vulnerability.
+
+
+ This may include becoming aware of a potential
+ vulnerability in a TOE through reading about generic
+ vulnerabilities in a particular product type in an IT
+ security publication or on a security e-mail list to which
+ the evaluator is subscribed.
+
+ Attack methods can be developed directly from these
+ potential vulnerabilities. Therefore, the encountered
+ potential vulnerabilities are collated at the time of
+ producing penetration tests based on the evaluator's
+ vulnerability analysis. There is no explicit action for
+ the evaluator to encounter potential
+ vulnerabilities. Therefore, the evaluator is directed
+ through an implicit action specified in and .*.4E.
+
+ Current information regarding public domain
+ vulnerabilities and attacks may be provided to the
+ evaluator by, for example, an evaluation authority. This
+ information is to be taken into account by the evaluator
+ when collating encountered vulnerabilities and attack
+ methods when developing penetration tests.
+
+
+
+ The following types of analysis are presented in terms of
+ the evaluator actions.
+
+
+ The unstructured analysis to be performed by the
+ evaluator (for )
+ permits the evaluator to consider the generic
+ vulnerabilities (as discussed in ). The evaluator will also apply their
+ experience and knowledge of flaws in similar technology
+ types.
+
+
+
+ During the conduct of evaluation activities the
+ evaluator may also identify areas of concern. These are
+ specific portions of the TOE evidence that the evaluator
+ has some reservation about, although the evidence meets
+ the requirements for the activity with which the
+ evidence is associated. For example, a particular
+ interface specification looks particularly complex, and
+ therefore may be prone to error either in the
+ development of the TOE or in the operation of the
+ TOE. There is no potential vulnerability apparent at
+ this stage, further investigation is required. This is
+ beyond the bounds of encountered, as further
+ investigation is required.
+
+ Difference between potential vulnerability and area of
+ concern:
+
+
+ Potential vulnerability - The evaluator knows a
+ method of attack that can be used to exploit the
+ weakness or the evaluator knows of vulnerability
+ information that is relevant to the TOE.
+
+
+ Area of concern - The evaluator may be able to
+ discount concern as a potential vulnerability based
+ on information provided elsewhere. While reading
+ interface specification, the evaluator identifies
+ that due to the extreme (unnecessary) complexity of
+ an interface a potential vulnerability may lay
+ within that area, although it is not apparent
+ through this initial examination.
+
+
+ The focused approach to the identification of
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. This
+ approach to the identification of potential
+ vulnerabilities can be used during the independent
+ vulnerability analysis required by .
+
+ This analysis can be achieved through different
+ approaches, that will lead to commensurate levels of
+ confidence. None of the approaches have a rigid format
+ for the examination of evidence to be performed.
+
+ The approach taken is directed by the results of the
+ evaluator's assessment of the evidence to determine it
+ meets the requirements of the /
+ sub-activities. Therefore, the investigation of the
+ evidence for the existence of potential vulnerabilities
+ may be directed by any of the following:
+
+
+ areas of concern identified during examination of
+ the evidence during the conduct of evaluation
+ activities;
+
+
+ reliance on particular functionality to provide
+ separation, identified during the analysis of the
+ architectural design (as in ), requiring further analysis to
+ determine it cannot be bypassed;
+
+
+ representative examination of the evidence to
+ hypothesise potential vulnerabilities in the
+ TOE.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, the evaluator may not be able to
+ describe the steps in identifying potential
+ vulnerabilities before the outset of the
+ examination. The approach will evolve as a result of the
+ outcome of evaluation activities.
+
+ The areas of concern may arise from examination of any
+ of the evidence provided to satisfy the SARs specified
+ for the TOE evaluation. The information publicly
+ accessible is also considered.
+
+ The activities performed by the evaluator can be
+ repeated and the same conclusions, in terms of the level
+ of assurance in the TOE, can be reached although the
+ steps taken to achieve those conclusions may vary. As
+ the evaluator is documenting the form the analysis took,
+ the actual steps taken to achieve those conclusions are
+ also reproducible.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the
+ focused identification method). The method is specified
+ in terms of the information that will be considered and
+ how/why it will be considered. This approach to the
+ identification of potential vulnerabilities can be used
+ during the independent vulnerability analysis required
+ by and .
+
+ This analysis of the evidence is deliberate and
+ pre-planned in approach, considering all evidence
+ identified as an input into the analysis.
+
+ All evidence provided to satisfy the () assurance requirements specified in the
+ assurance package are used as input to the potential
+ vulnerability identification activity.
+
+ The ``methodical'' descriptor for this analysis has been
+ used in an attempt to capture the characterisation that
+ this identification of potential vulnerabilities is to
+ take an ordered and planned approach. A ``method'' or
+ ``system'' is to be applied in the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered; and the
+ hypothesis that is to be generated.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a security mechanism, such as domain
+ separation, hypothesising internal buffer overflows
+ leading to degradation of separation;
+
+
+ analysis to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine the SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the analysis that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be analysed to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ This identification method will provide a plan of attack
+ of the TOE, that would be performed by an evaluator
+ completing penetration testing of potential
+ vulnerabilities in the TOE. The rationale for the method
+ of identification would provide the evidence for the
+ coverage and depth of exploitation determination that
+ would be performed on the TOE.
+
+
+
+
+
+
+
+ Attack potential is used by a PP/ST author during the
+ development of the PP/ST, in consideration of the threat
+ environment and the selection of assurance components. This
+ may simply be a determination that the attack potential
+ possessed by the assumed attackers of the TOE is generically
+ characterised as Basic, Enhanced-Basic, Moderate or
+ High. Alternatively, the PP/ST may wish to specify
+ particular levels of individual factors assumed to be
+ possessed by attackers. (e.g. the attackers are assumed to
+ be experts in the TOE technology type, with access to
+ specialised equipment.)
+
+ The PP/ST author considers the threat profile developed during a
+ risk assessment (outside the scope of the CC, but used as an
+ input into the development of the PP/ST in terms of the Security
+ Problem Definition or in the case of low assurance STs, the
+ requirements statement). Consideration of this threat profile in
+ terms of one of the approaches discussed in the following
+ sections will permit the specification of the attack potential
+ the TOE is to resist.
+
+
+
+ Attack potential is especially considered by the evaluator
+ in two distinct ways during the ST evaluation and the
+ vulnerability assessment activities.
+
+ Attack potential is used by an evaluator during the conduct
+ of the vulnerability analysis sub-activity to determine
+ whether or not the TOE is resistant to attacks assuming a
+ specific attack potential of an attacker. If the evaluator
+ determines that a potential vulnerability is exploitable in
+ the TOE, they have to confirm that it is exploitable
+ considering all aspects of the intended environment,
+ including the attack potential assumed by an
+ attacker.
+
+ Therefore, using the information provided in the threat
+ statement of the Security Target, the evaluator determines
+ the minimum attack potential required by an attacker to
+ effect an attack, and arrives at some conclusion about the
+ TOE's resistance to attacks. Table demonstrates the relationship between this
+ analysis and attack potential.
+
+
+
+
+ Vulnerability Component
+ TOE resistant to attacker with
+ attack potential of:
+ Residual vulnerabilities only
+ exploitable by attacker with attack potential
+ of:
+
+
+
+
+ VAN.5
+ High
+ Beyond High
+
+
+ VAN.4
+ Moderate
+ High
+
+
+ VAN.3
+ Enhanced-Basic
+ Moderate
+
+
+ VAN.2
+ Basic
+ Enhanced-Basic
+
+
+ VAN.1
+ Basic
+ Enhanced-Basic
+
+
+
+ Vulnerability testing and attack potential
+
+
+ The ``beyond high'' entry in the residual vulnerabilities
+ column of the above table represents those potential
+ vulnerabilities that would require an attacker to have an
+ attack potential greater than that of ``high'' in order to
+ exploit the potential vulnerability. A vulnerability
+ classified as residual in this instance reflects the fact
+ that a known weakness exists in the TOE, but in the current
+ operational environment, with the assumed attack potential,
+ the weakness cannot be exploited.
+
+ At any level of attack potential a potential vulnerability
+ may be deemed ``infeasible'' due to a countermeasure in the
+ operational environment that prevents the vulnerability from
+ being exploited.
+
+ A vulnerability analysis applies to all TSFI, including ones
+ that access probabilistic or permutational mechanisms. No
+ assumptions are made regarding the correctness of the design
+ and implementation of the TSFI; nor are constraints placed
+ on the attack method or the attacker's interaction with the
+ TOE - if an attack is possible, then it is to be considered
+ during the vulnerability analysis. As shown in Table , successful evaluation
+ against a vulnerability assurance component reflects that
+ the TSF is designed and implemented to protect against the
+ required level of threat.
+
+ It is not necessary for an evaluator to perform an attack
+ potential calculation for each potential vulnerability. In
+ some cases it is apparent when developing the attack method
+ whether or not the attack potential required to develop and
+ run the attack method is commensurate with that assumed of
+ the attacker in the operational environment. For any
+ vulnerabilities for which an exploitation is determined, the
+ evaluator performs an attack potential calculation to
+ determine that the exploitation is appropriate to the level
+ of attack potential assumed for the attacker.
+
+ The approach described below is to be applied whenever it is
+ necessary to calculate attack potential, unless the evaluation
+ authority provides mandatory guidance that an alternative
+ approach is to be applied. The values given in Tables and
+ below are not mathematically proven. Therefore, the values given
+ in these example tables may need to be adjusted according to the
+ technology type and specific environments. The evaluator should
+ seek guidance from the evaluation authority.
+
+
+
+
+
+ Attack potential is a function of expertise, resources and
+ motivation. There are multiple methods of representing and
+ quantifying these factors. Also, there may be other factors
+ that are applicable for particular TOE types.
+
+
+ Motivation is an attack potential factor that can be used
+ to describe several aspects related to the attacker and
+ the assets the attacker desires. Firstly, motivation can
+ imply the likelihood of an attack - one can infer from a
+ threat described as highly motivated that an attack is
+ imminent, or that no attack is anticipated from an
+ un-motivated threat. However, except for the two extreme
+ levels of motivation, it is difficult to derive a
+ probability of an attack occurring from motivation.
+
+ Secondly, motivation can imply the value of the asset,
+ monetarily or otherwise, to either the attacker or the
+ asset holder. An asset of very high value is more likely
+ to motivate an attack compared to an asset of little
+ value. However, other than in a very general way, it is
+ difficult to relate asset value to motivation because the
+ value of an asset is subjective - it depends largely upon
+ the value an asset holder places on it.
+
+ Thirdly, motivation can imply the expertise and resources
+ with which an attacker is willing to effect an attack. One
+ can infer that a highly motivated attacker is likely to
+ acquire sufficient expertise and resources to defeat the
+ measures protecting an asset. Conversely, one can infer
+ that an attacker with significant expertise and resources
+ is not willing to effect an attack using them if the
+ attacker's motivation is low.
+
+ During the course of preparing for and conducting an
+ evaluation, all three aspects of motivation are at some
+ point considered. The first aspect, likelihood of attack,
+ is what may inspire a developer to pursue an
+ evaluation. If the developer believes that the attackers
+ are sufficiently motivated to mount an attack, then an
+ evaluation can provide assurance of the ability of the TOE
+ to thwart the attacker's efforts. Where the operational
+ environment is well defined, for example in a system
+ evaluation, the level of motivation for an attack may be
+ known, and will influence the selection of
+ countermeasures.
+
+ Considering the second aspect, an asset holder may believe
+ that the value of the assets (however measured) is
+ sufficient to motivate attack against them. Once an
+ evaluation is deemed necessary, the attacker's motivation
+ is considered to determine the methods of attack that may
+ be attempted, as well as the expertise and resources used
+ in those attacks. Once examined, the developer is able to
+ choose the appropriate assurance level, in particular the
+ requirement components,
+ commensurate with the attack potential for the
+ threats. During the course of the evaluation, and in
+ particular as a result of completing the vulnerability
+ assessment activity, the evaluator determines whether or
+ not the TOE, operating in its operational environment, is
+ sufficient to thwart attackers with the identified
+ expertise and resources.
+
+ It may be possible for a PP author to quantify the
+ motivation of an attacker, as the PP author has greater
+ knowledge of the operational environment in which the TOE
+ (conforming to the requirements of the PP) is to be
+ placed. Therefore, the motivation could form an explicit
+ part of the expression of the attack potential in the PP,
+ along with the necessary methods and measures to quantify
+ the motivation.
+
+
+
+
+ This section examines the factors that determine attack
+ potential, and provides some guidelines to help remove some
+ of the subjectivity from this aspect of the evaluation
+ process.
+
+
+ The determination of the attack potential for an attack
+ corresponds to the identification of the effort required to
+ create the attack, and to demonstrate that it can be
+ successfully applied to the TOE (including setting up or
+ building any necessary test equipment), thereby exploiting the
+ vulnerability in the TOE. The demonstration that the attack can
+ be successfully applied needs to consider any difficulties in
+ expanding a result shown in the laboratory to create a useful
+ attack. For example, where an experiment reveals some bits or
+ bytes of a confidential data item (such as a key), it is
+ necessary to consider how the remainder of the data item would
+ be obtained (in this example some bits might be measured
+ directly by further experiments, while others might be found by
+ a different technique such as exhaustive search). It may not be
+ necessary to carry out all of the experiments to identify the
+ full attack, provided it is clear that the attack actually
+ proves that access has been gained to a TOE asset, and that the
+ complete attack could realistically be carried out in
+ exploitation according to the
+ component targeted. In some cases the only way to prove that an
+ attack can realistically be carried out in exploitation
+ according to the component
+ targeted is to perform completely the attack and
+ then rate it based upon the resources actually required.
+ One of the outputs from the identification of a potential
+ vulnerability is assumed to be a script that gives a
+ step-by-step description of how to carry out the attack that can
+ be used in the exploitation of the vulnerability on another
+ instance of the TOE.
+
+ In many cases, the evaluators will estimate the parameters
+ for exploitation, rather than carry out the full
+ exploitation. The estimates and their rationale will be
+ documented in the ETR.
+
+
+
+ The following factors should be considered during analysis
+ of the attack potential required to exploit a
+ vulnerability:
+
+
+ Time taken to identify and exploit (
+ Elapsed Time);
+
+
+ Specialist technical expertise required (
+ Specialist Expertise);
+
+
+ Knowledge of the TOE design and operation (
+ Knowledge of the TOE);
+
+
+
+ Window of opportunity;
+
+
+
+ IT hardware/software or other
+ equipment required for
+ exploitation.
+
+
+
+ In many cases these factors are not independent, but may be
+ substituted for each other in varying degrees. For example,
+ expertise or hardware/software may be a substitute for time. A
+ discussion of these factors follows. (The levels of each factor
+ are discussed in increasing order of magnitude.) When it is the
+ case, the less ``expensive'' combination is considered in the
+ exploitation phase.
+ Elapsed time is the total amount
+ of time taken by an attacker to identify that a particular
+ potential vulnerability may exist in the TOE, to develop an
+ attack method and to sustain effort required to mount the attack
+ against the TOE. When considering this factor, the worst case
+ scenario is used to estimate the amount of time required. The
+ identified amount of time is as follows:
+ less than one day;between one day and one week;between one week and two weeks;between two weeks and one month;each additional month up to 6 months leads to an
+ increased value;more than 6 months.
+
+ Specialist expertise refers
+ to the level of generic knowledge of the underlying
+ principles, product type or attack methods (e.g. Internet
+ protocols, Unix operating systems, buffer overflows). The
+ identified levels are as follows:
+
+
+ Laymen are unknowledgeable compared to experts or
+ proficient persons, with no particular expertise;
+
+
+ Proficient persons are knowledgeable in that they are
+ familiar with the security behaviour of the product or
+ system type;
+
+
+ Experts are familiar with the underlying algorithms,
+ protocols, hardware, structures, security behaviour,
+ principles and concepts of security employed,
+ techniques and tools for the definition of new
+ attacks, cryptography, classical attacks for the
+ product type, attack methods, etc. implemented in the
+ product or system type.
+
+
+ The level ``Multiple Expert'' is introduced to allow for
+ a situation, where different fields of expertise are
+ required at an Expert level for distinct steps of an
+ attack.
+
+ It may occur that several types of expertise are
+ required. By default, the higher of the different
+ expertises factors is chosen. In very specific cases, the
+ ``multiple expert'' level could be used but it should be
+ noted that the expertise must concern fields that are
+ strictly different like for example HW manipulation and
+ cryptography.
+
+
+ Knowledge of the TOE refers to
+ specific expertise in relation to the TOE. This is
+ distinct from generic expertise, but not unrelated to
+ it. Identified levels are as follows:
+
+
+ Public information concerning the TOE (e.g. as gained
+ from the Internet);
+
+
+ Restricted information concerning the TOE
+ (e.g. knowledge that is controlled within the
+ developer organisation and shared with other
+ organisations under a non-disclosure agreement)
+
+
+ Sensitive information about the TOE (e.g. knowledge
+ that is shared between discreet teams within the
+ developer organisation, access to which is constrained
+ only to members of the specified teams);
+
+
+ Critical information about the TOE (e.g. knowledge
+ that is known by only a few individuals, access to
+ which is very tightly controlled on a strict need to
+ know basis and individual undertaking).
+
+
+
+ The knowledge of the TOE may graduate according to design
+ abstraction, although this can only be done on a TOE by
+ TOE basis. Some TOE designs may be public source (or
+ heavily based on public source) and therefore even the
+ design representation would be classified as public or at
+ most restricted, while the implementation representation
+ for other TOEs is very closely controlled as it would give
+ an attacker information that would aid an attack and is
+ therefore considered to be sensitive or even
+ critical.
+
+ It may occur that several types of knowledge are
+ required. In such cases, the higher of the different
+ knowledge factors is chosen.
+
+
+ Window of opportunity
+
+ (Opportunity) is also an important consideration, and has
+ a relationship to the Elapsed Time
+ factor. Identification or exploitation of a
+ vulnerability may require considerable amounts of access
+ to a TOE that may increase the likelihood of
+ detection. Some attack methods may require considerable
+ effort off-line, and only brief access to the TOE to
+ exploit. Access may also need to be continuous, or over a
+ number of sessions.
+
+ For some TOEs the Window of
+ opportunity may equate to the number of
+ samples of the TOE that the attacker can obtain. This is
+ particularly relevant where attempts to penetrate the
+ TOE and undermine the SFRs may result in the destruction
+ of the TOE preventing use of that TOE sample for further
+ testing, e.g. hardware devices. Often in these cases
+ distribution of the TOE is controlled and so the
+ attacker must apply effort to obtain further samples of
+ the TOE.
+
+ For the purposes of this discussion:
+
+
+ unnecessary/unlimited access means that the attack
+ doesn't need any kind of opportunity to be realised
+ because there is no risk of being detected during
+ access to the TOE and it is no problem to access the
+ number of TOE samples for the attack;
+
+ easy means that access is required for less than a day
+ and that the number of TOE samples required to perform
+ the attack is less than ten;
+
+ moderate means that access is required for less than a
+ month and that the number of TOE samples required to
+ perform the attack is less than one hundred;
+
+ difficult means that access is required for at least a
+ month or that the number of TOE samples required to
+ perform the attack is at least one hundred;
+
+ none means that the opportunity window is not
+ sufficient to perform the attack (the length for which
+ the asset to be exploited is available or is sensitive
+ is less than the opportunity length needed to perform
+ the attack - for example, if the asset key is changed
+ each week and the attack needs two weeks); another
+ case is, that a sufficient number of TOE samples
+ needed to perform the attack is not accessible to the
+ attacker - for example if the TOE is a hardware and
+ the probability to destroy the TOE during the attack
+ instead of being successful is very high and the
+ attacker has only access to one sample of the
+ TOE.
+
+ Consideration of this factor may result in determining
+ that it is not possible to complete the exploit, due to
+ requirements for time availability that are greater than
+ the opportunity time.
+
+
+ IT hardware/software or other equipment
+ refers to the equipment required to identify
+ or exploit a vulnerability.
+
+
+ Standard equipment is readily available to the
+ attacker, either for the identification of a
+ vulnerability or for an attack. This equipment may be
+ a part of the TOE itself (e.g. a debugger in an
+ operating system), or can be readily obtained
+ (e.g. Internet downloads, protocol analyser or simple
+ attack scripts).
+
+
+ Specialised equipment is not readily available to the attacker,
+ but could be acquired without undue effort. This could include
+ purchase of moderate amounts of equipment (e.g. power analysis
+ tools, use of hundreds of PCs linked across the Internet would
+ fall into this category), or development of more extensive
+ attack scripts or programs. If clearly different test benches
+ consisting of specialised equipment are required for distinct
+ steps of an attack this would be rated as bespoke.
+
+
+ Bespoke equipment is not readily available to the
+ public as it may need to be specially produced
+ (e.g. very sophisticated software), or because the
+ equipment is so specialised that its distribution is
+ controlled, possibly even restricted. Alternatively,
+ the equipment may be very expensive.
+
+ The level ``Multiple Bespoke'' is introduced to allow
+ for a situation, where different types of bespoke
+ equipment are required for distinct steps of an
+ attack.
+
+ Specialist expertise and Knowledge of the
+ TOE are concerned with the information
+ required for persons to be able to attack a TOE. There
+ is an implicit relationship between an attacker's
+ expertise (where the attacker may be one or more persons
+ with complementary areas of knowledge) and the ability
+ to effectively make use of equipment in an attack. The
+ weaker the attacker's expertise, the lower the potential
+ to use equipment (IT hardware/software or other
+ equipment). Likewise, the greater the expertise, the
+ greater the potential for equipment to be used in the
+ attack. Although implicit, this relationship between
+ expertise and the use of equipment does not always
+ apply, for instance, when environmental measures prevent
+ an expert attacker's use of equipment, or when, through
+ the efforts of others, attack tools requiring little
+ expertise to be effectively used are created and freely
+ distributed (e.g. via the Internet).
+
+
+
+ Table identifies the
+ factors discussed in the previous section and associates
+ numeric values with the total value of each factor.
+
+ Where a factor falls close to the boundary of a range the
+ evaluator should consider use of an intermediate value to those
+ in the table. For example, if twenty samples are required to
+ perform the attack then a value between one and four may be
+ selected for that factor, or if the design is based on a
+ publicly available design but the developer has made some
+ alterations then a value between zero and three should be
+ selected according to the evaluator's view of the impact of
+ those design changes. The table is intended as a guide.
+
+ The ``**'' specification in the table in considering
+ Window of Opportunity is not
+ to be seen as a natural progression from the timescales
+ specified in the preceding ranges associated with this
+ factor. This specification identifies that for a
+ particular reason the potential vulnerability cannot be
+ exploited in the TOE in its intended operational
+ environment. For example, access to the TOE may be
+ detected after a certain amount of time in a TOE with a
+ known environment (i.e. in the case of a system) where
+ regular patrols are completed, and the attacker could not
+ gain access to the TOE for the required two weeks
+ undetected. However, this would not be applicable to a TOE
+ connected to the network where remote access is possible,
+ or where the physical environment of the TOE is
+ unknown.
+
+
+
+
+
+ Factor
+
+
+ Value
+
+
+
+
+
+
+ Elapsed Time
+
+
+
+
+
+ <= one day
+
+ 0
+
+
+
+ <= one week
+
+ 1
+
+
+
+ <= two weeks
+
+ 2
+
+
+
+ <= one month
+
+ 4
+
+
+
+ <= two months
+
+ 7
+
+
+
+ <= three months
+
+ 10
+
+
+
+ <= four months
+
+ 13
+
+
+
+ <= five months
+
+ 15
+
+
+
+ <= six months
+
+ 17
+
+
+
+ > six months
+
+ 19
+
+
+
+ Expertise
+
+
+
+
+
+ Layman
+
+ 0
+
+
+
+ Proficient
+
+
+ 3*When several proficient persons are
+ required to complete the attack path, the
+ resulting level of expertise still remains
+ ``proficient'' (which leads to a 3
+ rating).
+
+
+
+ Expert
+
+ 6
+
+
+
+ Multiple experts
+
+ 8
+
+
+
+ Knowledge of TOE
+
+
+
+
+
+ Public
+
+ 0
+
+
+
+ Restricted
+
+ 3
+
+
+
+ Sensitive
+
+ 7
+
+
+
+ Critical
+
+ 11
+
+
+
+ Window of Opportunity
+
+
+
+
+
+ Unnecessary / unlimited access
+
+ 0
+
+
+
+ Easy
+
+ 1
+
+
+
+ Moderate
+
+ 4
+
+
+
+ Difficult
+
+ 10
+
+
+
+ None
+
+
+ **Indicates that the attack path is not
+ exploitable due to other measures in the
+ intended operational environment of the
+ TOE.
+
+
+
+
+ Equipment
+
+
+
+
+
+ Standard
+
+ 0
+
+
+
+ Specialised
+
+ 4If clearly different test benches
+ consisting of specialised equipment are required
+ for distinct steps of an attack, this should be
+ rated as bespoke.
+
+
+
+ Bespoke
+
+ 7
+
+
+
+ Multiple bespoke
+
+ 9
+
+
+
+
+ Calculation of attack potential
+
+
+ To determine the resistance of the TOE to the potential
+ vulnerabilities identified the following steps should be
+ applied:
+
+
+ Define the possible attack scenarios {AS1, AS2, ...,
+ ASn} for the TOE in the operational
+ environment.
+
+ For each attack scenario, perform a theoretical
+ analysis and calculate the relevant attack potential
+ using Table .
+
+ For each attack scenario, if necessary, perform
+ penetration tests in order to confirm or to disprove
+ the theoretical analysis.
+
+ Divide all attack scenarios {AS1, AS2, ..., ASn} into
+ two groups:
+
+
+ the attack scenarios having been successful
+ (i.e. those that have been used to successfully
+ undermine the SFRs), and
+
+ the attack scenarios that have been demonstrated
+ to be unsuccessful.
+
+
+
+ For each successful attack scenario, apply Table and determine, whether
+ there is a contradiction between the resistance of the
+ TOE and the chosen
+ assurance component, see the last column of Table .
+
+ Should one contradiction be found, the vulnerability
+ assessment will fail, e.g. the author of the ST chose
+ the component and an
+ attack scenario with an attack potential of 21 points
+ (high) has broken the security of the TOE. In this
+ case the TOE is resistant to attacker with attack
+ potential 'Moderate', this contradicts to , hence, the vulnerability
+ assessment fails.
+
+ The ``Values'' column of Table indicates the range of attack potential values
+ (calculated using Table ) of an
+ attack scenario that results in the SFRs being
+ undermined.
+
+
+ An approach such as this cannot take account of every
+ circumstance or factor, but should give a better
+ indication of the level of resistance to attack required
+ to achieve the standard ratings. Other factors, such as
+ the reliance on unlikely chance occurrences are not
+ included in the basic model, but can be used by an
+ evaluator as justification for a rating other than those
+ that the basic model might indicate.
+
+ It should be noted that whereas a number of
+ vulnerabilities rated individually may indicate high
+ resistance to attack, collectively the combination of
+ vulnerabilities may indicate that overall a lower rating
+ is applicable. The presence of one vulnerability may make
+ another easier to exploit.
+
+ If a PP/ST author wants to use the attack potential table for
+ the determination of the level of attack the TOE should
+ withstand (selection of Vulnerability analysis () component), he should proceed as
+ follows: For all different attack scenarios (i.e. for all
+ different types of attacker and/or different types of attack the
+ author has in mind) which must not violate the SFRs, several
+ passes through Table should be
+ made to determine the different values of attack potential
+ assumed for each such unsuccessful attack scenario. The PP/ST
+ author then chooses the highest value of them in order to
+ determine the level of the TOE resistance to be claimed from
+ Table : the TOE resistance must
+ be at least equal to this highest value determined. For
+ example, the highest value of attack potentials of all attack
+ scenarios, which must not undermine the TOE security policy,
+ determined in such a way is Moderate; hence, the TOE resistance
+ shall be at least Moderate (i.e. Moderate or High); therefore,
+ the PP/ST author can choose either (for Moderate) or
+ (for High) as the appropriate assurance component.
+
+
+
+
+
+
+
+ Mechanisms subject to direct attack are often vital for system
+ security and developers often strengthen these mechanisms. As
+ an example, a TOE might use a simple pass number
+ authentication mechanism that can be overcome by an attacker
+ who has the opportunity to repeatedly guess another user's
+ pass number. The system can strengthen this mechanism by
+ restricting pass numbers and their use in various ways. During
+ the course of the evaluation an analysis of this direct attack
+ could proceed as follows:
+
+ Information gleaned from the ST and design evidence reveals
+ that identification and authentication provides the basis upon
+ which to control access to network resources from widely
+ distributed terminals. Physical access to the terminals is not
+ controlled by any effective means. The duration of access to a
+ terminal is not controlled by any effective means. Authorised
+ users of the system choose their own pass numbers when
+ initially authorised to use the system, and thereafter upon
+ user request. The system places the following restrictions on
+ the pass numbers selected by the user:
+
+
+ the pass number must be at least four and no greater than
+ six digits long;
+
+
+ consecutive numerical sequences are disallowed (such as
+ 7,6,5,4,3);
+
+
+ repeating digits is disallowed (each digit must be
+ unique).
+
+
+
+ Guidance provided to the users at the time of pass number
+ selection is that pass numbers should be as random as possible
+ and should not be affiliated with the user in some way - a
+ date of birth, for instance.
+
+ The pass number space is calculated as follows:
+
+
+ Patterns of human usage are important considerations that
+ can influence the approach to searching a password
+ space. Assuming the worst case scenario and the user
+ chooses a number comprising only four digits, the number
+ of pass number permutations assuming that each digit must
+ be unique is:
+
+
+ The number of possible increasing sequences is seven, as
+ is the number of decreasing sequences. The pass number
+ space after disallowing sequences is:
+
+
+
+ Based on further information gleaned from the design evidence,
+ the pass number mechanism is designed with a terminal locking
+ feature. Upon the sixth failed authentication attempt the
+ terminal is locked for one hour. The failed authentication
+ count is reset after five minutes so that an attacker can at
+ best attempt five pass number entries every five minutes, or
+ 60 pass number entries every hour.
+
+ On average, an attacker would have to enter 2513 pass numbers,
+ over 2513 minutes, before entering the correct pass number. The
+ average successful attack would, as a result, occur in slightly
+ less than:
+
+ Using the approach to calculate the attack potential, described
+ in the previous section, identifies that it is possible that a
+ layman can defeat the mechanism within days (given easy access
+ to the TOE), with the use of standard equipment, and with no
+ knowledge of the TOE, giving a value of 1. Given the resulting
+ sum, 1, the attack potential required to effect a successful
+ attack is not rated, as it falls below that considered to be
+ Basic.
+
+
+
+
+ Table describes the
+ relationship between the composition assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Composed Assurance Packages (CAPs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance for
+ composed TOEs.
+
+ It is important to note that there are only a small number of
+ families and components from CC Part 3 included in the
+ CAPs. This is due to their nature of building upon evaluation
+ results of previously evaluated entities (base components and
+ dependent components), and is not to say that these do not
+ provide meaningful and desirable assurances.
+
+
+ CAPs are to be applied to composed TOEs, which are comprised
+ of components that have been (are going through) component TOE
+ evaluation (see ). The
+ individual components will have been certified to an EAL or
+ another assurance package specified in the ST. It is expected
+ that a basic level of assurance in a composed TOE will be
+ gained through application of EAL1, which can be achieved with
+ information about the components that is generally available
+ in the public domain. (EAL1 can be applied as specified
+ within to both component and composed TOEs.) CAPs provide an
+ alternative approach to obtaining higher levels of assurance
+ for a composed TOE than application of the EALs above
+ EAL1.
+
+ While a dependent component can be evaluated using a
+ previously evaluated and certified base component to satisfy
+ the IT platform requirements in the environment, this does not
+ provide any formal assurance of the interactions between the
+ components or the possible introduction of vulnerabilities
+ resulting from the composition. Composed assurance packages
+ consider these interactions and, at higher levels of
+ assurance, ensure that the interface between the components
+ has itself been the subject of testing. A vulnerability
+ analysis of the composed TOE is also performed to consider the
+ possible introduction of vulnerabilities as a result of
+ composing the components.
+
+ Table represents a summary
+ of the CAPs. The columns represent a hierarchically ordered
+ set of CAPs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, three hierarchically
+ ordered composed assurance packages are defined in the CC for
+ the rating of a composed TOE's assurance. They are
+ hierarchically ordered inasmuch as each CAP represents more
+ assurance than all lower CAPs. The increase in assurance from
+ CAP to CAP is accomplished by substitution of a hierarchically
+ higher assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements). These increases result in
+ greater analysis of the composition to identify the impact on
+ the evaluation results gained for the individual component
+ TOEs.
+
+ These CAPs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each CAP includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ The CAPs only consider resistance against an attacker with an
+ attack potential up to Enhanced-Basic. This is due to the level
+ of design information that can be provided through the , limiting some of the factors
+ associated with attack potential (knowledge of the composed TOE)
+ and subsequently affecting the rigour of vulnerability analysis
+ that can be performed by the evaluator. Therefore, the level of
+ assurance in the composed TOE is limited, although the assurance
+ in the individual components within the composed TOE may be much
+ higher.
+
+
+
+
+ The following Subclauses provide definitions of the CAPs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ Unlike the CC, where each element maintains the last digit of
+ its identifying symbol for all components within the family,
+ the CEM may introduce new work units when a CC evaluator
+ action element changes from sub-activity to sub-activity; as a
+ result, the last digit of the work unit's identifying symbol
+ may change although the work unit remains unchanged.
+
+ Any methodology-specific evaluation work required that is not
+ derived directly from CC requirements is termed
+ task or sub-task.
+
+
+
+ All work unit and sub-task verbs are preceded by the auxiliary
+ verb shall and by presenting both the verb
+ and the shall in
+
+ bold italic type face. The
+ auxiliary verb shall is used only when the
+ provided text is mandatory and therefore only within the work
+ units and sub-tasks. The work units and sub-tasks contain
+ mandatory activities that the evaluator must perform in order
+ to assign verdicts.
+
+ Guidance text accompanying work units and sub-tasks gives
+ further explanation on how to apply the CC words in an
+ evaluation. The verb usage is in accordance with ISO
+ definitions for these verbs. The auxiliary verb
+ should is used when the described method is
+ strongly preferred. All other auxiliary verbs, including
+ may, are used where the described method(s)
+ is allowed but is neither recommended nor strongly preferred;
+ it is merely explanation.
+
+ The verbs check, examine,
+ report and record are used
+ with a precise meaning within this part of the CEM and the
+ Clause should be
+ referenced for their definitions.
+
+
+
+ Material that has applicability to more than one sub-activity
+ is collected in one place. Guidance whose applicability is
+ widespread (across activities and EALs) has been collected
+ into . Guidance that
+ pertains to multiple sub-activities within a single activity
+ has been provided in the introduction to that activity. If
+ guidance pertains to only a single sub-activity, it is
+ presented within that sub-activity.
+
+
+
+ There are direct relationships between the CC structure
+ (i.e. class, family, component and element) and the structure
+ of the CEM. Figure illustrates the correspondence
+ between the CC constructs of class, family and evaluator
+ action elements and CEM activities, sub-activities and
+ actions. However, several CEM work units may result from the
+ requirements noted in CC developer action and content and
+ presentation elements.
+
+
+
+ For the purposes of this document, the following terms and
+ definitions apply.
+ Terms which are presented in bold-faced type are themselves
+ defined in this Subclause.
+ action
+
+ evaluator action element of the CC Part 3
+
+ These actions are either explicitly stated as evaluator
+ actions or implicitly derived from developer actions (implied
+ evaluator actions) within the CC Part 3 assurance components.
+
+ activity
+
+ application of an assurance class of the CC Part 3
+
+ check
+
+ generate a verdict by a simple comparison
+
+ Evaluator expertise is not required. The statement
+ that uses this verb describes what is mapped.
+
+ evaluation deliverable
+
+ any resource required from the sponsor or developer by the
+ evaluator or evaluation authority to perform one or more evaluation or
+ evaluation oversight activities
+
+ evaluation evidence
+ tangible evaluation deliverable
+ evaluation technical report
+
+ report that documents the overall verdict and its
+ justification, produced by the evaluator and submitted to an
+ evaluation authority
+ examine
+
+ generate a verdict by analysis using
+ evaluator expertise
+
+ The statement that uses this verb identifies what is analysed
+ and the properties for which it is analysed.
+
+ interpretation
+ clarification or amplification of a CC, CEM or
+ scheme requirement
+ methodology
+
+ system of principles, procedures and processes applied to IT
+ security evaluations
+
+ observation report
+
+ report written by the evaluator requesting a clarification
+ or identifying a problem during the evaluation
+
+ overall verdict
+ pass or fail statement issued by an
+ evaluator with respect to the result of an
+ evaluation
+
+ oversight verdict
+
+ statement issued by an evaluation authority confirming or
+ rejecting an overall verdict based on the
+ results of evaluation oversight activities
+
+ record
+
+ retain a written description of procedures, events,
+ observations, insights and results in sufficient detail to
+ enable the work performed during the evaluation to be
+ reconstructed at a later time
+
+ report
+
+ include evaluation results and supporting material in the
+ Evaluation Technical Report or an
+ Observation Report
+ scheme
+
+ set of rules, established by an evaluation authority,
+ defining the evaluation environment, including criteria and
+ methodology required to conduct IT security
+ evaluations
+
+ sub-activity
+
+ application of an assurance component of the CC Part 3
+
+ Assurance families are not explicitly addressed in the CEM
+ because evaluations are conducted on a single assurance
+ component from an assurance family.
+
+ tracing
+
+ simple directional relation between two sets of
+ entities, which shows which entities in the first set
+ correspond to which entities in the second
+
+ verdict
+ pass, fail or inconclusive statement issued
+ by an evaluator with respect to a CC evaluator action element,
+ assurance component, or class
+
+ Also see overall verdict.
+
+ work unit
+
+ most granular level of evaluation work
+
+ Each CEM action comprises one or more work units, which are
+ grouped within the CEM action by CC content and presentation
+ of evidence or developer action element. The work units are
+ presented in the CEM in the same order as the CC elements
+ from which they are derived. Work units are identified in
+ the left margin by a symbol such as . In this symbol, the
+ string
+ indicates the CC component (i.e. the CEM sub-activity), and
+ the final digit (2) indicates that this is
+ the second work unit in the
+ sub-activity.
+
+
+
+ The target audience for the Common Methodology for Information
+ Technology Security Evaluation (CEM) is primarily evaluators
+ applying the CC and certifiers confirming evaluator actions;
+ evaluation sponsors, developers, PP/ST authors and other parties
+ interested in IT security may be a secondary audience.
+
+ The CEM recognises that not all questions concerning IT security
+ evaluation will be answered herein and that further
+ interpretations will be needed. Individual schemes will
+ determine how to handle such interpretations, although these may
+ be subject to mutual recognition agreements. A list of
+ methodology-related activities that may be handled by individual
+ schemes can be found in .
+
+
+
+
+ Clause defines the
+ conventions used in the CEM.
+
+ Clause
+ describes general evaluation tasks with no verdicts associated
+ with them as they do not map to CC evaluator action
+ elements.
+
+ Clause addresses the work
+ necessary for reaching an evaluation result on a PP.
+
+ Clauses to define the evaluation activities, organised by
+ Assurance Classes.
+
+ covers the basic
+ evaluation techniques used to provide technical evidence of
+ evaluation results.
+
+ provides an explanation
+ of the Vulnerability Analysis criteria and examples of their
+ application
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CC
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+
+
+
+
+ The Common Methodology for Information Technology Security
+ Evaluation (CEM) is a companion document to the Common Criteria
+ for Information Technology Security Evaluation (CC). The CEM
+ defines the minimum actions to be performed by an evaluator in
+ order to conduct a CC evaluation, using the criteria and
+ evaluation evidence defined in the CC.
+ The CEM does not define evaluator actions for certain high
+ assurance CC components, where there is as yet no generally
+ agreed guidance.
+
+
+
+ CEM
+
+ Common Methodology for Information Technology Security
+ Evaluation
+
+
+
+ ETR
+
+ Evaluation Technical Report
+
+
+
+ OR
+
+ Observation Report
+
+
+
+
+
+
+ Table describes the
+ relationship between the evaluation assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Evaluation Assurance Levels (EALs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance. The
+ CC approach identifies the separate concepts of assurance in a
+ TOE at the end of the evaluation, and of maintenance of that
+ assurance during the operational use of the TOE.
+
+ It is important to note that not all families and components
+ from CC Part 3 are included in the EALs. This is not to say that
+ these do not provide meaningful and desirable
+ assurances. Instead, it is expected that these families and
+ components will be considered for augmentation of an EAL in
+ those PPs and STs for which they provide utility.
+
+
+ Table represents a summary
+ of the EALs. The columns represent a hierarchically ordered
+ set of EALs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, seven hierarchically
+ ordered evaluation assurance levels are defined in the CC for
+ the rating of a TOE's assurance. They are hierarchically
+ ordered inasmuch as each EAL represents more assurance than
+ all lower EALs. The increase in assurance from EAL to EAL is
+ accomplished by substitution of a hierarchically higher
+ assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements).
+
+ These EALs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each EAL includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ While the EALs are defined in the CC, it is possible to
+ represent other combinations of assurance. Specifically, the
+ notion of ``augmentation'' allows the addition of assurance
+ components (from assurance families not already included in
+ the EAL) or the substitution of assurance components (with
+ another hierarchically higher assurance component in the same
+ assurance family) to an EAL. Of the assurance constructs
+ defined in the CC, only EALs may be augmented. The notion of
+ an ``EAL minus a constituent assurance component'' is not
+ recognised by the standard as a valid claim. Augmentation
+ carries with it the obligation on the part of the claimant to
+ justify the utility and added value of the added assurance
+ component to the EAL. An EAL may also be augmented with
+ extended assurance requirements.
+
+
+
+
+ The following Subclauses provide definitions of the EALs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ The objective of this clause is to cover general guidance
+ used to provide technical evidence of evaluation results. The
+ use of such general guidance helps in achieving objectivity,
+ repeatability and reproducibility of the work performed by the
+ evaluator.
+
+
+
+ This Subclause provides general guidance on sampling. Specific
+ and detailed information is given in those work units under
+ the specific evaluator action elements where sampling has to
+ be performed.
+
+ Sampling is a defined procedure of an evaluator whereby some
+ subset of a required set of evaluation evidence is examined
+ and assumed to be representative for the entire set. It allows
+ the evaluator to gain enough confidence in the correctness of
+ particular evaluation evidence without analysing the whole
+ evidence. The reason for sampling is to conserve resources
+ while maintaining an adequate level of assurance. Sampling of
+ the evidence can provide two possible outcomes:
+
+
+ The subset reveals no errors, allowing the evaluator to
+ have some confidence that the entire set is correct.
+
+
+ The subset reveals errors and therefore the validity of
+ the entire set is called into question. Even the
+ resolution of all errors that were found may be
+ insufficient to provide the evaluator the necessary
+ confidence and as a result the evaluator may have to
+ increase the size of the subset, or stop using sampling
+ for this particular evidence.
+
+
+
+ Sampling is a technique which can be used to reach a reliable
+ conclusion if a set of evidence is relatively homogeneous in
+ nature, e.g. if the evidence has been produced during a well
+ defined process.
+
+ Sampling in the cases identified in the CC, and in cases
+ specifically covered in CEM work items, is recognised as a
+ cost-effective approach to performing evaluator
+ actions. Sampling in other areas is permitted only in
+ exceptional cases, where performance of a particular activity
+ in its entirety would require effort disproportionate to the
+ other evaluation activities, and where this would not add
+ correspondingly to assurance. In such cases a rationale for
+ the use of sampling in that area will need to be made. Neither
+ the fact that the TOE is large and complex, nor that it has
+ many security functional requirements, is sufficient
+ justification, since evaluations of large, complex TOEs can be
+ expected to require more effort. Rather it is intended that
+ this exception be limited to cases such as that where the TOE
+ development approach yields large quantities of material for a
+ particular CC requirement that would normally all need to be
+ checked or examined, and where such an action would not be
+ expected to raise assurance correspondingly.
+
+ Sampling needs to be justified taking into account the
+ possible impact on the security objectives and threats of the
+ TOE. The impact depends on what might be missed as a result of
+ sampling. Consideration also needs to be given to the nature
+ of the evidence to be sampled, and the requirement not to
+ diminish or ignore any security functions.
+
+ It should be recognised that sampling of evidence directly
+ related to the implementation of the TOE (e.g. developer test
+ results) requires a different approach to sampling, then
+ sampling related to the determination of whether a process is
+ being followed. In many cases the evaluator is required to
+ determine that a process is being followed, and a sampling
+ strategy is recommended. The approach for sampling a
+ developer's test results will differ. This is because the
+ former case is concerned with ensuring that a process is in
+ place, and the latter deals with determining correct
+ implementation of the TOE. Typically, larger sample sizes
+ should be analysed in cases related to the correct
+ implementation of the TOE than would be necessary to ensure
+ that a process is in place.
+
+ In certain cases it may be appropriate for the evaluator to
+ give greater emphasis to the repetition of developer
+ testing. For example if the independent tests left for the
+ evaluator to perform would be only superficially different
+ from those included in an extensive developer test set
+ (possibly because the developer has performed more testing
+ than necessary to satisfy the
+ and criteria) then it would
+ be appropriate for the evaluator to give greater focus to the
+ repetition of developer tests. Note that this does not
+ necessarily imply a requirement for a high percentage sample
+ for repetition of developer tests; indeed, given an extensive
+ developer test set, the evaluator may be able to justify a low
+ percentage sample.
+
+ Where the developer has used an automated test suite to
+ perform functional testing, it will usually be easier for the
+ evaluator to re-run the entire test suite rather than repeat
+ only a sample of developer tests. However the evaluator does
+ have an obligation to check that the automatic testing does
+ not give misrepresentative results. The implication is thus
+ that this check must be performed for a sample of the
+ automatic test suite, with the principles for selecting some
+ tests in preference to others and ensuring a sufficient sample
+ size applying equally in this case.
+
+ The following principles should be followed whenever sampling
+ is performed:
+
+
+ Sampling should not be random, rather it should be chosen
+ such that it is representative of all of the evidence. The
+ sample size and composition must always be justified.
+
+
+ When sampling relates to the correct implementation of the
+ TOE, the sample should be representative of all aspects
+ relevant to the areas that are sampled. In particular, the
+ selection should cover a variety of components,
+ interfaces, developer and operational sites (if more than
+ one is involved) and hardware platform types (if more than
+ one is involved). The sample size should be commensurate
+ with the cost effectiveness of the evaluation and will
+ depend on a number of TOE dependent factors (e.g. the size
+ and complexity of the TOE, the amount of documentation).
+
+
+ Also, when sampling relates to specifically gaining
+ evidence that the developer testing is repeatable and
+ reproducible the sample used must be sufficient to
+ represent all distinct aspects of developer testing, such
+ as different test regimes. The sample used must be
+ sufficient to detect any systematic problem in the
+ developer's functional testing process. The evaluator
+ contribution resulting from the combination of repeating
+ developer tests and performing independent tests must be
+ sufficient to address the major points of concern for the
+ TOE.
+
+
+ Where sampling relates to gaining evidence that a process
+ (e.g. visitor control or design review) the evaluator
+ should sample sufficient information to gain reasonable
+ confidence that the procedure is being followed.
+
+
+ The sponsor and developer should not be informed in
+ advance of the exact composition of the sample, subject to
+ ensuring timely delivery of the sample and supporting
+ deliverable, e.g. test harnesses and equipment to the
+ evaluator in accordance with the evaluation schedule.
+
+
+ The choice of the sample should be free from bias to the
+ degree possible (one should not always choose the first or
+ last item). Ideally the sample selection should be done by
+ someone other than the evaluator.
+
+
+
+ Errors found in the sample can be categorised as being either
+ systematic or sporadic. If the error is systematic, the
+ problem should be corrected and a complete new sample
+ taken. If properly explained, sporadic errors might be solved
+ without the need for a new sample, although the explanation
+ should be confirmed. The evaluator should use judgement in
+ determining whether to increase the sample size or use a
+ different sample.
+
+
+
+ In general it is possible to perform the required evaluation
+ activities, sub-activities, and actions in any order or in
+ parallel. However, there are different kinds of dependencies
+ which have to be considered by the evaluator. This Subclause
+ provides general guidance on dependencies between different
+ activities, sub-activities, and actions.
+
+
+ For some cases the different assurance classes may recommend
+ or even require a sequence for the related activities. A
+ specific instance is the ST activity. The ST evaluation
+ activity is started prior to any TOE evaluation activities
+ since the ST provides the basis and context to perform
+ them. However, a final verdict on the ST evaluation may not
+ be possible until the TOE evaluation is complete, since
+ changes to the ST may result from activity findings during
+ the TOE evaluation.
+
+
+
+ Dependencies identified between components in CC Part 3 have
+ to be considered by the evaluator. Most dependencies are
+ one way, e.g. claims a
+ dependency on and . There are also instances of
+ mutual dependencies, where both components depend on each
+ other. An example of this is and .
+
+ A sub-activity can be assigned a pass verdict normally only
+ if all those sub-activities are successfully completed on
+ which it has a one-way dependency. For example, a pass
+ verdict on can normally
+ only be assigned if the sub-activities related to and are assigned a pass verdict too. In the case
+ of mutual dependency the ordering of these components is
+ down to the evaluator deciding which sub-activity to perform
+ first. Note this indicates that pass verdicts can normally
+ only be assigned once both sub-activities have been
+ successful.
+
+ So when determining whether a sub-activity will impact
+ another sub-activity, the evaluator should consider whether
+ this activity depends on potential evaluation results from
+ any dependent sub-activities. Indeed, it may be the case
+ that a dependent sub-activity will impact this sub-activity,
+ requiring previously completed evaluator actions to be
+ performed again.
+
+ A significant dependency effect occurs in the case of
+ evaluator-detected flaws. If a flaw is identified as a
+ result of conducting one sub-activity, the assignment of a
+ pass verdict to a dependent sub-activity may not be possible
+ until all flaws related to the sub-activity upon which it
+ depends are resolved.
+
+
+
+ It may be the case, that results which are generated by the
+ evaluator during one action are used for performing another
+ action. For example, actions for completeness and
+ consistency cannot be completed until the checks for content
+ and presentation have been completed. This means for example
+ that the evaluator is recommended to evaluate the PP/ST
+ rationale after evaluating the constituent parts of the
+ PP/ST.
+
+
+
+
+
+ The assurance class includes
+ requirements for
+
+
+ the application of configuration management, ensuring
+ that the integrity of the TOE is preserved;
+
+
+ measures, procedures, and standards concerned with
+ secure delivery of the TOE, ensuring that the security
+ protection offered by the TOE is not compromised during
+ the transfer to the user,
+
+
+ security measures, used to protect the development
+ environment.
+
+
+
+ A development site visit is a useful means whereby the
+ evaluator determines whether procedures are being followed
+ in a manner consistent with that described in the
+ documentation.
+
+ Reasons for visiting sites include:
+
+
+ to observe the use of the CM system as described in the
+ CM plan;
+
+
+ to observe the practical application of delivery
+ procedures as described in the delivery documentation;
+
+
+ to observe the application of security measures during
+ development and maintenance of the TOE as described in
+ the development security documentation.
+
+
+
+ Specific and detailed information is given in work units for
+ those activities where site visits are performed:
+
+
+ .n with n>=3
+ (especially work unit = = );
+
+
+ (especially work unit
+ );
+
+
+ (especially work unit
+ = ).
+
+
+
+
+
+ During an evaluation it is often necessary that the
+ evaluator will meet the developer more than once and it is a
+ question of good planning to combine the site visit with
+ another meeting to reduce costs. For example one might
+ combine the site visits for configuration management, for
+ the developer's security and for delivery. It may also be
+ necessary to perform more than one site visit to the same
+ site to allow the checking of all development phases. It
+ should be considered that development could occur at
+ multiple facilities within a single building, multiple
+ buildings at the same site, or at multiple sites.
+
+ The first site visit should be scheduled early during the
+ evaluation. In the case of an evaluation which starts during
+ the development phase of the TOE, this will allow corrective
+ actions to be taken, if necessary. In the case of an
+ evaluation which starts after the development of the TOE, an
+ early site visit could allow corrective measures to be put
+ in place if serious deficiencies in the applied procedures
+ emerge. This avoids unnecessary evaluation effort.
+
+ Interviews are also a useful means of determining whether the
+ written procedures reflect what is done. In conducting such
+ interviews, the evaluator aims to gain a deeper understanding of
+ the analysed procedures at the development site, how they are
+ used in practise and whether they are being applied as described
+ in the provided evaluation evidence. Such interviews complement
+ but do not replace the examination of evaluation
+ evidence.
+
+ As a first step preparing the site visits the evaluators
+ should perform the evaluator work units concerning the
+ assurance class excluding the
+ aspects describing the results of the site visit. Based on
+ the information provided by the relevant developer
+ documentation and the remaining open questions which were
+ not answered by the documentation the evaluators compile a
+ check list of the questions which are to be resolved by the
+ site visits.
+
+ The first version of the evaluation report concerning the
+ class and the check list serves
+ as input for the consultation with the evaluation authority
+ concerning the site visits.
+
+ The check list serve as a guide line for the site visits,
+ which questions are to be answered by inspection of the
+ relevant measures, their application and results, and by
+ interviews. Where appropriate, sampling is used for gaining
+ the required level of confidence (see Subclause ).
+
+ The results of the site visits are recorded and serve as
+ input for the final version of the evaluation report
+ concerning the assurance class .
+
+ Other approaches to gain confidence should be considered
+ that provide an equivalent level of assurance (e.g. to
+ analyse evaluation evidence). Any decision not to make a
+ visit should be determined in consultation with the
+ evaluation authority. Appropriate security criteria and a
+ methodology should be based on other standards of the
+ Information Security Management Systems area.
+
+
+
+ In the following some keywords are provided, which topics
+ should be checked during an audit.
+
+ Basic
+
+
+ Items of the configuration list, including TOE, source
+ code, run time libraries, design documentation,
+ development tools ().
+
+
+ Tracking of design documentation, source code, user
+ guidance to different versions of the TOE.
+
+
+ Integration of the configuration system in the design
+ and development process, test planning, test analysis
+ and quality management procedures.
+
+
+
+ Test analysis
+
+
+ Tracking of test plans and results to specific
+ configurations and versions of the TOE.
+
+
+
+ Access control to development systems
+
+
+ Policies for access control and logging.
+
+
+ Policies for project specific assignment and changing
+ of access rights.
+
+
+
+ Clearance
+
+
+ Policies for clearance of the TOE and user guidance to
+ the customer.
+
+
+ Policies for testing and approving of components and
+ the TOE before deployment.
+
+
+
+
+
+ Infrastructure
+
+
+ Security measures for physical access control to the
+ development site and rationale for the effectiveness
+ of these measures.
+
+
+
+ Organisational measures
+
+
+ Organisational structure of the company in respect of
+ the security of the development environment.
+
+
+ Organisational separation between development,
+ production, testing and quality assurance.
+
+
+
+ Personal measures
+
+
+ Measures for education of the personnel in respect of
+ development security.
+
+
+ Measures and legal agreements of non disclosure of
+ internal information.
+
+
+
+ Access control
+
+
+ Assignment of secured objects (for instance TOE,
+ source code, run time libraries, design documentation,
+ development tools, user guidance) and security
+ policies.
+
+
+ Policies and responsibilities concerning the access
+ control and the handling of authentication
+ information.
+
+
+ Policies for logging of any kind access to the
+ development site and protection of the logging data.
+
+
+
+ Input, processing and output of data
+
+
+ Security measures for protection of output and output
+ devices (printer, plotter and displays).
+
+
+ Securing of local networks and communication
+ connections.
+
+
+
+ Storage, transfer and destruction of documents and data
+ media.
+
+
+ Policies for handling of documents and data media.
+
+
+ Policies and responsibilities for destruction of
+ sorted out documents and logging of these events.
+
+
+
+ Data protection
+
+
+ Policies and responsibilities for data and information
+ protection (e.g. for performing backups).
+
+
+
+ Contingency plan
+
+
+ Practises in case of emergency and responsibilities.
+
+
+ Documentation of the contingency measures concerning
+ access control.
+
+
+ Information of the personnel about applicable
+ practises in extreme cases. protection (e.g. for
+ performing backups).
+
+
+
+
+
+
+ The examples of checklists for site visits consist in tables
+ for the preparation of an audit and for the presentation of
+ the results of an audit.
+
+ The checklist structure given in the following is
+ preliminary. Dependent on the concrete contents of the new
+ guideline, changes might become necessary.
+ The checklist is divided into three subclauses according
+ to the subjects indicated in the introduction (Subclause ).
+
+
+ Configuration management system.
+
+
+ Delivery procedures.
+
+
+ Security measures during development.
+
+
+ These subclauses correspond to the actual CC class , especially the families .n with n>=3, and .
+ The subclauses are subdivided further into rows
+ corresponding to the relevant work units of the CEM.
+
+ The columns of the checklist contain in turn
+
+
+ a consecutive number,
+
+
+ the referenced work unit,
+
+
+ the references to the corresponding developer
+ documentation,
+
+
+ the explicit reproduction of the developer measures,
+
+
+ special remarks and questions to be clarified on the
+ visit (beyond the standard evaluator task to verify the
+ application of the indicated measures),
+
+
+ the result of the examinations during the visit.
+
+
+ If it is decided to have separate checklists for
+ preparation and reporting of the audit, the result column is
+ omitted in the preparation list and the remarks and
+ questions column is omitted in the reporting list. The
+ remaining columns should be identical in both lists.
+
+
+ Example of a checklist at EAL 4 (extract)
+
+
+
+
+
+ A. Examination of the CM system ( and )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ A.1
+
+
+ ,
+
+
+
+ ``Configuration Management System'', ch. ...
+
+
+ The system automatically managing the source code
+ files is capable of administering user profiles and
+ graded access rights, and of checking identification
+ and authentication of users.
+
+
+ Does reading or updating of a source code file
+ require a user authentication?
+
+
+ If a user has not the right to access a confidential
+ document, it is not even displayed to him in the
+ file list.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ B. Examination of the Delivery Procedures ()
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ B.1
+
+
+ ,
+
+
+
+ ``Delivery of the TOE'', ch. ...
+
+
+ The software is transmitted PGP-signed and encrypted
+ to the customer.
+
+
+ ---
+
+
+ The evaluators have checked the process and found it
+ as described, additionally a checksum is
+ transmitted.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ C. Examination of the organisational and
+ infrastructural developer security
+ (,
+ ,
+ )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ C.1
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Premises)
+
+
+ The premises are protected by security fencing.
+
+
+ Is the fencing sufficiently strong and high to
+ prevent an easy intrusion into the premises?
+
+
+ The evaluators considered the fencing to be
+ sufficiently strong and high.
+
+
+
+
+ C.2
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Building)
+
+
+ The building has the following access possibilities:
+ The main entrance which is surveyed by the reception
+ and is closed if the reception is not manned. And an
+ access in the goods reception which is secured by
+ two roller shutters.
+
+
+ Is the listing of the access possibilities complete?
+
+
+ Beyond the indicated access possibilities, there is
+ an emergency exit that cannot be opened from the
+ outside. The roller shutters mentioned before can be
+ operated only from inside.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+
+ This CEM describes the minimum technical work that evaluations
+ conducted under oversight (scheme) bodies must
+ perform. However, it also recognises (both explicitly and
+ implicitly) that there are activities or methods upon which
+ mutual recognition of evaluation results do not rely. For the
+ purposes of thoroughness and clarity, and to better delineate
+ where the CEM ends and an individual scheme's methodology
+ begins, the following matters are left up to the discretion of
+ the schemes. Schemes may choose to provide the following,
+ although they may choose to leave some unspecified. (Every
+ effort has been made to ensure this list is complete;
+ evaluators encountering a subject neither listed here nor
+ addressed in the CEM should consult with their evaluation
+ schemes to determine under whose auspices the subject
+ falls.)
+
+ The matters that schemes may choose to specify include:
+
+
+ what is required in ensuring that an evaluation was done
+ sufficiently - every scheme has a means of verifying the
+ technical competence, understanding of work and the work
+ of its evaluators, whether by requiring the evaluators to
+ present their findings to the oversight body, by requiring
+ the oversight body to redo the evaluator's work, or by
+ some other means that assures the scheme that all
+ evaluation bodies are adequate and comparable;
+
+
+ process for disposing of evaluation evidence upon
+ completion of an evaluation;
+
+
+ any requirements for confidentiality (on the part of the
+ evaluator and the non-disclosure of information obtained
+ during evaluation);
+
+
+ the course of action to be taken if a problem is
+ encountered during the evaluation (whether the evaluation
+ continues once the problem is remedied, or the evaluation
+ ends immediately and the remedied product must be
+ re-submitted for evaluation);
+
+
+ any specific (natural) language in which documentation
+ must be provided;
+
+
+ any recorded evidence that must be submitted in the ETR -
+ this CEM specifies the minimum to be reported in an ETR;
+ however, individual schemes may require additional
+ information to be included;
+
+
+ any additional reports (other than the ETR) required from
+ the evaluators -for example, testing reports;
+
+
+ any specific ORs that may be required by the scheme,
+ including the structure, recipients, etc. of any such ORs;
+
+
+ any specific content structure of any written report as a
+ result from an ST evaluation - a scheme may have a
+ specific format for all of its reports detailing results
+ of an evaluation, be it the evaluation of a TOE or of an
+ ST;
+
+
+ any additional PP/ST identification information required;
+
+
+ any activities to determine the suitability of
+ explicitly-stated requirements in an ST;
+
+
+ any requirements for provision of evaluator evidence to
+ support re-evaluation and re-use of evidence;
+
+
+ any specific handling of scheme identifiers, logos,
+ trademarks, etc.;
+
+
+ any specific guidance in dealing with cryptography;
+
+
+ handling and application of scheme, national and
+ international interpretations;
+
+
+ a list or characterisations of suitable alternative
+ approaches to testing where testing is infeasible;
+
+
+ the mechanism by which an evaluation authority can determine what
+ steps an evaluator took while testing;
+
+
+ preferred test approach (if any): at internal interface or
+ at external interface;
+
+
+ a list or characterisation of acceptable means of
+ conducting the evaluator's vulnerability analysis
+ (e.g. flaw hypothesis methodology);
+
+
+ information regarding any vulnerabilities and weaknesses
+ to be considered.
+
+
+
+
+
+
+
+ The following annexes through provide the application notes for the functional
+ classes defined in the main body of this part of the CC.
+
+
+ For the purposes of this document, the terms, definitions,
+ symbols and abbreviated terms given in CC Part 1 apply.
+
+
+ Security functional components, as defined in this CC Part 2, are
+ the basis for the security functional requirements expressed in a
+ Protection Profile (PP) or a Security Target (ST). These
+ requirements describe the desired security behaviour expected of a
+ Target of Evaluation (TOE) and are intended to meet the security
+ objectives as stated in a PP or an ST. These requirements describe
+ security properties that users can detect by direct interaction
+ (i.e. inputs, outputs) with the IT or by the IT response to
+ stimulus.
+
+ Security functional components express security requirements
+ intended to counter threats in the assumed operating environment
+ of the TOE and/or cover any identified organisational security
+ policies and assumptions.
+
+ The audience for this CC Part 2 includes consumers, developers,
+ and evaluators of secure IT products. CC Part 1
+ Chapter provides additional
+ information on the target audience of the CC, and on the use of
+ the CC by the groups that comprise the target audience. These
+ groups may use this part of the CC as follows:
+
+
+ Consumers, who use this CC Part 2 when selecting components to
+ express functional requirements to satisfy the security
+ objectives expressed in a PP or ST. CC Part 1 Section provides more detailed
+ information on the relationship between security objectives
+ and security requirements.
+
+
+ Developers, who respond to actual or perceived consumer
+ security requirements in constructing a TOE, may find a
+ standardised method to understand those requirements in this
+ part of the CC. They can also use the contents of this part of
+ the CC as a basis for further defining the TOE security
+ functionality and mechanisms that comply with those
+ requirements.
+
+
+ Evaluators, who use the functional requirements defined in
+ this part of the CC in verifying that the TOE functional
+ requirements expressed in the PP or ST satisfy the IT security
+ objectives and that all dependencies are accounted for and
+ shown to be satisfied. Evaluators also should use this part of
+ the CC to assist in determining whether a given TOE satisfies
+ stated requirements.
+
+
+
+
+
+ The CC and the associated security functional requirements
+ described herein are not meant to be a definitive answer to all
+ the problems of IT security. Rather, the CC offers a set of well
+ understood security functional requirements that can be used to
+ create trusted products reflecting the needs of the market. These
+ security functional requirements are presented as the current
+ state of the art in requirements specification and
+ evaluation.
+
+ This part of the CC does not presume to include all possible
+ security functional requirements but rather contains those that
+ are known and agreed to be of value by the CC Part 2 authors at
+ the time of release.
+
+ Since the understanding and needs of consumers may change, the
+ functional requirements in this part of the CC will need to be
+ maintained. It is envisioned that some PP/ST authors may have
+ security needs not (yet) covered by the functional requirement
+ components in CC Part 2. In those cases the PP/ST author may
+ choose to consider using functional requirements not taken from
+ the CC (referred to as extensibility), as explained in annexes
+ and
+ of
+ CC Part 1.
+
+
+
+ Clause
+ describes the paradigm used in the security functional
+ requirements of CC Part 2.
+
+ Clause
+ introduces the catalogue of CC Part 2 functional components
+ while clauses through describe the functional classes.
+
+ provides explanatory information for potential
+ users of the functional components including a complete cross
+ reference table of the functional component dependencies.
+
+ through provide the explanatory information for the
+ functional classes. This material must be seen as normative
+ instructions on how to apply relevant operations and select
+ appropriate audit or documentation information; the use of the
+ auxiliary verb should means that the instruction is strongly
+ preferred, but others may be justifiable. Where different
+ options are given, the choice is left to the PP/ST
+ author.
+
+ Those who author PPs or STs should refer to clause 2 of CC Part
+ 1 for relevant structures, rules, and guidance:
+
+
+ CC Part 1, clause
+ defines the terms used in the CC.
+
+
+ CC Part 1, annex defines the
+ structure for STs.
+
+
+ CC Part 1, annex defines the
+ structure for PPs.
+
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest edition
+ of the referenced document (including any amendments) applies.CC
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 1: Introduction and general model.
+
+
+ This part of the CC defines the required structure and content
+ of security functional components for the purpose of security
+ evaluation. It includes a catalogue of functional components
+ that will meet the common security functionality requirements
+ of many IT products.
+
+
+ This chapter describes the paradigm used in the security
+ functional requirements of this part of the CC. Key concepts
+ discussed are highlighted in bold/italics. This section is not
+ intended to replace or supersede any of the terms found in CC Part
+ 1, chapter .
+
+ This part of the CC is a catalogue of security functional
+ components that can be specified for a Target of
+ Evaluation (TOE). A TOE is a set of software, firmware
+ and/or hardware possibly accompanied by user and administrator
+ guidance documentation. A TOE may contain resources such as
+ electronic storage media (e.g. main memory, disk space),
+ peripheral devices (e.g. printers), and computing capacity (e.g.
+ CPU time) that can be used for processing and storing
+ information and is the subject of an evaluation.
+
+ TOE evaluation is concerned primarily with ensuring that a defined
+ set of security functional requirements (SFRs) is
+ enforced over the TOE resources. The SFRs define the rules by
+ which the TOE governs access to and use of its resources, and thus
+ information and services controlled by the TOE.
+
+ The SFRs may define multiple Security Function Policies
+ (SFPs) to represent the rules that the TOE must enforce. Each such SFP
+ must specify its scope of control, by defining the subjects,
+ objects, resources or information, and operations to which it applies. All
+ SFPs are implemented by the TSF (see below), whose mechanisms enforce the
+ rules defined in the SFRs and provide necessary capabilities.
+
+ Those portions of a TOE that must be relied on for the correct
+ enforcement of the SFRs are collectively referred to as the
+ TOE Security Functionality (TSF). The TSF consists of
+ all hardware, software, and firmware of a TOE that is either
+ directly or indirectly relied upon for security enforcement.
+
+ The TOE may be a monolithic product containing hardware, firmware,
+ and software.
+
+ Alternatively a TOE may be a distributed product that consists
+ internally of multiple separated parts. Each of these parts of the
+ TOE provides a particular service for the TOE, and is connected to
+ the other parts of the TOE through an internal communication
+ channel. This channel can be as small as a processor bus,
+ or may encompass a network internal to the TOE.
+
+ When the TOE consists of multiple parts, each part of the TOE may
+ have its own part of the TSF which exchanges user and TSF data
+ over internal communication channels with other parts of the
+ TSF. This interaction is called internal TOE
+ transfer. In this case the separate parts of the TSF
+ abstractly form the composite TSF, which enforces the SFRs.
+
+ TOE interfaces may be localised to the particular TOE, or they may
+ allow interaction with other IT products over external
+ communication channels. These external interactions with
+ other IT products may take two forms:
+
+
+ The SFRs of the other ``trusted IT product'' and the SFRs of
+ the TOE have been administratively coordinated and the other
+ trusted IT product is assumed to enforce its SFRs correctly
+ (e. g. by being separately evaluated). Exchanges of
+ information in this situation are called inter-TSF
+ transfers, as they are between the TSFs of distinct
+ trusted products.
+
+
+ The other IT product may not be trusted, it may be called an
+ ``untrusted IT product''. Therefore its SFRs are either
+ unknown or their implementation is not viewed as
+ trustworthy. TSF mediated exchanges of information in this
+ situation are called transfers outside of the
+ TOE, as there is no TSF (or its policy characteristics
+ are unknown) on the other IT product.
+
+
+ The set of interfaces, whether interactive (man-machine
+ interface) or programmatic (application programming interface),
+ through which resources are accessed that are mediated by the TSF,
+ or information is obtained from the TSF, is referred to as the
+ TSF Interface (TSFI). The TSFI defines the boundaries
+ of the TOE functionality that provide for the enforcement of the
+ SFRs.
+
+ Users are outside of the TOE. However, in order to request that
+ services be performed by the TOE that are subject to rules
+ defined in the SFRs, users interact with the TOE through the
+ TSFIs. There are two types of users of interest to CC Part 2:
+ human users and external IT
+ entities. Human users may further be differentiated as
+ local human users, meaning they interact directly
+ with the TOE via TOE devices (e.g. workstations), or
+ remote human users, meaning they interact
+ indirectly with the TOE through another IT product.
+
+ A period of interaction between users and the TSF is referred to
+ as a user session. Establishment of user sessions can
+ be controlled based on a variety of considerations, for example:
+ user authentication, time of day, method of accessing the TOE, and
+ number of allowed concurrent sessions (per user or in total).
+
+ This part of the CC uses the term authorised to
+ signify a user who possesses the rights and/or privileges
+ necessary to perform an operation. The term authorised
+ user, therefore, indicates that it is allowable for a user
+ to perform a specific operation or a set of operations as defined
+ by the SFRs.
+
+ To express requirements that call for the separation of
+ administrator duties, the relevant security functional
+ components (from family )
+ explicitly state that administrative roles are
+ required. A role is a pre-defined set of rules establishing the
+ allowed interactions between a user operating in that role and
+ the TOE. A TOE may support the definition of any number of
+ roles. For example, roles related to the secure operation of a
+ TOE may include ``Audit Administrator'' and ``User Accounts
+ Administrator''.
+
+ TOEs contain resources that may be used for the
+ processing and storing of information. The primary goal of the TSF
+ is the complete and correct enforcement of the SFRs over the
+ resources and information that the TOE controls.
+
+ TOE resources can be structured and utilised in many different
+ ways. However, CC Part 2 makes a specific distinction that allows
+ for the specification of desired security properties. All entities
+ that can be created from resources can be characterised in one of
+ two ways. The entities may be active, meaning that they are the
+ cause of actions that occur internal to the TOE and cause
+ operations to be performed on information. Alternatively, the
+ entities may be passive, meaning that they are either the
+ container from which information originates or to which
+ information is stored.
+
+ Active entities in the TOE that perform operations on objects are
+ referred to as subjects. Several types of subjects
+ may exist within a TOE:
+
+
+ those acting on behalf of an authorised user (e.g. UNIX
+ processes);
+
+
+ those acting as a specific functional process that may in turn
+ act on behalf of multiple users (e.g. functions as might be
+ found in client/server architectures); or
+
+
+ those acting as part of the TOE itself (e.g. processes not
+ acting on behalf of a user).
+
+
+
+ CC Part 2 addresses the enforcement of the SFRs over types of
+ subjects as those listed above.
+
+ Passive entities in the TOE that contain or receive information
+ and upon which subjects perform operations are called
+ objects. In the case where a subject (an active
+ entity) is the target of an operation (e.g. interprocess
+ communication), a subject may also be acted on as an object.
+
+ Objects can contain information. This concept is
+ required to specify information flow control policies as addressed
+ in the FDP class.
+
+ Users, subjects, information, objects, sessions and resources
+ controlled by rules in the SFRs may possess certain
+ attributes that contain information that is used by
+ the TOE for its correct operation. Some attributes, such as file
+ names, may be intended to be informational or may be used to
+ identify individual resources while others, such as access control
+ information, may exist specifically for the enforcement of the
+ SFRs. These latter attributes are generally referred to as
+ ``security attributes''. The word attribute will be
+ used as a shorthand in some places of this part of the CC for the
+ word ``security attribute''. However, no matter what the intended
+ purpose of the attribute information, it may be necessary to have
+ controls on attributes as dictated by the SFRs.
+
+ Data in a TOE is categorised as either user data or TSF
+ data. Figure depicts this
+ relationship. User Data is information stored in TOE
+ resources that can be operated upon by users in accordance with
+ the SFRs and upon which the TSF places no special meaning. For
+ example, the content of an electronic mail message is user
+ data. TSF Data is information used by the TSF in making decisions
+ as required by the SFRs. TSF Data may be influenced
+ by users if allowed by the SFRs. Security attributes,
+ authentication data, TSF internal status variables used by the
+ rules defined in the SFRs or used for the protection of the TSF
+ and access control list entries are examples of TSF data.
+
+ There are several SFPs that apply to data protection such as
+ access control SFPs and information flow
+ control SFPs. The mechanisms that implement access control
+ SFPs base their policy decisions on attributes of the users,
+ resources, subjects, objects, sessions, TSF status data and
+ operations within the scope of control. These attributes are used
+ in the set of rules that govern operations that subjects may
+ perform on objects.
+
+ The mechanisms that implement information flow control SFPs base
+ their policy decisions on the attributes of the subjects and
+ information within the scope of control and the set of rules that
+ govern the operations by subjects on information. The attributes
+ of the information, which may be associated with the attributes of
+ the container or may be derived from the data in the container,
+ stay with the information as it is processed by the TSF.
+
+
+ Two specific types of TSF data addressed by CC Part 2 can be, but
+ are not necessarily, the same. These are authentication
+ data and secrets.
+
+ Authentication data is used to verify the claimed identity of a
+ user requesting services from a TOE. The most common form of
+ authentication data is the password, which depends on being kept
+ secret in order to be an effective security mechanism. However,
+ not all forms of authentication data need to be kept
+ secret. Biometric authentication devices (e.g. fingerprint
+ readers, retinal scanners) do not rely on the fact that the data
+ is kept secret, but rather that the data is something that only
+ one user possesses and that cannot be forged.
+
+ The term secrets, as used in CC Part 2, while applicable to
+ authentication data, is intended to also be applicable to other
+ types of data that must be kept secret in order to enforce a
+ specific SFP. For example, a trusted channel mechanism that
+ relies on cryptography to preserve the confidentiality of
+ information being transmitted via the channel can only be as
+ strong as the method used to keep the cryptographic keys secret
+ from unauthorised disclosure.
+
+ Therefore, some, but not all, authentication data needs to be kept
+ secret and some, but not all, secrets are used as authentication
+ data. Figure shows this relationship
+ between secrets and authentication data. In the Figure the types
+ of data typically encountered in the authentication data and the
+ secrets sections are indicated.
+
+
+
+
+
+ This clause provides an overview of the evaluation process
+ and defines the tasks an evaluator is intended to perform when
+ conducting an evaluation.
+
+ Each evaluation, whether of a PP or TOE (including ST),
+ follows the same process, and has four evaluator tasks in
+ common: the input task, the output task, the evaluation
+ sub-activities, and the demonstration of the technical
+ competence to the evaluation authority task.
+
+ The input task and the output tasks, which are related to
+ management of evaluation evidence and to report generation,
+ are entirely described in this clause. Each task has
+ associated sub-tasks that apply to, and are normative for all
+ CC evaluations (evaluation of a PP or a TOE).
+
+ The evaluation sub-activities are only introduced in this
+ clause, and fully described in the following clauses.
+
+ In contrast to the evaluation sub-activities, input and output
+ tasks have no verdicts associated with them as they do not map
+ to CC evaluator action elements; they are performed in order
+ to ensure conformance with the universal principles and to
+ comply with the CEM.
+
+ The demonstration of the technical competence to the
+ evaluation authority task may be fulfilled by the evaluation
+ authority analysis of the output tasks results, or may include
+ the demonstration by the evaluators of their understanding of
+ the inputs for the evaluation sub-activities. This task has no
+ associated evaluator verdict, but has an evaluator authority
+ verdict. The detailed criteria to pass this task are left to
+ the discretion of the evaluation authority, as noted in Annex
+ .
+
+
+
+
+ This subclause presents the general model of the methodology
+ and identifies:
+
+
+ roles and responsibilities of the parties involved in
+ the evaluation process;
+
+
+ the general evaluation model.
+
+
+
+
+
+ The general model defines the following roles: sponsor,
+ developer, evaluator and evaluation authority.
+
+ The sponsor is responsible for requesting and supporting an
+ evaluation. This means that the sponsor establishes the
+ different agreements for the evaluation (e.g. commissioning
+ the evaluation). Moreover, the sponsor is responsible for
+ ensuring that the evaluator is provided with the evaluation
+ evidence.
+
+ The developer produces the TOE and is responsible for
+ providing the evidence required for the evaluation
+ (e.g. training, design information), on behalf of the
+ sponsor.
+
+ The evaluator performs the evaluation tasks required in the
+ context of an evaluation: the evaluator receives the
+ evaluation evidence from the developer on behalf of the
+ sponsor or directly from the sponsor, performs the
+ evaluation sub-activities and provides the results of the
+ evaluation assessment to the evaluation authority.
+
+ The evaluation authority establishes and maintains the
+ scheme, monitors the evaluation conducted by the evaluator,
+ and issues certification/validation reports as well as
+ certificates based on the evaluation results provided by the
+ evaluator.
+
+
+
+ To prevent undue influence from improperly affecting an
+ evaluation, some separation of roles is required. This
+ implies that the roles described above are fulfilled by
+ different entities, except that the roles of developer and
+ sponsor may be satisfied by a single entity.
+
+ Moreover, some evaluations (e.g. EAL1 evaluation) may not
+ require the developer to be involved in the project. In this
+ case, it is the sponsor who provides the TOE to the
+ evaluator and who generates the evaluation evidence.
+
+
+
+ The evaluation process consists of the evaluator performing
+ the evaluation input task, the evaluation output task and
+ the evaluation sub-activities. Figure provides an overview of
+ the relationship between these tasks and
+ sub-activities.
+
+
+ The evaluation process may be preceded by a preparation
+ phase where initial contact is made between the sponsor and
+ the evaluator. The work that is performed and the
+ involvement of the different roles during this phase may
+ vary. It is typically during this step that the evaluator
+ performs a feasibility analysis to assess the likelihood of
+ a successful evaluation.
+
+
+
+ The evaluator assigns verdicts to the requirements of the CC
+ and not to those of the CEM. The most granular CC structure
+ to which a verdict is assigned is the evaluator action
+ element (explicit or implied). A verdict is assigned to an
+ applicable CC evaluator action element as a result of
+ performing the corresponding CEM action and its constituent
+ work units. Finally, an evaluation result is assigned, as
+ described in CC Part 1, Clause .
+
+
+ The CEM recognises three mutually exclusive verdict states:
+
+
+ Conditions for a pass verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST or TOE under evaluation are met. The
+ conditions for passing the element are defined as:
+
+
+ the constituent work units of the related CEM
+ action, and;
+
+
+ all evaluation evidence required for performing
+ these work units is coherent, that is it can be
+ fully and completely understood by the evaluator,
+ and
+
+
+ all evaluation evidence required for performing
+ these work units does not have any obvious internal
+ inconsistencies or inconsistencies with other
+ evaluation evidence. Note that obvious means here
+ that the evaluator discovers this inconsistency
+ while performing the work units: the evaluator
+ should not undertake a full consistency analysis
+ across the entire evaluation evidence every time a
+ work unit is performed.
+
+
+
+
+ Conditions for a fail verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST, or TOE under evaluation are not met, or
+ that the evidence is incoherent, or an obvious
+ inconsistency in the evaluation evidence has been found;
+
+
+ All verdicts are initially inconclusive
+ and remain so until either a pass or
+ fail verdict is assigned.
+
+
+
+ The overall verdict is pass if and only if
+ all the constituent verdicts are also
+ pass. In the example illustrated in Figure
+ , if the verdict for one
+ evaluator action element is fail then the
+ verdicts for the corresponding assurance component,
+ assurance class, and overall verdict are also
+ fail.
+
+
+
+
+
+ The objective of this task is to ensure that the evaluator
+ has available the correct version of the evaluation evidence
+ necessary for the evaluation and that it is adequately
+ protected. Otherwise, the technical accuracy of the
+ evaluation cannot be assured, nor can it be assured that the
+ evaluation is being conducted in a way to provide repeatable
+ and reproducible results.
+
+
+
+ The responsibility to provide all the required evaluation
+ evidence lies with the sponsor. However, most of the
+ evaluation evidence is likely to be produced and supplied by
+ the developer, on behalf of the sponsor.
+
+ Since the assurance requirements apply to the entire TOE,
+ all evaluation evidence pertaining to all parts of the TOE
+ is to be made available to the evaluator. The scope and
+ required content of such evaluation evidence is independent
+ of the level of control that the developer has over each of
+ the parts of the TOE. For example, if design is required,
+ then the requirements will
+ apply to all subsystems that are part of the TSF. In
+ addition, assurance requirements that call for procedures to
+ be in place (for example,
+ and ) will also apply to the
+ entire TOE (including any part produced by another
+ developer).
+
+ It is recommended that the evaluator, in conjunction with
+ the sponsor, produce an index to required evaluation
+ evidence. This index may be a set of references to the
+ documentation. This index should contain enough information
+ (e.g. a brief summary of each document, or at least an
+ explicit title, indication of the subclauses of interest) to
+ help the evaluator to find easily the required
+ evidence.
+
+ It is the information contained in the evaluation evidence
+ that is required, not any particular document
+ structure. Evaluation evidence for a sub-activity may be
+ provided by separate documents, or a single document may
+ satisfy several of the input requirements of a
+ sub-activity.
+
+ The evaluator requires stable and formally-issued versions
+ of evaluation evidence. However, draft evaluation evidence
+ may be provided during an evaluation, for example, to help
+ an evaluator make an early, informal assessment, but is not
+ used as the basis for verdicts. It may be helpful for the
+ evaluator to see draft versions of particular appropriate
+ evaluation evidence, such as:
+
+
+ test documentation, to allow the evaluator to make an
+ early assessment of tests and test procedures;
+
+
+ design documents, to provide the evaluator with
+ background for understanding the TOE design;
+
+
+ source code or hardware drawings, to allow the evaluator
+ to assess the application of the developer's standards.
+
+
+
+ Draft evaluation evidence is more likely to be encountered
+ where the evaluation of a TOE is performed concurrently with
+ its development. However, it may also be encountered during
+ the evaluation of an already-developed TOE where the
+ developer has had to perform additional work to address a
+ problem identified by the evaluator (e.g. to correct an
+ error in design or implementation) or to provide evaluation
+ evidence of security that is not provided in the existing
+ documentation (e.g. in the case of a TOE not originally
+ developed to meet the requirements of the CC).
+
+
+
+
+ The evaluator shall perform configuration control of the
+ evaluation evidence.
+
+ The CC implies that the evaluator is able to identify and
+ locate each item of evaluation evidence after it has been
+ received and is able to determine whether a specific
+ version of a document is in the evaluator's
+ possession.
+
+ The evaluator shall protect the evaluation evidence from
+ alteration or loss while it is in the evaluator's
+ possession.
+
+
+
+ Schemes may wish to control the disposal of evaluation
+ evidence at the conclusion of an evaluation. The disposal
+ of the evaluation evidence should be achieved by one or
+ more of:
+
+
+ returning the evaluation evidence;
+
+
+ archiving the evaluation evidence;
+
+
+ destroying the evaluation evidence.
+
+
+
+
+
+ An evaluator may have access to sponsor and developer
+ commercially-sensitive information (e.g. TOE design
+ information, specialist tools), and may have access to
+ nationally-sensitive information during the course of an
+ evaluation. Schemes may wish to impose requirements for
+ the evaluator to maintain the confidentiality of the
+ evaluation evidence. The sponsor and evaluator may
+ mutually agree to additional requirements as long as these
+ are consistent with the scheme.
+
+ Confidentiality requirements affect many aspects of
+ evaluation work, including the receipt, handling, storage
+ and disposal of evaluation evidence.
+
+
+
+
+
+ The evaluation sub-activities vary depending whether it is a
+ PP or a TOE evaluation. Moreover, in the case of a TOE
+ evaluation, the sub-activities depend upon the selected
+ assurance requirements.
+
+
+
+
+ The objective of this Subclause is to describe the Observation
+ Report (OR) and the Evaluation Technical Report
+ (ETR). Schemes may require additional evaluator reports such
+ as reports on individual units of work, or may require
+ additional information to be contained in the OR and the
+ ETR. The CEM does not preclude the addition of information
+ into these reports as the CEM specifies only the minimum
+ information content.
+
+ Consistent reporting of evaluation results facilitates the
+ achievement of the universal principle of repeatability and
+ reproducibility of results. The consistency covers the type and
+ the amount of information reported in the ETR and OR. ETR and OR
+ consistency among different evaluations is the responsibility of
+ the evaluation authority.
+
+ The evaluator performs the two following sub-tasks in order
+ to achieve the CEM requirements for the information content
+ of reports:
+
+
+ write OR sub-task (if needed in the context of the
+ evaluation);
+
+
+ write ETR sub-task.
+
+
+
+
+
+ The evaluator delivers the ETR to the evaluation authority,
+ as well as any ORs as they become available. Requirements
+ for controls on handling the ETR and ORs are established by
+ the scheme which may include delivery to the sponsor or
+ developer. The ETR and ORs may include sensitive or
+ proprietary information and may need to be sanitised before
+ they are given to the sponsor.
+
+
+
+ In this version of the CEM, the requirements for the
+ provision of evaluator evidence to support re-evaluation and
+ re-use have not been explicitly stated. Where information
+ for re-evaluation or re-use is required by the sponsor, the
+ scheme under which the evaluation is being performed should
+ be consulted.
+
+
+
+ ORs provide the evaluator with a mechanism to request a
+ clarification (e.g. from the evaluation authority on the application of a
+ requirement) or to identify a problem with an aspect of the
+ evaluation.
+
+ In the case of a fail verdict, the evaluator shall provide
+ an OR to reflect the evaluation result. Otherwise, the
+ evaluator may use ORs as one way of expressing clarification
+ needs.
+
+ For each OR, the evaluator shall report the following:
+
+
+ the identifier of the PP or TOE evaluated;
+
+
+ the evaluation task/sub-activity during which the
+ observation was generated;
+
+
+ the observation;
+
+
+ the assessment of its severity (e.g. implies a fail
+ verdict, holds up progress on the evaluation, requires a
+ resolution prior to evaluation being completed);
+
+
+ the identification of the organisation responsible for
+ resolving the issue;
+
+
+ the recommended timetable for resolution;
+
+
+ the assessment of the impact on the evaluation of
+ failure to resolve the observation.
+
+
+
+ The intended audience of an OR and procedures for handling the
+ report depend on the nature of the report's content and on the
+ scheme. Schemes may distinguish different types of ORs or define
+ additional types, with associated differences in required
+ information and distribution (e.g. evaluation ORs to evaluation authorities
+ and sponsors).
+
+
+
+
+ The evaluator shall provide an ETR to present technical
+ justification of the verdicts.
+
+ The CEM defines the ETR's minimum content requirement;
+ however, schemes may specify additional content and
+ specific presentational and structural requirements. For
+ instance, schemes may require that certain introductory
+ material (e.g. disclaimers and copyright Clauses) be
+ reported in the ETR.
+
+ The reader of the ETR is assumed to be familiar with
+ general concepts of information security, the CC, the CEM,
+ evaluation approaches and IT.
+
+ The ETR supports the evaluation authority to confirm that
+ the evaluation was done to the required standard, but it
+ is anticipated that the documented results may not provide
+ all of the necessary information, so additional
+ information specifically requested by the scheme may be
+ necessary. This aspect is outside the scope of the
+ CEM.
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a PP evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report PP configuration control
+ identifiers.
+
+ PP configuration control identifiers (e.g. name, date and
+ version number) are required to identify what is being evaluated
+ in order for the evaluation authority to verify that the verdicts have been
+ assigned correctly by the evaluator.
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the PP developer is required to identify
+ the party responsible for producing the PP.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator references the evaluation criteria,
+ methodology and interpretations used to evaluate the
+ PP.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the handling of evaluation
+ results and assumptions made during the evaluation that
+ have an impact on the evaluation results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ The evaluator shall report a verdict and a supporting
+ rationale for each assurance component that constitutes
+ an activity, as a result of
+ performing the corresponding CEM action and its
+ constituent work units.
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, in particular the overall verdict as defined
+ in CC Part 1 Clause , and determined by application
+ of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be useful for
+ the evaluation authority. These recommendations may include shortcomings of
+ the PP discovered during the evaluation or mention of features
+ which are particularly useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a TOE evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report ST and TOE configuration
+ control identifiers.
+
+ ST and TOE configuration control identifiers identify
+ what is being evaluated in order for the evaluation authority to
+ verify that the verdicts have been assigned correctly by
+ the evaluator.
+
+ If the ST claims that the TOE conforms to the
+ requirements of one or more PPs, the ETR shall report
+ the reference of the corresponding PPs.
+
+ The PPs reference contains information that uniquely
+ identifies the PPs (e.g. title, date, and version
+ number).
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the TOE developer is required to
+ identify the party responsible for producing the
+ TOE.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report a high level description of
+ the TOE and its major components based on the evaluation
+ evidence described in the CC assurance family entitled
+ , where
+ applicable.
+
+ The intent of this Subclause is to characterise the degree
+ of architectural separation of the major components. If
+ there is no requirement
+ in the ST, this is not applicable and is considered to
+ be satisfied.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator may reference the evaluation criteria,
+ methodology and interpretations used to evaluate the TOE
+ or the devices used to perform the tests.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the distribution of
+ evaluation results and assumptions made during the
+ evaluation that have an impact on the evaluation
+ results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ For each activity on which the TOE is evaluated, the
+ evaluator shall report:
+
+
+ the title of the activity considered;
+
+
+ a verdict and a supporting rationale for each
+ assurance component that constitutes this activity,
+ as a result of performing the corresponding CEM
+ action and its constituent work units.
+
+
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+ The evaluator shall report all information specifically
+ required by a work unit.
+
+ For the and activities, work units that identify
+ information to be reported in the ETR have been
+ defined.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, which will relate to whether the TOE has
+ satisfied its associated ST, in particular the overall
+ verdict as defined in CC Part 1 Clause , and determined by
+ application of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be useful for
+ the evaluation authority. These recommendations may include shortcomings of
+ the IT product discovered during the evaluation or mention of
+ features which are particularly useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+
+
+ The CC permits comparability between the results of independent
+ security evaluations. The CC does so by providing a common set
+ of requirements for the security functionality of IT products
+ and for assurance measures applied to these IT products during a
+ security evaluation. These IT products may be implemented in
+ hardware, firmware or software.
+ The evaluation process establishes a level of confidence that
+ the security functionality of these IT products and the
+ assurance measures applied to these IT products meet these
+ requirements. The evaluation results may help consumers to
+ determine whether these IT products fulfil their security needs.
+ The CC is useful as a guide for the development, evaluation
+ and/or procurement of IT products with security functionality.
+ The CC is intentionally flexible, enabling a range of evaluation
+ methods to be applied to a range of security properties of a
+ range of IT products. Therefore users of the standard are
+ cautioned to exercise care that this flexibility is not
+ misused. For example, using the CC in conjunction with
+ unsuitable evaluation methods, irrelevant security properties,
+ or inappropriate IT products, may result in meaningless
+ evaluation results.
+ Consequently, the fact that an IT product has been evaluated has
+ meaning only in the context of the security properties that were
+ evaluated and the evaluation methods that were used. Evaluation
+ authorities are advised to carefully check the products,
+ properties and methods to determine that an evaluation will
+ provide meaningful results. Additionally, purchasers of
+ evaluated products are advised to carefully consider this
+ context to determine whether the evaluated product is useful and
+ applicable to their specific situation and needs.
+ The CC addresses protection of assets from unauthorised
+ disclosure, modification, or loss of use. The categories of
+ protection relating to these three types of failure of security
+ are commonly called confidentiality, integrity, and
+ availability, respectively. The CC may also be applicable
+ to aspects of IT security outside of these three. The CC
+ is applicable to risks arising from human activities (malicious
+ or otherwise) and to risks arising from non-human
+ activities. Apart from IT security, the CC may be applied
+ in other areas of IT, but makes no claim of applicability in
+ these areas.
+ Certain topics, because they involve specialised techniques or
+ because they are somewhat peripheral to IT security, are
+ considered to be outside the scope of the CC. Some of these are
+ identified below.
+
+ The CC does not contain security evaluation criteria
+ pertaining to administrative security measures not related
+ directly to the IT security functionality. However, it is
+ recognised that significant security can often be achieved
+ through or supported by administrative measures such as
+ organisational, personnel, physical, and procedural
+ controls.
+
+ The evaluation of some technical physical aspects of IT
+ security such as electromagnetic emanation control is not
+ specifically covered, although many of the concepts
+ addressed will be applicable to that area.
+
+ The CC does not address the evaluation methodology
+ under which the criteria should be applied. This methodology
+ is given in the CEM.
+
+ The CC does not address the administrative and legal
+ framework under which the criteria may be applied by
+ evaluation authorities. However, it is expected that the CC
+ will be used for evaluation purposes in the context of such
+ a framework.
+
+ The procedures for use of evaluation results in
+ accreditation are outside the scope of the CC. Accreditation
+ is the administrative process whereby authority is granted
+ for the operation of an IT product (or collection thereof)
+ in its full operational environment including all of its
+ non-IT parts. The results of the evaluation process are an
+ input to the accreditation process. However, as other
+ techniques are more appropriate for the assessments of
+ non-IT related properties and their relationship to the IT
+ security parts, accreditors should make separate provisions
+ for those aspects.
+
+ The subject of criteria for the assessment of the inherent
+ qualities of cryptographic algorithms is not covered in the
+ CC. Should independent assessment of mathematical properties
+ of cryptography be required, the evaluation scheme under
+ which the CC is applied must make provision for such
+ assessments.
+
+ ISO terminology, such as "can", "informative", "may",
+ "normative", "shall" and "should" used throughout the document
+ are defined in the ISO/IEC Directives, Part 2. Note that the
+ term "should" has an additional meaning applicable when using
+ this standard. See the note below. The following definition is
+ given for the use of ``should'' in the CC.
+ should
+
+ within normative text, ``should'' indicates ``that among
+ several possibilities one is recommended as particularly
+ suitable, without mentioning or excluding others, or that a
+ certain course of action is preferred but not necessarily
+ required.'' (ISO/IEC Directives, Part 2).
+
+ The CC interprets ``not necessarily required'' to mean
+ that the choice of another possibility requires a justification
+ of why the preferred option was not chosen.
+
+ This part of the CC establishes the general concepts and
+ principles of IT security evaluation and specifies the general
+ model of evaluation given by various parts of the standard which
+ in its entirety is meant to be used as the basis for evaluation
+ of security properties of IT products.
+ Part one provides an overview of all parts of the CC
+ standard. It describes the various parts of the standard;
+ defines the terms and abbreviations to be used in all parts of
+ the standard; establishes the core concept of a Target of
+ Evaluation (TOE); the evaluation context and describes the
+ audience to which the evaluation criteria are addressed. An
+ introduction to the basic security concepts necessary for
+ evaluation of IT products is given.
+ It defines the various operations by which the functional and
+ assurance components given in CC Part 2 and CC Part 3 may be
+ tailored through the use of permitted operations.
+ The key concepts of protection profiles (PP), packages of
+ security requirements and the topic of conformance are specified
+ and the consequences of evaluation, evaluation results are
+ described. This part of the CC gives guidelines for the
+ specification of Security Targets (ST) and provides a
+ description of the organization of components throughout the
+ model. General information about the evaluation methodology are
+ given in the CEM and the scope of evaluation schemes is
+ provided.
+ The following referenced documents are indispensable for the
+ application of this CC part 1. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.CC-2
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 2: Functional security components.
+ CC-3
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 3: Assurance security components.
+ CEM
+ Common Methodology for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+ For the purpose of the CC, the following terms and definitions
+ apply.
+ This Clause contains only
+ those terms which are used in a specialised way throughout the
+ CC. Some combinations of common terms used in the CC, while not
+ meriting inclusion in this Clause , are explained for clarity in the context
+ where they are used.
+ adverse actions
+
+ actions performed by a threat agent on an asset
+
+ assets
+
+ entities that the owner of the TOE presumably places value upon
+
+ assignment
+
+ the specification of an identified parameter in a component
+ (of the CC) or requirement
+
+ assurance
+
+ grounds for confidence that a TOE meets the SFRs
+
+ attack potential
+
+ measure of the effort to be expended in attacking a TOE,
+ expressed in terms of an attacker's expertise, resources and
+ motivation
+
+ augmentation
+
+ addition of one or more requirement(s) to a package
+
+ authentication data
+
+ information used to verify the claimed identity of a user
+
+ authorised user
+
+ TOE user who may, in accordance with the SFRs, perform an operation
+
+ class
+
+ set of CC families that share a common focus
+
+ coherent
+
+ logically ordered and having discernible meaning
+
+ For documentation, this addresses both the actual text and
+ the structure of the document, in terms of whether it is
+ understandable by its target audience.
+
+ complete
+
+ property where all necessary parts of an entity have been provided
+
+ In terms of documentation, this means that all relevant
+ information is covered in the documentation, at such a level
+ of detail that no further explanation is required at that
+ level of abstraction.
+
+ component
+
+ smallest selectable set of elements on which requirements
+ may be based
+
+ composed assurance package
+
+ assurance package consisting of requirements drawn from
+ CC Part 3 (predominately from the class), representing a point on the CC
+ predefined composition assurance scale
+
+ confirm
+
+ declare that something has been reviewed in detail with an
+ independent determination of sufficiency
+
+ The level of rigour required depends on the nature of the subject
+ matter. This term is only applied to evaluator actions.
+
+ connectivity
+
+ property of the TOE allowing interaction with IT entities
+ external to the TOE
+
+ This includes exchange of data by wire or by wireless means,
+ over any distance in any environment or configuration.
+
+ consistent
+
+ relationship between two or more entities such that there
+ are no apparent contradictions between these entities
+
+ counter, verb
+
+ meet an attack where the impact of a particular threat is
+ mitigated but not necessarily eradicated
+
+ demonstrable conformance
+
+ relation between an ST and a PP, where the ST provides a
+ solution which solves the generic security problem in the PP
+
+ The PP and the ST may contain entirely different statements
+ that discuss different entities, use different concepts
+ etc. Demonstrable conformance is also suitable for a TOE
+ type where several similar PPs already exist, thus allowing
+ the ST author to claim conformance to these PPs
+ simultaneously, thereby saving work.
+
+ demonstrate
+
+ provide a conclusion gained by an analysis which is less
+ rigorous than a ``proof''
+
+ dependency
+
+ relationship between components such that if a requirement
+ based on the depending component is included in a PP, ST or
+ package, a requirement based on the component that is
+ depended upon must normally also be included in the PP, ST
+ or package
+
+ describe
+
+ provide specific details of an entity
+
+ determine
+
+ affirm a particular conclusion based on independent analysis
+ with the objective of reaching a particular conclusion
+
+ The usage of this term implies a truly independent analysis,
+ usually in the absence of any previous analysis having been
+ performed. Compare with the terms ``confirm'' or
+ ``verify'' which imply that an analysis has already been
+ performed which needs to be reviewed
+
+ development environment
+
+ environment in which the TOE is developed
+
+ element
+
+ indivisible statement of a security need
+
+ ensure
+
+ guarantee a strong causal relationship between an action and
+ its consequences
+
+ When this term is preceded by the word ``help'' it indicates
+ that the consequence is not fully certain, on the basis of
+ that action alone.
+
+ evaluation
+
+ assessment of a PP, an ST or a TOE, against defined criteria
+
+ evaluation assurance level
+
+ set of assurance requirements drawn from CC Part 3,
+ representing a point on the CC predefined assurance scale,
+ that form an assurance package
+
+ evaluation authority
+
+ body that sets the standards and monitors the quality of
+ evaluations conducted by bodies within a specific community
+ and implements the CC for that community by means of an
+ evaluation scheme
+
+ evaluation scheme
+
+ administrative and regulatory framework under which the CC
+ is applied by an evaluation authority within a specific
+ community
+
+ exhaustive
+
+ characteristic of a methodical approach taken to perform an
+ analysis or activity according to an unambiguous plan
+
+ This term is used in the CC with respect to conducting an
+ analysis or other activity. It is related to ``systematic''
+ but is considerably stronger, in that it indicates not only
+ that a methodical approach has been taken to perform the
+ analysis or activity according to an unambiguous plan, but
+ that the plan that was followed is sufficient to ensure that
+ all possible avenues have been exercised.
+
+ explain
+
+ give argument accounting for the reason for taking a course
+ of action
+
+ This term differs from both ``describe'' and
+ ``demonstrate''. It is intended to answer the question
+ ``Why?'' without actually attempting to argue that the
+ course of action that was taken was necessarily optimal.
+
+ extension
+
+ addition to an ST or PP of functional requirements not
+ contained in CC Part 2 and/or assurance requirements not
+ contained in CC Part 3
+
+ external entity
+
+ human or IT entity possibly interacting with the TOE from
+ outside of the TOE boundary
+
+ family
+
+ set of components that share a similar goal but differ in
+ emphasis or rigour
+
+ formal
+
+ expressed in a restricted syntax language with defined
+ semantics based on well-established mathematical concepts
+
+ guidance documentation
+
+ documentation that describes the delivery, preparation,
+ operation, management and/or use of the TOE
+
+ identity
+
+ representation uniquely identifying entities (e.g. a user, a
+ process or a disk) within the context of the TOE
+
+ An example of such a representation is a string. For a human
+ user, the representation can be the full or abbreviated name
+ or a (still unique) pseudonym.
+
+ informal
+
+ expressed in natural language
+
+ inter TSF transfers
+
+ communicating data between the TOE and the security
+ functionality of other trusted IT products
+
+ internal communication channel
+
+ communication channel between separated parts of the TOE
+
+ internal TOE transfer
+
+ communicating data between separated parts of the TOE
+
+ internally consistent
+
+ no apparent contradictions exist between any aspects of an
+ entity
+
+ In terms of documentation, this means that there can be no
+ statements within the documentation that can be taken to
+ contradict each other.
+
+ iteration
+
+ use of the same component to express two or more distinct
+ requirements
+
+ justification
+
+ analysis leading to a conclusion
+
+ ``Justification'' is more rigorous than a
+ demonstration. This term requires significant rigour in
+ terms of very carefully and thoroughly explaining every step
+ of a logical argument.
+
+ object
+
+ passive entity in the TOE, that contains or receives
+ information, and upon which subjects perform operations
+
+ operation (on a component of the CC)
+
+ modification or repetition of a component
+
+ Allowed operations on components are assignment, iteration,
+ refinement and selection.
+
+ operation (on an object)
+
+ specific type of action performed by a subject on an object
+
+ operational environment
+
+ environment in which the TOE is operated
+
+ organisational security policy
+
+ set of security rules, procedures, or guidelines for an
+ organisation
+
+ A policy may pertain to a specific operational environment.
+
+ package
+
+ named set of either security functional or security
+ assurance requirements
+
+ An example of a package is ``EAL 3''.
+
+ Protection Profile evaluation
+
+ assessment of a PP against defined criteria
+
+ Protection Profile
+
+ implementation-independent statement of security needs for a
+ TOE type
+
+ prove
+
+ show correspondence by formal analysis in its mathematical
+ sense
+
+ It is completely rigorous in all ways. Typically, ``prove''
+ is used when there is a desire to show correspondence
+ between two TSF representations at a high level of rigour.
+
+ refinement
+
+ addition of details to a component
+
+ role
+
+ predefined set of rules establishing the allowed
+ interactions between a user and the TOE
+
+ secret
+
+ information that must be known only to authorised users
+ and/or the TSF in order to enforce a specific SFP
+
+ secure state
+
+ state in which the TSF data are consistent and the TSF
+ continues correct enforcement of the SFRs
+
+ security attribute
+
+ property of subjects, users (including external IT
+ products), objects, information, sessions and/or resources
+ that is used in defining the SFRs and whose values are used
+ in enforcing the SFRs
+
+ security function policy
+
+ set of rules describing specific security behaviour enforced
+ by the TSF and expressible as a set of SFRs
+
+ security objective
+
+ statement of an intent to counter identified threats and/or
+ satisfy identified organisation security policies and/or
+ assumptions
+
+ security problem
+
+ statement which in a formal manner defines the nature and
+ scope of the security that the TOE is intended to address
+
+ This statement consists of a combination of:
+
+ threats to be countered by the TOE and its operational environment,
+
+ the OSPs enforced by the TOE and its operational environment, and
+
+ the assumptions that are upheld for the operational environment of the TOE.
+
+ security requirement
+
+ requirement, stated in a standardised language, which is
+ meant to contribute to achieving the security objectives for
+ a TOE
+
+ Security Target
+
+ implementation-dependent statement of security needs for a
+ specific identified TOE
+
+ selection
+
+ specification of one or more items from a list in a component
+
+ semiformal
+
+ expressed in a restricted syntax language with defined semantics
+
+ specify
+
+ provide specific details about an entity in a rigorous and precise manner
+
+ strict conformance
+
+ hierarchical relationship between a PP and an ST where all
+ the requirements in the PP also exist in the ST
+
+ This relation can be roughly defined as ``the ST shall
+ contain all statements that are in the PP, but may contain
+ more''. Strict conformance is expected to be used for
+ stringent requirements that are to be adhered to in a single
+ manner.
+
+ ST evaluation
+
+ assessment of an ST against defined criteria
+
+ subject
+
+ active entity in the TOE that performs operations on objects
+
+ target of evaluation
+
+ set of software, firmware and/or hardware possibly
+ accompanied by guidance
+
+ threat agent
+
+ entity that can adversely act on assets
+
+ TOE evaluation
+
+ assessment of a TOE against defined criteria
+
+ TOE resource
+
+ anything useable or consumable in the TOE
+
+ TOE security functionality
+
+ combined functionality of all hardware, software, and
+ firmware of a TOE that must be relied upon for the correct
+ enforcement of the SFRs
+
+ trace, verb
+
+ perform an informal correspondence analysis between two
+ entities with only a minimal level of rigour
+
+ transfers outside of the TOE
+
+ TSF mediated communication of data to entities not under the
+ control of the TSF
+
+ translation
+
+ describes the process of describing security requirements in
+ a standardised language.
+
+ use of the term translation in this context is not literal
+ and does not imply that every SFR expressed in standardised
+ language can also be translated back to the security
+ objectives.
+
+ trusted channel
+
+ a means by which a TSF and another trusted IT product can
+ communicate with necessary confidence
+
+ trusted IT product
+
+ IT product, other than the TOE, which has its security
+ functional requirements administratively coordinated with
+ the TOE and which is assumed to enforce its security
+ functional requirements correctly
+
+ An example of a trusted IT product would be one that has
+ been separately evaluated.
+
+ trusted path
+
+ means by which a user and a TSF can communicate with the
+ necessary confidence
+
+ TSF data
+
+ data for the operation of the TOE upon which the enforcement
+ of the SFR relies
+
+ TSF interface
+
+ means by which external entities (or subjects in the TOE but
+ outside of the TSF) supply data to the TSF, receive data
+ from the TSF and invoke services from the TSF
+
+ user
+
+ see external entity
+
+ user data
+
+ data for the user, that does not affect the operation of the TSF
+
+ verify
+
+ rigorously review in detail with an independent
+ determination of sufficiency
+
+ Also see ``confirm''. This term has more rigorous
+ connotations. The term ``verify'' is used in the context
+ of evaluator actions where an independent effort is required
+ of the evaluator.
+
+ The following terms are used in the requirements for software
+ internal structuring. Some of these are derived from the
+ IEEE Std 610.12-1990,
+ Standard glossary of software engineering terminology,
+ Institute of Electrical and Electronics Engineers.
+ administrator
+
+ entity that has a level of trust with respect to all
+ policies implemented by the TSF
+
+ Not all PPs or STs assume the same level of trust for
+ administrators. Typically administrators are assumed to
+ adhere at all times to the policies in the ST of the
+ TOE. Some of these policies may be related to the
+ functionality of the TOE, others may be related to the
+ operational environment.
+
+ call tree
+
+ identifies the modules in a system in diagrammatic form
+ showing which modules call one another
+
+ Adapted from
+ cohesion
+
+ module strength
+
+ manner and degree to which the tasks performed by a single
+ software module are related to one another
+
+ Types of cohesion include coincidental, communicational,
+ functional, logical, sequential, and temporal. These types
+ of cohesion are described by the relevant term entry.
+
+ coincidental cohesion
+
+ module with the characteristic of performing unrelated, or
+ loosely related, activities
+
+ See ``cohesion''.
+
+ communicational cohesion
+
+ module containing functions that produce output for, or use
+ output from, other functions within the module
+
+ See ``cohesion''.
+ An example of a communicationally cohesive module is an
+ access check module that includes mandatory,
+ discretionary, and capability checks.
+ complexity
+
+ measure of how difficult software is to understand, and thus
+ to analyse, test, and maintain
+
+ Reducing complexity is the ultimate goal for using modular
+ decomposition, layering and minimisation. Controlling
+ coupling and cohesion contributes significantly to this
+ goal.
+ A good deal of effort in the software engineering field
+ has been expended in attempting to develop metrics to
+ measure the complexity of source code. Most of these
+ metrics use easily computed properties of the source code,
+ such as the number of operators and operands, the
+ complexity of the control flow graph (cyclomatic
+ complexity), the number of lines of source code, the ratio
+ of comments to executable code, and similar
+ measures. Coding standards have been found to be a useful
+ tool in generating code that is more readily understood.
+ The family calls for a complexity
+ analysis in all components. It is expected that the
+ developer will provide support for the claims that there
+ has been a sufficient reduction in complexity. This
+ support could include the developer's programming
+ standards, and an indication that all modules meet the
+ standard (or that there are some exceptions that are
+ justified by software engineering arguments). It could
+ include the results of tools used to measure some of the
+ properties of the source code, or it could include other
+ support that the developer finds appropriate.
+ coupling
+
+ manner and degree of interdependence between software modules
+
+ Types of coupling include call, common and content
+ coupling. These are characterised below:
+
+ call coupling
+
+ relationship between two modules
+
+ Examples of call coupling are data, stamp, and control:
+
+ call coupling (data)
+
+ relationship between two modules communicating strictly
+ through the use of call parameters that represent single
+ data items.
+
+ See ``call coupling''
+
+ call coupling (stamp)
+
+ relationship between two modules through the use of call
+ parameters that comprise multiple fields or that have
+ meaningful internal structures.
+
+ See ``call coupling''
+
+ call coupling (control)
+
+ relationship between two modules if one passes information
+ that is intended to influence the internal logic of the
+ other.
+
+ See ``call coupling''
+
+ common coupling
+
+ relationship between two modules sharing a common data area
+ or other common system resource
+
+ Global variables indicate that modules using those global
+ variables are common coupled. Common coupling through global
+ variables is generally allowed, but only to a limited
+ degree.
+ For example, variables that are placed into a global area,
+ but are used by only a single module, are inappropriately
+ placed, and should be removed. Other factors that need to
+ be considered in assessing the suitability of global
+ variables are:
+
+ The number of modules that modify a global variable:
+ In general, only a single module should be allocated
+ the responsibility for controlling the contents of a
+ global variable, but there may be situations in which
+ a second module may share that responsibility; in such
+ a case, sufficient justification must be provided. It
+ is unacceptable for this responsibility to be shared
+ by more than two modules. (In making this assessment,
+ care should be given to determining the module
+ actually responsible for the contents of the variable;
+ for example, if a single routine is used to modify the
+ variable, but that routine simply performs the
+ modification requested by its caller, it is the
+ calling module that is responsible, and there may be
+ more than one such module). Further, as part of the
+ complexity determination, if two modules are
+ responsible for the contents of a global variable,
+ there should be clear indications of how the
+ modifications are coordinated between them.
+
+ The number of modules that reference a global
+ variable: Although there is generally no limit on the
+ number of modules that reference a global variable,
+ cases in which many modules make such a reference
+ should be examined for validity and necessity.
+
+ content coupling
+
+ relationship between two modules where one makes direct
+ reference to the internals of the other
+
+ Examples include modifying code of, or referencing labels
+ internal to, the other module. The result is that some or
+ all of the content of one module are effectively included in
+ the other. Content coupling can be thought of as using
+ unadvertised module interfaces; this is in contrast to call
+ coupling, which uses only advertised module interfaces.
+
+ domain separation
+
+ security architecture property whereby the TSF defines
+ separate security domains for each user and for the TSF and
+ ensures that no user process can affect the contents of a
+ security domain of another user or of the TSF
+
+ functional cohesion
+
+ functional property of a module which performs activities
+ related to a single purpose
+
+ A functionally cohesive module transforms a single type of
+ input into a single type of output, such as a stack manager or
+ a queue manager. See also ``cohesion''.
+
+ interaction
+
+ general communication-based activity between entities
+
+ interface
+
+ means of interaction with a component or module
+
+ layering
+
+ design technique where separate groups of modules (the
+ layers) are hierarchically organised to have separate
+ responsibilities such that one layer depends only on layers
+ below it in the hierarchy for services, and provides its
+ services only to the layers above it
+
+ Strict layering adds the constraint that each layer receives
+ services only from the layer immediately beneath it, and
+ provides services only to the layer immediately above it.
+
+ logical cohesion
+
+ procedural cohesion
+
+ characteristics of a module performing similar activities on
+ different data structures
+
+ A module exhibits logical cohesion if its functions perform
+ related, but different, operations on different inputs. See
+ also ``cohesion''.
+
+ modular decomposition
+
+ process of breaking a system into components to facilitate
+ design, development and evaluation
+
+ non-bypassability (of the TSF)
+
+ security architecture property whereby all SFR-related
+ actions are mediated by the TSF
+
+ procedural cohesion
+
+ See ``logical cohesion''
+
+ security domains
+
+ environments provided by the TSF for the use by untrusted entities in such a way that these environments are isolated and protected from each other
+
+ sequential cohesion
+
+ module containing functions each of whose output is input
+ for the following function in the module
+
+ An example of a sequentially cohesive module is one that
+ contains the functions to write audit records and to
+ maintain a running count of the accumulated number of audit
+ violations of a specified type.
+
+ software engineering
+
+ application of a systematic, disciplined, quantifiable
+ approach to the development and maintenance of software;
+ that is, the application of engineering to software
+
+ As with engineering practices in general, some amount of
+ judgement must be used in applying engineering
+ principles. Many factors affect choices, not just the
+ application of measures of modular decomposition, layering,
+ and minimisation. For example, a developer may design a
+ system with future applications in mind that will not be
+ implemented initially. The developer may choose to include
+ some logic to handle these future applications without fully
+ implementing them; further, the developer may include some
+ calls to as-yet unimplemented modules, leaving call
+ stubs. The developer's justification for such deviations
+ from well-structured programs will have to be assessed using
+ judgement, as well as the application of good software
+ engineering discipline.
+
+ temporal cohesion
+
+ characteristics of a module containing functions that need
+ to be executed at about the same time
+
+ Adapted from . Examples of temporally
+ cohesive modules include initialisation, recovery, and
+ shutdown modules.
+
+ TSF self-protection
+
+ security architecture property whereby the TSF cannot be
+ corrupted by non-TSF code or entities
+
+ installation
+
+ procedure performed by a human user embedding the TOE in its
+ operational environment and putting it into an operational
+ state
+
+ This operation is performed normally only once, after
+ receipt and acceptance of the TOE. The TOE is expected to be
+ progressed to a configuration allowed by the ST. If similar
+ processes have to be performed by the developer they are
+ denoted as ``generation'' throughout . If
+ the TOE requires an initial start-up that does not need to
+ be repeated regularly, this process would be classified as
+ installation.
+
+ operation
+
+ usage phase of the TOE including ``normal usage'',
+ administration and maintenance of the TOE after delivery and
+ preparation
+
+ preparation
+
+ activity in the life-cycle phase of a product, comprising
+ the customer's acceptance of the delivered TOE and its
+ installation which may include such things as booting,
+ initialisation, start-up and progressing the TOE to a state
+ ready for operation
+
+ acceptance criteria
+
+ criteria to be applied when performing the acceptance
+ procedures (e.g. successful document review, or successful
+ testing in the case of software, firmware or hardware)
+
+ acceptance procedures
+
+ procedures followed in order to accept newly created or
+ modified configuration items as part of the TOE, or to move
+ them to the next step of the life-cycle
+
+ These procedures identify the roles or individuals
+ responsible for the acceptance and the criteria to be
+ applied in order to decide on the acceptance.
+ There are several types of acceptance situations some of
+ which may overlap:
+
+ acceptance of an item into the configuration
+ management system for the first time, in particular
+ inclusion of software, firmware and hardware
+ components from other manufacturers into the TOE
+ (``integration'');
+
+ progression of configuration items to the next
+ life-cycle phase at each stage of the construction of
+ the TOE (e.g. module, subsystem, quality control of
+ the finished TOE);
+
+ subsequent to transports of configuration items (for
+ example parts of the TOE or preliminary products)
+ between different development sites;
+
+ subsequent to the delivery of the TOE to the consumer.
+
+ configuration management
+
+ discipline applying technical and administrative direction
+ and surveillance to: identify and document the functional
+ and physical characteristics of a configuration item,
+ control changes to those characteristics, record and report
+ change processing and implementation status, and verify
+ compliance with specified requirements.
+
+ CM documentation
+
+ all CM documentation including CM output, CM list
+ (configuration list), CM system records, CM plan and CM
+ usage documentation
+
+ configuration management evidence
+
+ everything that may be used to establish confidence in the
+ correct operation of the CM system
+
+ For example, CM output, rationales provided by the
+ developer, observations, experiments or interviews made by
+ the evaluator during a site visit.
+
+ configuration item
+
+ object managed by the CM system during the TOE development
+
+ These may be either parts of the TOE or objects related to
+ the development of the TOE like evaluation documents or
+ development tools. CM items may be stored in the CM system
+ directly (for example files) or by reference (for example
+ hardware parts) together with their version.
+
+ configuration list
+
+ configuration management output document listing all
+ configuration items for a specific product together with the
+ exact version of each configuration management item relevant
+ for a specific version of the complete product
+
+ This list allows distinguishing the items belonging to the
+ evaluated version of the product from other versions of
+ these items belonging to other versions of the product. The
+ final configuration management list is a specific document
+ for a specific version of a specific product. (Of course the
+ list can be an electronic document inside of a configuration
+ management tool. In that case it can be seen as a specific
+ view into the system or a part of the system rather than an
+ output of the system. However, for the practical use in an
+ evaluation the configuration list will probably be delivered
+ as a part of the evaluation documentation.) The
+ configuration list defines the items that are under the
+ configuration management requirements of .
+
+ configuration management output
+
+ results, related to configuration management, produced or
+ enforced by the configuration management system
+
+ These configuration management related results could occur
+ as documents (for example filled paper forms, configuration
+ management system records, logging data, hard-copies and
+ electronic output data) as well as actions (for example
+ manual measures to fulfil configuration management
+ instructions). Examples of such configuration management
+ outputs are configuration lists, configuration management
+ plans and/or behaviours during the product life-cycle.
+
+ configuration management plan
+
+ description of how the configuration management system is
+ used for the TOE
+
+ The objective of issuing a configuration management plan is
+ that staff members can see clearly what they have to
+ do. From the point of view of the overall configuration
+ management system this can be seen as an output document
+ (because it may be produced as part of the application of
+ the configuration management system). From the point of view
+ of the concrete project it is a usage document because
+ members of the project team use it in order to understand
+ the steps that they have to perform during the project. The
+ configuration management plan defines the usage of the
+ system for the specific product; the same system may be used
+ to a different extent for other products. That means the
+ configuration management plan defines and describes the
+ output of the configuration management system of a company
+ which is used during the TOE development.
+
+ configuration management system
+
+ set of procedures and tools (including their documentation)
+ used by a developer to develop and maintain configurations
+ of his products during their life-cycles
+
+ Configuration management systems may have varying degrees of
+ rigour and function. At higher levels, configuration
+ management systems may be automated, with flaw remediation,
+ change controls, and other tracking mechanisms.
+
+ configuration management system records
+
+ output produced during the operation of the configuration
+ management system documenting important configuration
+ management activities
+
+ Examples of configuration management system records are
+ configuration management item change control forms or
+ configuration management item access approval forms.
+
+ configuration management tools
+
+ manually operated or automated tools realising or supporting
+ a configuration management system
+
+ For example tools for the version management of the parts of
+ the TOE.
+
+ configuration management usage documentation
+
+ part of the configuration management system, which
+ describes, how the configuration management system is
+ defined and applied by using for example handbooks,
+ regulations and/or documentation of tools and procedures
+
+ delivery
+
+ transmission of the finished TOE from the production
+ environment into the hands of the customer
+
+ This product life-cycle phase may include packaging and
+ storage at the development site, but does not include
+ transportations of the unfinished TOE or parts of the TOE
+ between different developers or different development
+ sites.
+
+ developer
+
+ organisation responsible for the development of the TOE
+
+ development
+
+ product life-cycle phase which is concerned with generating
+ the implementation representation of the TOE
+
+ Throughout the requirements, development
+ and related terms (developer, develop) are meant in the more
+ general sense to comprise development and production.
+
+ development tools
+
+ tools (including test software, if applicable) supporting
+ the development and production of the TOE
+
+ For example for a software TOE, development tools are
+ usually programming languages, compilers, linkers and
+ generating tools.
+
+ implementation representation
+
+ least abstract representation of the TSF, specifically the
+ one that is used to create the TSF itself without further
+ design refinement
+
+ Source code that is then compiled or a hardware drawing that
+ is used to build the actual hardware are examples of parts
+ of an implementation representation.
+
+ life-cycle
+
+ sequence of stages of existence of an object (for example a
+ product or a system) in time
+
+ life-cycle definition
+
+ definition of the life-cycle model
+
+ life cycle model
+
+ description of the stages and their relations to each other
+ that are used in the management of the life-cycle of a
+ certain object, how the sequence of stages looks like and
+ which high level characteristics the stages have
+
+ production
+
+ production life-cycle phase follows the development phase
+ and consists of transforming the implementation
+ representation into the implementation of the TOE, i.e. into
+ a state acceptable for delivery to the customer
+
+ This phase may comprise manufacturing, integration,
+ generation, internal transports, storage, and labelling of
+ the TOE.
+
+ covert channel
+
+ enforced, illicit signalling channel that allows a user to
+ surreptitiously contravene the multi-level separation policy
+ and unobservability requirements of the TOE
+
+ encountered potential vulnerabilities
+
+ potential weakness in the TOE identified by the evaluator
+ while performing evaluation activities that could be used to
+ violate the SFRs
+
+ exploitable vulnerability
+
+ weakness in the TOE that can be used to violate the SFRs in
+ the operational environment for the TOE
+
+ monitoring attacks
+
+ generic category of attack methods that includes passive
+ analysis techniques aiming at disclosure of sensitive
+ internal data of the TOE by operating the TOE in the way
+ that corresponds to the guidance documents
+
+ potential vulnerability
+
+ suspected, but not confirmed, weakness
+
+ Suspicion is by virtue of a postulated attack path to
+ violate the SFRs.
+
+ residual vulnerability
+
+ weakness that cannot be exploited in the operational
+ environment for the TOE, but that could be used to violate
+ the SFRs by an attacker with greater attack potential than
+ is anticipated in the operational environment for the TOE
+
+ vulnerability
+
+ weakness in the TOE that can be used to violate the SFRs in
+ some environment
+
+ base component
+
+ entity in a composed TOE, which has itself been the subject
+ of an evaluation, providing services and resources to a
+ dependent component
+
+ compatible (components)
+
+ property of a component able to provide the services
+ required by the other component, through the corresponding
+ interfaces of each component, in consistent operational
+ environments
+
+ component TOE
+
+ successfully evaluated TOE that is part of another composed
+ TOE
+
+ composed TOE
+
+ TOE comprised solely of two or more components that have
+ been successfully evaluated
+
+ dependent component
+
+ entity in a composed TOE, which is itself the subject of an
+ evaluation, relying on the provision on services by a base
+ component
+
+ functional interface
+
+ external interface providing a user with access to
+ functionality of the TOE which is not directly involved in
+ enforcing security functional requirements
+
+ In a composed TOE these are the interfaces provided by the
+ base component that are required by the dependent component
+ to support the operation of the composed TOE.
+
+ The following abbreviations are used in one or more parts of the
+ CC:API
+ Application Programming Interface
+ CAP
+ Composed Assurance Package
+ CC
+ Common Criteria
+ CCRAArrangement on the
+ Recognition of Common Criteria Certificates in the field of IT
+ Security
+ CM
+ Configuration Management
+ DAC
+ Discretionary Access Control
+ EAL
+ Evaluation Assurance Level
+ GHz
+ Gigahertz
+ GUI
+ Graphical User Interface
+ IC
+ Integrated Circuit
+ IOCTL
+ Input Output Control
+ IP
+ Internet Protocol
+ IT
+ Information Technology
+ MB
+ Mega Byte
+ OS
+ Operating System
+ OSP
+ Organisational Security Policy
+ PC
+ Personal Computer
+ PCI
+ Peripheral Component Interconnect
+ PKI
+ Public Key Infrastructure
+ PP
+ Protection Profile
+ RAM
+ Random Access Memory
+ RPC
+ Remote Procedure Call
+ SAR
+ Security Assurance Requirement
+ SFR
+ Security Functional Requirement
+ SFP
+ Security Function Policy
+ SPD
+ Security Problem Definition
+ ST
+ Security Target
+ TCP
+ Transmission Control Protocol
+ TOE
+ Target of Evaluation
+ TSF
+ TOE Security Functionality
+ TSFI
+ TSF Interface
+ VPN
+ Virtual Private Network
+
+ This Clause introduces the main concepts of the CC. It
+ identifies the concept ``TOE'', the target audience of the CC,
+ and the approach taken to present the material in the remainder
+ of the CC.
+ The CC is flexible in what to evaluate and is therefore not
+ tied to the boundaries of IT products as commonly
+ understood. Therefore in the context of evaluation, the CC
+ uses the term ``TOE'' (Target of Evaluation).
+ A TOE is defined as a set of software, firmware and/or
+ hardware possibly accompanied by guidance.
+ While there are cases where a TOE consists of an IT product,
+ this need not be the case. The TOE may be an IT product, a
+ part of an IT product, a set of IT products, a unique
+ technology that may never be made into a product, or a
+ combination of these.
+ As far as the CC is concerned, the precise relation
+ between the TOE and any IT products is only important in one
+ aspect: the evaluation of a TOE containing only part of an IT
+ product should not be misrepresented as the evaluation of the
+ entire IT product.
+ Examples of TOEs include:
+
+ A software application;
+
+ An operating system;
+
+ A software application in combination with an operating
+ system;
+
+ A software application in combination with an operating
+ system and a workstation;
+
+ An operating system in combination with a workstation;
+
+ A smart card integrated circuit;
+
+ The cryptographic co-processor of a smart card integrated
+ circuit;
+
+ A Local Area Network including all terminals, servers,
+ network equipment and software;
+
+ A database application excluding the remote client
+ software normally associated with that database
+ application.
+
+ In the CC, a TOE can occur in several
+ representations, such as (for a software TOE):
+
+ a list of files in a configuration management system;
+
+ a single master copy, that has just been compiled;
+
+ a box containing a CD-ROM and a manual, ready to be shipped to a customer;
+
+ an installed and operational version.
+
+ All of these are considered to be a TOE: and wherever the
+ term ``TOE'' is used in the remainder of the CC, the
+ context determines the representation that is meant.
+ In general, IT products can be configured in many ways:
+ installed in different ways, with different options enabled
+ or disabled. As, during a CC evaluation, it will be
+ determined whether a TOE meets certain requirements, this
+ flexibility in configuration may lead to problems, as all
+ possible configurations of the TOE must meet the
+ requirements. For these reasons, it is often the case that
+ the guidance part of the TOE strongly constrains the
+ possible configurations of the TOE. That is: the guidance of
+ the TOE may be different from the general guidance of the IT
+ product.
+ An example is an operating system IT product. This product
+ can be configured in many ways (e.g. types of users, number
+ of users, types of external connections allowed/disallowed,
+ options enabled/disabled etc.).
+ If the same IT product is to be a TOE, and is evaluated
+ against a reasonable set of requirements, the configuration
+ should be much more tightly controlled, as many options
+ (e.g. allow all types of external connections or the system
+ administrator does not need to be authenticated) will lead
+ to a TOE not meeting the requirements.
+ For this reason, there would normally be a difference
+ between the guidance of the IT product (allowing many
+ configurations) and the guidance of the TOE (allowing only
+ one or only configurations that do not differ in
+ security-relevant ways).
+ Note that if the guidance of the TOE still allows more than
+ one configuration, these configurations are collectively
+ called ``the TOE'' and each such configuration must meet the
+ requirements levied on the TOE.
+ There are three groups with a general interest in evaluation
+ of the security properties of TOEs: consumers, developers and
+ evaluators. The criteria presented in this CC part 1 have been
+ structured to support the needs of all three groups. They are
+ all considered to be the principal users of the CC. The
+ three groups can benefit from the criteria as explained in the
+ following paragraphs.
+ The CC is written to ensure that evaluation fulfils
+ the needs of the consumers as this is the fundamental
+ purpose and justification for the evaluation process.
+ Consumers can use the results of evaluations to help decide
+ whether a TOE fulfils their security needs. These security
+ needs are typically identified as a result of both risk
+ analysis and policy direction. Consumers can also use the
+ evaluation results to compare different TOEs.
+ The CC gives consumers, especially in consumer groups
+ and communities of interest, an implementation-independent
+ structure, termed the Protection Profile (PP), in which to
+ express their security requirements in an unambiguous
+ manner.
+ The CC is intended to support developers in preparing
+ for and assisting in the evaluation of their TOEs and in
+ identifying security requirements to be satisfied by those
+ TOEs. These requirements are contained in an
+ implementation-dependent construct termed the Security
+ Target (ST). This ST may be based on one or more PPs to show
+ that the ST conforms to the security requirements from
+ consumers as laid down in those PPs.
+ The CC can then be used to determine the
+ responsibilities and actions to provide evidence that is
+ necessary to support the evaluation of the TOE against these
+ requirements. It also defines the content and presentation
+ of that evidence.
+ The CC contains criteria to be used by evaluators
+ when forming judgements about the conformance of TOEs to
+ their security requirements. The CC describes the set
+ of general actions the evaluator is to carry out. Note that
+ the CC does not specify procedures to be followed in
+ carrying out those actions. More information on these
+ procedures may be found in Subclause .
+ While the CC is oriented towards specification and
+ evaluation of the IT security properties of TOEs, it may
+ also be useful as reference material to all parties with an
+ interest in or responsibility for IT security. Some of the
+ additional interest groups that can benefit from information
+ contained in the CC are:
+
+ system custodians and system security officers
+ responsible for determining and meeting organisational
+ IT security policies and requirements;
+
+ auditors, both internal and external, responsible for
+ assessing the adequacy of the security of an IT solution
+ (which may consist of or contain a TOE);
+
+ security architects and designers responsible for the
+ specification of security properties of IT products;
+
+ accreditors responsible for accepting an IT solution for
+ use within a particular environment;
+
+ sponsors of evaluation responsible for requesting and
+ supporting an evaluation; and
+
+ evaluation authorities responsible for the management
+ and oversight of IT security evaluation programmes.
+
+ The CC is presented as a set of distinct but related
+ parts as identified below. Terms used in the description of
+ the parts are explained in Clause .
+ Part 1, Introduction and general model is the
+ introduction to the CC. It defines the general concepts
+ and principles of IT security evaluation and presents a
+ general model of evaluation.
+ Part 2, Security functional components
+ establishes a set of functional components that serve as
+ standard templates upon which to base functional
+ requirements for TOEs. CC Part 2 catalogues the set of
+ functional components and organises them in families and
+ classes.
+ Part 3, Security assurance components
+ establishes a set of assurance components that serve as
+ standard templates upon which to base assurance
+ requirements for TOEs. CC Part 3 catalogues the set of
+ assurance components and organises them into families and
+ classes. CC Part 3 also defines evaluation criteria for
+ PPs and STs and presents seven pre-defined assurance
+ packages which are called the Evaluation Assurance Levels
+ (EALs).
+
+ In support of the three parts of the CC listed above,
+ other documents have been published, the CEM provides
+ the methodology for IT security evaluation using the CC
+ as a basis. It is anticipated that other documents will be
+ published, including technical rationale material and guidance
+ documents.
+ The following table presents, for the three key target
+ audience groupings, how the parts of the CC will be of
+ interest.
+ Consumers
+
+ Developers
+
+ Evaluators
+
+ Part 1
+
+ Use for background information and
+ are obliged to use for reference purposes. Guidance
+ structure for PPs.
+
+ Use for background information and reference
+ purposes. Are obliged to use for the development of
+ security specifications for TOEs.
+
+ Are obliged to use for reference purposes and for
+ guidance in the structure for PPs and STs.
+
+ Part 2
+
+ Use for guidance and reference when formulating
+ statements of requirements for a TOE.
+
+ Are obliged to use for reference when interpreting
+ statements of functional requirements and formulating
+ functional specifications for TOEs.
+
+ Are obliged to use for reference when interpreting
+ statements of functional requirements.
+
+ Part 3
+
+ Use for guidance when determining required levels of
+ assurance.
+
+ Use for reference when interpreting statements of
+ assurance requirements and determining assurance
+ approaches of TOEs.
+
+ Use for reference when interpreting statements of
+ assurance requirements.
+ Road map to the Common Criteria
+ In order to achieve greater comparability between evaluation
+ results, evaluations should be performed within the framework
+ of an authoritative evaluation scheme that sets the standards,
+ monitors the quality of the evaluations and administers the
+ regulations to which the evaluation facilities and evaluators
+ must conform.
+ The CC does not state requirements for the regulatory
+ framework. However, consistency between the regulatory
+ frameworks of different evaluation authorities will be
+ necessary to achieve the goal of mutual recognition of the
+ results of such evaluations.
+ A second way of achieving greater comparability between
+ evaluation results is using a common methodology to achieve
+ these results. For the CC, this methodology is given in
+ the CEM.
+ Use of a common evaluation methodology contributes to the
+ repeatability and objectivity of the results but is not by
+ itself sufficient. Many of the evaluation criteria require the
+ application of expert judgement and background knowledge for
+ which consistency is more difficult to achieve. In order to
+ enhance the consistency of the evaluation findings, the final
+ evaluation results may be submitted to a certification
+ process.
+ The certification process is the independent inspection of the
+ results of the evaluation leading to the production of the
+ final certificate or approval, which is normally publicly
+ available. The certification process is a means of gaining
+ greater consistency in the application of IT security
+ criteria.
+ The evaluation schemes and certification processes are the
+ responsibility of the evaluation authorities that run such
+ schemes and processes and are outside the scope of the CC.
+ This clause presents the general concepts used throughout the
+ CC, including the context in which the concepts are to be used
+ and the CC approach for applying the concepts. CC Part 2 and CC
+ Part 3, which are obliged to be consulted by users of the CC
+ Part 1, expand on the use of these concepts and assume that the
+ approach described is used. Further, for users of the CC who
+ intend to perform evaluation activities the CEM is
+ applicable. This clause assumes some knowledge of IT security
+ and does not propose to act as a tutorial in this area.
+ The CC discusses security using a set of security
+ concepts and terminology. An understanding of these concepts and
+ the terminology is a prerequisite to the effective use of
+ the CC. However, the concepts themselves are quite
+ general and are not intended to restrict the class of IT
+ security problems to which the CC is applicable.
+ Security is concerned with the protection of assets. Assets
+ are entities that someone places value upon. Examples of
+ assets include:
+ contents of a file or a server;the authenticity of votes cast in an election;the availability of an electronic commerce
+ process;the ability to use an expensive printer;access to a classified facility.
+ but given that value is highly subjective, almost anything can
+ be an asset.
+ The environment(s) in which these assets are located is called
+ the operational environment. Examples of (aspects of)
+ operational environments are:
+
+ the computer room of a bank;
+
+ a computer network connected to the Internet;
+
+ a LAN;
+
+ a general office environment.
+
+ Many assets are in the form of information that is stored,
+ processed and transmitted by IT products to meet requirements
+ laid down by owners of the information. Information owners may
+ require that availability, dissemination and modification of
+ any such information are strictly controlled and that the
+ assets are protected from threats by countermeasures. Figure
+ illustrates these
+ high level concepts and relationships.
+ Safeguarding assets of interest is the responsibility of
+ owners who place value on those assets. Actual or presumed
+ threat agents may also place value on the assets and seek to
+ abuse assets in a manner contrary to the interests of the
+ owner. Examples of threat agents include hackers, malicious
+ users, non-malicious users (who sometimes make errors),
+ computer processes and accidents.
+ The owners of the assets will perceive such threats as
+ potential for impairment of the assets such that the value of
+ the assets to the owners would be reduced. Security-specific
+ impairment commonly includes, but is not limited to: loss of
+ asset confidentiality, loss of asset integrity and loss of
+ asset availability.
+ These threats therefore give rise to risks to the assets,
+ based on the likelihood of a threat being realised and the
+ impact on the assets when that threat is
+ realised. Subsequently countermeasures are imposed to reduce
+ the risks to assets. These countermeasures may consist of IT
+ countermeasures (such as firewalls and smart cards) and non-IT
+ countermeasures (such as guards and procedures). See also
+ ISO/IEC 27001 and ISO/IEC 27002 for a more general discussion
+ on security countermeasures (controls).
+ Owners of assets may be (held) responsible for those assets
+ and therefore should be able to defend the decision to accept
+ the risks of exposing the assets to the threats.
+ Two important elements in defending this decision are being
+ able to demonstrate that:
+
+ the countermeasures are sufficient: if the countermeasures do what
+ they claim to do, the threats to the assets are countered;
+
+ the countermeasures are correct: the countermeasures do
+ what they claim to do.
+
+ Many owners of assets lack the knowledge, expertise or
+ resources necessary to judge sufficiency and correctness of
+ the countermeasures, and they may not wish to rely solely on
+ the assertions of the developers of the countermeasures. These
+ consumers may therefore choose to increase their confidence in
+ the sufficiency and correctness of some or all of their
+ countermeasures by ordering an evaluation of these
+ countermeasures.
+ In an evaluation, sufficiency of the countermeasures is
+ analysed through a construct called the Security Target. In
+ this Subclause a simplified view on this construct is
+ provided: a more detailed and complete description may be
+ found in .
+ The Security Target begins with describing the assets and
+ the threats to those assets. The Security Target then
+ describes the countermeasures (in the form of Security
+ Objectives) and demonstrates that these countermeasures are
+ sufficient to counter these threats: if the countermeasures
+ do what they claim to do, the threats are countered.
+ The Security Target then divides these countermeasures in
+ two groups:
+
+ the security objectives for the TOE: these describe the
+ countermeasure(s) for which correctness will be
+ determined in the evaluation;
+
+ the security objectives for the Operational Environment:
+ these describe the countermeasures for which correctness
+ will not be determined in the evaluation.
+
+ The reasons for this division are:
+
+ The CC is only suitable for assessing the
+ correctness of IT countermeasures. Therefore the non-IT
+ countermeasures (e.g. human security guards, procedures)
+ are always in the Operational Environment.
+
+ Assessing correctness of countermeasures costs time and
+ money, possibly making it infeasible to assess the
+ correctness of all IT countermeasures.
+
+ The correctness of some IT countermeasures may already
+ have been assessed in another evaluation. It is
+ therefore not cost-effective to assess this correctness
+ again.
+
+ For the TOE (the IT countermeasures whose correctness will
+ be assessed during the evaluation), the Security Target
+ requires a further detailing of the security objectives for
+ the TOE in Security Functional Requirements (SFRs). These
+ SFRs are formulated in a standardised language (described in
+ CC Part 2) to ensure exactness and facilitate comparability.
+ In summary, the Security Target demonstrates that:
+
+ The SFRs meet the security objectives for the TOE;
+
+ The security objectives for the TOE and the security
+ objectives for the operational environment counter the
+ threats;
+
+ And therefore, the SFRs and the security objectives for
+ the operational environment counter the threats.
+
+ From this it follows that a correct TOE (meeting the SFRs)
+ in combination with a correct operational environment
+ (meeting the security objectives for the operational
+ environment) will counter the threats. In the next two
+ subclauses correctness of the TOE and correctness of the
+ operational environment are discussed separately.
+ A TOE may be incorrectly designed and implemented, and may
+ therefore contain errors that lead to vulnerabilities. By
+ exploiting these vulnerabilities, attackers may still damage
+ and/or abuse the assets.
+ These vulnerabilities may arise from accidental errors made
+ during development, poor design, intentional addition of
+ malicious code, poor testing etc.
+ To determine correctness of the TOE, various activities can
+ be performed such as:
+
+ testing the TOE;
+
+ examining various design representations of the TOE;
+
+ examining the physical security of the development
+ environment of the TOE.
+
+ The Security Target provides a structured description of
+ these activities to determine correctness in the form of
+ Security Assurance Requirements (SARs). These SARs are
+ formulated in a standardised language (described in CC Part
+ 3) to ensure exactness and facilitate comparability.
+ If the SARs are met, there exists assurance in the
+ correctness of the TOE and the TOE is therefore less likely
+ to contain vulnerabilities that can be exploited by
+ attackers. The amount of assurance that exists in the
+ correctness of the TOE is determined by the SARs themselves:
+ a few ``weak'' SARs will lead to a little assurance, a lot
+ of ``strong'' SARs will lead to a lot of assurance.
+ The operational environment may also be incorrectly designed
+ and implemented, and may therefore contain errors that lead
+ to vulnerabilities. By exploiting these vulnerabilities,
+ attackers may still damage and/or abuse the assets.
+ However, in the CC, no assurance is obtained
+ regarding the correctness of the operational
+ environment. Or, in other words, the operational environment
+ is not evaluated (see the next Subclause).
+ As far as the evaluation is concerned, the operational
+ environment is assumed to be a 100% correct instantiation of
+ the security objectives for the operational environment.
+ This does not preclude a consumer of the TOE from using
+ other methods to determine the correctness of his
+ operational environment, such as:
+
+ If, for an OS TOE, the security objectives for the
+ operational environment state ``The operational
+ environment shall ensure that entities from an untrusted
+ network (e.g. the Internet) can only access the TOE by
+ ftp'', the consumer could select an evaluated firewall,
+ and configure it to only allow ftp access to the TOE;
+
+ If the security objectives for the operational
+ environment state ``The operational environment shall
+ ensure that all administrative personnel will not behave
+ maliciously'', the consumer could adapt his contracts
+ with administrative personnel to include punitive
+ sanctions for malicious behaviour, but this
+ determination is not part of a CC evaluation.
+
+ The CC recognises two types of evaluation: an ST/TOE
+ evaluation, which is described below, and an evaluation of
+ PPs, which is defined in CC Part 3. In many places,
+ the CC uses the term evaluation (without qualifiers) to
+ refer to an ST/TOE evaluation.
+ In the CC an ST/TOE evaluation proceeds in two steps:
+
+ An ST evaluation: where the sufficiency of the TOE and the
+ operational environment are determined;
+
+ A TOE evaluation: where the correctness of the TOE is
+ determined. As said earlier, the TOE evaluation does not
+ assess correctness of the operational environment.
+
+ The ST evaluation is carried out by applying the Security
+ Target evaluation criteria (which are defined in CC Part 3) to
+ the Security Target. The precise method to apply the criteria is determined by the evaluation
+ methodology that is used.
+ The TOE evaluation is more complex. The principal inputs to a
+ TOE evaluation are: the evaluation evidence, which includes
+ the TOE and ST, but will usually also include input from the
+ development environment, such as design documents or developer
+ test results.
+ The TOE evaluation consists of applying the SARs (from the
+ Security Target) to the evaluation evidence. The precise
+ method to apply a specific SAR is determined by the evaluation
+ methodology that is used.
+ How the results of applying the SARs are documented, and what
+ reports need to be generated and in what detail, is determined
+ by both the evaluation methodology that is used and the
+ evaluation scheme under which the evaluation is carried out.
+ The result of the TOE evaluation process is either:
+
+ A statement that not all SARs have been met and that
+ therefore there is not the specified level of assurance
+ that the TOE meets the SFRs as stated in the ST;
+
+ A statement that all SARs have been met, and that
+ therefore there is the specified level of assurance that
+ the TOE meets the SFRs as stated in the ST.
+
+ The TOE evaluation may be carried out after TOE development
+ has finished, or in parallel with TOE development.
+ The method of stating ST/TOE evaluation results is described
+ in Clause . These results also
+ identify the PP(s) and package(s) to which the TOE claims
+ conformance, and these constructs are described in the next
+ Clause.
+ The CC functional and assurance components may be used exactly
+ as defined in CC Part 2 and CC Part 3, or they may be tailored
+ through the use of permitted operations. When using
+ operations, the PP/ST author should be careful that the
+ dependency needs of other requirements that depend on this
+ requirement are satisfied. The permitted operations are
+ selected from the following set:
+
+ Iteration: allows a component to be used more than once
+ with varying operations;
+
+ Assignment: allows the specification of parameters;
+
+ Selection: allows the specification of one or more items
+ from a list; and
+
+ Refinement: allows the addition of details.
+
+ The assignment and selection operations are permitted only
+ where specifically indicated in a component. Iteration and
+ refinement are permitted for all components. The operations
+ are described in more detail below.
+ The CC Part 2 Annexes provide the guidance on the valid
+ completion of selections and assignments. This guidance
+ provides normative instructions on how to complete operations,
+ and those instructions shall be followed unless the PP/ST
+ author justifies the deviation:
+
+ ``None'' is only available as a choice for the completion
+ of a selection if explicitly provided.
+
+ The lists provided for the completion of selections must
+ be non-empty. If a ``None'' option is chosen, no
+ additional selection options may be chosen. If ``None''
+ is not given as an option in a selection, it is
+ permissible to combine the choices in a selection with
+ ``and''s and ``or''s, unless the selection explicitly
+ states ``choose one of''.
+ Selection operations may be combined by iteration where
+ needed. In this case, the applicability of the option
+ chosen for each iteration should not overlap the subject
+ of the other iterated selection, since they are intended
+ to be exclusive.
+ For the completion of assignments, the CC Part 2 Annexes
+ shall be consulted in order to determine when ``None''
+ would be a valid completion.
+
+ The iteration operation may be performed on every
+ component. The PP/ST author performs an iteration operation
+ by including multiple requirements based on the same
+ component. Each iteration of a component shall be different
+ from all other iterations of that component, which is
+ realised by completing assignments and selections in a
+ different way, or by applying refinements to it in a
+ different way.
+ Different iterations should be uniquely identified to allow
+ clear rationales and tracings to and from these
+ requirements.
+ It is important to note that sometimes an iteration
+ operation can be used with components where could also be
+ possible to perform an assignment operation with a range or
+ list of values instead of iterate them. In that case the
+ author can select the most appropriate alternative,
+ considering if there is a necessity of providing a whole
+ rationale for the range of values or if it is necessary to
+ have a separate one for each of them. The author should also
+ keep in mind if individual traces are required for those
+ values.
+ An assignment operation occurs where a given component
+ contains an element with a parameter that may be set by the
+ PP/ST author. The parameter may be an unrestricted variable,
+ or a rule that narrows the variable to a specific range of
+ values.
+ Whenever an element in a PP contains an assignment, a PP
+ author shall do one of four things:
+
+ leave the assignment uncompleted. The PP author could
+ include ``When the
+ defined number of unsuccessful authentication attempts
+ has been met or surpassed, the TSF shall
+ [assignment: list of actions].'' in the PP.
+
+ complete the assignment. As an example, the PP author
+ could include ``When
+ the defined number of unsuccessful authentication
+ attempts has been met or surpassed, the TSF shall
+ prevent that external entity from binding to any
+ subject in the future.'' in the PP.
+
+ narrow the assignment, to further limit the range of
+ values that is allowed. As an example, the PP author
+ could include ``The
+ TSF shall detect when [assignment: positive
+ integer between 4 and 9] unsuccessful authentication
+ attempts occur ...'' in the PP.
+
+ transform the assignment to a selection, thereby
+ narrowing the assignment. As an example, the PP author
+ could include ``When
+ the defined number of unsuccessful authentication
+ attempts has been met or surpassed, the TSF shall
+ [selection: prevent that user from binding to any
+ subject in the future, notify the
+ administrator].'' in the PP.
+
+ Whenever an element in an ST contains an assignment, an ST
+ author shall complete that assignment, as indicated in b)
+ above. Options a), c) and d) are not allowed for STs.
+ The values chosen in options b), c) and d) shall conform to
+ the indicated type required by the assignment.
+ When an assignment is to be completed with a set
+ (e.g. subjects), one may list a set of subjects, but also
+ some description of the set from which the elements of the
+ set can be derived such as:
+
+ all subjects
+
+ all subjects of type X
+
+ all subjects except subject a
+
+ as long as it is clear which subjects are meant.
+
+ The selection operation occurs where a given component
+ contains an element where a choice from several items has to
+ be made by the PP/ST author.
+ Whenever an element in a PP contains a selection, the PP
+ author may do one of three things:
+
+ leave the selection uncompleted.
+
+ complete the selection by choosing one or more items.
+
+ restrict the selection by removing some of the choices,
+ but leaving two or more.
+
+ Whenever an element in an ST contains a selection, an ST
+ author shall complete that selection, as indicated in b)
+ above. Options a) and c) are not allowed for STs.
+ The item or items chosen in b) and c) shall be taken from
+ the items provided in the selection.
+ The refinement operation can be performed on every
+ requirement. The PP/ST author performs a refinement by
+ altering that requirement. The first rule for a refinement
+ is that a TOE meeting the refined requirement also meets the
+ unrefined requirement in the context of the PP/ST (i.e. a
+ refined requirement must be ``stricter'' than the original
+ requirement). If a refinement does not meet this rule, the
+ resulting refined requirement is considered to be an
+ extended requirement and shall be treated as such.
+ The first rule for a refinement is that a TOE meeting the
+ refined requirement also meets the unrefined requirement in
+ the context of the PP/ST (i.e. a refined requirement must be
+ ``stricter'' than the original requirement)
+ The only exception to this rule is that a PP/ST author is
+ allowed to refine a SFR to apply to some but not all
+ subjects, objects, operations, security attributes and/or
+ external entities.
+ However, this exception does not apply to refining SFRs that
+ are taken from PPs that compliance is being claimed to;
+ these SFRs may not be refined to apply to fewer subjects,
+ objects, operations, security attributes and/or external
+ entities than the SFR in the PP.
+ The second rule for a refinement is that the refinement
+ shall be related to the original component.
+ A special case of refinement is an editorial refinement,
+ where a small change is made in a requirement,
+ i.e. rephrasing a sentence due to adherence to proper
+ English grammar, or to make it more understandable to the
+ reader. This change is not allowed to modify the meaning of
+ the requirement in any way.
+ Dependencies may exist between components. Dependencies arise
+ when a component is not self sufficient and relies upon the
+ presence of another component to provide security
+ functionality or assurance.
+ The functional components in CC Part 2 typically have
+ dependencies on other functional components as do some of the
+ assurance components in CC Part 3 which may have dependencies
+ on other CC Part 3 components. CC Part 2 dependencies on CC
+ Part 3 components may also be defined. However, this does not
+ preclude extended functional components having dependencies on
+ assurance components or vice versa.
+ Component dependency descriptions are determined by consulting
+ the CC Part 2 and CC Part 3 component definitions. In order to
+ ensure completeness of the TOE security requirements,
+ dependencies should be satisfied when requirements based on
+ components with dependencies are incorporated into PPs and
+ STs. Dependencies should also be considered when constructing
+ packages.
+ In other words: if component A has a dependency on component
+ B, this means that whenever a PP/ST contains a security
+ requirement based on component A, the PP/ST shall also contain
+ one of :
+
+ a security requirement based on component B, or
+
+ a security requirement based on a component that is
+ hierarchically higher than B, or
+
+ a justification why the PP/ST does not contain a security
+ requirement based on component B.
+
+ In cases a) and b), when a security requirement is included
+ because of a dependency, it may be necessary to complete
+ operations (assignment, iteration, refinement, selection) on
+ that security requirement in a particular manner to make sure
+ that it actually satisfies the dependency.
+ In case c), the justification that a security requirement is
+ not included should address either:
+
+ why the dependency is not necessary or useful, or
+
+ that the dependency has been addressed by the operational
+ environment of the TOE, in which case the justification
+ should describe how the security objectives for the
+ operational environment address this dependency, or
+
+ that the dependency has been addressed by the other SFRs
+ in some other manner (extended SFRs, combinations of SFRs
+ etc.)
+
+ In the CC it is mandatory to base requirements on
+ components from CC Part 2 or CC Part 3 with two
+ exceptions:
+
+ there are security objectives for the TOE that can not be
+ translated to Part 2 SFRs, or there are third party
+ requirements (e.g., laws, standards) that can not be
+ translated to Part 3 SARs (e.g. regarding evaluation of
+ cryptography);
+
+ a security objective can be translated, but only with
+ great difficulty and/or complexity based on components in
+ CC Part 2 and/or CC Part 3.
+
+ In both cases the PP/ST author is required to define his own
+ components. These newly defined components are called extended
+ components. A precisely defined extended component is needed
+ to provide context and meaning to the extended SFRs and SARs
+ based on that component.
+ After the new components have been defined correctly, the
+ PP/ST author can then base one or more SFRs or SARs on these
+ newly defined extended components and use them in the same way
+ as the other SFRs and SARs. From this point on, there is no
+ further distinction between SARs and SFRs based on the CC and
+ SARs and SFRs based on extended components. Refer to CC Part 3
+ and for further
+ requirements on extended components.
+ To allow consumer groups and communities of interest to
+ express their security needs, and to facilitate writing STs,
+ this part of the CC provides two special constructs: packages
+ and Protection Profiles (PPs). In the following two subclauses
+ these constructs are described in more detail, followed by a
+ subclause on how these constructs can be used.
+ A package is a named set of security requirements. A package
+ is either
+
+ a functional package, containing only SFRs, or
+
+ an assurance package, containing only SARs.
+
+ Mixed packages containing both SFRs and SARs are not allowed.
+ A package can be defined by any party and is intended to be
+ re-usable. To this goal it should contain requirements that
+ are useful and effective in combination. Packages can be used
+ in the construction of larger packages, PPs and STs. At
+ present there are no criteria for the evaluation of packages,
+ therefore any set of SFRs or SARs can be a package.
+ Examples of assurance packages are the evaluation assurance
+ levels (EALs) that are defined in CC Part 3. At the time
+ of writing there are no functional packages for this version
+ of the CC.
+ Whereas an ST always describes a specific TOE (e.g. the
+ MinuteGap v18.5 Firewall), a PP is intended to describe a TOE
+ type (e.g. firewalls). The same PP may therefore be used as a
+ template for many different STs to be used in different
+ evaluations. A detailed description of PPs is given in .
+ In general an ST describes requirements for a TOE and is
+ written by the developer of that TOE, while a PP describes
+ the general requirements for a TOE type, and is therefore
+ typically written by:
+
+ A user community seeking to come to a consensus on the
+ requirements for a given TOE type;
+
+ A developer of a TOE, or a group of developers of
+ similar TOEs wishing to establish a minimum baseline for
+ that type of TOE;
+
+ A government or large corporation specifying its
+ requirements as part of its acquisition process.
+
+ The PP determines the allowed type of conformance of the ST
+ to the PP. That is, the PP states (in the PP conformance
+ statement, see subclause )
+ what the allowed types of conformance for the ST are:
+
+ if the PP states that strict conformance is required,
+ the ST shall conform to the PP in a strict manner;
+
+ if the PP states that demonstrable conformance is
+ required, the ST shall conform to the PP in a strict or
+ demonstrable manner.
+
+ Restating this in other words, an ST is only allowed to
+ conform in a PP in a demonstrable manner, if the PP
+ explicitly allows this.
+ If an ST claims conformance to multiple PPs, it shall
+ conform (as described above) to each PP in the manner
+ ordained by that PP. This may mean that the ST conforms
+ strictly to some PPs and demonstrably to other PPs.
+ Note that either the ST conforms to the PP in question or it
+ does not. The CC does not recognise ``partial''
+ conformance. It is therefore the responsibility of the PP
+ author to ensure the PP is not overly onerous, prohibiting
+ PP/ST authors in claiming conformance to the PP.
+ An ST is equivalent or more restrictive than a PP if:
+
+ all TOEs that meet the ST also meet the PP, and
+
+ all operational environments that meet the PP also meet
+ the ST.
+
+ or, informally, the ST shall levy the same or more,
+ restrictions on the TOE and the same or less restrictions on
+ the operational environment of the TOE.
+ This general statement can be made more specific for various
+ subclauses of the ST:
+ Security problem definition: The
+ conformance rationale in the ST shall demonstrate that
+ the security problem definition in the ST is equivalent
+ (or more restrictive) than the security problem
+ definition in the PP. This means that:
+
+ all TOEs that would meet the security problem
+ definition in the ST also meet the security problem
+ definition in the PP;
+
+ all operational environments that would meet the
+ security problem definition in the PP would also
+ meet the security problem definition in the ST.
+ Security objectives: The conformance
+ rationale in the ST shall demonstrate that the security
+ objectives in the ST is equivalent (or more restrictive)
+ than the security objectives in the PP. This means that:
+
+ all TOEs that would meet the security objectives for
+ the TOE in the ST also meet the security objectives
+ for the TOE in the PP;
+
+ all operational environments that would meet the
+ security objectives for the operational environment
+ in the PP would also meet the security objectives
+ for the operational environment in the ST.
+
+ If strict conformance for protection profiles is specified
+ then the following requirements apply:
+ Security problem definition:
+
+ The ST shall contain the security problem definition of the PP and may specify additional
+ threats and OSPs; it shall contain all assumptions as defined in the PP, with two
+ possible exceptions as explained in the next two bullets;
+ an assumption (or a part of an assumption) specified in the PP may be omitted from the ST, if
+ all security objectives for the operational environment defined in the PP addressing this
+ assumption (or this part of an assumption) are replaced by security objectives for the TOE in
+ the ST;
+ a new assumption may be added in the ST to the set of assumptions defined in the PP, if this
+ new assumption does not mitigate a threat (or part of a threat) meant to be addressed by
+ security objectives for the TOE in the PP and if this assumption doesn't fulfil an OSP (or a
+ part of an OSP) meant to be addressed by security objectives for the TOE in the PP; Security objectives: The ST:
+
+ shall contain all security objectives for the TOE of the PP but may specify additional security
+ objectives for the TOE;
+ shall contain all security objectives for the operational environment as defined in the
+ PP with two exceptions as explained in the next two bullet points;
+ may specify that certain objectives for the operational environment in the PP are security
+ objectives for the TOE in the ST. This is called re-assigning a security objective. If a security
+ objective is re-assigned to the TOE the security objectives justification has to make clear which
+ assumption or part of the assumption may not be necessary any more;
+ may specify additional objectives for the operational environment, if these new objectives do not
+ mitigate a threat (or part of a threat) meant to be addressed by security objectives of the TOE in
+ the PP and if these new objectives do not fulfil an OSP (or a part of an OSP) meant to be
+ addressed by security objectives of the TOE in the PPSecurity requirements: The ST shall contain
+ all SFRs and SARs in the PP, but may claim additional or
+ hierarchically stronger SFRs and SARs. The completion of
+ operations in the ST must be consistent with that in the
+ PP; either the same completion will be used in the ST as
+ that in the PP or one that makes the requirement more
+ restrictive (the rules of refinement apply).
+
+ If demonstrable conformance for protection profiles is
+ specified then the following requirements apply:
+
+ the ST shall contain a rationale on why the ST is
+ considered to be ``equivalent or more restrictive'' than
+ the PP.
+
+ Demonstrable conformance allows a PP author to describe
+ a common security problem to be solved and provide
+ generic guidelines to the requirements necessary for its
+ resolution, in the knowledge that there is likely to be
+ more than one way of specifying a resolution.
+
+ PP evaluation is optional. Evaluation is performed by applying
+ the criteria to them as listed in
+ CC Part 3. The goal of such an evaluation is to demonstrate
+ that the PP is complete, consistent, and technically sound and
+ suitable for use as a template on which to build another PP or
+ an ST.
+ Basing a PP/ST on an evaluated PP has two advantages:
+
+ There is much less risk that there are errors, ambiguities
+ or gaps in the PP. If any problems with a PP (that would
+ have been caught by evaluating that PP) are found during
+ the writing or evaluation of the new ST, significant time
+ may elapse before the PP is corrected.
+
+ Evaluation of the new PP/ST may often re-use evaluation
+ results of the evaluated PP, resulting in less effort
+ for evaluating the new PP/ST.
+
+ If an ST claims to be conformant to one or more packages
+ and/or Protection Profiles, the evaluation of that ST will
+ (among other properties of that ST) demonstrate that the ST
+ actually conforms to these packages and/or PPs that they claim
+ conformance to. Details of this determination of conformance
+ can be found in .
+ This allows the following process:
+
+ An organisation seeking to acquire a particular type of
+ IT security product develops their security needs into a
+ PP, then has this evaluated and publishes it;
+
+ A developer takes this PP, writes an ST that claims
+ conformance to the PP and has this ST evaluated;
+
+ The developer then builds a TOE (or uses an existing
+ one) and has this evaluated against the ST.
+
+ The result is that the developer can prove that his TOE is
+ conformant to the security needs of the organisation: the
+ organisation can therefore acquire that TOE. A similar line of
+ reasoning applies to packages.
+ The CC also allows PPs to conform to other PPs, allowing
+ chains of PPs to be constructed, each based on the previous
+ one(s).
+ For instance, one could take a PP for an Integrated Circuit
+ and a PP for a Smart Card OS, and use these to construct a
+ Smart Card PP (IC and OS) that claims conformance to the
+ other two. One could then write a PP on Smart Cards for
+ Public Transport based on the Smart Card PP and a PP on
+ Applet Loading. Finally, a developer could then construct an
+ ST based on this Smart Cards for Public Transport PP.
+ This clause presents the expected results from PP and ST/TOE
+ evaluations performed according to the CEM.
+ PP evaluations lead to catalogues of evaluated PPs.
+ An ST evaluation leads to intermediate results that are used
+ in the frame of a TOE evaluation.
+ ST/TOE evaluations lead to catalogues of evaluated TOEs. In
+ many cases these catalogues will refer to the IT products that
+ the TOEs are derived from rather than the specific
+ TOE. Therefore, the existence of an IT product in a catalogue
+ should not be construed as meaning that the whole IT product
+ has been evaluated; instead the actual extent of the ST/TOE
+ evaluation is defined by the ST. Refer to the bibliography for
+ examples of such catalogues.
+ STs may be based on packages, evaluated PPs or non-evaluated
+ PPs - however this is not mandatory, as STs do not have to be
+ based on anything at all.
+ Evaluation should lead to objective and repeatable results
+ that can be cited as evidence, even if there is no absolute
+ objective scale for representing the results of a security
+ evaluation. The existence of a set of evaluation criteria is a
+ necessary pre-condition for evaluation to lead to a meaningful
+ result and provides a technical basis for mutual recognition
+ of evaluation results between evaluation authorities.
+ An evaluation result represents the findings of a specific
+ type of investigation of the security properties of a
+ TOE. Such a result does not automatically guarantee fitness
+ for use in any particular application environment. The
+ decision to accept a TOE for use in a specific application
+ environment is based on consideration of many security issues
+ including the evaluation findings.
+ CC Part 3 contains the evaluation criteria that an evaluator
+ is obliged to consult in order to state whether a PP is
+ complete, consistent, and technically sound and hence suitable
+ for use in developing an ST.
+ The results of the evaluation shall also include a
+ ``Conformance Claim'' (see Subclause )).
+ CC Part 3 contains the evaluation criteria that an evaluator
+ is obliged to consult in order to determine whether
+ sufficient assurance exists that the TOE satisfies the SFRs
+ in the ST. Evaluation of the TOE shall therefore result in a
+ pass/fail statement for the ST. If both the ST and the TOE
+ evaluation have resulted in a pass statement, the underlying
+ product is eligible for inclusion in a registry. The results
+ of evaluation shall also include a ``Conformance Claim'' as
+ defined in the next subclause.
+ It may be the case that the evaluation results are
+ subsequently used in a certification process, but this
+ certification process is outside the scope of the CC.
+ The conformance claim indicates the source of the collection
+ of requirements that is met by a PP or ST that passes its
+ evaluation. This conformance claim contains a CC conformance
+ claim that:
+
+ describes the version of the CC to which the PP
+ or ST claims conformance.
+
+ describes the conformance to CC Part 2 (security
+ functional requirements) as either:
+ CC Part 2 conformant - A PP or ST
+ is CC Part 2 conformant if all SFRs in that PP
+ or ST are based only upon functional components in
+ CC Part 2, or
+ CC Part 2 extended - A PP or ST
+ is CC Part 2 extended if at least one SFR in
+ that PP or ST is not based upon functional
+ components in CC Part 2.
+
+ describes the conformance to CC Part 3 (security
+ assurance requirements) as either:
+ CC Part 3 conformant - A PP or ST
+ is CC Part 3 conformant if all SARs in that PP
+ or ST are based only upon assurance components in
+ CC Part 3, or
+ CC Part 3 extended - A PP or ST
+ is CC Part 3 extended if at least one SAR in
+ that PP or ST is not based upon assurance components
+ in CC Part 3.
+
+ Additionally, the conformance claim may include a statement
+ made with respect to packages, in which case it consists of
+ one of the following:
+ Package name Conformant - A PP or ST is
+ conformant to a pre-defined package (e.g. EAL) if:
+
+ the SFRs of that PP or ST are identical to the SFRs
+ in the package, or
+
+ the SARs of that PP or ST are identical to the SARs
+ in the package.
+ Package name Augmented - A PP or ST is
+ an augmentation of a predefined package if:
+
+ the SFRs of that PP or ST contain all SFRs in the
+ package, but have at least one additional SFR or one
+ SFR that is hierarchically higher than an SFR in the
+ package.
+
+ the SARs of that PP or ST contain all SARs in the
+ package, but have at least one additional SAR or one
+ SAR that is hierarchically higher than an SAR in the
+ package.
+
+ Note that when a TOE is successfully evaluated to a given
+ ST, any conformance claims of the ST also hold for the
+ TOE. A TOE can therefore also be e.g. CC Part 2 conformant.
+ Finally, the conformance claim may also include two
+ statements with respect to Protection Profiles:
+ PP Conformant - A PP or TOE meets
+ specific PP(s), which are listed as part of the
+ conformance result.
+ Conformance Statement (Only for PPs) -
+ This statement describes the manner in which PPs or STs
+ must conform to this PP: strict or demonstrable. For
+ more information on this Conformance Statement, see
+ .
+
+ Once an ST and a TOE have been evaluated, asset owners can
+ have the assurance (as defined in the ST) that the TOE,
+ together with the operational environment, counters the
+ threats. The evaluation results may be used by the asset
+ owner in deciding whether to accept the risk of exposing the
+ assets to the threats.
+ However, the asset owner should carefully check whether:
+
+ the Security Problem Definition in the ST matches the
+ security problem of the asset owner;
+
+ the Operational Environment of the asset owner conforms
+ (or can be made to conform) to the security objectives
+ for the Operational Environment described in the ST.
+
+ If either of these is not the case, the TOE may not be
+ suitable for the purposes of the asset owner.
+ Additionally, once an evaluated TOE is in operation, it is
+ still possible that previously unknown errors or
+ vulnerabilities in the TOE may surface. In that case, the
+ developer may correct the TOE (to repair the
+ vulnerabilities) or change the ST to exclude the
+ vulnerabilities from the scope of the evaluation. In either
+ case, the old evaluation results may no longer be valid.
+ If it is deemed necessary that confidence is regained,
+ re-evaluation is needed. The CC may be used for this
+ re-evaluation, but detailed procedures for re-evaluation are
+ outside the scope of this part of the CC.
+ The goal of this annex is to explain the Security Target (ST)
+ concept. This annex does not define the criteria; this definition can be found in CC Part
+ 3 and is supported by the documents given in the bibliography.
+ This annex consists of four major parts:
+ What an ST must contain. This is
+ summarised in Subclause , and described in more detail
+ in Subclauses - . These subclauses describe the
+ mandatory contents of the ST, the interrelationships
+ between these contents, and provide examples.
+ How an ST should be used. This is
+ summarised in Subclause , and described in more detail in
+ subclause . These
+ subclauses describe how an ST should be used, and some of
+ the questions that can be answered with an ST.
+ Low Assurance STs. Low Assurance STs are
+ STs with reduced content. They are described in detail in
+ subclause .
+ Claiming compliance with
+ standards. Subclause describes how an ST writer can claim that
+ the TOE meets a particular standard.
+
+ Figure portrays the mandatory
+ contents of an ST that are given in CC Part 3. Figure may also be used as a structural outline
+ of the ST, though alternative structures are allowed. For
+ instance, if the security requirements rationale is
+ particularly bulky, it could be included in an appendix of the
+ ST instead of in the security requirements subclause. The
+ separate subclauses of an ST and the contents of those
+ subclauses are briefly summarised below and explained in much
+ more detail in subclauses to . An ST normally contains:
+ an ST introduction containing three
+ narrative descriptions of the TOE on different levels of
+ abstraction;
+ a conformance claim, showing whether the
+ ST claims conformance to any PPs and/or packages, and if
+ so, to which PPs and/or packages;
+ a security problem definition, showing
+ threats, OSPs and assumptions;
+ security objectives, showing how the
+ solution to the security problem is divided between
+ security objectives for the TOE and security objectives
+ for the operational environment of the TOE;
+ extended components definition
+ (optional), where new components (i.e. those not included
+ in CC Part 2 or CC Part 3) may be defined. These new
+ components are needed to define extended functional and
+ extended assurance requirements;
+ security requirements, where a
+ translation of the security objectives for the TOE into a
+ standardised language is provided. This standardised
+ language is in the form of SFRs. Additionally this
+ subclause defines the SARs;
+ a TOE summary specification, showing how
+ the SFRs are implemented in the TOE.
+
+ There also exists low assurance STs which have reduced
+ contents; these are described in detail in subclause . All other parts of this Annex assume an ST
+ with full contents.
+ A typical ST fulfils two roles:
+
+ Before and during the evaluation, the ST specifies
+ ``what is to be evaluated''. In this role, the ST serves
+ as a basis for agreement between the developer and the
+ evaluator on the exact security properties of the TOE
+ and the exact scope of the evaluation. Technical
+ correctness and completeness are major issues for this
+ role. Subclause describes how
+ the ST should be used in this role.
+
+ After the evaluation, the ST specifies ``what was
+ evaluated''. In this role, the ST serves as a basis for
+ agreement between the developer or re-seller of the TOE
+ and the potential consumer of the TOE. The ST describes
+ the exact security properties of the TOE in an abstract
+ manner, and the potential consumer can rely on this
+ description because the TOE has been evaluated to meet
+ the ST. Ease of use and understandability are major
+ issues for this role. Subclause describes how the ST should be used
+ in this role.
+
+ Two roles (among many) that an ST should not fulfil are:
+ a detailed specification: An ST is
+ designed to be a security specification on a relatively
+ high level of abstraction. An ST should, in general, not
+ contain detailed protocol specifications, detailed
+ descriptions of algorithms and/or mechanisms, long
+ description of detailed operations etc.
+ a complete specification: An ST is
+ designed to be a security specification and not a
+ general specification. Unless security-relevant,
+ properties such as interoperability, physical size and
+ weight, required voltage etc. should not be part of an
+ ST. This means that in general an ST may be a part of a
+ complete specification, but not a complete specification
+ itself.
+
+ The ST introduction describes the TOE in a narrative way on
+ three levels of abstraction:
+
+ the ST reference and the TOE reference, which provide
+ identification material for the ST and the TOE that the ST
+ refers to;
+
+ the TOE overview, which briefly describes the TOE;
+
+ the TOE description, which describes the TOE in more
+ detail.
+
+ An ST contains a clear ST reference that identifies that
+ particular ST. A typical ST reference consists of title,
+ version, authors and publication date. An example of an ST
+ reference is ``MauveRAM Database ST, version 1.3, MauveCorp
+ Specification Team, 11 October 2002''.
+ An ST also contains a TOE reference that identifies the TOE
+ that claims conformance to the ST. A typical TOE reference
+ consists of developer name, TOE name and TOE version
+ number. An example of a TOE reference is ``MauveCorp
+ MauveRAM Database v2.11''. As a single TOE may be evaluated
+ multiple times, for instance by different consumers of that
+ TOE, and therefore have multiple STs, this reference is not
+ necessarily unique.
+ If the TOE is constructed from one or more well-known
+ products, it is allowed to reflect this in the TOE
+ reference, by referring to the product name(s). However,
+ this should not be used to mislead consumers: situations
+ where major parts or security functionalities were not
+ considered in the evaluation, yet the TOE reference does not
+ reflect this are not allowed.
+ The ST reference and the TOE reference facilitate indexing
+ and referencing the ST and TOE and their inclusion in
+ summaries of lists of evaluated TOEs/Products.
+ The TOE overview is aimed at potential consumers of a TOE
+ who are looking through lists of evaluated TOEs/Products to
+ find TOEs that may meet their security needs, and are
+ supported by their hardware, software and firmware. The
+ typical length of a TOE overview is several paragraphs.
+ To this end, the TOE overview briefly describes the usage of
+ the TOE and its major security features, identifies the TOE
+ type and identifies any major non-TOE
+ hardware/software/firmware required by the TOE.
+ The description of the usage and major security features
+ of the TOE is intended to give a very general idea of what
+ the TOE is capable of in terms of security, and what it
+ can be used for in a security context. This subclause
+ should be written for (potential) TOE consumers,
+ describing TOE usage and major security features in terms
+ of business operations, using language that TOE consumers
+ understand.
+ An example of this is ``The MauveCorp MauveRAM Database
+ v2.11 is a multi-user database intended to be used in a
+ networked environment. It allows 1024 users to be active
+ simultaneously. It allows password/token and biometric
+ authentication, protects against accidental data
+ corruption, and can roll-back ten thousand
+ transactions. Its audit features are highly configurable,
+ so as to allow detailed audit to be performed for some
+ users and transactions, while protecting the privacy of
+ other users and transactions.''
+ The TOE overview identifies the general type of TOE, such
+ as: firewall, VPN-firewall, smart card, crypto-modem,
+ intranet, web server, database, web server and database,
+ LAN, LAN with web server and database, etc.
+ It may be the case that the TOE is not of a readily
+ available type, in which case ``none'' would be
+ acceptable.
+ In some cases, a TOE type can mislead consumers. Examples include:
+
+ certain functionality can be expected of the TOE
+ because of its TOE type, but the TOE does not have
+ this functionality. Examples include:
+
+ an ATM-card type TOE, which does not support any
+ identification/authentication functionality;
+
+ a firewall type TOE, which does not support
+ protocols that are almost universally used;
+
+ a PKI-type TOE, which has no certificate
+ revocation functionality.
+
+ the TOE can be expected to operate in certain
+ operational environments because of its TOE type, but
+ it cannot do so. Examples include:
+
+ a PC-operating system type TOE, which is unable to
+ function securely unless the PC has no network
+ connection, floppy drive, and CD/DVD-player;
+
+ a firewall, which is unable to function securely
+ unless all users that can connect through that
+ firewall are benign.
+
+ While some TOEs do not rely upon other IT, many TOEs
+ (notably software TOEs) rely on additional, non-TOE,
+ hardware, software and/or firmware. In the latter case,
+ the TOE overview is required to identify such non-TOE
+ hardware,software and/or firmware . A complete and fully
+ detailed identification of the additional hardware,
+ software and/or firmware is not necessary, but the
+ identification should be complete and detailed enough for
+ potential consumers to determine the major
+ hardware,software and/or firmware needed to use the TOE.
+ Example hardware/software/firmware identifications are:
+
+ a standard PC with a 1GHz or faster processor and
+ 512MB or more RAM, running version 3.0 Update 6b, c,
+ or 7, or version 4.0 of the Yaiza operating system;
+
+ a standard PC with a 1GHz or faster version processor
+ and 512MB or more RAM, running version 3.0 Update 6d
+ of the Yaiza operating system and the WonderMagic 1.0
+ Graphics card with the 1.0 WM Driver Set;
+
+ a standard PC with version 3.0 of the Yaiza OS (or
+ higher);
+
+ a CleverCard SB2067 integrated circuit;
+
+ a CleverCard SB2067 integrated circuit running v2.0 of
+ the QuickOS smart card operating system;
+
+ the December 2002 installation of the LAN of the
+ Director-General's Office of the Department of
+ Traffic.
+
+ A TOE description is a narrative description of the TOE,
+ likely to run to several pages. The TOE description should
+ provide evaluators and potential consumers with a general
+ understanding of the security capabilities of the TOE, in
+ more detail than was provided in the TOE overview. The TOE
+ description may also be used to describe the wider
+ application context into which the TOE will fit.
+ The TOE description discusses the physical scope of the TOE:
+ a list of all hardware, firmware, software and guidance
+ parts that constitute the TOE. This list should be described
+ at a level of detail that is sufficient to give the reader a
+ general understanding of those parts.
+ The TOE description should also discuss the logical scope of
+ the TOE: the logical security features offered by the TOE at
+ a level of detail that is sufficient to give the reader a
+ general understanding of those features. This description is
+ expected to be in more detail than the major security
+ features described in the TOE overview.
+ An important property of the physical and logical scopes is
+ that they describe the TOE in such a way that there remains
+ no doubt on whether a certain part or feature is in the TOE
+ or whether this part or feature is outside the TOE. This is
+ especially important when the TOE is intertwined with and
+ cannot be easily separated from non-TOE entities.
+ Examples where the TOE is intertwined with non-TOE entities
+ are:
+
+ the TOE is a cryptographic co-processor of a smart card
+ IC, instead of the entire IC;
+
+ the TOE is a smart card IC, except for the cryptographic
+ processor;
+
+ the TOE is the Network Address Translation part of the
+ MinuteGap Firewall v18.5.
+
+ This subclause of an ST describes how the ST conforms with:
+
+ Part 2 and Part 3 of this International Standard;
+
+ Protection Profiles (if any);
+
+ Packages (if any).
+
+ The description of how the ST conforms to the CC consists of
+ two items: the version of the CC that is used and whether the
+ ST contains extended security requirements or not (see
+ Subclause ).
+ The description of conformance of the ST to Protection
+ Profiles means that the ST lists the packages that conformance
+ is being claimed to. For an explanation of this, see Subclause
+ .
+ The description of conformance of the ST to packages means
+ that the ST lists the packages that conformance is being
+ claimed to. For an explanation of this, see Subclause .
+ The security problem definition defines the security problem
+ that is to be addressed. The security problem definition is,
+ as far as the CC is concerned, axiomatic. That is,
+ the process of deriving the security problem definition
+ falls outside the scope of the CC.
+ However, it should be noted that the usefulness of the
+ results of an evaluation strongly depends on the ST, and the
+ usefulness of the ST strongly depends on the quality of the
+ security problem definition. It is therefore often
+ worthwhile to spend significant resources and use
+ well-defined processes and analyses to derive a good
+ security problem definition.
+ Note that according to CC Part 3 it is not mandatory
+ to have statements in all subclauses, an ST with threats
+ does not need to have OSPs and vice versa. Also, any ST may
+ omit assumptions.
+ Also note that where the TOE is physically distributed, it
+ may be better to discuss the relevant threats, OSPs and
+ assumptions separately for distinct domains of the TOE
+ operational environment.
+ This subclause of the security problem definition shows
+ the threats that are to be countered by the TOE, its
+ operational environment, or a combination of the two.
+ A threat consists of an adverse action performed by a
+ threat agent on an asset.
+ Adverse actions are actions performed by a threat agent on
+ an asset. These actions influence one or more properties
+ of an asset from which that asset derives its value.
+ Threat agents may be described as individual entities, but
+ in some cases it may be better to describe them as types
+ of entities, groups of entities etc.
+ Examples of threat agents are hackers, users, computer
+ processes, and accidents. Threat agents may be further
+ described by aspects such as expertise, resources,
+ opportunity and motivation.
+ Examples of threats are:
+
+ a hacker (with substantial expertise, standard
+ equipment, and being paid to do so) remotely copying
+ confidential files from a company network;
+
+ a worm seriously degrading the performance of a
+ wide-area network;
+
+ a system administrator violating user privacy;
+
+ someone on the Internet listening in on confidential
+ electronic communication.
+
+ This subclause of the security problem definition shows
+ the OSPs that are to be enforced by the TOE, its
+ operational environment, or a combination of the two.
+ OSPs are security rules, procedures, or guidelines imposed
+ (or presumed to be imposed) now and/or in the future by an
+ actual or hypothetical organisation in the operational
+ environment. OSPs may be laid down by an organisation
+ controlling the operational environment of the TOE, or
+ they may be laid down by legislative or regulatory
+ bodies. OSPs can apply to the TOE and/or the operational
+ environment of the TOE.
+ Examples of OSPs are:
+
+ All products that are used by the Government must
+ conform to the National Standard for password
+ generation and encryption;
+
+ Only users with System Administrator privilege and
+ clearance of Department Secret shall be allowed to
+ manage the Department Fileserver.
+
+ This subclause of the security problem definition shows
+ the assumptions that are made on the operational
+ environment in order to be able to provide security
+ functionality. If the TOE is placed in an operational
+ environment that does not meet these assumptions, the TOE
+ may not be able to provide all of its security
+ functionality anymore. Assumptions can be on physical,
+ personnel and connectivity of the operational environment.
+ Examples of assumptions are:
+
+ Assumptions on physical aspects of the operational environment:
+
+ It is assumed that the TOE will be placed in a
+ room that is designed to minimise electromagnetic
+ emanations;
+
+ It is assumed that the administrator consoles of
+ the TOE will be placed in a restricted access
+ area.
+
+ Assumptions on personnel aspects of the operational
+ environment:
+
+ It is assumed that users of the TOE will be
+ trained sufficiently in order to operate the TOE;
+
+ It is assumed that users of the TOE are approved
+ for information that is classified as National
+ Secret;
+
+ It is assumed that users of the TOE will not write
+ down their passwords.
+
+ Assumptions on connectivity aspects of the operational
+ environment:
+
+ It is assumed that a PC workstation with at least
+ 10GB of disk space is available to run the TOE on;
+
+ It is assumed that the TOE is the only non-OS
+ application running on this workstation;
+
+ It is assumed that the TOE will not be connected
+ to an untrusted network.
+
+ Note that during the evaluation these assumptions are
+ considered to be true: they are not tested in any way. For
+ these reasons, assumptions can only be made on the
+ operational environment. Assumptions can never be made on
+ the behaviour of the TOE because an evaluation consists of
+ evaluating assertions made about the TOE and not by
+ assuming that assertions on the TOE are true.
+ The security objectives are a concise and abstract statement
+ of the intended solution to the problem defined by the
+ security problem definition. The role of the security
+ objectives is threefold:
+
+ provide a high-level, natural language solution of the
+ problem;
+
+ divide this solution into two part wise solutions, that
+ reflect that different entities each have to address a
+ part of the problem;
+
+ demonstrate that these part wise solutions form a
+ complete solution to the problem.
+
+ The security objectives consist of a set of short and
+ clear statements without overly much detail that together
+ form a high-level solution to the security problem. The
+ level of abstraction of the security objectives aims at
+ being clear and understandable to knowledgeable potential
+ consumers of the TOE. The security objectives are in
+ natural language.
+ In an ST the high-level security solution, as described by
+ the security objectives, is divided into two part wise
+ solutions. These part wise solutions are called the
+ security objectives for the TOE and the security
+ objectives for the operational environment. This reflects
+ that these part wise solutions are to be provided by two
+ different entities: the TOE, and the operational
+ environment.
+ The TOE provides security functionality to solve a
+ certain part of the problem defined by the security
+ problem definition. This part wise solution is called
+ the security objectives for the TOE and consists of a
+ set of objectives that the TOE should achieve in order
+ to solve its part of the problem.
+ Examples of security objectives for the TOE are:
+
+ The TOE shall keep confidential the content of all
+ files transmitted between it and a Server;
+
+ The TOE shall identify and authenticate all users
+ before allowing them access to the Transmission
+ Service provided by the TOE;
+
+ The TOE shall restrict user access to data according
+ to the Data Access policy described in Annex 3 of
+ the ST.
+
+ If the TOE is physically distributed, it may be better
+ to subdivide the ST subclause containing the security
+ objectives for the TOE into several sub-subclauses to
+ reflect this.
+ The operational environment of the TOE implements
+ technical and procedural measures to assist the TOE in
+ correctly providing its security functionality (which is
+ defined by the security objectives for the TOE). This
+ part wise solution is called the security objectives for
+ the operational environment and consists of a set of
+ statements describing the goals that the operational
+ environment should achieve.
+ Examples of security objectives for the operational
+ environment are:
+
+ The operational environment shall provide a
+ workstation with the OS Inux version 3.01b to
+ execute the TOE on;
+
+ The operational environment shall ensure that all
+ human TOE users receive appropriate training before
+ allowing them to work with the TOE;
+
+ The operational environment of the TOE shall
+ restrict physical access to the TOE to
+ administrative personnel and maintenance personnel
+ accompanied by administrative personnel;
+
+ The operational environment shall ensure the
+ confidentiality of the audit logs generated by the
+ TOE before sending them to the central Audit Server.
+
+ If the operational environment of the TOE consists of
+ multiple sites, each with different properties, it may
+ be better to subdivide the ST subclause containing the
+ security objectives for the operational environment into
+ several sub-subclauses to reflect this.
+ The ST also contains a security objectives rationale
+ containing two subclauses:
+
+ a tracing that shows which security objectives
+ address which threats, OSPs and assumptions;
+
+ a set of justifications that shows that all threats,
+ OSPs, and assumptions are effectively addressed by
+ the security objectives.
+
+ The tracing shows how the security objectives trace
+ back to the threats, OSPs and assumptions as described
+ in the security problem definition.
+ No spurious objectives: Each
+ security objective traces to at least one threat,
+ OSP or assumption.
+ Complete with respect to the security
+ problem definition: Each threat, OSP and
+ assumption has at least one security objective
+ tracing to it.
+ Correct tracing: Since
+ assumptions are always made by the TOE on the
+ operational environment, security objectives for
+ the TOE do not trace back to assumptions. The
+ tracings allowed by CC Part 3 are depicted in
+ Figure .
+
+ Multiple security objectives may trace to the same
+ threat, indicating that the combination of those
+ security objectives counters that threat. A similar
+ argument holds for OSPs and assumptions.
+ The security objectives rationale also demonstrates
+ that the tracing is effective: All the given threats,
+ OSPs and assumption are addressed (i.e. countered,
+ enforced and upheld respectively) if all security
+ objectives tracing to a particular threat, OSP or
+ assumption are achieved.
+ This demonstration analyses the effect of achieving
+ the relevant security objectives on countering the
+ threats, enforcing the OSPs and upholding the
+ assumptions and leads to the conclusion that this is
+ indeed the case.
+ In some cases, where parts of the security problem
+ definition very closely resemble some security
+ objectives, the demonstration can be very simple. An
+ example is: a threat ``T17: Threat agent X reads the
+ Confidential Information in transit between A and B'',
+ a security objective for the TOE: ``OT12: The TOE
+ shall ensure that all information transmitted between
+ A and B is kept confidential'', and a demonstration
+ ``T17 is directly countered by OT12''.
+ Countering a threat does not necessarily mean removing
+ that threat, it can also mean sufficiently diminishing
+ that threat or sufficiently mitigating that threat.
+ Examples of removing a threat are:
+
+ removing the ability to execute the adverse action
+ from the threat agent;
+
+ moving, changing or protecting the asset in such a
+ way that the adverse action is no longer
+ applicable to it;
+
+ removing the threat agent (e.g. removing machines
+ from a network that frequently crash that
+ network).
+
+ Examples of diminishing a threat are:
+
+ restricting the ability of a threat agent to
+ perform adverse actions;
+
+ restricting the opportunity to execute an adverse
+ action of a threat agent;
+
+ reducing the likelihood of an executed adverse
+ action being successful;
+
+ reducing the motivation to execute an adverse
+ action of a threat agent by deterrence;
+
+ requiring greater expertise or greater resources
+ from the threat agent.
+
+ Examples of mitigating the effects of a threat are:
+
+ making frequent back-ups of the asset;
+
+ obtaining spare copies of an asset;
+
+ insuring an asset;
+
+ ensuring that successful adverse actions are
+ always timely detected, so that appropriate action
+ can be taken.
+
+ Based on the security objectives and the security
+ objectives rationale, the following conclusion can be
+ drawn: if all security objectives are achieved then the
+ security problem as defined in is
+ solved: all threats are countered, all OSPs are
+ enforced, and all assumptions are upheld.
+ In many cases the security requirements (see the next
+ subclause) in an ST are based on components in CC Part 2
+ or CC Part 3. However, in some cases, there may be
+ requirements in an ST that are not based on components in
+ CC Part 2 or CC Part 3. In this case, new components
+ (extended components) must be defined, and this definition
+ should be done in the Extended Components Definition. For
+ more information on this, see Annex .
+ Note that this subclause is intended to contain only the
+ extended components and not the extended requirements
+ (requirements based on extended components). The extended
+ requirements should be included in the security
+ requirements (see the next subclause) and are for all
+ purposes the same as requirements based on components in
+ CC Part 2 or CC Part 3.
+ The security requirements consist of two groups of
+ requirements:
+ the security functional requirements
+ (SFRs): a translation of the security objectives for the
+ TOE into a standardised language;
+ the security assurance requirements
+ (SARs): a description of how assurance is to be gained
+ that the TOE meets the SFRs.
+
+ These two groups are discussed in the following two subclauses:
+ The SFRs are a translation of the security objectives for
+ the TOE. They are usually at a more detailed level of
+ abstraction, but they have to be a complete translation
+ (the security objectives must be completely addressed) and
+ be independent of any specific technical solution
+ (implementation). The CC requires this translation into a
+ standardised language for several reasons:
+
+ to provide an exact description of what is to be
+ evaluated. As security objectives for the TOE are
+ usually formulated in natural language, translation
+ into a standardised language enforces a more exact
+ description of the functionality of the TOE.
+
+ to allow comparison between two STs. As different ST
+ authors may use different terminology in describing
+ their security objectives, the standardised language
+ enforces using the same terminology and concepts. This
+ allows easy comparison.
+
+ There is no translation required in the CC for the
+ security objectives for the operational environment,
+ because the operational environment is not evaluated and
+ does therefore not require a description aimed at its
+ evaluation. See the bibliography for items relevant to the
+ security assessment of operational systems.
+ It may be the case that parts of the operational
+ environment are evaluated in another evaluation, but this
+ is out of scope for the current evaluation. For example:
+ an OS TOE may require a firewall to be present in its
+ operational environment. Another evaluation may
+ subsequently evaluate the firewall, but this evaluation
+ has nothing to do with the evaluation of the OS TOE.
+ The CC supports this translation in three ways:
+
+ by providing a predefined precise ``language''
+ designed to describe exactly what is to be
+ evaluated. This language is defined as a set of
+ components defined in CC Part 2. The use of this
+ language as a well-defined translation of the
+ security objectives for the TOE to SFRs is
+ mandatory, though some exceptions exist (see
+ Subclause ).
+
+ by providing operations: mechanisms that allow the
+ ST writer to modify the SFRs to provide a more
+ accurate translation of the security objectives for
+ the TOE. This part of the CC defines the four
+ allowed operations: assignment, selection,
+ iteration, and refinement. These are described
+ further in Subclause .
+
+ by providing dependencies: a mechanism that supports
+ a more complete translation to SFRs. In the CC Part
+ 2 language, an SFR can have a dependency on other
+ SFRs. This signifies that if an ST uses that SFR, it
+ generally needs to use those other SFRs as
+ well. This makes it much harder for the ST writer to
+ overlook including necessary SFRs and thereby
+ improves the completeness of the ST. Dependencies
+ are described further in Subclause .
+
+ The ST also contains a security requirements rationale,
+ consisting of two subclauses about SFRs:
+
+ a tracing that shows which SFRs address which
+ security objectives for the TOE;
+
+ a set of justifications that shows that all security
+ objectives for the TOE are effectively addressed by
+ the SFRs.
+
+ The tracing shows how the SFRs trace back to the
+ security objectives for the TOE as follows:
+ No spurious SFRs: Each SFR traces
+ back to at least one security objective.
+ Complete with respect to the security
+ objectives for the TOE: Each security
+ objective for the TOE has at least one SFR tracing
+ to it.
+
+ Multiple SFRs may trace to the same security objective
+ for the TOE, indicating that the combination of those
+ security requirements meets that security objective
+ for the TOE.
+ The security requirements rationale demonstrates that
+ the tracing is effective: if all SFRs tracing to a
+ particular security objective for the TOE are
+ satisfied, that security objective for the TOE is
+ achieved.
+ This demonstration should analyse the effects of
+ satisfying the relevant SFRs on achieving the security
+ objective for the TOE and lead to the conclusion that
+ this is indeed the case.
+ In cases where SFRs very closely resemble security
+ objectives for the TOE, the demonstration can be very
+ simple.
+ The SARs are a description of how the TOE is to be
+ evaluated. This description uses a standardised language
+ for two reasons:
+
+ to provide an exact description of how the TOE is to
+ be evaluated. Using a standardised language assists in
+ creating an exact description and avoids ambiguity.
+
+ to allow comparison between two STs. As different ST
+ authors may use different terminology in describing
+ the evaluation, the standardised language enforces
+ using the same terminology and concepts. This allows
+ easy comparison.
+
+ This standardised language is defined as a set of
+ components defined in CC Part 3. The use of this
+ language is mandatory, though some exceptions
+ exist. The CC enhances this language in two ways:
+
+ by providing operations: mechanisms that allow the ST
+ writer to modify the SARs. The CC has four operations:
+ assignment, selection, iteration, and
+ refinement. These are described further in Subclause
+ .
+
+ by providing dependencies: a mechanism that supports a
+ more complete translation to SARs. In CC Part 3
+ language, an SAR can have a dependency on other
+ SARs. This signifies that if an ST uses that SAR, it
+ generally needs to use those other SARs as well. This
+ makes it much harder for the ST writer to overlook
+ including necessary SARs and thereby improves the
+ completeness of STs. Dependencies are described
+ further in Subclause .
+
+ The ST also contains a security requirements rationale
+ that explains why this particular set of SARs was deemed
+ appropriate. There are no specific requirements for this
+ explanation. The goal for this explanation is to allow the
+ readers of the ST to understand the reasons why this
+ particular set was chosen.
+ An example of an inconsistency is if the security problem
+ description mentions threats where the threat agent is
+ very capable, and a low (or no) is
+ included in the SARs.
+ In the security problem definition of the ST, the security
+ problem is defined as consisting of threats, OSPs and
+ assumptions. In the security objectives subclause of the
+ ST, the solution is provided in the form of two
+ sub-solutions:
+
+ security objectives for the TOE;
+
+ security objectives for the operational environment.
+
+ Additionally, a security objectives rationale is provided
+ showing that if all security objectives are achieved, the
+ security problem is solved: all threats are countered, all
+ OSPs are enforced, and all assumptions are upheld.
+ In the security requirements subclause of the ST, the
+ security objectives for the TOE are translated to SFRs and
+ a security requirements rationale is provided showing that
+ if all SFRs are satisfied, all security objectives for the
+ TOE are achieved.
+ Additionally, a set of SARs is provided to show how the
+ TOE is evaluated, together with an explanation for
+ selecting these SARs.
+ All of the above can be combined into the statement: If
+ all SFRs and SARs are satisfied and all security
+ objectives for the operational environment are achieved,
+ then there exists assurance that the security problem as
+ defined in is solved: all
+ threats are countered, all OSPs are enforced, and all
+ assumptions are upheld. This is illustrated in Figure
+ .
+ The amount of assurance obtained is defined by the SARs,
+ and whether this amount of assurance is sufficient is
+ defined by the explanation for choosing these SARs.
+ The objective for the TOE summary specification is to provide
+ potential consumers of the TOE with a description of how the
+ TOE satisfies all the SFRs. The TOE summary specification
+ should provide the general technical mechanisms that the TOE
+ uses for this purpose. The level of detail of this description
+ should be enough to enable potential consumers to understand
+ the general form and implementation of the TOE.
+ For instance if the TOE is an Internet PC and the SFRs contain
+ to specify authentication,
+ the TOE summary specification should indicate how this
+ authentication is done: password, token, iris scanning
+ etc. More information, like applicable standards that the TOE
+ uses to meet SFRs, or more detailed descriptions may also be
+ provided.
+ After the evaluation, the ST specifies ``what was
+ evaluated''. In this role, the ST serves as a basis for
+ agreement between the developer or re-seller of the TOE and
+ the potential consumer of the TOE. The ST can therefore answer
+ the following questions (and more):
+ How can I find the ST/TOE that I need given the
+ multitude of existing STs/TOEs? This question is
+ addressed by the TOE overview, which gives a brief
+ (several paragraphs) summary of the TOE;
+ Does this TOE fit in with my existing
+ IT-infrastructure? This question is addressed by
+ the TOE overview, which identifies the major
+ hardware/firmware/software elements needed to run the TOE;
+ Does this TOE fit in with my existing operational
+ environment? This question is addressed by the
+ security objectives for the operational environment, which
+ identifies all constraints the TOE places on the
+ operational environment in order to function;
+ What does the TOE do (interested reader)?
+ This question is addressed by the TOE overview, which
+ gives a brief (several paragraphs) summary of the TOE;
+ What does the TOE do (potential
+ consumer)? This question is addressed by the TOE
+ description, which gives a less brief (several pages)
+ summary of the TOE;
+ What does the TOE do (technical)? This
+ question is addressed by the TOE summary specification
+ which provides a high-level description of the mechanisms
+ the TOE uses;
+ What does the TOE do (expert)? This
+ question is addressed by the SFRs which provide an
+ abstract highly technical description, and the TOE summary
+ specification which provide additional detail;
+ Does the TOE address the problem as defined by my
+ government/organisation? If your
+ government/organisation has defined packages and/or PPs to
+ define this solution, then the answer can be found in the
+ Conformance Claims subclause of the ST, which lists all
+ packages and PPs that the ST conforms to
+ Does the TOE address my security problem
+ (expert)? What are the threats countered by the
+ TOE? What organisational security policies does it
+ enforce? What assumptions does it make about the
+ operational environment? These questions are addressed by
+ the security problem definition;
+ How much trust can I place in the TOE?
+ This can be found in the SARs in the security requirements
+ subclause, which provide the assurance level that was used
+ to evaluate the TOE, and hence the trust that the
+ evaluation provides in the correctness of the TOE.
+
+ Writing an ST is not a trivial task, and may, especially in
+ low assurance evaluations, be a major part of the total effort
+ expended by the developer and the evaluator in the whole of
+ the evaluation. For this reason, it is also possible to write
+ a low assurance ST.
+ The CC allows the use of a low assurance ST for an EAL 1
+ evaluation, but not for EAL 2 and up. A low-assurance ST may
+ only claim conformance to a low-assurance PP (see ). A regular ST
+ (i.e., one with full contents) may claim conformance with a
+ low assurance PP.
+ A low assurance ST has a significantly reduced content
+ compared to a regular ST:
+
+ there is no need to describe the security problem definition;
+
+ there is no need to describe the security objectives for
+ the TOE. The security objectives for the operational
+ environment must still be described;
+
+ there is no need to describe the security objectives
+ rationale as there is no security problem definition in
+ the ST;
+
+ the security requirements rationale only needs to justify
+ (any) dependencies not being satisfied as there are no
+ security objectives for the TOE in the ST.
+
+ All that remains are:
+
+ the references to TOE and ST;
+
+ a conformance claim;
+
+ the various narrative descriptions;
+
+ the TOE overview;
+
+ the TOE description;
+
+ the TOE summary specification.
+
+ security objectives for the operational environment;
+
+ the SFRs and the SARs (including the extended components
+ definition) and the security requirements rationale (only
+ if the dependencies are not satisfied).
+
+ The reduced content of a low assurance ST is shown in Figure
+ .
+ In some cases, an ST writer may wish to refer to an external
+ standard, such as a particular cryptographic standard or
+ protocol. The CC allows three ways of doing this:
+
+ As an organisational security policy (or part of it).
+
+ If, for example, there exists a government standard
+ defining how passwords have to be chosen, this may be
+ stated as an organisational security policy in an
+ ST. This may lead to an objective for the environment
+ (e. g. if users of the TOE need to choose passwords
+ accordingly), or it may lead to security objectives for
+ the TOE and then to appropriate SFRs (likely of the
+ class), if the TOE generates
+ passwords. In both cases the rationale of the developer
+ needs to make plausible that the security objectives for
+ the TOE and the SFRs are suitable to fulfil the OSP. The
+ evaluator will examine if this is in fact plausible (and
+ may decide to look into the standard for this), if the
+ OSP is implemented by SFRs, as explained below.
+ As a technical standard (for example a cryptographic
+ standard) used in a refinement of an SFR.
+
+ In this case conformance to the standard is part of the
+ fulfilment of the SFR by the TOE and is treated as if
+ the full text of the standard is part of the
+ SFR. Conformance is subsequently determined like any
+ other conformance to SFRs: during and
+ it is analysed, by design analysis and
+ tests, that the SFR is completely and fully implemented
+ in the TOE. If reference to only a certain part of a
+ standard is desired, that part should be unambiguously
+ stated in the SFR refinement.
+ As a technical standard (for example a cryptographic
+ standard) mentioned in the TOE summary specification.
+
+ The TOE summary specification is only considered as an
+ explanation of how the SFRs are realised, and is not
+ strictly used as a strict implementation requirement
+ like the SFRs or the documents delivered for . So the evaluator may detect an inconsistency
+ if the TSS references a technical standard and this is
+ not reflected in documentation, but
+ there is no routine activity to test fulfilment of the
+ standard.
+ The goal of this Annex is to explain the Protection Profile
+ (PP) concept. This Annex does not define the criteria; this definition can be found in
+ CC Part 3 and is supported by the documents given in the
+ bibliography.
+ As PPs and STs have a significant overlap, this Annex focuses
+ on the differences between PPs and STs. The material that is
+ identical between STs and PPs is described in .
+ This annex consists of four major parts:
+ What a PP must contain. This is
+ summarised in Subclause , and described in more detail
+ in Subclauses -. These clauses describe the
+ mandatory contents of the PP, the interrelationships
+ between these contents, and provide examples.
+ How a PP should be used. This is
+ summarised in Subclause .
+ Low Assurance PPs. Low Assurance PPs are
+ PPs with reduced content. They are described in detail in
+ Subclause .
+ Claiming compliance with
+ standards. Subclause describes how a PP writer can claim that
+ the TOE is to meet a particular standard.
+
+ Figure portrays the
+ mandatory content for a PP that is given in
+ CC Part 3. Figure may
+ also be used as a structural outline of the PP, though
+ alternative structures are allowed. For instance, if the
+ security requirements rationale is particularly bulky, it
+ could be included in an appendix of the PP instead of in the
+ security requirements subclause. The separate subclauses of a
+ PP and the contents of those subclauses are briefly summarised
+ below and explained in much more detail in Subclauses - . A
+ PP contains:
+
+ a PP introduction containing a narrative
+ description of the TOE type;
+
+ a conformance claim, showing whether the
+ PP claims conformance to any PPs and/or packages, and if
+ so, to which PPs and/or packages;
+
+ a security problem definition, showing
+ threats, OSPs and assumptions;
+ security objectives, showing how the
+ solution to the security problem is divided between
+ security objectives for the TOE and security objectives
+ for the operational environment of the TOE;
+ extended components definition, where new
+ components (i.e. those not included in CC Part 2 or
+ CC Part 3) may be defined. These new components are
+ needed to define extended functional and extended
+ assurance requirements;
+ security requirements, where a
+ translation of the security objectives for the TOE into a
+ standardised language is provided. This standardised
+ language is in the form of SFRs. Additionally this
+ subclause defines the SARs;
+
+ There also exist low assurance PPs, which have reduced
+ contents; these are described in detail in Subclause . With this exception, all other
+ parts of this Annex assume a PP with full contents.
+ A PP is typically a statement of need where a user
+ community, a regulatory entity, or a group of developers
+ define a common set of security needs. A PP gives consumers
+ a means of referring to this set, and facilitates future
+ evaluation against these needs.
+ A PP is therefore typically used as:
+
+ part of a requirement specification for a specific
+ consumer or group of consumers, who will only consider
+ buying a specific type of IT if it meets the PP;
+
+ part of a regulation from a specific regulatory entity,
+ who will only allow a specific type of IT to be used if
+ it meets the PP;
+
+ a baseline defined by a group of IT developers, who then
+ agree that all IT that they produce of this type will
+ meet this baseline.
+
+ though this does not preclude other uses.
+ Three roles (among many) that a PP should not fulfil are:
+ a detailed specification: A PP is
+ designed to be a security specification on a relatively
+ high level of abstraction. A PP should, in general, not
+ contain detailed protocol specifications, detailed
+ descriptions of algorithms and/or mechanisms, long
+ description of detailed operations etc.
+ a complete specification: A PP is
+ designed to be a security specification and not a general
+ specification. Unless security-relevant, properties such
+ as interoperability, physical size and weight, required
+ voltage etc. should not be part of a PP. This means that
+ in general a PP is a part of a complete specification, but
+ not a complete specification itself.
+ a specification of a single product:
+ Unlike an ST, a PP is designed to describe a certain type
+ of IT, and not a single product. When only a single
+ product is described, it is better to use an ST for this
+ purpose.
+
+ The PP introduction describes the TOE in a narrative way on
+ two levels of abstraction:
+
+ the PP reference, which provides identification material
+ for the PP;
+
+ the TOE overview, which briefly describes the TOE.
+
+ A PP contains a clear PP reference that identifies that
+ particular PP. A typical PP reference consists of title,
+ version, authors and publication date. An example of a PP
+ reference is ``Atlantean Navy CablePhone Encryptor PP,
+ version 2b, Atlantean Navy Procurement Office, April 7,
+ 2003''. The reference must be unique so that it is possible
+ to tell different PPs and different versions of the same PP
+ apart.
+ The PP reference facilitates indexing and referencing the PP
+ and its inclusion in lists of PPs.
+ The TOE overview is aimed at potential consumers of a TOE
+ who are looking through lists of evaluated products to find
+ TOEs that may meet their security needs, and are supported
+ by their hardware, software and firmware.
+ The TOE overview is also aimed at developers who may use the
+ PP in designing TOEs or in adapting existing products.
+ The typical length of a TOE overview is several paragraphs.
+ To this end, the TOE overview briefly describes the usage of
+ the TOE and its major security features, identifies the TOE
+ type and identifies any major non-TOE
+ hardware/software/firmware available to the TOE.
+ The description of the usage and major security features
+ of the TOE is intended to give a very general idea of what
+ the TOE should be capable of, and what it can be used
+ for. This subclause should be written for (potential) TOE
+ consumers, describing TOE usage and major security
+ features in terms of business operations, using language
+ that TOE consumers understand.
+ An example of this is ``The Atlantean Navy CablePhone
+ Encryptor is an encryption device that should allow
+ confidential communication between ships across the
+ Atlantean Navy CablePhone system. To this end it should
+ allow at least 32 different users and support at least 100
+ Mbps encryption speed. It should allow both bilateral
+ communication between ships and broadcast across the
+ entire network.''
+ The TOE overview identifies the general type of TOE, such
+ as: firewall, VPN-firewall, smart card, crypto-modem,
+ intranet, web server, database, web server and database,
+ LAN, LAN with web server and database, etc.
+ While some TOEs do not rely upon other IT, many TOEs
+ (notably software TOEs) rely on additional, non-TOE,
+ hardware, software and/or firmware. In the latter case,
+ the TOE overview is required to identify the non-TOE
+ hardware/software/firmware.
+ As a Protection Profile is not written for a specific
+ product, in many cases only a general idea can be given of
+ the available hardware/software/firmware. In some other
+ cases, e.g. a requirements specification for a specific
+ consumer where the platform is already known, (much) more
+ specific information may be provided.
+ Examples of hardware/software/firmware identifications
+ are:
+
+ None. (for a completely stand-alone TOE);
+
+ The Yaiza 3.0 Operating System running on a general
+ PC;
+
+ a CleverCard SB2067 integrated circuit;
+
+ a CleverCard SB2067 IC running v2.0 of the QuickOS
+ smart card operating system;
+
+ the December 2002 installation of the LAN of the
+ Director-General's Office of the Department of
+ Traffic.
+
+ This subclause of a PP describes how the PP conforms with
+ other PPs and with packages. It is identical to the
+ conformance claims subclause for an ST (see Subclause ), with one exception:
+ the conformance statement.
+ The conformance statement in the PP states how STs and/or
+ other PPs must conform to that PP. The PP author selects
+ whether ``strict'' or ``demonstrable'' conformance is
+ required. See
+ for more details on this.
+ This subclause is identical to the security problem definition
+ subclause of an ST as explained in Subclause .
+ This subclause is identical to the security objectives subclause
+ of an ST as explained in Subclause .
+ This subclause is identical to the extended components subclause
+ of an ST as explained in Subclause .
+ This subclause is identical to the security requirements
+ subclause of an ST as explained in Subclause . Note however that the rules for completing
+ operations in a PP are slightly different from the rules for
+ completing operations in an ST. This is explained in more
+ detail in Subclause .
+ A PP has no TOE summary specification.
+ A low assurance PP has the same relationship to a regular PP
+ (i.e., one with full contents), as a low assurance ST has to a
+ regular ST. This means that a low-assurance PP consists of
+
+ a PP introduction, consisting of a PP reference and a TOE
+ overview;
+
+ a conformance claim;
+
+ security objectives for the operational environment;
+
+ the SFRs and the SARs (including the extended components
+ definition) and the security requirements rationale (only
+ if the dependencies are not satisfied).
+
+ A low-assurance PP may only claim conformance to a
+ low-assurance PP (see ). A
+ regular PP may claim conformance with a low assurance PP.
+ The reduced content of a low assurance PP is shown in Figure
+ .
+ This subclause is identical to the subclause on standards for
+ STs as described in Subclause , with one exception: as a PP has no TOE
+ summary specification, the third option is not valid for PPs.
+ The PP author is reminded that referring to a standard in SFRs
+ may impose a significant burden on a developer developing a
+ TOE to meet that PP (depending on the size and complexity of
+ the standard and the assurance level required), and that it
+ may be more suitable to require alternative (non-CC related)
+ ways to assess conformance to that standard.
+ As described in this CC part 1, Protection Profiles and
+ Security Targets contain pre-defined security requirements, as
+ well as providing PP and ST authors the ability to extend the
+ component lists in some circumstances.
+ The four types of operations are given in section . Examples of the various
+ operations are described below:
+ As described in section
+ the iteration operation may be performed on every
+ component. The PP/ST author performs an iteration operation
+ by including multiple requirements based on the same
+ component. Each iteration of a component is different from
+ all other iterations of that component, which is realised by
+ completing assignments and selections in a different way, or
+ by applying refinements to it in a different way. Different
+ iterations should be uniquely identified to allow clear
+ rationales and tracings to and from these requirements.
+ A typical example of an iteration is
+ being iterated twice in order to require the implementation
+ of two different cryptographic algorithms. An example of
+ each iteration being uniquely identified is:
+
+ Cryptographic operation (RSA and DSA signatures)
+ (FCS_COP.1(1))
+
+ Cryptographic operation (TLS/SSL: symmetric operations)
+ (FCS_COP.1(2))
+
+ As described in subclause
+ an assignment operation occurs where a given component
+ contains an element with a parameter that may be set by the
+ PP/ST author. The parameter may be an unrestricted variable,
+ or a rule that narrows the variable to a specific range of
+ values.
+ An example of an element with an assignment is: ``When the defined number of
+ unsuccessful authentication attempts has been met or
+ surpassed, the TSF shall [assignment: list of
+ actions].''
+ As described in subclause
+ the selection operation occurs where a given component
+ contains an element where a choice from several items has to
+ be made by the PP/ST author.
+ An example of an element with a selection is: ``The TSF shall run a suite of
+ self tests [selection: during initial start-up, periodically
+ during normal operation, at the request of the authorised
+ user, at the conditions [assignment: conditions under which
+ self test should occur]] to demonstrate the correct
+ operation of ...''
+ As described in subclause
+ the refinement operation can be performed on every
+ requirement. The PP/ST author performs a refinement by
+ altering that requirement.
+ An example of a valid refinement is ``The TSF shall require each user to be
+ successfully authenticated before allowing any other
+ TSF-mediated actions on behalf of that user.'' being refined
+ to ``The TSF shall require each user to be successfully
+ authenticated by username/password before
+ allowing any other TSF-mediated actions on behalf of that
+ user.''
+ The first rule for a refinement is that a TOE meeting the
+ refined requirement also meets the unrefined requirement in
+ the context of the PP/ST (i.e. a refined requirement must be
+ ``stricter'' than the original requirement)
+ The only exception to this rule is that a PP/ST author is
+ allowed to refine a SFR to apply to some but not all
+ subjects, objects, operations, security attributes and/or
+ external entities.
+ An example of a such an exception is ``The TSF shall require each user to be
+ successfully authenticated before allowing any other
+ TSF-mediated actions on behalf of that user.'' being refined
+ to ``The TSF shall require each user originating from
+ the internet to be successfully authenticated before
+ allowing any other TSF-mediated actions on behalf of that
+ user.''
+ The second rule for a refinement given is that the
+ refinement shall be related to the original component. For
+ example, refining an audit component with an extra element
+ on prevention of electromagnetic radiation is not allowed.
+ A special case of refinement is an editorial refinement,
+ where a small change is made in a requirement,
+ i.e. rephrasing a sentence due to adherence to proper
+ English grammar, or to make it more understandable to the
+ reader. This change is not allowed to modify the meaning of
+ the requirement in any way. Examples of editorial
+ refinements include:
+
+ the SFR ``The TSF shall
+ continue to preserve a secure state when the following
+ failures occur: breakdown of one CPU''
+ could be refined to
+ ``The TSF shall continue to preserve a secure state when
+ the following failure occurs: breakdown of one
+ CPU'' or even
+ ``The TSF shall continue to preserve a secure state when
+ one CPU breaks down''.
+
+ The CC has organised the components in CC Part 2 and CC Part 3
+ into hierarchical structures:
+ Classes, consisting ofFamilies, consisting ofComponents, consisting ofElements.
+ This organisation into a hierarchy of class - family -
+ component - element is provided to assist consumers,
+ developers and evaluators in locating specific components.
+ The CC presents functional and assurance components in
+ the same general hierarchical style and use the same
+ organisation and terminology for each.
+ An example of a class is the class that is
+ focused at identification of users, authentication of users
+ and binding of users and subjects.
+ An example of a family is the family
+ which is part of the class. This family
+ concentrates on the authentication of users.
+ An example of a component is which
+ concentrates on unforgeable authentication.
+ An example of an element is which
+ concentrates on the prevention of use of copied
+ authentication data.
+ Whenever a PP/ST author defines an extended component,
+ this has to be done in a similar manner to the existing CC
+ components: clear, unambiguous and evaluatable (it is
+ possible to systematically demonstrate whether a
+ requirement based on that component holds for a
+ TOE). Extended components must use similar labelling,
+ manner of expression, and level of detail as the existing
+ CC components.
+ The PP/ST author also has to make to sure that all
+ applicable dependencies of an extended component are
+ included in the definition of that extended
+ component. Examples of possible dependencies are:
+
+ if an extended component refers to auditing,
+ dependencies to components of the
+ class may have to be included;
+
+ if an extended component modifies or accesses data,
+ dependencies to components of the
+ family may have to be included;
+
+ if an extended component uses a particular design
+ description a dependency to the appropriate family (e.g. Functional Specification) may
+ have to be included.
+
+ In the case of an extended functional component, the PP/ST
+ author also has to include any applicable audit and
+ associated operations information in the definition of
+ that component, similar to existing CC Part 2
+ components. In the case of an extended assurance
+ component, the PP/ST author also has to provide suitable
+ evaluation methodology for the component, similar to the
+ methodology provided in the CEM.
+ Extended components may be placed in existing families, in
+ which case the PP/ST writer has to show how these families
+ change. If they do not fit into an existing family, they
+ shall be placed in a new family. New families have to be
+ defined similarly to the CC.
+ New families may be placed in existing classes in which
+ case the PP/ST writer has to show how these classes
+ change. If they do not fit into an existing class, they
+ shall be placed in a new class. New classes have to be
+ defined similarly to the CC.
+ A PP is intended to be used as a ``template'' for an ST. That
+ is: the PP describes a set of user needs, while an ST that
+ conforms to that PP describes a TOE that satisfies those
+ needs.
+ Note that it is also possible for a PP to be used as a
+ template for another PP. That is PPs can claim conformance to
+ other PPs. This case is completely similar to that of an ST
+ vs. a PP. For clarity this Annex describes only the ST/PP
+ case, but it holds also for the PP/PP case.
+ The CC does not allow any form of partial conformance, so if a
+ PP is claimed, the PP or ST must fully conform to the
+ referenced PP or PPs. There are however two types of
+ conformance (``strict'' and demonstrable'') and the type of
+ conformance allowed is determined by the PP. That is, the PP
+ states (in the PP conformance statement, see subclause ) what the allowed types of conformance for the ST
+ are. This distinction between strict and demonstrable
+ conformance is applicable to each PP to which an ST may claim
+ conformance on an individual basis. This may mean that the ST
+ conforms strictly to some PPs and demonstrably to other
+ PPs. An ST is only allowed to conform to a PP in a
+ demonstrable manner, if the PP explicitly allows this, whereas
+ an ST can always conform with strict conformance to any PP.
+ Restating this in other words, an ST is only allowed to
+ conform to a PP in a demonstrable manner, if the PP explicitly
+ allows this.
+ Conformance to a PP means that the PP or ST (and if an ST is
+ of an evaluated product, the product as well) meets all
+ requirements of that PP.
+ Published PPs will normally require demonstrable
+ conformance. This means that STs claiming conformance with the
+ PP must offer a solution to the generic security problem
+ described in the PP, but can do so in any way that is
+ equivalent or more restrictive to that described in the
+ PP. ``Equivalent but more restrictive'' is defined at length
+ within the CC, but in principle it means that the PP
+ and ST may contain entirely different statements that discuss
+ different entities, use different concepts etc., provided that
+ overall the ST levies the same or more restrictions on the
+ TOE, and the same or less restrictions on the operational
+ environment of the TOE.
+ Strict conformance is oriented to the PP-author who requires
+ evidence that the requirements in the PP are met, that the ST
+ is an instantiation of the PP, though the ST could be broader
+ than the PP. In essence, the ST specifies that the TOE does at
+ least the same as in the PP, while the operational environment
+ does at most the same as in the PP.
+ A typical example of the use of strict conformance is in
+ selection based purchasing where a product's security
+ requirements are expected to exactly match those specified in
+ the PP.
+ An ST instantiating strict conformance to a PP can still
+ introduce additional restrictions to those given in the PP.
+ Demonstrable conformance is orientated to the PP-author who
+ requires evidence that the ST is a suitable solution to the
+ generic security problem described in the PP.
+ Where there is a clear subset-superset type relation between
+ PP and ST in the case of strict conformance, the relation is
+ less clear-cut in the case of demonstrable conformance. STs
+ claiming conformance with the PP must offer a solution to the
+ generic security problem described in the PP. but can do so in
+ any way that is equivalent or more restrictive to that
+ described in the PP.
+ This bibliography contains references to further material and
+ standards that the reader of the CC may find useful. For
+ undated references the reader is recommended to refer to the
+ latest edition of the referenced document.ISO/IEC 15292Information technology -- Security techniques --
+ Protection Profile registration proceduresISO/IEC 15443Information technology -- Security techniques
+ -- A framework for IT security assurance - all partsISO/IEC 15446Information technology -- Security techniques
+ -- Guide for the production of Protection Profiles and Security
+ TargetsISO/IEC 19790Information technology -- Security techniques
+ -- Security requirements for cryptographic modulesISO/IEC 19791Information technology -- Security techniques
+ -- Security assessment of operational systemsISO/IEC 27001Information technology -- Security techniques
+ -- Information security management systems -- RequirementsISO/IEC 27002Information technology -- Security techniques
+ -- Code of practice for information security managementIEEE Std 610.12-1990
+ Institute of Electrical and Electronics Engineers, Standard
+ Glossary of Software Engineering Terminology
+ CC portal
+ Common Criteria portal, February 2009. CCRA, www.commoncriteriaportal.org
+
+
+
+ Table describes the
+ relationship between PPs and the families and components of the
+ class.
+
+
+
+
+
+
+
+
+
+
+ The following Subclauses describe the constructs used in
+ representing the assurance classes, families, and
+ components.
+
+ Figure
+ illustrates the SARs defined in this CC Part 3. Note that the
+ most abstract collection of SARs is referred to as a
+ class. Each class contains assurance families, which then
+ contain assurance components, which in turn contain assurance
+ elements. Classes and families are used to provide a taxonomy
+ for classifying SARs, while components are used to specify
+ SARs in a PP/ST.
+
+
+ Figure
+ illustrates the assurance class structure.
+
+
+ Each assurance class is assigned a unique name. The name
+ indicates the topics covered by the assurance
+ class.
+
+ A unique short form of the assurance class name is also
+ provided. This is the primary means for referencing the
+ assurance class. The convention adopted is an ``A''
+ followed by two letters related to the class name.
+
+
+
+ Each assurance class has an introductory Subclause that
+ describes the composition of the class and contains
+ supportive text covering the intent of the class.
+
+
+
+ Each assurance class contains at least one assurance
+ family. The structure of the assurance families is
+ described in the following Subclause.
+
+
+
+
+
+ Figure
+ illustrates the assurance family structure.
+
+
+ Every assurance family is assigned a unique name. The name
+ provides descriptive information about the topics covered
+ by the assurance family. Each assurance family is placed
+ within the assurance class that contains other families
+ with the same intent.
+
+ A unique short form of the assurance family name is also
+ provided. This is the primary means used to reference the
+ assurance family. The convention adopted is that the short
+ form of the class name is used, followed by an underscore,
+ and then three letters related to the family name.
+
+
+
+ The objectives Subclause of the assurance family presents
+ the intent of the assurance family.
+
+ This Subclause describes the objectives, particularly
+ those related to the CC assurance paradigm, that the
+ family is intended to address. The description for the
+ assurance family is kept at a general level. Any specific
+ details required for objectives are incorporated in the
+ particular assurance component.
+
+
+
+ Each assurance family contains one or more assurance
+ components. This Subclause of the assurance family
+ describes the components available and explains the
+ distinctions between them. Its main purpose is to
+ differentiate between the assurance components once it has
+ been determined that the assurance family is a necessary
+ or useful part of the SARs for a PP/ST.
+
+ Assurance families containing more than one component are
+ levelled and rationale is provided as to how the
+ components are levelled. This rationale is in terms of
+ scope, depth, and/or rigour.
+
+
+
+ The application notes Subclause of the assurance family,
+ if present, contains additional information for the
+ assurance family. This information should be of particular
+ interest to users of the assurance family (e.g. PP and ST
+ authors, designers of TOEs, evaluators). The presentation
+ is informal and covers, for example, warnings about
+ limitations of use and areas where specific attention may
+ be required.
+
+
+
+ Each assurance family has at least one assurance
+ component. The structure of the assurance components is
+ provided in the following Subclause.
+
+
+
+
+ Figure illustrates the
+ assurance component structure.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding convention. Those parts of the
+ requirements that are new, enhanced or modified beyond the
+ requirements of the previous component within a hierarchy
+ are bolded.
+
+
+ The component identification Subclause provides
+ descriptive information necessary to identify, categorise,
+ register, and reference a component.
+
+ Every assurance component is assigned a unique name. The
+ name provides descriptive information about the topics
+ covered by the assurance component. Each assurance
+ component is placed within the assurance family that
+ shares its security objective.
+
+ A unique short form of the assurance component name is
+ also provided. This is the primary means used to reference
+ the assurance component. The convention used is that the
+ short form of the family name is used, followed by a
+ period, and then a numeric character. The numeric
+ characters for the components within each family are
+ assigned sequentially, starting from 1.
+
+
+
+ The objectives Subclause of the assurance component, if
+ present, contains specific objectives for the particular
+ assurance component. For those assurance components that
+ have this Subclause, it presents the specific intent of
+ the component and a more detailed explanation of the
+ objectives.
+
+
+
+ The application notes Subclause of an assurance component,
+ if present, contains additional information to facilitate
+ the use of the component.
+
+
+
+ Dependencies among assurance components arise when a
+ component is not self-sufficient, and relies upon the
+ presence of another component.
+
+ Each assurance component provides a complete list of
+ dependencies to other assurance components. Some
+ components may list ``No dependencies'', to indicate that
+ no dependencies have been identified. The components
+ depended upon may have dependencies on other
+ components.
+
+ The dependency list identifies the minimum set of
+ assurance components which are relied upon. Components
+ which are hierarchical to a component in the dependency
+ list may also be used to satisfy the dependency.
+
+ In specific situations the indicated dependencies might
+ not be applicable. The PP/ST author, by providing
+ rationale for why a given dependency is not applicable,
+ may elect not to satisfy that dependency.
+
+
+
+ A set of assurance elements is provided for each assurance
+ component. An assurance element is a security requirement
+ which, if further divided, would not yield a meaningful
+ evaluation result. It is the smallest security requirement
+ recognised in the CC.
+
+ Each assurance element is identified as belonging to one
+ of the three sets of assurance elements:
+
+
+ Developer action elements: the activities that shall
+ be performed by the developer. This set of actions is
+ further qualified by evidential material referenced in
+ the following set of elements. Requirements for
+ developer actions are identified by appending the
+ letter ``D'' to the element number.
+
+
+ Content and presentation of evidence elements: the
+ evidence required, what the evidence shall
+ demonstrate, and what information the evidence shall
+ convey. Requirements for content and presentation of
+ evidence are identified by appending the letter ``C''
+ to the element number.
+
+
+ Evaluator action elements: the activities that shall
+ be performed by the evaluator. This set of actions
+ explicitly includes confirmation that the requirements
+ prescribed in the content and presentation of evidence
+ elements have been met. It also includes explicit
+ actions and analysis that shall be performed in
+ addition to that already performed by the
+ developer. Implicit evaluator actions are also to be
+ performed as a result of developer action elements
+ which are not covered by content and presentation of
+ evidence requirements. Requirements for evaluator
+ actions are identified by appending the letter ``E''
+ to the element number.
+
+
+
+ The developer actions and content and presentation of
+ evidence define the assurance requirements that are used
+ to represent a developer's responsibilities in
+ demonstrating assurance in the TOE meeting the SFRs of a
+ PP or ST.
+
+ The evaluator actions define the evaluator's
+ responsibilities in the two aspects of evaluation. The
+ first aspect is validation of the PP/ST, in accordance
+ with the classes and in Clauses and . The second
+ aspect is verification of the TOE's conformance with its
+ SFRs and SARs. By demonstrating that the PP/ST is valid
+ and that the requirements are met by the TOE, the
+ evaluator can provide a basis for confidence that the TOE
+ in its operational environment solves the defined security
+ problem.
+
+ The developer action elements, content and presentation of
+ evidence elements, and explicit evaluator action elements,
+ identify the evaluator effort that shall be expended in
+ verifying the security claims made in the ST of the
+ TOE.
+
+
+
+
+ Each element represents a requirement to be met. These
+ statements of requirements are intended to be clear,
+ concise, and unambiguous. Therefore, there are no compound
+ sentences: each separable requirement is stated as an
+ individual element.
+
+
+
+ This CC Part 3 contains classes of families and components
+ that are grouped on the basis of related assurance. At the
+ start of each class is a diagram that indicates the families
+ in the class and the components in each family.
+
+
+ In Figure ,
+ above, the class as shown contains a single family. The
+ family contains three components that are linearly
+ hierarchical (i.e. component 2 requires more than component
+ 1, in terms of specific actions, specific evidence, or
+ rigour of the actions or evidence). The assurance families
+ in this CC Part 3 are all linearly hierarchical, although
+ linearity is not a mandatory criterion for assurance
+ families that may be added in the future.
+
+
+
+
+ Figure illustrates
+ the EALs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in an EAL by reference to the actual
+ components defined in the CC.
+
+
+
+ Each EAL is assigned a unique name. The name provides
+ descriptive information about the intent of the EAL.
+
+ A unique short form of the EAL name is also provided. This
+ is the primary means used to reference the EAL.
+
+
+
+ The objectives Subclause of the EAL presents the intent of
+ the EAL.
+
+
+ The application notes Subclause of the EAL, if present,
+ contains information of particular interest to users of the
+ EAL (e.g. PP and ST authors, designers of TOEs targeting
+ this EAL, evaluators). The presentation is informal and
+ covers, for example, warnings about limitations of use and
+ areas where specific attention may be required.
+ A set of assurance components have been chosen for each
+ EAL.
+ A higher level of assurance than that provided by a given
+ EAL can be achieved by:
+
+ including additional assurance components from other
+ assurance families; or
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ assurance levels defined in the CC. While assurance
+ components further decompose into assurance elements,
+ assurance elements cannot be individually referenced by
+ assurance levels. Note that the arrow in the figure
+ represents a reference from an EAL to an assurance component
+ within the class where it is defined.
+
+
+
+
+
+ The structure of the CAPs is similar to that of the EALs. The
+ main difference between these two types of package is the type
+ of TOE they apply to; the EALs applying to component TOEs and
+ the CAPs applying to composed TOEs.
+
+ Figure illustrates
+ the CAPs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in a CAP by reference to the actual
+ components defined in the CC.
+
+
+
+ Each CAP is assigned a unique name. The name provides
+ descriptive information about the intent of the CAP.
+
+ A unique short form of the CAP name is also provided. This
+ is the primary means used to reference the CAP.
+
+
+
+ The objectives Subclause of the CAP presents the intent of
+ the CAP.
+
+
+ The application notes Subclause of the CAP, if present,
+ contains information of particular interest to users of the
+ CAP (e.g. PP and ST authors, integrators of composed TOEs
+ targeting this CAP, evaluators). The presentation is
+ informal and covers, for example, warnings about limitations
+ of use and areas where specific attention may be
+ required.
+ A set of assurance components have been chosen for each
+ CAP.
+ Some dependencies identify the activities performed during
+ the evaluation of the dependent component on which the
+ composed TOE activity relies. Where it is not explicitly
+ identified that the dependency is on a dependent component
+ activity, the dependency is to another evaluation activity
+ of the composed TOE.
+ A higher level of assurance than that provided by a given
+ CAP can be achieved by:
+
+ including additional assurance components from other
+ assurance families; or
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+ The components included in the CAP
+ assurance packages should not be used as augmentations for
+ component TOE evaluations, as this would provide no
+ meaningful assurance for the component.
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ composed assurance packages defined in the CC. While
+ assurance components further decompose into assurance
+ elements, assurance elements cannot be individually
+ referenced by assurance packages. Note that the arrow in the
+ figure represents a reference from a CAP to an assurance
+ component within the class where it is defined.
+
+
+
+
+
+
+
+
+ This clause defines the content and presentation of the
+ functional requirements of the CC, and provides guidance on
+ the organisation of the requirements for new components to be
+ included in an ST. The functional requirements are expressed
+ in classes, families, and components.
+
+
+
+ Figure illustrates the
+ functional class structure in diagrammatic form. Each
+ functional class includes a class name, class introduction,
+ and one or more functional families.
+
+
+
+
+
+ The class name subclause provides information necessary to
+ identify and categorise a functional class. Every
+ functional class has a unique name. The categorical
+ information consists of a short name of three
+ characters. The short name of the class is used in the
+ specification of the short names of the families of that
+ class.
+
+
+
+ The class introduction expresses the common intent or
+ approach of those families to satisfy security
+ objectives. The definition of functional classes does not
+ reflect any formal taxonomy in the specification of the
+ requirements.
+
+ The class introduction provides a figure describing the
+ families in this class and the hierarchy of the components
+ in each family, as explained in subclause .
+
+
+
+
+
+ Figure
+ illustrates the functional family structure in diagrammatic
+ form.
+
+
+
+
+
+ The family name subclause provides categorical and
+ descriptive information necessary to identify and
+ categorise a functional family. Every functional family
+ has a unique name. The categorical information consists of
+ a short name of seven characters, with the first three
+ identical to the short name of the class followed by an
+ underscore and the short name of the family as follows
+ XXX_YYY. The unique short form of the family name provides
+ the principal reference name for the components.
+
+
+
+ The family behaviour is the narrative description of the
+ functional family stating its security objective and a
+ general description of the functional requirements. These
+ are described in greater detail below:
+
+
+ The security objectives of the family
+ address a security problem that may be solved with the
+ help of a TOE that incorporates a component of this
+ family;
+
+
+ The description of the functional
+ requirements summarises all the requirements
+ that are included in the component(s). The description
+ is aimed at authors of PPs, STs and functional
+ packages who wish to assess whether the family is
+ relevant to their specific requirements.
+
+
+
+
+
+ Functional families contain one or more components, any
+ one of which can be selected for inclusion in PPs, STs and
+ functional packages. The goal of this section is to
+ provide information to users in selecting an appropriate
+ functional component once the family has been identified
+ as being a necessary or useful part of their security
+ requirements.
+
+ This section of the functional family description
+ describes the components available, and their
+ rationale. The exact details of the components are
+ contained within each component.
+
+ The relationships between components within a functional
+ family may or may not be hierarchical. A component is
+ hierarchical to another if it offers more security.
+
+ As explained in the descriptions of the
+ families provide a graphical overview of the hierarchy of
+ the components in a family.
+
+
+
+
+ The management clauses contain information for
+ the PP/ST authors to consider as management activities for a
+ given component. The clauses reference components of the
+ management class (FMT), and provide guidance regarding potential
+ management activities that may be applied via operations to
+ those components.
+
+ A PP/ST author may select the indicated management components or
+ may include other management requirements not listed to detail
+ management activities. As such the information should be
+ considered informative.
+
+
+
+
+ The audit requirements contain auditable
+ events for the PP/ST authors to select, if requirements
+ from the class , are included in the
+ PP/ST. These requirements include security relevant events
+ in terms of the various levels of detail supported by the
+ components of the family. For example,
+ an audit note might include actions that are in terms of:
+ Minimal - successful use of the security mechanism; Basic
+ - any use of the security mechanism as well as relevant
+ information regarding the security attributes involved;
+ Detailed - any configuration changes made to the
+ mechanism, including the actual configuration values
+ before and after the change.
+
+ It should be observed that the categorisation of auditable
+ events is hierarchical. For example, when Basic Audit
+ Generation is desired, all auditable events identified as
+ being both Minimal and Basic should be included in the
+ PP/ST through the use of the appropriate assignment
+ operation, except when the higher level event simply
+ provides more detail than the lower level event. When
+ Detailed Audit Generation is desired, all identified
+ auditable events (Minimal, Basic and Detailed) should be
+ included in the PP/ST.
+
+ In the class the rules governing the audit
+ are explained in more detail.
+
+
+
+
+
+ Figure illustrates the
+ functional component structure.
+
+
+
+
+
+ The component identification subclause provides
+ descriptive information necessary to identify, categorise,
+ register and cross-reference a component. The following is
+ provided as part of every functional component:
+
+ A unique name. The name reflects the
+ purpose of the component.
+
+ A short name. A unique short form of the
+ functional component name. This short name serves as the
+ principal reference name for the categorisation,
+ registration and cross-referencing of the component. This
+ short name reflects the class and family to which the
+ component belongs and the component number within the
+ family.
+
+ A hierarchical-to list. A list of other
+ components that this component is hierarchical to and for
+ which this component can be used to satisfy dependencies
+ to the listed components.
+
+
+
+
+ A set of elements is provided for each component. Each
+ element is individually defined and is self-contained.
+
+ A functional element is a security functional requirement
+ that if further divided would not yield a meaningful
+ evaluation result. It is the smallest security functional
+ requirement identified and recognised in the CC.
+
+ When building packages, PPs and/or STs, it is not
+ permitted to select only one or more elements from a
+ component. The complete set of elements of a component
+ must be selected for inclusion in a PP, ST or package.
+
+ A unique short form of the functional element name is
+ provided. For example the requirement name FDP_IFF.4.2
+ reads as follows: F - functional requirement, DP - class
+ ``User data protection'', _IFF -
+ family ``Information flow control
+ functions'', .4 - 4th component named
+ ``Partial elimination of illicit information
+ flows'', .2 - 2nd element of the component.
+
+
+
+
+ Dependencies among functional components arise when a
+ component is not self sufficient and relies upon the
+ functionality of, or interaction with, another component
+ for its own proper functioning.
+
+ Each functional component provides a complete list of
+ dependencies to other functional and assurance
+ components. Some components may list ``No
+ dependencies''. The components depended upon may in
+ turn have dependencies on other components. The list
+ provided in the components will be the direct
+ dependencies. That is only references to the functional
+ requirements that are required for this requirement to
+ perform its job properly. The indirect dependencies, that
+ is the dependencies that result from the depended upon
+ components can be found in
+ of this part of the CC. It is noted that in some cases the
+ dependency is optional in that a number of functional
+ requirements are provided, where each one of them would be
+ sufficient to satisfy the dependency (see for example
+ ).
+
+ The dependency list identifies the minimum functional or
+ assurance components needed to satisfy the security
+ requirements associated with an identified
+ component. Components that are hierarchical to the
+ identified component may also be used to satisfy the
+ dependency.
+
+ The dependencies indicated in CC Part 2 are
+ normative. They must be satisfied within a PP/ST. In
+ specific situations the indicated dependencies might not
+ be applicable. The PP/ST author, by providing the
+ rationale why it is not applicable, may leave the depended
+ upon component out of the package, PP or ST.
+
+
+
+
+
+
+
+
+ The grouping of the components in this part of the CC does not
+ reflect any formal taxonomy.
+
+ This part of the CC contains classes of families and
+ components, which are rough groupings on the basis of related
+ function or purpose, presented in alphabetic order. At the
+ start of each class is an informative diagram that indicates
+ the taxonomy of each class, indicating the families in each
+ class and the components in each family. The diagram is a
+ useful indicator of the hierarchical relationship that may
+ exist between components.
+
+ In the description of the functional components, a section
+ identifies the dependencies between the component and any
+ other components.
+
+ In each class a figure describing the family hierarchy similar
+ to Figure , is provided. In Figure
+ the first family, Family 1,
+ contains three hierarchical components, where component 2 and
+ component 3 can both be used to satisfy dependencies on
+ component 1. Component 3 is hierarchical to component 2 and
+ can also be used to satisfy dependencies on component 2.
+
+
+
+
+ In Family 2 there are three components not all of which are
+ hierarchical. Components 1 and 2 are hierarchical to no other
+ components. Component 3 is hierarchical to component 2, and
+ can be used to satisfy dependencies on component 2, but not to
+ satisfy dependencies on component 1.
+
+ In Family 3, components 2, 3, and 4 are hierarchical to
+ component 1. Components 2 and 3 are both hierarchical to
+ component 1, but non-comparable. Component 4 is hierarchical
+ to both component 2 and component 3.
+
+ These diagrams are meant to complement the text of the
+ families and make identification of the relationships
+ easier. They do not replace the ``Hierarchical
+ to:'' note in each component that is the mandatory
+ claim of hierarchy for each component.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding
+ convention. This bolding convention calls for the bolding of
+ all new requirements. For hierarchical components,
+ requirements are bolded when they are
+ enhanced or modified beyond the requirements of the previous
+ component. In addition, any new or enhanced permitted
+ operations beyond the previous component are also
+ highlighted using bold type.
+
+
+
+
+
+ This annex contains additional guidance for the families and
+ components defined in the elements of this CC Part 2, which
+ may be required by users, developers or evaluators to use the
+ components. To facilitate finding the appropriate information,
+ the presentation of the classes, families and components in
+ this annex is similar to the presentation within the elements.
+
+
+
+ This clause defines the content and presentation of the notes
+ related to functional requirements of the CC.
+
+
+
+ Figure below
+ illustrates the functional class structure in this annex.
+
+
+
+
+
+ This is the unique name of the class defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The class introduction in this annex provides information
+ about the use of the families and components of the
+ class. This information is completed with the informative
+ diagram that describes the organisation of each class with
+ the families in each class and the hierarchical
+ relationship between components in each family.
+
+
+
+
+
+ Figure illustrates
+ the functional family structure for application notes in
+ diagrammatic form.
+
+
+
+
+
+ This is the unique name of the family defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The user notes contain additional information that is of
+ interest to potential users of the family, that is PP, ST
+ and functional package authors, and developers of TOEs
+ incorporating the functional components. The presentation
+ is informative, and might cover warnings about limitations
+ of use and areas where specific attention might be
+ required when using the components.
+
+
+
+
+ The evaluator notes contain any information that is of
+ interest to developers and evaluators of TOEs that claim
+ compliance with a component of the family. The
+ presentation is informative and can cover a variety of
+ areas where specific attention might be needed when
+ evaluating the TOE. This can include clarifications of
+ meaning and specification of the way to interpret
+ requirements, as well as caveats and warnings of specific
+ interest to evaluators.
+
+ These User Notes and Evaluator Notes sections are not
+ mandatory and appear only if appropriate.
+
+
+
+
+
+ Figure illustrates
+ the functional component structure for the application
+ notes.
+
+
+
+
+
+ This is the unique name of the component defined within
+ the normative elements of this part of the CC.
+
+
+
+
+ Any specific information related to the component can be
+ found in this section.
+
+
+ The rationale contains the specifics
+ of the rationale that refine the general statements on
+ rationale for the specific level, and should only be
+ used if level specific amplification is required.
+
+
+ The application notes contain
+ additional refinement in terms of narrative
+ qualification as it pertains to a specific
+ component. This refinement can pertain to user notes,
+ and/or evaluator notes as described in Subclause . This refinement can be
+ used to explain the nature of the dependencies
+ (e.g. shared information, or shared operation).
+
+
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+ This portion of each component contains advice relating to
+ the permitted operations of the component.
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+
+ The following dependency tables for functional components
+ show their direct, indirect and optional dependencies. Each
+ of the components that is a dependency of some functional
+ component is allocated a column. Each functional component is
+ allocated a row. The value in the table cell indicate whether
+ the column label component is directly required (indicated by
+ a cross ``X''), indirectly required (indicated by a
+ dash ``-''), or optionally required (indicated by a
+ ``o'') by the row label component. An example of a
+ component with optional dependencies is , which requires either
+ or to be present. So if is present, is not
+ necessary and vice versa. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+
+
+ Security auditing involves recognising, recording, storing,
+ and analysing information related to security relevant
+ activities (i.e. activities controlled by the TSF). The
+ resulting audit records can be examined to determine which
+ security relevant activities took place and whom (which user)
+ is responsible for them.
+
+
+
+ CC audit families allow PP/ST authors the ability to define
+ requirements for monitoring user activities and, in some
+ cases, detecting real, possible, or imminent violations of
+ the enforcement of the SFRs. The TOE's security audit functions are
+ defined to help monitor security-relevant events, and act as a
+ deterrent against security violations. The requirements of the
+ audit families refer to functions that include audit data
+ protection, record format, and event selection, as well as
+ analysis tools, violation alarms, and real-time analysis. The
+ audit trail should be presented in human-readable format
+ either directly (e.g. storing the audit trail in
+ human-readable format) or indirectly (e.g. using audit
+ reduction tools), or both.
+
+ While developing the security audit requirements, the PP/ST
+ author should take note of the inter-relationships among the
+ audit families and components. The potential exists to specify
+ a set of audit requirements that comply with the
+ family/component dependencies lists, while at the same time
+ resulting in a deficient audit function (e.g. an audit
+ function that requires all security relevant events to be
+ audited but without the selectivity to control them on any
+ reasonable basis such as individual user or object).
+
+
+ The implementation of audit requirements for networks and
+ other large systems may differ significantly from those
+ needed for stand-alone systems. Larger, more complex and
+ active systems require more thought concerning which audit
+ data to collect and how this should be managed, due to
+ lowered feasibility of interpreting (or even storing) what
+ gets collected. The traditional notion of a time-ordered list
+ or ``trail'' of audited events may not
+ be applicable in a global asynchronous network with
+ arbitrarily many events occurring at once.
+
+ Also, different hosts and servers on a distributed TOE may
+ have differing naming policies and values. Symbolic names
+ presentation for audit review may require a net-wide
+ convention to avoid redundancies and ``name
+ clashes.''
+
+ A multi-object audit repository, portions of which are
+ accessible by a potentially wide variety of authorised
+ users, may be required if audit repositories are to serve a
+ useful function in distributed systems.
+
+ Finally, misuse of authority by authorised users should be
+ addressed by systematically avoiding local storage of audit
+ data pertaining to administrator actions.
+
+
+
+
+
+
+ This family defines the response to be taken in case of
+ detected events indicative of a potential security
+ violation.
+
+
+
+ The Security audit automatic response family describes
+ requirements for the handling of audit events. The
+ requirement could include requirements for alarms or TSF
+ action (automatic response). For example, the TSF could
+ include the generation of real time alarms, termination of
+ the offending process, disabling of a service, or
+ disconnection or invalidation of a user account.
+
+ An audit event is defined to be an ``potential
+ security violation'' if so indicated by the
+ components.
+
+
+
+
+
+
+
+
+ An action should be taken for follow up action in the
+ event of an alarm. This action can be to inform the
+ authorised user, to present the authorised user with a set
+ of possible containment actions, or to take corrective
+ actions. The timing of the actions should be carefully
+ considered by the PP/ST author.
+
+
+
+ At , the TSF shall take actions in
+ case a potential security violation is detected.
+
+
+ the management (addition, removal, or modification) of
+ actions.
+
+
+ Actions taken due to potential security violations.
+
+
+ The TSF shall take
+
+
+ list of actions
+
+
+
+ the PP/ST author should specify the actions to be taken
+ in case of a potential security violation. An example of
+ such a list is: ``inform the authorised user, disable
+ the subject that created the potential security
+ violation.'' It can also specify that the action to be
+ taken can be specified by an authorised user.
+
+
+ upon detection of a potential security violation.
+
+
+
+
+
+
+
+ This family defines requirements for recording the
+ occurrence of security relevant events that take place under
+ TSF control. This family identifies the level of auditing,
+ enumerates the types of events that shall be auditable by
+ the TSF, and identifies the minimum set of audit-related
+ information that should be provided within various audit
+ record types.
+
+
+
+ The Security audit data generation family includes
+ requirements to specify the audit events that should be
+ generated by the TSF for security-relevant events.
+
+ This family is presented in a manner that avoids a dependency
+ on all components requiring audit support. Each component has
+ an audit section developed in which the events to be audited
+ for that functional area are listed. When the PP/ST author
+ assembles the PP/ST, the items in the audit area are used to
+ complete the variable in this component. Thus, the
+ specification of what could be audited for a functional area
+ is localised in that functional area.
+
+ The list of auditable events is entirely dependent on the
+ other functional families within the PP/ST. Each family
+ definition should therefore include a list of its
+ family-specific auditable events. Each auditable event in the
+ list of auditable events specified in the functional family
+ should correspond to one of the levels of audit event
+ generation specified in this family (i.e. minimal, basic,
+ detailed). This provides the PP/ST author with information
+ necessary to ensure that all appropriate auditable events are
+ specified in the PP/ST. The following example shows how
+ auditable events are to be specified in appropriate functional
+ families:
+
+ ``The following actions should be auditable if is included in the PP/ST:
+
+
+ Minimal: Successful use of the user security attribute
+ administration functions;
+
+
+ Basic: All attempted uses of the user security attribute
+ administration functions;
+
+
+ Basic: Identification of which user security attributes
+ have been modified;
+
+
+ Detailed: With the exception of specific sensitive
+ attribute data items (e.g. passwords, cryptographic
+ keys), the new values of the attributes should be
+ captured.''
+
+
+
+ For each functional component that is chosen, the auditable
+ events that are indicated in that component, at and below the
+ level indicated in should be
+ auditable. If, for example, in the previous example ``Basic''
+ would be selected in , the
+ auditable events mentioned in a), b) and c) should be
+ auditable.
+
+ Observe that the categorisation of auditable events is
+ hierarchical. For example, when Basic Audit Generation is
+ desired, all auditable events identified as being either
+ Minimal or Basic, should also be included in the PP/ST
+ through the use of the appropriate assignment operation,
+ except when the higher level event simply provides more
+ detail than the lower level event. When Detailed Audit
+ Generation is desired, all identified auditable events
+ (Minimal, Basic, and Detailed) should be included in the
+ PP/ST.
+
+ A PP/ST author may decide to include other auditable events
+ beyond those required for a given audit level. For example,
+ the PP/ST may claim only minimal audit capabilities while
+ including most of the basic capabilities because the few
+ excluded capabilities conflict with other PP/ST constraints
+ (e.g. because they require the collection of unavailable
+ data).
+
+ The functionality that creates the auditable event should be
+ specified in the PP or ST as a functional requirement.
+
+ The following are examples of the types of the events that
+ should be defined as auditable within each PP/ST functional
+ component:
+
+
+ Introduction of objects within the control of the TSF into a
+ subject's address space;
+
+
+ Deletion of objects;
+
+
+ Distribution or revocation of access rights or
+ capabilities;
+
+
+ Changes to subject or object security attributes;
+
+
+ Policy checks performed by the TSF as a result of a
+ request by a subject;
+
+
+ The use of access rights to bypass a policy check;
+
+
+ Use of Identification and Authentication functions;
+
+
+ Actions taken by an operator, and/or authorised user
+ (e.g. suppression of a TSF protection mechanism as
+ human-readable labels);
+
+
+ Import/export of data from/to removable media
+ (e.g. printed output, tapes, diskettes).
+
+
+
+
+
+
+
+
+
+
+ This component defines requirements to identify the
+ auditable events for which audit records should be
+ generated, and the information to be provided in the audit
+ records.
+
+ by itself might be used
+ when the SFRs do not require that individual user identities
+ be associated with audit events. This could be appropriate
+ when the PP/ST also contains privacy requirements. If the
+ user identity must be incorporated could be used in addition.
+
+ If the subject is a user, the user identity may be recorded as
+ the subject identity. The identity of the user may not yet been
+ verified if has not been
+ applied. Therefore in the instance of an invalid login the
+ claimed user identity should be recorded. It should be
+ considered to indicate when a recorded identity has not been
+ authenticated.
+
+
+
+ There is a dependency on . If correctness of time is not an issue for
+ this TOE, elimination of this dependency could be
+ justified.
+
+
+
+ defines the level of auditable
+ events, and specifies the list of data that shall be
+ recorded in each record.
+
+
+ The TSF shall be able to generate an audit record of the
+ following auditable events:
+
+
+ Start-up and shutdown of the audit functions;
+
+
+ All auditable events for the
+
+ minimum
+ basic
+ detailed
+ not specified
+
+
+ the PP/ST author should select the level of
+ auditable events called out in the audit section of
+ other functional components included in the
+ PP/ST. This level is one of the following:
+ ``minimum'', ``basic'', ``detailed'' or ``not
+ specified''.
+
+
+ level of audit; and
+
+
+
+
+ other specifically defined auditable events
+
+
+
+ the PP/ST author should assign a list of other
+ specifically defined auditable events to be included
+ in the list of auditable events. The assignment may
+ comprise none, or events that could be auditable
+ events of a functional requirement that are of a
+ higher audit level than requested in , as well as the
+ events generated through the use of a specified
+ Application Programming Interface (API).
+
+ .
+
+
+
+
+ The TSF shall record within each audit record at least the
+ following information:
+
+
+ Date and time of the event, type of event, subject identity (if
+ applicable), and the outcome (success or failure) of the event;
+ and
+
+
+ For each audit event type, based on the auditable event
+ definitions of the functional components included in the
+ PP/ST,
+
+
+ other audit relevant information
+
+
+
+ the PP/ST author should assign, for each auditable
+ events included in the PP/ST, either a list of other
+ audit relevant information to be included in audit
+ events records or none.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ This component addresses the requirement of accountability
+ of auditable events at the level of individual user
+ identity. This component should be used in addition to
+ .
+
+ There is a potential conflict between the audit and privacy
+ requirements. For audit purposes it may be desirable to know
+ who performed an action. The user may want to keep his/her
+ actions to himself/herself and not be identified by other
+ persons (e.g. a site with job offers). Or it might be
+ required in the Organisational Security Policy that the
+ identity of the users must be protected. In those cases the
+ objectives for audit and privacy might contradict each
+ other. Therefore if this requirement is selected and privacy
+ is important, inclusion of the component user pseudonimity
+ might be considered. Requirements on determining the real
+ user name based on its pseudonym are specified in the
+ privacy class.
+
+ If the identity of the user has not yet been verified through
+ authentication, in the instance of an invalid login the claimed
+ user identity should be recorded. It should be considered to
+ indicate when a recorded identity has not been authenticated.
+
+
+
+ At , the TSF shall associate
+ auditable events to individual user identities.
+
+
+ For audit events resulting from actions of identified users, the
+ TSF shall be able to associate each auditable event with the
+ identity of the user that caused the event.
+
+
+
+
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible or
+ real security violations. This analysis may work in support of
+ intrusion detection, or automatic response to a potential
+ security violation.
+
+ The actions to be taken based on the detection can be
+ specified using the family as
+ desired.
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible
+ or real security violations. This analysis may work in
+ support of intrusion detection, or automatic response to a
+ potential security violation.
+
+ The action to be performed by the TSF on detection of a
+ potential violation is defined in components.
+
+ For real-time analysis, audit data could be transformed into a
+ useful format for automated treatment, but into a different
+ useful format for delivery to authorised users for
+ review.
+
+
+
+
+
+
+
+
+ This component is used to specify the set of auditable
+ events whose occurrence or accumulated occurrence held to
+ indicate a potential violation of the enforcement of the
+ SFRs, and any rules to be used to perform the violation
+ analysis.
+
+
+
+ In , basic threshold
+ detection on the basis of a fixed rule set is
+ required.
+
+
+ maintenance of the rules by (adding, modifying, deletion)
+ of rules from the set of rules.
+
+
+ Enabling and disabling of any of the analysis mechanisms;
+
+
+ Automated responses performed by the tool.
+
+
+ The TSF shall be able to apply a set of rules in monitoring
+ the audited events and based upon these rules indicate a
+ potential violation of the enforcement of the SFRs.
+
+
+ The TSF shall enforce the following rules for monitoring
+ audited events:
+
+
+ Accumulation or combination of
+
+
+ subset of defined auditable events
+
+
+
+ the PP/ST author should identify the subset of
+ defined auditable events whose occurrence or
+ accumulated occurrence need to be detected as an
+ indication of a potential violation of the
+ enforcement of the SFRs.
+
+
+ known to indicate a potential security violation;
+
+
+
+
+ any other rules
+
+
+
+ the PP/ST author should specify any other rules that
+ the TSF should use in its analysis of the audit
+ trail. Those rules could include specific
+ requirements to express the needs for the events to
+ occur in a certain period of time (e.g. period of
+ the day, duration). If there are no additional
+ rules that the TSF should use in the analysis of the
+ audit trail, this assignment can be completed with
+ ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ A profile is a structure that
+ characterises the behaviour of users and/or subjects; it
+ represents how the users/subjects interact with the TSF in
+ a variety of ways. Patterns of usage are established with
+ respect to the various types of activity the
+ users/subjects engage in (e.g. patterns in exceptions
+ raised, patterns in resource utilisation (when, which,
+ how), patterns in actions performed). The ways in which
+ the various types of activity are recorded in the profile
+ (e.g. resource measures, event counters, timers) are
+ referred to as profile metrics.
+
+ Each profile represents the expected patterns of usage
+ performed by members of the profile target
+ group. This pattern may be based on past use
+ (historical patterns) or on normal use for users of
+ similar target groups (expected behaviour). A profile
+ target group refers to one or more users who interact with
+ the TSF. The activity of each member of the profile group
+ is used by the analysis tool in establishing the usage
+ patterns represented in the profile. The following are
+ some examples of profile target groups:
+
+
+ Single user account: one profile per
+ user;
+
+
+ Group ID or Group Account: one profile
+ for all users who possess the same group ID or operate
+ using the same group account;
+
+
+ Operating Role: one profile for all users
+ sharing a given operating role;
+
+
+ System: one profile for all users of a
+ system.
+
+
+
+ Each member of a profile target group is assigned an
+ individual suspicion rating that
+ represents how closely that member's new
+ activity corresponds to the established patterns of usage
+ represented in the group profile.
+
+ The sophistication of the anomaly detection tool will
+ largely be determined by the number of target profile
+ groups required by the PP/ST and the complexity of the
+ required profile metrics.
+
+
+ The PP/ST author should enumerate specifically what activity
+ should be monitored and/or analysed by the TSF. The PP/ST
+ author should also identify specifically what information
+ pertaining to the activity is necessary to construct the
+ usage profiles.
+
+ requires that the TSF
+ maintain profiles of system usage. The word maintain implies
+ that the anomaly detector is actively updating the usage
+ profile based on new activity performed by the profile
+ target members. It is important here that the metrics for
+ representing user activity are defined by the PP/ST
+ author. For example, there may be a thousand different
+ actions an individual may be capable of performing, but the
+ anomaly detector may choose to monitor a subset of that
+ activity. Anomalous activity gets integrated into the
+ profile just like non-anomalous activity (assuming the tool
+ is monitoring those actions). Things that may have appeared
+ anomalous four months ago, might over time become the norm
+ (and vice-versa) as the user's work duties change. The TSF
+ wouldn't be able to capture this notion if it filtered out
+ anomalous activity from the profile updating
+ algorithms.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ suspicion rating.
+
+ The PP/ST author should define how to interpret suspicion
+ ratings and the conditions under which anomalous activity is
+ indicated to the
+ mechanism.
+
+
+
+ In , the TSF maintains
+ individual profiles of system usage, where a profile
+ represents the historical patterns of usage performed by
+ members of the profile target group. A profile target group
+ refers to a group of one or more individuals (e.g. a single
+ user, users who share a group ID or group account, users who
+ operate under an assigned role, users of an entire system or
+ network node) who interact with the TSF. Each member of a
+ profile target group is assigned an individual suspicion
+ rating that represents how well that member's current
+ activity corresponds to the established patterns of usage
+ represented in the profile. This analysis can be performed
+ at runtime or during a post-collection batch-mode
+ analysis.
+
+
+ maintenance (deletion, modification, addition) of the
+ group of users in the profile target group.
+
+
+
+ The TSF shall be able to maintain profiles of system usage,
+ where an individual profile represents the historical
+ patterns of usage performed by the member(s) of
+
+
+ the profile target group
+
+
+
+ the PP/ST author should specify the profile target
+ group. A single PP/ST may include multiple profile
+ target groups.
+
+ .
+
+
+ The TSF shall be able to maintain a suspicion rating
+ associated with each user whose activity is recorded in a
+ profile, where the suspicion rating represents the degree to
+ which the user's current activity is found
+ inconsistent with the established patterns of usage
+ represented in the profile.
+
+
+ The TSF shall be able to indicate a possible violation of
+ the enforcement of the SFRs when a user's suspicion rating exceeds
+ the following threshold conditions
+
+
+ conditions under which anomalous activity is reported by
+ the TSF
+
+
+
+ the PP/ST author should specify conditions under which
+ anomalous activity is reported by the TSF. Conditions
+ may include the suspicion rating reaching a certain
+ value, or be based on the type of anomalous activity
+ observed.
+
+ .
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant that they are always worthy of
+ independent review. Example of such events include the
+ deletion of a key TSF security data file (e.g. the
+ password file) or activity such as a remote user
+ attempting to gain administrative privilege. These events
+ are referred to as signature events in that their
+ occurrence in isolation from the rest of the system
+ activity are indicative of intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data).
+
+ The elements of do not
+ require that the TSF implementing the immediate attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able
+ to detect the occurrence of signature events that represent
+ a significant threat to enforcement of the SFRs. This search
+ for signature events may occur in real-time or during a
+ post-collection batch-mode analysis.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of system
+ events whose occurrence, in isolation from all other
+ system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by
+ themselves indicate a clear violation to the enforcement
+ of the SFRs, or whose occurrence is so significant that
+ they warrant actions.
+
+
+ that may indicate a violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events
+ against the record of system activity discernible from an
+ examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when a system event is found to match
+ a signature event that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant they are always worthy of independent
+ review. Example of such events include the deletion of a key
+ TSF security data file (e.g. the password file) or activity
+ such as a remote user attempting to gain administrative
+ privilege. These events are referred to as signature events
+ in that their occurrence in isolation from the rest of the
+ system activity are indicative of intrusive activity. Event
+ sequences are an ordered set of signature events that might
+ indicate intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events and event sequences.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data). Levelling, therefore, requires the
+ PP/ST author to specify the type of input data used to
+ monitor system activity.
+
+ The elements of do not
+ require that the TSF implementing the complex attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able to
+ represent and detect multi-step intrusion scenarios. The
+ TSF is able to compare system events (possibly performed
+ by multiple individuals) against event sequences known to
+ represent entire intrusion scenarios. The TSF shall be
+ able to indicate when a signature event or event sequence
+ is found that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events;
+
+
+ maintenance (deletion, modification, addition) of the set of
+ sequence of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following event sequences of known intrusion
+ scenarios
+
+
+ list of sequences of system events whose occurrence are
+ representative of known penetration scenarios
+
+
+
+ the PP/ST author should identify a base set of list of
+ sequences of system events whose occurrence are
+ representative of known penetration scenarios. These
+ event sequences represent known penetration
+ scenarios. Each event represented in the sequence should
+ map to a monitored system event, such that as the system
+ events are performed, they are bound (mapped) to the
+ known penetration event sequences.
+
+
+ and the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of
+ system events whose occurrence, in isolation from all
+ other system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by themselves indicate
+ a clear violation to the SFRs, or whose occurrence is
+ so significant they warrant action.
+
+
+ that may indicate a potential
+ violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events and
+ event sequences against the record of system activity
+ discernible from an examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when system activity is found to match
+ a signature event or event sequence that indicates a potential
+ violation of the enforcement of the SFRs.
+
+
+
+
+
+
+
+ This family defines the requirements for audit tools that
+ should be available to authorised users to assist in the
+ review of audit data.
+
+
+
+ The Security audit review family defines requirements
+ related to review of the audit information.
+
+ These functions should allow pre-storage or post-storage
+ audit selection that includes, for example, the ability to
+ selectively review:
+
+
+ the actions of one or more users (e.g. identification,
+ authentication, TOE entry, and access control actions);
+
+
+ the actions performed on a specific object or TOE
+ resource;
+
+
+ all of a specified set of audited exceptions;
+ or
+
+
+ actions associated with a specific SFR attribute.
+
+
+
+ The distinction between audit reviews is based on
+ functionality. Audit review (only) encompasses the ability to
+ view audit data. Selectable review is more sophisticated, and
+ requires the ability to select subsets of audit data based on a
+ single criterion or multiple criteria with logical (i.e. and/or)
+ relations, and order the audit data before it is
+ reviewed.
+
+
+
+
+
+
+
+
+ This component will provide authorised users the
+ capability to obtain and interpret the information. In
+ case of human users this information needs to be in a
+ human understandable presentation. In case of external IT
+ entities the information needs to be unambiguously
+ represented in an electronic fashion.
+
+
+
+ This component is used to specify that users and/or
+ authorised users can read the audit records. These audit
+ records will be provided in a manner appropriate to the
+ user. There are different types of users (human users,
+ machine users) that might have different needs.
+
+ The content of the audit records that can be viewed can be
+ specified.
+
+
+
+ , provides the capability to read
+ information from the audit records.
+
+
+ maintenance (deletion, modification, addition) of the group
+ of users with read access right to the audit records.
+
+
+ Reading of information from the audit records.
+
+
+ The TSF shall provide
+
+
+ authorised users
+
+
+
+ the PP/ST author should specify the authorised users
+ that can use this capability. If appropriate the PP/ST
+ author may include security roles (see ).
+
+
+ with the capability to read
+
+
+ list of audit information
+
+
+
+ the PP/ST author should specify the type of information
+ the specified user is permitted to obtain from the audit
+ records. Examples are ``all'', ``subject identity'',
+ ``all information belonging to audit records referencing
+ this user''. When employing the SFR, FAU_SAR.1, it is not
+ necessary to repeat, in full detail, the list of audit
+ information first specified in FAU_GEN.1. Use of terms
+ such as ``all'' or ``all audit information'' assist in
+ eliminating ambiguity and the further need for
+ comparative analysis between the two security
+ requirements.
+
+
+ from the audit records.
+
+
+ The TSF shall provide the audit records in a manner suitable
+ for the user to interpret the information.
+
+
+
+
+
+
+
+
+
+ This component specifies that any users not identified in
+ will not be able to read
+ the audit records.
+
+
+
+ , requires that there are
+ no other users except those that have been identified in
+ that can read the
+ information.
+
+
+ Unsuccessful attempts to read information from the audit
+ records.
+
+
+ The TSF shall prohibit all users read access to the audit
+ records, except those users that have been granted explicit
+ read-access.
+
+
+
+
+
+
+
+
+
+ This component is used to specify that it should be
+ possible to perform selection of the audit data to be
+ reviewed. If based on multiple criteria, those criteria
+ should be related together with logical
+ (i.e. ``and'' or
+ ``or'') relations, and the tools
+ should provide the ability to manipulate audit data
+ (e.g. sort, filter).
+
+
+
+ , requires audit review
+ tools to select the audit data to be reviewed based on
+ criteria.
+
+
+ the parameters used for the viewing.
+
+
+ The TSF shall provide the ability to apply
+
+ methods of selection and/or ordering
+
+ the PP/ST author should specify whether capabilities to
+ select and/or order audit data is required from the
+ TSF.
+ of audit data based on
+
+ criteria with logical relations
+
+ the PP/ST author should assign the criteria, possibly
+ with logical relations, to be used to select the audit
+ data for review. The logical relations are intended to
+ specify whether the operation can be on an individual
+ attribute or a collection of attributes. An example of
+ this assignment could be: ``application, user account
+ and/or location''. In this case the operation could be
+ specified using any combination of the three attributes:
+ application, user account and location..
+
+
+
+
+
+
+
+ This family defines requirements to select the set of events to
+ be audited during TOE operation from the set of all auditable
+ events.
+
+
+
+ The Security audit event selection family provides
+ requirements related to the capabilities of identifying which
+ of the possible auditable events are to be audited. The
+ auditable events are defined in the family, but those events should be defined as
+ being selectable in this component to be audited.
+
+ This family ensures that it is possible to keep the audit
+ trail from becoming so large that it becomes useless, by
+ defining the appropriate granularity of the selected
+ security audit events.
+
+
+
+
+
+
+
+
+
+ This component defines the selection criteria used, and the
+ resulting audited subsets of the set of all auditable events,
+ based on user attributes, subject attributes, object attributes,
+ or event types.
+
+ The existence of individual user identities is not assumed
+ for this component. This allows for TOEs such as routers
+ that may not support the notion of users.
+
+ For a distributed environment, the host identity could be
+ used as a selection criteria for events to be audited.
+
+ The management function
+ will handle the rights of authorised users to query or
+ modify the selections.
+
+
+ , requires the ability to
+ select the set of events to be audited from the set of all
+ auditable events, identified in , based upon attributes to be specified by the
+ PP/ST author.
+
+
+ maintenance of the rights to view/modify the audit events.
+
+
+ All modifications to the audit configuration that occur
+ while the audit collection functions are operating.
+
+
+ The TSF shall be able to select the set of events to be audited from
+ the set of all auditable events based on the following
+ attributes:
+ object identityuser identitysubject identityhost identityevent type
+ the PP/ST author should select whether the
+ security attributes upon which audit selectivity
+ is based, is related to object identity, user
+ identity, subject identity, host identity, or event type.
+ list of additional attributes that audit selectivity is based upon
+
+ the PP/ST author should specify any additional
+ attributes upon which audit selectivity is based. If
+ there are no additional rules upon which audit
+ selectivity is based, this assignment can be
+ completed with ``none''.
+
+
+
+
+
+
+ This family defines the requirements for the TSF to be able
+ to create and maintain a secure audit trail. Stored audit
+ records refers to those records within the audit trail, and
+ not the audit records that have been retrieved (to temporary
+ storage) through selection.
+
+
+
+ The Security audit event storage family describes
+ requirements for storing audit data for later use, including
+ requirements controlling the loss of audit information due
+ to TOE failure, attack and/or exhaustion of storage
+ space.
+
+
+
+
+
+
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+ The TSF will protect the stored audit records in the audit trail from unauthorised
+ deletion and modification. It is noted that in some TOEs the
+ auditor (role) might not be authorised to delete the audit
+ records for a certain period of time.
+
+
+
+ At , requirements are
+ placed on the audit trail. It will be protected from
+ unauthorised deletion and/or modification.
+
+
+ The TSF shall protect the stored audit records in the audit
+ trail from unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+
+
+
+
+
+
+
+
+ This component allows the PP/ST author to specify to which
+ metrics the audit trail should conform.
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+
+
+ , specifies the guarantees
+ that the TSF maintains over the audit data given the
+ occurrence of an undesired condition.
+
+
+ maintenance of the parameters that control the audit storage
+ capability.
+
+
+ The TSF shall protect the stored audit records in the audit trail from
+ unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+ The TSF shall ensure that
+
+
+ metric for saving audit records
+
+
+
+ the PP/ST author should specify the metric that the TSF
+ must ensure with respect to the stored audit
+ records. This metric limits the data loss by enumerating
+ the number of records that must be kept, or the time
+ that records are guaranteed to be maintained. An example
+ of the metric could be ``100,000'' indicating that
+ 100,000 audit records can be stored.
+
+
+ stored audit records will be maintained when the
+ following conditions occur:
+
+ audit storage exhaustion
+ failure
+ attack
+
+
+ the PP/ST author should specify the condition under which the
+ TSF shall still be able to maintain a defined amount of audit
+ data. This condition can be any of the following: audit
+ storage exhaustion, failure, attack.
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that actions will be taken when
+ the audit trail exceeds certain pre-defined limits.
+
+
+
+ , specifies actions to be taken if a
+ threshold on the audit trail is exceeded.
+
+
+ maintenance of the threshold;
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of imminent audit storage failure.
+
+
+ Actions taken due to exceeding of a threshold.
+
+
+ The TSF shall
+
+
+ actions to be taken in case
+ of possible audit storage failure
+
+
+
+ the PP/ST author should indicate the pre-defined
+ limit. If the management functions indicate that this
+ number might be changed by the authorised user, this
+ value is the default value. The PP/ST author might
+ choose to let the authorised user define this
+ limit. In that case the assignment can be for example
+ ``an authorised user set limit''.
+
+
+ if the audit trail exceeds
+
+
+ pre-defined limit
+
+
+
+ the PP/ST author should specify actions that should be
+ taken in case of imminent audit storage failure
+ indicated by exceeding the threshold. Actions might
+ include informing an authorised user.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies the behaviour of the TOE if the audit
+ trail is full: either audit records are ignored, or the TOE is
+ frozen such that no audited events can take place. The
+ requirement also states that no matter how the requirement is
+ instantiated, the authorised user with specific rights to this
+ effect, can continue to generate audited events (actions). The
+ reason is that otherwise the authorised user could not even
+ reset the TOE. Consideration should be given to the choice of
+ the action to be taken by the TSF in the case of audit storage
+ exhaustion, as ignoring events, which provides better
+ availability of the TOE, will also permit actions to be
+ performed without being recorded and without the user being
+ accountable.
+
+
+
+ , specifies actions in case the
+ audit trail is full.
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of audit storage failure.
+
+
+ Actions taken due to the audit storage failure.
+
+
+ The TSF shall
+ ``ignore audited
+ events''``prevent audited events,
+ except those taken by the authorised user with special
+ rights''
+ ``overwrite the oldest stored audit
+ records''
+
+ the PP/ST author should select whether the TSF shall ignore
+ audited actions, or whether it should prevent audited
+ actions from happening, or whether the oldest audit records
+ should be overwritten when the TSF can no longer store audit
+ records. Only one of these options may be chosen.
+ and
+
+ other actions to be taken in case of audit storage
+ failure
+
+ the PP/ST author should specify other actions that should be
+ taken in case of audit storage failure, such as informing the
+ authorised user. If there is no other action to be taken in
+ case of audit storage failure, this assignment can be
+ completed with ``none''.
+ if the audit trail is full.
+
+
+
+
+
+
+
+ This class provides two families specifically concerned with
+ assuring the identity of a party participating in a data
+ exchange. These families are related to assuring the identity
+ of the originator of transmitted information (proof of origin)
+ and assuring the identity of the recipient of transmitted
+ information (proof of receipt). These families ensure that an
+ originator cannot deny having sent the message, nor can the
+ recipient deny having received it.
+
+
+
+ This class describes requirements specifically of interest for
+ TOEs that are used for the transport of information. Families
+ within this class deal with non-repudiation.
+
+ In this class the concept of ``information'' is
+ used. This information should be interpreted as the object
+ being communicated, and could contain an electronic mail
+ message, a file, or a set of predefined attribute types.
+
+ In the literature, the terms ``proof of receipt''
+ and ``proof of origin'' are commonly used
+ terms. However it is recognised that the term
+ ``proof'' might be interpreted in a legal sense to
+ imply a form of mathematical rationale. The components in this
+ class interpret the de-facto use of the word
+ ``proof'' in the context of ``evidence''
+ that the TSF demonstrates the non-repudiated transport of
+ types of information.
+
+
+
+
+
+ Non-repudiation of origin ensures that the originator of
+ information cannot successfully deny having sent the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that receives information
+ during a data exchange is provided with evidence of the
+ origin of the information. This evidence can then be
+ verified by either this subject or other subjects.
+
+
+
+ Non-repudiation of origin defines requirements to provide
+ evidence to users/subjects about the identity of the
+ originator of some information. The originator cannot
+ successfully deny having sent the information because
+ evidence of origin (e.g. digital signature) provides
+ evidence of the binding between the originator and the
+ information sent. The recipient or a third party can verify
+ the evidence of origin. This evidence should not be
+ forgeable.
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of origin might
+ fail. Therefore a PP/ST author should consider including
+ integrity requirements such as in the
+ PP/ST.
+
+ In non-repudiation there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of origin (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of origin, for
+ example, a recipient or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was transmitted. For example, requests for
+ proposals must be transmitted before a certain date in order
+ to be considered. In such instances, these requirements can
+ be customised to provide a timestamp indication (time of
+ origin).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with the capability to request evidence of the
+ origin of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and recipients of evidence.
+
+
+ The identity of the user who requested that evidence of
+ origin would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall be able to generate evidence of origin for
+ transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection, should specify the third
+ parties that can request evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of origin.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+ list of information fields
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of origin for transmitted information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of origin
+ for transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at all times.
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ Non-repudiation of receipt ensures that the recipient of
+ information cannot successfully deny receiving the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that transmits information
+ during a data exchange is provided with evidence of receipt
+ of the information. This evidence can then be verified by
+ either this subject or other subjects.
+
+
+
+ Non-repudiation of receipt defines requirements to provide
+ evidence to other users/subjects that the information was
+ received by the recipient. The recipient cannot successfully
+ deny having received the information because evidence of
+ receipt (e.g. digital signature) provides evidence of the
+ binding between the recipient attributes and the
+ information. The originator or a third party can verify the
+ evidence of receipt. This evidence should not be forgeable.
+
+ It should be noted that the provision of evidence that the
+ information was received does not necessarily imply that the
+ information was read or comprehended, but only delivered
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of receipt with
+ respect to the original information might fail. Therefore a
+ PP/ST author should consider including integrity
+ requirements such as in the PP/ST.
+
+ In non-repudiation, there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of receipt (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided, (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of receipt, for
+ example, an originator or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case, the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was received. For example, when an offer expires
+ at a certain date, orders must be received before a certain
+ date in order to be considered. In such instances, these
+ requirements can be customised to provide a timestamp
+ indication (time of receipt).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with a capability to request evidence of the
+ receipt of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and third parties recipients of
+ evidence.
+
+
+ The identity of the user who requested that evidence of
+ receipt would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+ The TSF shall be able to generate
+ evidence of receipt for received
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can request
+ evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of receipt.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of receipt for received information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of receipt
+ for received
+
+ list of information types
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example electronic mail messages. at all times.
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+ For each cryptographic key generation method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key distribution method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key access method implemented by the
+ TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key destruction method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic operation (such as digital signature,
+ data encryption, key agreement, secure hash, etc.) performed
+ by the TOE, if any, the PP/ST author should select the component.
+
+ Cryptographic functionality may be used to meet objectives
+ specified in class , and in families , , ,
+ , , , to meet a variety of objectives. In the cases
+ where cryptographic functionality is used to meet objectives
+ for other classes, the individual functional components
+ specify the objectives that cryptographic functionality must
+ satisfy. The objectives in class should be
+ used when cryptographic functionality of the TOE is sought by
+ consumers.
+
+
+
+
+
+ Cryptographic keys must be managed throughout their life
+ cycle. This family is intended to support that lifecycle and
+ consequently defines requirements for the following
+ activities: cryptographic key generation, cryptographic key
+ distribution, cryptographic key access and cryptographic key
+ destruction. This family should be included whenever there
+ are functional requirements for the management of
+ cryptographic keys.
+
+
+
+ Cryptographic keys must be managed throughout their
+ lifetime. The typical events in the lifecycle of a
+ cryptographic key include (but are not limited to):
+ generation, distribution, entry, storage, access
+ (e.g. backup, escrow, archive, recovery) and destruction.
+
+ The inclusion of other stages is dependent on the key management
+ strategy being implemented, as the TOE need not be involved in
+ all of the key life-cycle (e.g. the TOE may only generate and
+ distribute cryptographic keys).
+
+ This family is intended to support the cryptographic key
+ lifecycle and consequently defines requirements for the
+ following activities: cryptographic key generation,
+ cryptographic key distribution, cryptographic key access and
+ cryptographic key destruction. This family should be
+ included whenever there are functional requirements for the
+ management of cryptographic keys.
+
+ If Security Audit Data Generation is
+ included in the PP/ST then, in the context of the events
+ being audited:
+
+
+ The object attributes may include the assigned user
+ for the cryptographic key, the user role, the
+ cryptographic operation that the cryptographic key is
+ to be used for, the cryptographic key identifier and
+ the cryptographic key validity period.
+
+
+ The object value may include the values of cryptographic
+ key(s) and parameters excluding any sensitive
+ information (such as secret or private cryptographic
+ keys).
+
+
+
+ Typically, random numbers are used to generate cryptographic
+ keys. If this is the case, then
+ should be used instead of the component .
+ In cases where random number generation is required for purposes other
+ than for the generation of cryptographic keys, the component
+ should be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic key sizes and
+ method used to generate cryptographic keys to be
+ specified, this can be in accordance with an assigned
+ standard. It should be used to specify the cryptographic
+ key sizes and the method (e.g. algorithm) used to generate
+ the cryptographic keys. Only one instance of the component
+ is needed for the same method and multiple key sizes. The
+ key size could be common or different for the various
+ entities, and could be either the input to or the output
+ from the method.
+
+
+
+ , requires cryptographic keys to be
+ generated in accordance with a specified algorithm and key
+ sizes which can be based on an assigned standard.
+
+
+
+ Success and failure of the activity.
+
+
+ The object attribute(s), and object value(s) excluding any
+ sensitive information (e.g. secret or private keys).
+
+
+ The TSF shall generate cryptographic keys in accordance with
+ a specified cryptographic key generation algorithm
+
+
+ cryptographic key generation algorithm
+
+
+
+ the PP/ST author should specify the cryptographic key
+ generation algorithm to be used.
+
+
+ and specified cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to generate
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to distribute
+ cryptographic keys to be specified, this can be in
+ accordance with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ distributed in accordance with a specified distribution
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall distribute cryptographic keys in accordance
+ with a specified cryptographic key distribution method
+
+
+ cryptographic key distribution method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ distribution method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to distribute
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to access
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires access to cryptographic
+ keys to be performed in accordance with a specified access
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall perform
+
+
+ type of cryptographic key access
+
+
+
+ the PP/ST author should specify the type of
+ cryptographic key access being used. Examples of types
+ of cryptographic key access include (but are not
+ limited to) cryptographic key backup, cryptographic
+ key archival, cryptographic key escrow and
+ cryptographic key recovery.
+
+
+ in accordance with a specified cryptographic key access
+ method
+
+
+ cryptographic key access method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ access method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to access cryptographic
+ keys. The assigned standard may comprise none, one or
+ more actual standards publications, for example, from
+ international, national, industry or organisational
+ standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to destroy
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ destroyed in accordance with a specified destruction
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall destroy cryptographic keys in accordance with
+ a specified cryptographic key destruction method
+
+
+ cryptographic key destruction method
+
+
+
+ the PP/ST author should specify the key destruction
+ method to be used to destroy cryptographic keys.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to destroy
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+ In order for a cryptographic operation to function
+ correctly, the operation must be performed in accordance
+ with a specified algorithm and with a cryptographic key of a
+ specified size. This family should be included whenever
+ there are requirements for cryptographic operations to be
+ performed.
+
+ Typical cryptographic operations include data encryption
+ and/or decryption, digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or verification of checksum, secure hash
+ (message digest), cryptographic key encryption and/or
+ decryption, and cryptographic key agreement.
+
+
+
+ A cryptographic operation may have cryptographic mode(s) of
+ operation associated with it. If this is the case, then the
+ cryptographic mode(s) must be specified. Examples of
+ cryptographic modes of operation are cipher block chaining,
+ output feedback mode, electronic code book mode, and cipher
+ feedback mode.
+
+ Cryptographic operations may be used to support one or more
+ TOE security services. The component
+ may need to be iterated more than once depending on:
+
+
+ the user application for which the security service is
+ being used.
+
+
+ the use of different cryptographic algorithms and/or
+ cryptographic key sizes.
+
+
+ the type or sensitivity of the data being operated on.
+
+
+
+ If Security audit data generation is
+ included in the PP/ST then, in the context of the
+ cryptographic operation events being audited:
+
+
+ The types of cryptographic operation may include digital
+ signature generation and/or verification, cryptographic
+ checksum generation for integrity and/or for
+ verification of checksum, secure hash (message digest)
+ computation, data encryption and/or decryption,
+ cryptographic key encryption and/or decryption,
+ cryptographic key agreement and random number
+ generation.
+
+
+ The subject attributes may include subject role(s) and
+ user(s) associated with the subject.
+
+
+ The object attributes may include the assigned user for
+ the cryptographic key, user role, cryptographic
+ operation the cryptographic key is to be used for,
+ cryptographic key identifier, and the cryptographic key
+ validity period.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic algorithm and
+ key size used to perform specified cryptographic
+ operation(s) which can be based on an assigned standard.
+
+
+
+ , requires a cryptographic operation
+ to be performed in accordance with a specified algorithm
+ and with a cryptographic key of specified sizes. The
+ specified algorithm and cryptographic key sizes can be
+ based on an assigned standard.
+
+
+ Success and failure, and the type of cryptographic
+ operation.
+
+
+ Any applicable cryptographic mode(s) of operation, subject
+ attributes and object attributes.
+
+
+ The TSF shall perform
+
+
+ list of cryptographic operations
+
+
+
+ the PP/ST author should specify the cryptographic
+ operations being performed. Typical cryptographic
+ operations include digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or for verification of checksum, secure
+ hash (message digest) computation, data encryption
+ and/or decryption, cryptographic key encryption and/or
+ decryption, cryptographic key agreement and random
+ number generation. The cryptographic operation may be
+ performed on user data or TSF data.
+
+
+ in accordance with a specified cryptographic algorithm
+
+
+ cryptographic algorithm
+
+
+
+ the PP/ST author should specify the cryptographic
+ algorithm to be used. Typical cryptographic algorithms
+ include, but are not limited to, DES, RSA and IDEA.
+
+
+ and cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents how the identified cryptographic
+ operation(s) are performed. The assigned standard may
+ comprise none, one or more actual standards
+ publications, for example, from international,
+ national, industry or organisational standards.
+
+ .
+
+
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. is split
+ into four groups of families (listed below) that address user
+ data within a TOE, during import, export, and storage as well
+ as security attributes directly related to user data.
+
+ The families in this class are organised into four groups:
+
+
+ User data protection security function policies:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families permit the PP/ST author to
+ name the user data protection security function policies
+ and define the scope of control of the policy, necessary
+ to address the security objectives. The names of these
+ policies are meant to be used throughout the remainder
+ of the functional components that have an operation that
+ calls for an assignment or selection of an "access
+ control SFP" or an "information flow control
+ SFP". The rules that define the functionality of
+ the named access control and information flow control
+ SFPs will be defined in the and
+ families (respectively).
+
+
+ Forms of user data protection:
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ; and
+
+
+ .
+
+
+
+
+ Off-line storage, import and export:
+
+
+ ;
+
+
+ ;
+
+
+ .
+
+
+
+ Components in these families address the trustworthy
+ transfer into or out of the TOE.
+
+
+ Inter-TSF communication:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families address communication
+ between the TSF of the TOE and another trusted IT
+ product.
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. This class differs from FIA and FPT
+ in that specifies components to
+ protect user data, FIA specifies components to protect
+ attributes associated with the user, and FPT specifies
+ components to protect TSF information.
+
+ The class does not contain explicit requirements for
+ traditional Mandatory Access Controls (MAC) or traditional
+ Discretionary Access Controls (DAC); however, such
+ requirements may be constructed using components from this
+ class.
+
+ does not explicitly deal with
+ confidentiality, integrity, or availability, as all three are
+ most often intertwined in the policy and mechanisms. However,
+ the TOE security policy must adequately cover these three
+ objectives in the PP/ST.
+
+ A final aspect of this class is that it specifies access
+ control in terms of ``operations''. An operation
+ is defined as a specific type of access on a specific
+ object. It depends on the level of abstraction of the PP/ST
+ author whether these operations are described as
+ ``read'' and/or ``write''
+ operations, or as more complex operations such as
+ ``update the database''.
+
+ The access control policies are policies that control access
+ to the information container. The attributes represent
+ attributes of the container. Once the information is out of
+ the container, the accessor is free to modify that
+ information, including writing the information into a
+ different container with different attributes. By contrast, an
+ information flow policies controls access to the information,
+ independent of the container. The attributes of the
+ information, which may be associated with the attributes of
+ the container (or may not, as in the case of a multi-level
+ database) stay with the information as it moves. The accessor
+ does not have the ability, in the absence of an explicit
+ authorisation, to change the attributes of the information.
+
+ This class is not meant to be a complete taxonomy of IT access
+ policies, as others can be imagined. Those policies included
+ here are simply those for which current experience with actual
+ systems provides a basis for specifying requirements. There
+ may be other forms of intent that are not captured in the
+ definitions here.
+
+ For example, one could imagine a goal of having user-imposed
+ (and user-defined) controls on information flow (e.g. an
+ automated implementation of the NO FOREIGN handling
+ caveat). Such concepts could be handled as refinements of, or
+ extensions to the components.
+
+ Finally, it is important when looking at the components in
+ to remember that these components are
+ requirements for functions that may be implemented by a
+ mechanism that also serves or could serve another purpose. For
+ example, it is possible to build an access control policy
+ () that uses labels () as the basis of the access control
+ mechanism.
+
+ A set of SFRs may encompass many security function
+ policies (SFPs), each to be identified by the two policy
+ oriented components , and . These policies will typically take
+ confidentiality, integrity, and availability aspects into
+ consideration as required, to satisfy the TOE
+ requirements. Care should be taken to ensure that all objects
+ are covered by at least one SFP and that there are no
+ conflicts arising from implementing the multiple SFPs.
+
+ When building a PP/ST using components from the class, the following information provides guidance
+ on where to look and what to select from the class.
+
+ The requirements in the class are defined in
+ terms of a set of SFRs that will
+ implement a SFP. Since a TOE may implement multiple SFPs
+ simultaneously, the PP/ST author must specify the name for
+ each SFP, so it can be referenced in other families. This name
+ will then be used in each component selected to indicate that
+ it is being used as part of the definition of requirements for
+ that SFP. This allows the author to easily indicate the
+ scope for operations such as objects covered, operations
+ covered, authorised users, etc.
+
+ Each instantiation of a component can apply to only one
+ SFP. Therefore if an SFP is specified in a component then
+ this SFP will apply to all the elements in this
+ component. The components may be instantiated multiple times
+ within a PP/ST to account for different policies if so
+ desired.
+
+ The key to selecting components from this family is to have a
+ well defined set of TOE security objectives to enable proper
+ selection of the components from the two policy components;
+ and . In and respectively, all access control
+ policies and all information flow control policies are
+ named. Furthermore the scope of control of these components in
+ terms of the subjects, objects and operations covered by this
+ security functionality. The names of these policies are meant
+ to be used throughout the remainder of the functional
+ components that have an operation that calls for an assignment
+ or selection of an ``access control SFP'' or an ``information
+ flow control SFP''. The rules that define the functionality
+ of the named access control and information flow control SFPs
+ will be defined in the and
+ families
+ (respectively).
+
+ The following steps are guidance on how this class is applied
+ in the construction of a PP/ST:
+
+
+ Identify the policies to be enforced from the , and families. These
+ families define scope of control for the policy,
+ granularity of control and may identify some rules to go
+ with the policy.
+
+
+ Identify the components and perform any applicable operations
+ in the policy components. The assignment operations may be
+ performed generally (such as with a statement ``All
+ files'') or specifically (``The files
+ ``A'', ``B'', etc.) depending upon
+ the level of detail known.
+
+
+ Identify any applicable function components from the and families to address
+ the named policy families from and
+ . Perform the operations to make the
+ components define the rules to be enforced by the named
+ policies. This should make the components fit the
+ requirements of the selected function envisioned or to be
+ built.
+
+
+ Identify who will have the ability to control and change
+ security attributes under the function, such as only a
+ security administrator, only the owner of the object,
+ etc. Select the appropriate components from
+ and perform the operations. Refinements may be useful here
+ to identify missing features, such as that some or all
+ changes must be done via trusted path.
+
+
+ Identify any appropriate components from the for initial values for new objects and subjects.
+
+
+ Identify any applicable rollback components from the family.
+
+
+ Identify any applicable residual information protection
+ requirements from the family.
+
+
+ Identify any applicable import or export components, and how
+ security attributes should be handled during import and
+ export, from the and families.
+
+
+ Identify any applicable internal TOE communication
+ components from the family.
+
+
+ Identify any requirements for integrity protection of stored
+ information from the .
+
+
+ Identify any applicable inter-TSF communication components
+ from the or
+ families.
+
+
+
+
+
+
+
+ This family identifies the access control SFPs (by name) and
+ defines the scope of control of the policies that form the
+ identified access control portion of the SFRs related to the
+ SFP. This scope of control is characterised by three sets: the
+ subjects under control of the policy, the objects under control
+ of the policy, and the operations among controlled subjects and
+ controlled objects that are covered by the policy. The criteria
+ allows multiple policies to exist, each having a unique name.
+ This is accomplished by iterating components from this family
+ once for each named access control policy. The rules that
+ define the functionality of an access control SFP will be
+ defined by other families such as and . The names
+ of the access control SFPs identified here in are meant to be used throughout the remainder of
+ the functional components that have an operation that calls for
+ an assignment or selection of an ``access control SFP.''
+
+
+
+ This family is based upon the concept of arbitrary controls
+ on the interaction of subjects and objects. The scope and
+ purpose of the controls is based upon the attributes of the
+ accessor (subject), the attributes of the container being
+ accessed (object), the actions (operations) and any
+ associated access control rules.
+
+ The components in this family are capable of identifying the
+ access control SFPs (by name) to be enforced by the traditional
+ Discretionary Access Control (DAC) mechanisms. It further
+ defines the subjects, objects and operations that are covered by
+ identified access control SFPs. The rules that define the
+ functionality of an access control SFP will be defined by other
+ families, such as and . The names of the access control SFPs
+ defined in are meant to be used
+ throughout the remainder of the functional components that have
+ an operation that calls for an assignment or selection of an
+ ``access control SFP.''
+
+ The access control SFP covers a set of triplets: subject,
+ object, and operations. Therefore a subject can be covered
+ by multiple access control SFPs but only with respect to a
+ different operation or a different object. Of course the
+ same applies to objects and operations.
+
+ A critical aspect of an access control function that
+ enforces an access control SFP is the ability for users to
+ modify the attributes involved in access control
+ decisions. The family does not address
+ these aspects. Some of these requirements are left
+ undefined, but can be added as refinements, while others are
+ covered elsewhere in other families and classes such as
+ .
+
+ There are no audit requirements in as
+ this family specifies access control SFP requirements. Audit
+ requirements will be found in families specifying functions
+ to satisfy the access control SFPs identified in this
+ family.
+
+ This family provides a PP/ST author the capability to
+ specify several policies, for example, a fixed access
+ control SFP to be applied to one scope of control, and a
+ flexible access control SFP to be defined for a different
+ scope of control. To specify more than one access control
+ policy, the components from this family can be iterated
+ multiple times in a PP/ST to different subsets of operations
+ and objects. This will accommodate TOEs that contain
+ multiple policies, each addressing a particular set of
+ operations and objects. In other words, the PP/ST author
+ should specify the required information in the ACC component
+ for each of the access control SFPs that the TSF will
+ enforce. For example, a TOE incorporating three access
+ control SFPs, each covering only a subset of the objects,
+ subjects, and operations within the TOE, will contain one
+ component for each of the three
+ access control SFPs, necessitating a total of three components.
+
+
+
+
+
+
+
+
+ The terms object and subject refer to generic elements in
+ the TOE. For a policy to be implementable, the entities
+ must be clearly identified. For a PP, the objects and
+ operations might be expressed as types such as: named
+ objects, data repositories, observe accesses, etc. For a
+ specific TOE these generic terms (subject, object) must be
+ refined, e.g. files, registers, ports, daemons, open
+ calls, etc.
+
+ This component specifies that the policy cover some
+ well-defined set of operations on some subset of the
+ objects. It places no constraints on any operations
+ outside the set - including operations on objects for
+ which other operations are controlled.
+
+
+
+ , requires that each identified
+ access control SFP be in place for a subset of the
+ possible operations on a subset of the objects in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects, objects, and operations among subjects
+ and objects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ objects, and operations among subjects and objects
+ covered by the SFP.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations on
+ objects, that are included in the SFP, are covered by an
+ access control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ objects and subjects is covered by an access control SFP.
+
+
+
+ , requires that each identified
+ access control SFP cover all operations on subjects and
+ objects covered by that SFP. It further requires that all
+ objects and operations protected by the TSF are covered by at
+ least one identified access control SFP.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects and objects
+
+
+
+ the PP/ST author should specify the list of subjects
+ and objects covered by the SFP. All operations among
+ those subjects and objects will be covered by the SFP.
+
+
+ and all operations among subjects and objects covered by the
+ SFP.
+
+
+ The TSF shall ensure that all operations between any subject
+ controlled by the TSF and any object controlled by the TSF are covered by an
+ access control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in . specifies the scope of control of the
+ policy.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in which also specifies the scope of
+ control of the policy.
+
+ This family provides a PP/ST author the capability to
+ describe the rules for access control. This results in a
+ TOE where the access to objects will not change. An
+ example of such an object is ``Message of the Day'', which
+ is readable by all, and changeable only by the authorised
+ administrator. This family also provides the PP/ST author
+ with the ability to describe rules that provide for
+ exceptions to the general access control rules. Such
+ exceptions would either explicitly allow or deny
+ authorisation to access an object.
+
+ There are no explicit components to specify other possible
+ functions such as two-person control, sequence rules for
+ operations, or exclusion controls. However, these
+ mechanisms, as well as traditional DAC mechanisms, can be
+ represented with the existing components, by careful
+ drafting of the access control rules.
+
+ A variety of acceptable access control functionality may be
+ specified in this family such as:
+
+
+ Access control lists (ACLs)
+
+
+ Time-based access control specifications
+
+
+ Origin-based access control specifications
+
+
+ Owner-controlled access control attributes
+
+
+
+
+
+
+
+
+
+
+ This component provides requirements for a mechanism that
+ mediates access control based on security attributes
+ associated with subjects and objects. Each object and
+ subject has a set of associated attributes, such as
+ location, time of creation, access rights (e.g., Access
+ Control Lists (ACLs)). This component allows the PP/ST
+ author to specify the attributes that will be used for the
+ access control mediation. This component allows access
+ control rules, using these attributes, to be
+ specified.
+
+ Examples of the attributes that a PP/ST author might
+ assign are presented in the following paragraphs.
+
+ An identity attribute may be associated with users,
+ subjects, or objects to be used for mediation. Examples of
+ such attributes might be the name of the program image
+ used in the creation of the subject, or a security
+ attribute assigned to the program image.
+
+ A time attribute can be used to specify that access will
+ be authorised during certain times of the day, during
+ certain days of the week, or during a certain calendar
+ year.
+
+ A location attribute could specify whether the location is
+ the location of the request for the operation, the
+ location where the operation will be carried out, or
+ both. It could be based upon internal tables to translate
+ the logical interfaces of the TSF into locations such as
+ through terminal locations, CPU locations, etc.
+
+ A grouping attribute allows a single group of users to be
+ associated with an operation for the purposes of access
+ control. If required, the refinement operation should be
+ used to specify the maximum number of definable groups,
+ the maximum membership of a group, and the maximum number
+ of groups to which a user can concurrently be
+ associated.
+
+ This component also provides requirements for the access
+ control security functions to be able to explicitly
+ authorise or deny access to an object based upon security
+ attributes. This could be used to provide privilege,
+ access rights, or access authorisations within the
+ TOE. Such privileges, rights, or authorisations could
+ apply to users, subjects (representing users or
+ applications), and objects.
+
+
+
+ This family addresses security attribute usage and
+ characteristics of policies. The component within this
+ family is meant to be used to describe the rules for the
+ function that implements the SFP as identified in . The PP/ST author may also
+ iterate this component to address multiple policies in the
+ TOE.
+
+ Security attribute
+ based access control allows the TSF to enforce access
+ based upon security attributes and named groups of
+ attributes. Furthermore, the TSF may have the ability to
+ explicitly authorise or deny access to an object based
+ upon security attributes.
+
+
+ Managing the attributes used to make explicit access or
+ denial based decisions.
+
+
+ Successful requests to perform an operation on an object
+ covered by the SFP.
+
+
+ All requests to perform an operation on an object covered by
+ the SFP.
+
+
+ The specific security attributes used in making an access
+ check.
+
+
+ The TSF shall enforce the
+
+ access control SFP
+
+ the PP/ST author should specify an access control SFP
+ name that the TSF is to enforce. The name of the access
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+ to objects based on the following:
+
+ list of subjects and objects controlled under the
+ indicated SFP, and for each, the SFP-relevant security
+ attributes, or named groups of SFP-relevant security
+ attributes
+
+ the PP/ST author should specify, for each controlled
+ subject and object, the security attributes and/or named
+ groups of security attributes that the function will use
+ in the specification of the rules. For example, such
+ attributes may be things such as the user identity,
+ subject identity, role, time of day, location, ACLs, or
+ any other attribute specified by the PP/ST author. Named
+ groups of security attributes can be specified to
+ provide a convenient means to refer to multiple security
+ attributes. Named groups could provide a useful way to
+ associate ``roles'' defined in , and
+ all of their relevant attributes, with subjects. In
+ other words, each role could relate to a named group of
+ attributes..
+
+
+ The TSF shall enforce the following rules to determine if an
+ operation among controlled subjects and controlled objects
+ is allowed:
+
+
+ rules governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects
+
+
+
+ the PP/ST author should specify the SFP rules
+ governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects. These rules specify when access
+ is granted or denied. It can specify general access
+ control functions (e.g. typical permission bits) or
+ granular access control functions (e.g. ACLs).
+
+ .
+
+
+ The TSF shall explicitly authorise access of subjects to
+ objects based on the following additional rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise access of subjects to objects
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise access
+ of subjects to objects that will be used to explicitly
+ authorise access. These rules are in addition to those
+ specified in . They are
+ included in as they are
+ intended to contain exceptions to the rules in . An example of rules to explicitly
+ authorise access is based on a privilege vector
+ associated with a subject that always grants access to
+ objects covered by the access control SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny access of subjects to objects based on the
+ following additional rules:
+ rules, based on security attributes, that
+ explicitly deny access of subjects to objects the PP/ST author should specify the rules,
+ based on security attributes, that explicitly deny access of subjects
+ to objects. These rules are in addition to those specified in
+
+ . They are included in
+
+ as they are intended to contain exceptions to the rules in
+
+ . An example of rules to explicitly deny access is based on a privilege
+ vector associated with a subject
+ that always denies access to objects covered by the access control SFP
+ that has been specified. If such a capability is not desired, then the
+ PP/ST author should specify ``none''..
+
+
+
+
+
+
+
+ Data authentication permits an entity to accept
+ responsibility for the authenticity of information (e.g., by
+ digitally signing it). This family provides a method of
+ providing a guarantee of the validity of a specific unit of
+ data that can be subsequently used to verify that the
+ information content has not been forged or fraudulently
+ modified. In contrast to , this family is
+ intended to be applied to "static" data rather
+ than data that is being transferred.
+
+
+
+ This family describes specific functions that can be used to
+ authenticate ``static'' data.
+
+ Components in this family are to be used when there is a
+ requirement for ``static'' data
+ authentication, i.e. where data is to be signed but not
+ transmitted. (Note that the family
+ provides for non-repudiation of origin of information
+ received during a data exchange.)
+
+
+
+
+
+ This component may be satisfied by one-way hash functions
+ (cryptographic checksum, fingerprint, message digest), to
+ generate a hash value for a definitive document that may
+ be used as verification of the validity or authenticity of
+ its information content.
+
+
+
+ , requires that the TSF is capable
+ of generating a guarantee of authenticity of the
+ information content of objects (e.g. documents).
+
+
+ The assignment or modification of the objects for which data
+ authentication may apply could be configurable.
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element. The list of subjects could be
+ very specific, if the subjects are known, or it could
+ be more generic and refer to a
+ ``type'' of subject such
+ as an identified role.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information.
+
+
+
+
+
+
+
+
+
+
+ This component additionally requires the ability to verify
+ the identity of the user that provided the guarantee of
+ authenticity (e.g. a trusted third party).
+
+
+
+ additionally requires that the TSF
+ is capable of establishing the identity of the subject who
+ provided the guarantee of authenticity.
+
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The identity of the subject that generated the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element as well as the identity of the
+ user that created the data authentication evidence.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information and the identity of the user that
+ generated the evidence.
+
+
+
+
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes and protection
+ either can be explicitly preserved or can be ignored once it
+ has been exported. It is concerned with limitations on
+ export and with the association of security attributes with
+ the exported user data.
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes either can be
+ explicitly preserved or can be ignored once it has been
+ exported. Consistency of these security attributes are
+ addressed by .
+
+ is concerned with limitations on export
+ and association of security attributes with the exported
+ user data.
+
+ This family, and the corresponding Import family , address how the TOE deals with user data
+ transferred into and outside its control. In principle this
+ family is concerned with the TSF-mediated exporting of user data and its
+ related security attributes.
+
+ A variety of activities might be involved here:
+
+
+ exporting of user data without any security attributes;
+
+
+ exporting user data including security attributes where
+ the two are associated with one another and the security
+ attributes unambiguously represent the exported user
+ data.
+
+
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the TSF-mediated exporting of user data
+ without the export of its security attributes.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs when exporting user data outside the
+ TSF. User data that is exported by this function is
+ exported without its associated security attributes.
+
+
+ Successful export of information.
+
+
+ All attempts to export information.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data without the user
+ data's associated security attributes
+
+
+
+
+
+
+
+
+
+
+
+
+ The user data is exported together with its security
+ attributes. The security attributes are unambiguously
+ associated with the user data. There are several ways of
+ achieving this association. One way that this can be
+ achieved is by physically collocating the user data and
+ the security attributes (e.g. the same floppy), or by
+ using cryptographic techniques such as secure signatures
+ to associate the attributes and the user data. could be used to assure that the attributes
+ are correctly received at the other trusted IT product
+ while can be used to make sure that
+ those attributes are properly interpreted. Furthermore,
+ could be used to make sure that the
+ export is being initiated by the proper user.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs using a function that accurately and
+ unambiguously associates security attributes with the user
+ data that is exported.
+
+
+ The additional exportation control rules could be
+ configurable by a user in a defined role.
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data with the user
+ data's associated security attributes.
+
+
+ The TSF shall ensure that the security attributes, when
+ exported outside the TOE, are unambiguously associated with
+ the exported user data.
+
+
+ The TSF shall enforce the following rules when user data is
+ exported from the TOE:
+
+
+ additional exportation control rules
+
+
+
+ the PP/ST author should specify any additional
+ exportation control rules or
+ ``none'' if there are no
+ additional exportation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family identifies the information flow control SFPs (by
+ name) and defines the scope of control for each named
+ information flow control SFP. This scope of control is
+ characterised by three sets: the subjects under control of the
+ policy, the information under control of the policy, and
+ operations which cause controlled information to flow to and
+ from controlled subjects covered by the policy. The criteria
+ allows multiple policies to exist, each having a unique name.
+ This is accomplished by iterating components from this family
+ once for each named information flow control policy. The rules
+ that define the functionality of an information flow control SFP
+ will be defined by other families such as and . The names
+ of the information flow control SFPs identified here in are meant to be used throughout the
+ remainder of the functional components that have an operation
+ that calls for an assignment or selection of an ``information
+ flow control SFP.''
+
+ The TSF mechanism controls the flow of information in
+ accordance with the information flow control SFP. Operations
+ that would change the security attributes of information are
+ not generally permitted as this would be in violation of an
+ information flow control SFP. However, such operations may
+ be permitted as exceptions to the information flow control
+ SFP if explicitly specified.
+
+
+
+ This family covers the identification of information flow
+ control SFPs; and, for each, specifies the scope of control
+ of the SFP.
+
+ The components in this family are capable of identifying the
+ information flow control SFPs to be enforced by the traditional
+ Mandatory Access Control mechanisms that would be found in a
+ TOE. However, they go beyond just the traditional MAC mechanisms
+ and can be used to identify and describe non-interference
+ policies and state-transitions. It further defines the subjects
+ under control of the policy, the information under control of
+ the policy, and operations which cause controlled information to
+ flow to and from controlled subjects for each information flow
+ control SFP in the TOE. The information flow control SFP will be
+ defined by other families such as and . The
+ information flow control SFPs named here in are meant to be used throughout the remainder of
+ the functional components that have an operation that calls for
+ an assignment or selection of an ``information flow control
+ SFP.''
+
+ These components are quite flexible. They allow the domain
+ of flow control to be specified and there is no requirement
+ that the mechanism be based upon labels. The different
+ elements of the information flow control components also
+ permit different degrees of exception to the policy.
+
+ Each SFP covers a set of triplets: subject, information, and
+ operations that cause information to flow to and from
+ subjects. Some information flow control policies may be at a
+ very low level of detail and explicitly describe subjects in
+ terms of processes within an operating system. Other
+ information flow control policies may be at a high level and
+ describe subjects in the generic sense of users or
+ input/output channels. If the information flow control
+ policy is at too high a level of detail, it may not clearly
+ define the desired IT security functions. In such cases, it
+ is more appropriate to include such descriptions of
+ information flow control policies as objectives. Then the
+ desired IT security functions can be specified as supportive
+ of those objectives.
+
+ In the second component (), each
+ information flow control SFP will cover all possible
+ operations that cause information covered by that SFP to
+ flow to and from subjects covered by that SFP. Furthermore,
+ all information flows will need to be covered by a
+ SFP. Therefore for each action that causes information to
+ flow, there will be a set of rules that define whether the
+ action is allowed. If there are multiple SFPs that are
+ applicable for a given information flow, all involved SFPs
+ must allow this flow before it is permitted to take place.
+
+ An information flow control SFP covers a well-defined set of
+ operations. The SFPs coverage may be
+ ``complete'' with respect to some
+ information flows, or it may address only some of the
+ operations that affect the information flow.
+
+ An access control SFP controls access to the objects that
+ contain information. An information flow control SFP
+ controls access to the information, independent of its
+ container. The attributes of the information, which may be
+ associated with the attributes of the container (or may not,
+ as in the case of a multi-level database) stay with the
+ information as it flows. The accessor does not have the
+ ability, in the absence of an explicit authorisation, to
+ change the attributes of the information.
+
+ Information flows and operations can be expressed at
+ multiple levels. In the case of a ST, the information flows
+ and operations might be specified at a system-specific
+ level: TCP/IP packets flowing through a firewall based upon
+ known IP addresses. For a PP, the information flows and
+ operations might be expressed as types: email, data
+ repositories, observe accesses, etc.
+
+ The components in this family can be applied multiple times
+ in a PP/ST to different subsets of operations and
+ objects. This will accommodate TOEs that contain multiple
+ policies, each addressing a particular set of objects,
+ subjects, and operations.
+
+
+
+
+
+
+
+
+ This component requires that an information flow control
+ policy apply to a subset of the possible operations in the
+ TOE.
+
+
+
+ , requires that each identified
+ information flow control SFPs be in place for a subset of
+ the possible operations on a subset of information flows
+ in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects, information, and operations that cause
+ controlled information to flow to and from controlled
+ subjects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ information, and operations which cause controlled
+ information to flow to and from controlled subjects
+ covered by the SFP. As mentioned above, the list of
+ subjects could be at various levels of detail
+ depending on the needs of the PP/ST author. It could
+ specify users, machines, or processes for
+ example. Information could refer to data such as email
+ or network protocols, or more specific objects similar
+ to those specified under an access control policy. If
+ the information that is specified is contained within
+ an object that is subject to an access control policy,
+ then both the access control policy and information
+ flow control policy must be enforced before the
+ specified information could flow to or from the
+ object.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations that
+ cause information to flow to and from subjects included in
+ the SFP, are covered by an information flow control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ information flows and subjects is covered by an
+ information flow control SFP.
+
+
+
+ , requires that each identified
+ information flow control SFP cover all operations on
+ subjects and information covered by that SFP. It further
+ requires that all information flows and operations controlled
+ by the TSF are covered by at least one identified information
+ flow control SFP.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects and information
+
+
+
+ the PP/ST author should specify the list of subjects
+ and information that will be covered by the SFP. All
+ operations that cause that information to flow to and
+ from subjects will be covered by the SFP. As mentioned
+ above, the list of subjects could be at various levels
+ of detail depending on the needs of the PP/ST
+ author. It could specify users, machines, or processes
+ for example. Information could refer to data such as
+ email or network protocols, or more specific objects
+ similar to those specified under an access control
+ policy. If the information that is specified is
+ contained within an object that is subject to an
+ access control policy, then both the access control
+ policy and information flow control policy must be
+ enforced before the specified information could flow
+ to or from the object.
+
+
+ and all operations that cause that information to flow to
+ and from subjects covered by the SFP.
+
+
+ The TSF shall ensure that all operations that cause any
+ information in the TOE to flow to and from any subject in
+ the TOE are covered by an information flow control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policy. It consists of two kinds of
+ requirements: one addressing the common information flow
+ function issues, and a second addressing illicit information
+ flows (i.e. covert channels). This division arises because
+ the issues concerning illicit information flows are, in some
+ sense, orthogonal to the rest of an information flow control
+ SFP. By their nature they circumvent the information flow
+ control SFP resulting in a violation of the policy. As such,
+ they require special functions to either limit or prevent
+ their occurrence.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policies. It consists of two
+ ``trees:'' one addressing the common
+ information flow control function issues, and a second
+ addressing illicit information flows (i.e. covert channels)
+ with respect to one or more information flow control
+ SFPs. This division arises because the issues concerning
+ illicit information flows are, in some sense, orthogonal to
+ the rest of an SFP. Illicit information flows are flows in
+ violation of policy; thus they are not a policy issue.
+
+ In order to implement strong protection against disclosure
+ or modification in the face of untrusted software, controls
+ on information flow are required. Access controls alone are
+ not sufficient because they only control access to
+ containers, allowing the information they contain to flow,
+ without controls, throughout a system.
+
+ In this family, the phrase ``types of illicit
+ information flows'' is used. This phrase may be
+ used to refer to the categorisation of flows as
+ ``Storage Channels'' or
+ ``Timing Channels'', or it can refer to
+ improved categorisations reflective of the needs of a PP/ST
+ author.
+
+ The flexibility of these components allows the definition of
+ a privilege policy within and to allow the controlled bypass of all or
+ part of a particular SFP. If there is a need for a
+ predefined approach to SFP bypass, the PP/ST author should
+ consider incorporating a privilege policy.
+
+
+
+
+
+
+
+
+
+ This component requires security attributes on
+ information, and on subjects that cause that information
+ to flow and subjects that act as recipients of that
+ information. The attributes of the containers of the
+ information should also be considered if it is desired
+ that they should play a part in information flow control
+ decisions or if they are covered by an access control
+ policy. This component specifies the key rules that are
+ enforced, and describes how security attributes are
+ derived.
+
+ This component does not specify the details of how a
+ security attribute is assigned (i.e. user versus
+ process). Flexibility in policy is provided by having
+ assignments that allow specification of additional policy
+ and function requirements, as necessary.
+
+ This component also provides requirements for the
+ information flow control functions to be able to
+ explicitly authorise and deny an information flow based
+ upon security attributes. This could be used to implement
+ a privilege policy that covers exceptions to the basic
+ policy defined in this component.
+
+
+
+ , requires security attributes on
+ information, and on subjects that cause that information
+ to flow and on subjects that act as recipients of that
+ information. It specifies the rules that must be enforced
+ by the function, and describes how security attributes are
+ derived by the function.
+
+
+ Managing the attributes used to make explicit access based
+ decisions.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+ the PP/ST author should specify any additional information
+ flow control SFP rules that the TSF is to enforce. This
+ includes all rules of the SFP that are either not based on the
+ security attributes of the information and the subject or
+ rules that automatically modify the security attributes of
+ information or subjects as a result of an access operation.
+ An example for the first case is a rule of the SFP controlling
+ a threshold value for specific types of information. This
+ would for example be the case when the information flow SFP
+ contains rules on access to statistical data where a subject
+ is only allowed to access this type of information up to a
+ specific number of accesses. An example for the second case
+ would be a rule stating under which conditions and how the
+ security attributes of a subject or object change as the
+ result of an access operation. Some information flow policies
+ for example may limit the number of access operations to
+ information with specific security attributes. If there are
+ no additional rules then the PP/ST author should specify
+ ``none''.
+ .
+
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on security
+ attributes, that explicitly deny information flows. These rules
+ are in addition to those specified in the preceding
+ elements. They are included in as they
+ are intended to contain exceptions to the rules in the preceding
+ elements. An example of rules to explicitly deny information
+ flows is based on a privilege vector associated with a subject
+ that always denies the subject the ability to cause an
+ information flow for information that is covered by the SFP that
+ has been specified. If such a capability is not desired, then
+ the PP/ST author should specify ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that the named information flow control
+ SFP uses hierarchical security attributes that
+ form a lattice.
+
+ It is important to note that the hierarchical relationship
+ requirements identified in need
+ only apply to the information flow control security
+ attributes for the information flow control SFPs that have
+ been identified in . This
+ component is not meant to apply to other SFPs such as
+ access control SFPs.
+ phrases the requirements for the set of
+ security attributes to form a lattice. A number of information
+ flow policies defined in the literature and implemented in IT
+ products are based on a set of security attributes that form a
+ lattice. is specifically included to
+ address this type of information flow policies.
+
+ If it is the case that multiple information flow control
+ SFPs are to be specified, and that each of these SFPs will
+ have their own security attributes that are not related to
+ one another, then the PP/ST author should iterate this
+ component once for each of those SFPs. Otherwise a
+ conflict might arise with the sub-items of since the required relationships will
+ not exist.
+
+
+ expands on the requirements
+ of by requiring that all
+ information flow control SFPs in the set of SFRs use
+ hierarchical security attributes that form a lattice (as defined
+ in mathematics). is derived from the
+ mathematical properties of a lattice. A lattice consists of a
+ set of elements with an ordering relationship with the property
+ defined in the first bullet, a least upper bound which is the
+ unique element in the set that is greater or equal (in the
+ ordering relationship) than any other element of the lattice,
+ and a greatest lower bound, which is the unique element in the set
+ that is smaller or equal than any other element of the lattice.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules, based on the
+ ordering relationships between security attributes hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce. These
+ relationships should be based upon the ordering
+ relationships between the security attributes.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+ the PP/ST author should specify any additional information
+ flow control SFP rules that the TSF is to enforce. This
+ includes all rules of the SFP that are either not based on the
+ security attributes of the information and the subject or
+ rules that automatically modify the security attributes of
+ information or subjects as a result of an access operation.
+ An example for the first case is a rule of the SFP controlling
+ a threshold value for specific types of information. This
+ would for example be the case when the information flow SFP
+ contains rules on access to statistical data where a subject
+ is only allowed to access this type of information up to a
+ specific number of accesses. An example for the second case
+ would be a rule stating under which conditions and how the
+ security attributes of a subject or object change as the
+ result of an access operation. Some information flow policies
+ for example may limit the number of access operations to
+ information with specific security attributes. If there are
+ no additional rules then the PP/ST author should specify
+ ``none''.
+ .
+
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on security
+ attributes, that explicitly deny information flows. These rules
+ are in addition to those specified in the preceding
+ elements. They are included in as they are intended to contain exceptions to the
+ rules in the preceding elements. An example of rules to
+ explicitly deny information flows is based on a privilege vector
+ associated with a subject that always denies the subject the
+ ability to cause an information flow for information that is
+ covered by the SFP that has been specified. If such a capability
+ is not desired, then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall enforce the following relationships for any
+ two valid information flow control security attributes:
+
+
+ There exists an ordering function that, given two valid
+ security attributes, determines if the security
+ attributes are equal, if one security attribute is
+ greater than the other, or if the security attributes
+ are incomparable; and
+
+
+ There exists a ``least upper bound''
+ in the set of security attributes, such that, given any
+ two valid security attributes, there is a valid security
+ attribute that is greater than or equal to the two valid
+ security attributes; and
+
+
+ There exists a ``greatest lower
+ bound'' in the set of security attributes,
+ such that, given any two valid security attributes,
+ there is a valid security attribute that is not greater
+ than the two valid security attributes.
+
+
+
+
+
+
+
+
+
+
+
+ This component should be used when at least one of the
+ SFPs that requires control of illicit information flows
+ does not require elimination of flows.
+
+ For the specified illicit information flows, certain
+ maximum capacities should be provided. In addition a PP/ST
+ author has the ability to specify whether the illicit
+ information flows must be audited.
+
+
+
+ , requires the SFP to cover illicit
+ information flows, but not necessarily eliminate them.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The use of identified illicit information flow channels.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The use of identified illicit information flow channels with
+ estimated maximum capacity exceeding a specified value.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when all the SFPs that
+ requires control of illicit information flows require
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+ , requires the SFP to cover the
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows which are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+ The TSF shall prevent
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows to be eliminated. This list may not
+ be empty as this component requires that some illicit
+ information flows are to be eliminated.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when the SFPs that require
+ control of illicit information flows require elimination
+ of all illicit information flows. However, the PP/ST
+ author should carefully consider the potential impact that
+ eliminating all illicit information flows might have on
+ the normal functional operation of the TOE. Many practical
+ applications have shown that there is an indirect
+ relationship between illicit information flows and normal
+ functionality within a TOE and eliminating all illicit
+ information flows may result in less than desired
+ functionality.
+
+
+
+ , requires SFP to cover the
+ elimination of all illicit information flows.
+
+
+
+
+
+ The TSF shall ensure that no illicit information flows exist
+ to circumvent
+
+
+ name of information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFP for which illicit information flows are to
+ be eliminated. The name of the information flow
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+
+ .
+
+
+
+
+
+
+
+
+
+ This component should be used when it is desired that the
+ TSF provide the ability to monitor the use of illicit
+ information flows that exceed a specified capacity. If it
+ is desired that such flows be audited, then this component
+ could serve as the source of audit events to be used by
+ components from the family.
+
+
+
+ , requires the SFP to monitor
+ illicit information flows for specified and maximum
+ capacities.
+
+
+ The enabling or disabling of the monitoring function.
+
+
+ Modification of the maximum capacity at which the monitoring
+ occurs.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to monitor
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that will be monitored for exceeding
+ a maximum capacity.
+
+
+ when it exceeds the
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ above which illicit information flows will be
+ monitored by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family defines the mechanisms for TSF-mediated importing of user
+ data into the TOE such that it has appropriate security
+ attributes and is appropriately protected. It is concerned
+ with limitations on importation, determination of desired
+ security attributes, and interpretation of security
+ attributes associated with the user data.
+
+
+
+ This family defines mechanisms for TSF-mediated importing of user data from
+ outside the TOE into the TOE such that the user data
+ security attributes can be preserved. Consistency of these
+ security attributes are addressed by .
+
+ is concerned with limitations on
+ import, user specification of security attributes, and
+ association of security attributes with the user data.
+
+ This family, and the corresponding export family , address how the TOE deals with user data
+ outside its control. This family is concerned with assigning
+ and abstraction of the user data security attributes.
+
+ A variety of activities might be involved here:
+
+
+ importing user data from an unformatted medium
+ (e.g. floppy disk, tape, scanner, video or audit
+ signal), without including any security attributes, and
+ physically marking the medium to indicate its contents;
+
+
+ importing user data, including security attributes, from
+ a medium and verifying that the object security
+ attributes are appropriate;
+
+
+ importing user data, including security attributes, from
+ a medium using a cryptographic sealing technique to
+ protect the association of user data and security
+ attributes.
+
+
+
+ This family is not concerned with the determination of
+ whether the user data may be imported. It is concerned with
+ the values of the security attributes to associate with the
+ imported user data.
+
+ There are two possibilities for the import of user data:
+ either the user data is unambiguously associated with
+ reliable object security attributes (values and meaning of
+ the security attributes is not modified), or no reliable
+ security attributes (or no security attributes at all) are
+ available from the import source. This family addresses both
+ cases.
+
+ If there are reliable security attributes available, they
+ may have been associated with the user data by physical
+ means (the security attributes are on the same media), or by
+ logical means (the security attributes are distributed
+ differently, but include unique object identification,
+ e.g. cryptographic checksum).
+
+ This family is concerned with TSF-mediated importing of user data and
+ maintaining the association of security attributes as
+ required by the SFP. Other families are concerned with other
+ import aspects such as consistency, trusted channels, and
+ integrity that are beyond the scope of this
+ family. Furthermore, is only concerned
+ with the interface to the import medium. is responsible for the other end point of the
+ medium (the source).
+
+ Some of the well known import requirements are:
+
+
+ importing of user data without any security attributes;
+
+
+ importing of user data including security attributes
+ where the two are associated with one another and the
+ security attributes unambiguously represent the
+ information being imported.
+
+
+
+ These import requirements may be handled by the TSF with or
+ without human intervention, depending on the IT limitations
+ and the organisational security policy. For example, if user
+ data is received on a ``confidential''
+ channel, the security attributes of the objects will be set
+ to ``confidential''.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that does not have reliable (or any) security attributes
+ associated with it. This function requires that the
+ security attributes for the imported user data be
+ initialised within the TSF. It could also be the case that
+ the PP/ST author specifies the rules for import. It may be
+ appropriate, in some environments, to require that these
+ attributes be supplied via a trusted path or a trusted
+ channel mechanism.
+
+
+
+ , requires that the security
+ attributes correctly represent the user data and are
+ supplied separately from the object.
+
+
+ The modification of the additional control rules used for
+ import.
+
+
+ Successful import of user data, including any security
+ attributes.
+
+
+ All attempts to import user data, including any security
+ attributes.
+
+
+ The specification of security attributes for imported user
+ data supplied by an authorised user.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s) and/or information flow control SFP(s)
+
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be
+ enforced when importing user data from outside of the
+ TOE. The user data that this function imports is
+ scoped by the assignment of these SFPs.
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall ignore any security attributes associated with
+ the user data when imported from outside the TOE.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that has reliable security attributes associated with
+ it. This function relies upon the security attributes that
+ are accurately and unambiguously associated with the
+ objects on the import medium. Once imported, those objects
+ will have those same attributes. This requires to ensure the consistency of the data. It
+ could also be the case that the PP/ST author specifies the
+ rules for import.
+
+
+
+ , requires that security attributes
+ correctly represent the user data and are accurately and
+ unambiguously associated with the user data imported from
+ outside the TOE.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when importing user data from outside
+ of the TOE. The user data that this function imports
+ is scoped by the assignment of these SFPs.
+
+
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall use the security attributes associated with
+ the imported user data.
+
+
+ The TSF shall ensure that the protocol used provides for the
+ unambiguous association between the security attributes and
+ the user data received.
+
+
+ The TSF shall ensure that interpretation of the security
+ attributes of the imported user data is as intended by the
+ source of the user data.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between separated parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and families,
+ which provide protection for user data when it is
+ transferred between distinct TSFs across an external
+ channel, and and ,
+ which address TSF-mediated transfer of data to or from outside the
+ TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and family, which
+ provide protection for user data when it is transferred
+ between distinct TSFs across an external channel, and and , which address
+ TSF-mediated transfer of data to or from outside the TOE.
+
+ The requirements in this family allow a PP/ST author to
+ specify the desired security for user data while in transit
+ within the TOE. This security could be protection against
+ disclosure, modification, or loss of availability.
+
+ The determination of the degree of physical separation above
+ which this family should apply depends on the intended
+ environment of use. In a hostile environment, there may be
+ risks arising from transfers between parts of the TOE
+ separated by only a system bus. In more benign environments,
+ the transfers may be across more traditional network media.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ , requires that user data be
+ protected when transmitted between parts of the TOE.
+
+
+ If the TSF provides multiple methods to protect user data
+ during transmission between physically separated parts of
+ the TOE, the TSF could provide a pre-defined role with the
+ ability to select the method that will be used.
+
+
+ Successful transfers of user data, including identification
+ of the protection method used.
+
+
+ All attempts to transfer user data, including the protection
+ method used and any errors that occurred.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component could, for example, be used to provide
+ different forms of protection to information with
+ different clearance levels.
+
+ One of the ways to achieve separation of data when it is
+ transmitted is through the use of separate logical or
+ physical channels.
+
+
+
+ , requires separation of data based
+ on the value of SFP-relevant attributes in addition to the
+ first component.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+ The TSF shall separate data controlled by the SFP(s) when
+ transmitted between physically-separated parts of the TOE,
+ based on the values of the following:
+
+
+ security attributes that require separation
+
+
+
+ the PP/ST author should specify the security
+ attributes, the values of which the TSF will use to
+ determine when to separate data that is being
+ transmitted between physically-separated parts of the
+ TOE. An example is that user data associated with the
+ identity of one owner is transmitted separately from
+ the user data associated with the identify of a
+ different owner. In this case, the value of the
+ identity of the owner of the data is what is used to
+ determine when to separate the data for transmission.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with either or . It ensures
+ that the TSF checks received user data (and their
+ attributes) for integrity. or will provide the data in a manner such
+ that it is protected from modification (so that can detect any modifications).
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ , requires that the TSF monitor user
+ data transmitted between parts of the TOE for identified
+ integrity errors.
+
+
+ The specification of the actions to be taken upon detection
+ of an integrity error could be configurable.
+
+
+ Successful transfers of user data, including identification
+ of the integrity protection method used.
+
+
+ All attempts to transfer user data, including the integrity
+ protection method used and any errors that occurred.
+
+
+ Unauthorised attempts to change the integrity protection
+ method.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with . It ensures that the TSF checks received
+ user data, that has been transmitted by separate channels
+ (based on values of specified security attributes), for
+ integrity. It allows the PP/ST author to specify actions
+ to be taken upon detection of an integrity error.
+
+ For example, this component could be used to provide
+ different integrity error detection and action for
+ information at different integrity levels.
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author should specify the attributes (and
+ associated transmission channels) that necessitate
+ integrity error monitoring
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ expands on the third component by
+ allowing the form of integrity monitoring to differ by
+ SFP-relevant attribute.
+
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow
+ control SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ , based on the following attributes:
+
+
+ security attributes that require separate transmission
+ channels
+
+
+
+ the PP/ST author should specify a list of security
+ attributes that require separate transmission
+ channels. This list is used to determine which user
+ data to monitor for integrity errors., based on its
+ security attributes and its transmission channel. This
+ element is directly related to .
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity
+ error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the need to ensure that any data contained
+ in a resource is not available when the resource is de-allocated
+ from one object and reallocated to a different object. This
+ family requires protection for any data contained in a resource
+ that has been logically deleted or released, but may still be
+ present within the TSF-controlled resource which in turn may be
+ re-allocated to another object.
+
+
+
+ Residual information protection ensures that TSF-controlled
+ resources when de-allocated from an object and before they are
+ reallocated to another object are treated by the TSF in a way
+ that it is not possible to reconstruct all or part of the data
+ contained in the resource before it was de-allocated.
+
+ A TOE usually has a number of functions that potentially
+ de-allocate resources from an object and potentially re-allocate
+ those resources to objects. Some, but not all of those resources
+ may have been used to store critical data from the previous use
+ of the resource and for those resources FDP_RIP requires that
+ they are prepared for reuse. Object reuse applies to explicit
+ requests of a subject or user to release resources as well as
+ implicit actions of the TSF that result in the de-allocation and
+ subsequent re-allocation of resources to different
+ objects. Examples of explicit requests are the deletion or
+ truncation of a file or the release of an area of main
+ memory. Examples of implicit actions of the TSF are the
+ de-allocation and re-allocation of cache regions.
+ The requirement for object reuse is related to the content of
+ the resource belonging to an object, not all information about
+ the resource or object that may be stored elsewhere in the
+ TSF. As an example to satisfy the FDP_RIP requirement for files
+ as objects requires that all sectors that make up the file need
+ to be prepared for re-use.
+
+ It also applies to resources that are serially reused by
+ different subjects within the system. For example, most
+ operating systems typically rely upon hardware registers
+ (resources) to support processes within the system. As
+ processes are swapped from a ``run'' state to a ``sleep''
+ state (and vice versa), these registers are serially reused
+ by different subjects. While this ``swapping'' action may
+ not be considered an allocation or deallocation of a
+ resource, could apply to
+ such events and resources.
+
+ typically controls access
+ to information that is not part of any currently defined or
+ accessible object; however, in certain cases this may not be
+ true. For example, object ``A'' is a file and object ``B''
+ is the disk upon which that file resides. If object ``A'' is
+ deleted, the information from object ``A'' is under the
+ control of even though it
+ is still part of object ``B''.
+
+ It is important to note that applies only to on-line objects and not
+ off-line objects such as those backed-up on tapes. For
+ example, if a file is deleted in the TOE, can be instantiated to require that no
+ residual information exists upon deallocation; however, the
+ TSF cannot extend this enforcement to that same file that
+ exists on the off-line back-up. Therefore that same file is
+ still available. If this is a concern, then the PP/ST author
+ should make sure that the proper environmental objectives
+ are in place to support operational user guidance to address
+ off-line objects.
+
+ and can conflict when is instantiated to require that residual
+ information be cleared at the time the application releases
+ the object to the TSF (i.e. upon deallocation). Therefore,
+ the selection of
+ ``deallocation'' should not be used with since there would be no information to roll
+ back. The other selection, ``unavailability upon
+ allocation'', may be used with , but there is the risk that the resource
+ which held the information has been allocated to a new
+ object before the roll back took place. If that were to
+ occur, then the roll back would not be possible.
+
+ There are no audit requirements in because this is not a user-invokable
+ function. Auditing of allocated or deallocated resources
+ would be auditable as part of the access control SFP or the
+ information flow control SFP operations.
+
+ This family should apply to the objects specified in the
+ access control SFP(s) or the information flow control SFP(s)
+ as specified by the PP/ST author.
+
+
+
+
+
+ This component requires that, for a subset of the objects
+ in the TOE, the TSF will ensure that there is no available
+ residual information contained in a resource allocated to
+ those objects or deallocated from those objects.
+
+
+
+ , requires that the TSF
+ ensure that any residual information content of any
+ resources is unavailable to a defined subset of the
+ objects controlled by the TSF upon the resource's
+ allocation or deallocation.
+
+
+ The choice of when to perform residual information
+ protection (i.e. upon allocation or deallocation) could be
+ made configurable within the TOE.
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ the following objects:
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ subject to residual information protection.
+
+ .
+
+
+
+
+
+
+
+ This component requires that for all objects in the TOE,
+ the TSF will ensure that there is no available residual
+ information contained in a resource allocated to those
+ objects or deallocated from those objects.
+
+
+
+ , requires that the TSF ensure that
+ any residual information content of any resources is
+ unavailable to all objects upon the resource's
+ allocation or deallocation.
+
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ all objects.
+
+
+
+
+
+
+
+ The rollback operation involves undoing the last operation
+ or a series of operations, bounded by some limit, such as a
+ period of time, and return to a previous known
+ state. Rollback provides the ability to undo the effects of
+ an operation or series of operations to preserve the
+ integrity of the user data.
+
+
+
+ This family addresses the need to return to a well defined
+ valid state, such as the need of a user to undo
+ modifications to a file or to undo transactions in case of
+ an incomplete series of transaction as in the case of
+ databases.
+
+ This family is intended to assist a user in returning to a
+ well defined valid state after the user undoes the last set
+ of actions, or, in distributed databases, the return of all
+ of the distributed copies of the databases to the state
+ before an operation failed.
+
+ and conflict when
+ enforces that the contents will be made
+ unavailable at the time that a resource is deallocated from
+ an object. Therefore, this use of
+ cannot be combined with as there would
+ be no information to roll back. can be
+ used only with when it enforces that
+ the contents will be unavailable at the time that a resource
+ is allocated to an object. This is because the mechanism will have an opportunity to access
+ the previous information that may still be present in the
+ TOE in order to successfully roll back the operation.
+
+ The rollback requirement is bounded by certain limits. For
+ example a text editor typically only allows you roll back up
+ to a certain number of commands. Another example would be
+ backups. If backup tapes are rotated, after a tape is
+ reused, the information can no longer be retrieved. This
+ also poses a bound on the rollback requirement.
+
+
+
+
+
+
+
+
+
+
+
+ This component allows a user or subject to undo a set of
+ operations on a predefined set of objects. The undo is
+ only possible within certain limits, for example up to a
+ number of characters or up to a time limit.
+
+
+
+ addresses a need to roll back or
+ undo a limited number of operations within the defined
+ bounds.
+
+
+ The boundary limit to which rollback may be performed could
+ be a configurable item within the TOE.
+
+
+ Permission to perform a rollback operation could be
+ restricted to a well defined role.
+
+
+ All successful rollback operations.
+
+
+ All attempts to perform rollback operations.
+
+
+ All attempts to perform rollback operations, including
+ identification of the types of operations rolled back.
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of the
+
+
+ list of operations
+
+
+
+ the PP/ST author should specify the list of operations
+ that can be rolled back.
+
+
+ on the
+
+ information and/or list of objects
+
+ the PP/ST author should specify the information and/or
+ list of objects that are subjected to the rollback policy..
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component enforces that the TSF provide the
+ capability to rollback all operations; however, the user
+ can choose to rollback only a part of them.
+
+
+
+ addresses the need to roll back or
+ undo all operations within the defined bounds.
+
+
+
+
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of all the operations on the
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ that are subjected to the rollback policy.
+
+ .
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF. Integrity
+ errors may affect user data stored in memory, or in a
+ storage device. This family differs from which protects the user data from integrity
+ errors while being transferred within the TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF.
+
+ Hardware glitches or errors may affect data stored in
+ memory. This family provides requirements to detect these
+ unintentional errors. The integrity of user data while
+ stored on storage devices controlled by the TSF are also addressed
+ by this family.
+
+ To prevent a subject from modifying the data, the or families are required
+ (rather than this family).
+
+ This family differs from that protects
+ the user data from integrity errors while being transferred
+ within the TOE.
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify different kinds of
+ user data attributes that will be used as the basis for
+ monitoring.
+
+
+
+ , requires that the TSF monitor user
+ data stored within containers controlled by the TSF for identified integrity
+ errors.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify which action should
+ be taken in case an integrity error is detected.
+
+
+
+ adds the additional capability to
+ the first component by allowing for actions to be taken as
+ a result of an error detection.
+
+
+ The actions to be taken upon the detection of an integrity
+ error could be configurable.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ action to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken in case an integrity error is detected.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT product.
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT
+ product. Confidentiality is enforced by preventing
+ unauthorised disclosure of user data in transit between the
+ two end points. The end points may be a TSF or a user.
+
+ This family provides a requirement for the protection of user
+ data during transit. In contrast, handles TSF data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Depending on the access control or information flow policies the TSF is
+ required to send or receive user data in a manner such that the
+ confidentiality of the user data is protected.
+
+
+
+ In , the goal is to provide
+ protection from disclosure of user data while in transit.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any unauthorised user or subject attempting
+ to use the data exchange mechanisms.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the information.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s) and/or information flow control SFP(s)
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be enforced when exchanging
+ user data. The specified policies will be enforced to make decisions about
+ who can exchange data and which data can be exchanged.
+ to
+ transmitreceivethe PP/ST author should specify whether this element
+ applies to a mechanism that transmits or receives user data.
+ user data in a manner protected from unauthorised disclosure.
+
+
+
+
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TOE and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TSF and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+ This family defines the requirements for providing integrity
+ for user data in transit; while handles
+ TSF data.
+
+ and are duals of
+ each other, as addresses user data
+ confidentiality. Therefore, the same mechanism that
+ implements could possibly be used to
+ implement other families such as and
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Depending on the access control or information flow policies the TSF is
+ required to send or receive user data in a manner such that modification
+ of the user data is detected. There is no requirement for a TSF mechanism
+ to attempt to recover from the modification.
+
+
+
+ addresses detection of
+ modifications, deletions, insertions, and replay errors of
+ the user data transmitted.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+ access control SFP(s) and/or information flow control SFP(s)
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be enforced on the transmitted
+ data or on the received data. The specified policies will be enforced to make
+ decisions about who can transmit or who can receive data, and which data can be
+ transmitted or received.
+ to
+ transmitreceivethe PP/ST author should specify whether this element applies
+ to a TSF that is transmitting or receiving objects.
+ user data in a manner protected from
+ modificationdeletioninsertionreplaythe PP/ST author should specify whether the data should be
+ protected from modification, deletion, insertion or replay.
+ errors.
+
+
+ The TSF shall be able to determine on receipt of user data,
+ whether
+
+
+ modification
+
+
+ deletion
+
+
+ insertion
+
+
+ replay
+
+
+
+ the PP/ST author should specify whether the errors of
+ the type: modification, deletion, insertion or replay
+ are detected.
+
+
+ has occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors, if required, with the
+ help of the other trusted IT product. As the other trusted
+ IT product is outside the TOE, the TSF cannot control its
+ behaviour. However, it can provide functions that have the
+ ability to cooperate with the other trusted IT product for
+ the purposes of recovery. For example, the TSF could
+ include functions that depend upon the source trusted IT
+ product to re-send the data in the event that an error is
+ detected. This component deals with the ability of the TSF
+ to handle such an error recovery.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF with help from the source
+ trusted IT product.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ Successful recovery from errors including they type of error
+ that was detected.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the TSF, with the help of the source
+ trusted IT product, is be able to recover the original
+ user data.
+
+
+ with the help of the source trusted IT product.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors. It accomplishes this
+ task without help from the source trusted IT product. For
+ example, if certain errors are detected, the transmission
+ protocol must be robust enough to allow the TSF to recover
+ from the error based on checksums and other information
+ available within that protocol.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF on its own without any help
+ from the source trusted IT product.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the receiving TSF, alone, is able to
+ recover the original user data.
+
+
+ without any help from the source trusted IT product.
+
+
+
+
+
+
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user identity.
+
+ Identification and Authentication is required to ensure that
+ users are associated with the proper security attributes
+ (e.g. identity, groups, roles, security or integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the intended
+ security policies. The families in this class deal with
+ determining and verifying the identity of users, determining
+ their authority to interact with the TOE, and with the correct
+ association of security attributes for each authorised
+ user. Other classes of requirements (e.g. User Data
+ Protection, Security Audit) are dependent upon correct
+ identification and authentication of users in order to be
+ effective.
+
+
+
+ A common security requirement is to unambiguously identify the
+ person and/or entity performing functions in a TOE. This
+ involves not only establishing the claimed identity of each
+ user, but also verifying that each user is indeed who he/she
+ claims to be. This is achieved by requiring users to provide
+ the TSF with some information that is known by the TSF to be
+ associated with the user in question.
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user
+ identity. Identification and Authentication is required to
+ ensure that users are associated with the proper security
+ attributes (e.g. identity, groups, roles, security or
+ integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the security
+ policies.
+
+ The family addresses determining the
+ identity of a user.
+
+ The family addresses verifying the
+ identity of a user.
+
+ The family addresses defining limits on
+ repeated unsuccessful authentication attempts.
+
+ The family address the definition of user
+ attributes that are used in the enforcement of the SFRs.
+
+ The family addresses the correct
+ association of security attributes for each authorised user.
+
+ The family addresses the generation and
+ verification of secrets that satisfy a defined metric.
+
+
+
+
+
+ This family contains requirements for defining values for
+ some number of unsuccessful authentication attempts and TSF
+ actions in cases of authentication attempt
+ failures. Parameters include, but are not limited to, the
+ number of failed authentication attempts and time
+ thresholds.
+
+
+
+ This family addresses requirements for defining values for
+ authentication attempts and TSF actions in cases of
+ authentication attempt failure. Parameters include, but are
+ not limited to, the number of attempts and time thresholds.
+
+ The session establishment process is the interaction with
+ the user to perform the session establishment independent of
+ the actual implementation. If the number of unsuccessful
+ authentication attempts exceeds the indicated threshold,
+ either the user account or the terminal (or both) will be
+ locked. If the user account is disabled, the user cannot
+ log-on to the system. If the terminal is disabled, the
+ terminal (or the address that the terminal has) cannot be
+ used for any log-on. Both of these situations continue until
+ the condition for re-establishment is satisfied.
+
+
+
+
+
+
+
+
+ The PP/ST author may define the number of unsuccessful
+ authentication attempts or may choose to let the TOE
+ developer or the authorised user to define this
+ number. The unsuccessful authentication attempts need not
+ be consecutive, but rather related to an authentication
+ event. Such an authentication event could be the count
+ from the last successful session establishment at a given
+ terminal.
+
+ The PP/ST author could specify a list of actions that the
+ TSF shall take in the case of authentication failure. An
+ authorised administrator could also be allowed to manage
+ the events, if deemed opportune by the PP/ST author. These
+ actions could be, among other things, terminal
+ deactivation, user account deactivation, or administrator
+ alarm. The conditions under which the situation will be
+ restored to normal must be specified on the action.
+
+ In order to prevent denial of service, TOEs usually ensure
+ that there is at least one user account that cannot be
+ disabled.
+
+ Further actions for the TSF can be stated by the PP/ST
+ author, including rules for re-enabling the user session
+ establishment process, or sending an alarm to the
+ administrator. Examples of these actions are: until a
+ specified time has lapsed, until the authorised
+ administrator re-enables the terminal/account, a time
+ related to failed previous attempts (every time the
+ attempt fails, the disabling time is doubled).
+
+
+
+ , requires that the TSF be able to
+ terminate the session establishment process after a
+ specified number of unsuccessful user authentication
+ attempts. It also requires that, after termination of the
+ session establishment process, the TSF be able to disable
+ the user account or the point of entry (e.g. workstation)
+ from which the attempts were made until an
+ administrator-defined condition occurs.
+
+
+ management of the threshold for unsuccessful authentication
+ attempts;
+
+
+ management of actions to be taken in the event of an
+ authentication failure.
+
+
+ the reaching of the threshold for the unsuccessful
+ authentication attempts and the actions (e.g. disabling of a
+ terminal) taken and the subsequent, if appropriate,
+ restoration to the normal state (e.g. re-enabling of a
+ terminal).
+
+
+ The TSF shall detect when
+
+ positive integer number
+
+ if the assignment of a positive integer is selected,
+ the PP/ST author should specify the default number
+ (positive integer) of unsuccessful authentication
+ attempts that, when met or surpassed, will trigger
+ the events.
+ an administrator configurable positive integer within
+
+ range of acceptable values
+
+ if an administrator configurable positive integer is
+ selected, the PP/ST author should specify the range of
+ acceptable values from which the administrator of the
+ TOE may configure the number of unsuccessful
+ authentication attempts. The number of authentication
+ attempts should be less than or equal to the upper
+ bound and greater or equal to the lower bound values.
+ the PP/ST author should select either the assignment of a positive integer,
+ or the phrase ``an administrator configurable positive integer'' specifying
+ the range of acceptable values.
+ unsuccessful authentication attempts occur related to
+
+
+ list of authentication events
+
+
+
+ the PP/ST author should specify the authentication
+ events. Examples of these authentication events are:
+ the unsuccessful authentication attempts since the
+ last successful authentication for the indicated user
+ identity, the unsuccessful authentication attempts
+ since the last successful authentication for the
+ current terminal, the number of unsuccessful
+ authentication attempts in the last 10 minutes. At
+ least one authentication event must be specified.
+
+ .
+
+
+ When the defined number of unsuccessful authentication
+ attempts has been
+ metsurpassed
+ the PP/ST author should select whether the event of
+ meeting or surpassing the defined number of unsuccessful
+ authentication attemps shall trigger an action by the
+ TSF., the TSF shall
+
+ list of actions
+
+ the PP/ST author should specify the actions to be taken in
+ case the threshold is met or surpassed, as selected. These
+ actions could be disabling of an account for 5 minutes,
+ disabling the terminal for an increasing amount of time (2
+ to the power of the number of unsuccessful attempts in
+ seconds), or disabling of the account until unlocked by
+ the administrator and simultaneously informing the
+ administrator. The actions should specify the measures and
+ if applicable the duration of the measure (or the
+ conditions under which the measure will be ended)..
+
+
+
+
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that is used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that are used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+ There are dependencies on the individual security policy (SFP)
+ definitions. These individual definitions should contain the
+ listing of attributes that are necessary for policy
+ enforcement.
+
+
+
+
+
+ This component specifies the security attributes that
+ should be maintained at the level of the user. This means
+ that the security attributes listed are assigned to and
+ can be changed at the level of the user. In other words,
+ changing a security attribute in this list associated with
+ a user should have no impact on the security attributes of
+ any other user.
+
+ In case security attributes belong to a group of users
+ (such as Capability List for a group), the user will need
+ to have a reference (as security attribute) to the
+ relevant group.
+
+
+
+ , allows user security attributes
+ for each user to be maintained individually.
+
+
+ if so indicated in the assignment, the authorised
+ administrator might be able to define additional security
+ attributes for users.
+
+
+ The TSF shall maintain the following list of security
+ attributes belonging to individual users:
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that are associated to an individual
+ user. An example of such a list is
+ {``clearance'', ``group
+ identifier'', ``rights''}.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets and generate
+ secrets to satisfy the defined metric.
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets, and generate
+ secrets to satisfy the defined metric. Examples of such
+ mechanisms may include automated checking of user supplied
+ passwords, or automated password generation.
+
+ A secret can be generated outside the TOE (e.g. selected by
+ the user and introduced in the TOE). In such cases, the
+ component can be used to
+ ensure that the external generated secret adheres to certain
+ standards, for example a minimum size, not present in a
+ dictionary, and/or not previously used.
+
+ Secrets can also be generated by the TOE. In those cases,
+ the component can be used
+ to require the TOE to ensure that the secrets that will
+ adhere to some specified metrics.
+
+ Secrets contain the authentication data provided by the user
+ for an authentication mechanism that is based on knowledge
+ the user possesses. When cryptographic keys are employed,
+ the class should be used instead of this
+ family.
+
+
+
+
+
+ Secrets can be generated by the user. This component
+ ensures that those user generated secrets can be verified
+ to meet a certain quality metric.
+
+
+
+ , requires the TSF to verify that
+ secrets meet defined quality metrics.
+
+
+ the management of the metric used to verify the secrets.
+
+
+ Rejection by the TSF of any tested secret;
+
+
+ Rejection or acceptance by the TSF of any tested secret;
+
+
+ Identification of any changes to the defined quality
+ metrics.
+
+
+ The TSF shall provide a mechanism to verify that secrets
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed, or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+
+
+
+
+ This component allows the TSF to generate secrets for
+ specific functions such as authentication by means of
+ passwords.
+
+ When a pseudo-random number generator is used in a secret
+ generation algorithm, it should accept as input random
+ data that would provide output that has a high degree of
+ unpredictability. This random data (seed) can be derived
+ from a number of available parameters such as a system
+ clock, system registers, date, time, etc. The parameters
+ should be selected to ensure that the number of unique
+ seeds that can be generated from these inputs should be at
+ least equal to the minimum number of secrets that must be
+ generated.
+
+
+
+ , requires the TSF to be able to
+ generate secrets that meet defined quality metrics.
+
+
+ the management of the metric used to generate the secrets.
+
+
+
+
+
+ The TSF shall provide a mechanism to generate secrets that
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+ The TSF shall be able to enforce the use of TSF generated
+ secrets for
+
+
+ list of TSF functions
+
+
+
+ the PP/ST author should provide a list of TSF
+ functions for which the TSF generated secrets must be
+ used. An example of such a function could include a
+ password based authentication mechanism.
+
+ .
+
+
+
+
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family also defines
+ the required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family defines the
+ required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+
+
+
+
+
+ This component requires that the PP/ST author define the
+ TSF-mediated actions that can be performed by the TSF on
+ behalf of the user before the claimed identity of the user
+ is authenticated. The TSF-mediated actions should have no
+ security concerns with users incorrectly identifying
+ themselves prior to being authenticated. For all other
+ TSF-mediated actions not in the list, the user must be
+ authenticated before the action can be performed by the
+ TSF on behalf of the user.
+
+ This component cannot control whether the actions can also
+ be performed before the identification took place. This
+ requires the use of either or
+ with the appropriate assignments.
+
+
+
+ , allows a user to perform certain
+ actions prior to the authentication of the
+ user's identity.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the associated
+ user;
+
+
+ managing the list of actions that can be taken before the
+ user is authenticated.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism;
+
+
+ All TSF mediated actions performed before authentication of
+ the user.
+
+
+ The TSF shall allow
+
+
+ list of TSF mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the claimed identity of the user is
+ authenticated. This list cannot be empty. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ authenticated.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+
+
+
+
+ This component requires that a user is authenticated before any other
+ TSF-mediated action can take place on behalf of that user.
+
+
+ , requires that users are
+ authenticated before any other action will be allowed by the TSF.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the user associated
+ with this data.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+ This component addresses requirements for mechanisms that
+ provide protection of authentication data. Authentication
+ data that is copied from another user, or is in some way
+ constructed should be detected and/or rejected. These
+ mechanisms provide confidence that users authenticated by
+ the TSF are actually who they claim to be.
+
+ This component may be useful only with authentication
+ mechanisms that are based on authentication data that
+ cannot be shared (e.g. biometrics). It is impossible for a
+ TSF to detect or prevent the sharing of passwords outside
+ the control of the TSF.
+
+
+
+ Unforgeable authentication,
+ requires the authentication mechanism to be able to detect
+ and prevent the use of authentication data that has been
+ forged or copied.
+
+
+ Detection of fraudulent authentication data;
+
+
+ All immediate measures taken and results of checks on the
+ fraudulent data.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent forging of
+ authentication data.
+
+
+ use of authentication data that has been forged by any user
+ of the TSF.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent copying of
+ authentication data.
+
+
+ use of authentication data that has been copied from any
+ other user of the TSF.
+
+
+
+
+
+
+ This component addresses requirements for authentication
+ mechanisms based on single-use authentication
+ data. Single-use authentication data can be something the
+ user has or knows, but not something the user is. Examples
+ of single-use authentication data include single-use
+ passwords, encrypted time-stamps, and/or random numbers
+ from a secret lookup table.
+
+ The PP/ST author can specify to which authentication
+ mechanism(s) this requirement applies.
+
+
+
+ , requires an authentication
+ mechanism that operates with single-use authentication
+ data.
+
+
+ Attempts to reuse authentication data.
+
+
+ The TSF shall prevent reuse of authentication data related
+ to
+
+
+ identified authentication mechanism(s)
+
+
+
+ the PP/ST author should specify the list of
+ authentication mechanisms to which this requirement
+ applies. This assignment can be ``all
+ authentication mechanisms''. An example of
+ this assignment could be ``the
+ authentication mechanism employed to authenticate
+ people on the external network''.
+
+ .
+
+
+
+
+
+
+ The use of this component allows specification of
+ requirements for more than one authentication mechanism to
+ be used within a TOE. For each distinct mechanism,
+ applicable requirements must be chosen from the class to be applied to each
+ mechanism. It is possible that the same component could be
+ selected multiple times in order to reflect different
+ requirements for the different use of the authentication
+ mechanism.
+
+ The management functions in the class FMT may provide
+ maintenance capabilities for the set of authentication
+ mechanisms, as well as the rules that determine whether
+ the authentication was successful.
+
+ To allow anonymous users to interact with the TOE, a
+ ``none'' authentication mechanism can be incorporated. The
+ use of such access should be clearly explained in the
+ rules of .
+
+
+
+ , requires that different
+ authentication mechanisms be provided and used to
+ authenticate user identities for specific events.
+
+
+ the management of authentication mechanisms;
+
+
+ the management of the rules for authentication.
+
+
+ The final decision on authentication;
+
+
+ The result of each activated mechanism together with the
+ final decision.
+
+
+ The TSF shall provide
+
+
+ list of multiple authentication mechanisms
+
+
+
+ the PP/ST author should define the available
+ authentication mechanisms. An example of such a list
+ could be: ``none, password mechanism,
+ biometric (retinal scan), S/key mechanism''.
+
+
+ to support user authentication.
+
+
+ The TSF shall authenticate any user's claimed
+ identity according to the
+
+
+ rules describing how the multiple authentication
+ mechanisms provide authentication
+
+
+
+ the PP/ST author should specify the rules that
+ describe how the authentication mechanisms provide
+ authentication and when each is to be used. This means
+ that for each situation the set of mechanisms that
+ might be used for authenticating the user must be
+ described. An example of a list of such rules is:
+ ``if the user has special privileges a
+ password mechanism and a biometric mechanism both
+ shall be used, with success only if both succeed; for
+ all other users a password mechanism shall be
+ used.''
+
+ The PP/ST author might give the boundaries within
+ which the authorised administrator may specify
+ specific rules. An example of a rule is:
+ ``the user shall always be authenticated by
+ means of a token; the administrator might specify
+ additional authentication mechanisms that also must be
+ used.'' The PP/ST author also might choose
+ not to specify any boundaries but leave the
+ authentication mechanisms and their rules completely
+ up to the authorised administrator.
+
+ .
+
+
+
+
+
+
+ This component addresses potential needs to
+ re-authenticate users at defined points in time. These may
+ include user requests for the TSF to perform security
+ relevant actions, as well as requests from non-TSF
+ entities for re-authentication (e.g. a server application
+ requesting that the TSF re-authenticate the client it is
+ serving).
+
+
+
+ , requires the ability to specify
+ events for which the user needs to be re-authenticated.
+
+
+ if an authorised administrator could request
+ re-authentication, the management includes a
+ re-authentication request.
+
+
+ Failure of reauthentication;
+
+
+ All reauthentication attempts.
+
+
+ The TSF shall re-authenticate the user under the conditions
+
+
+ list of conditions under which re-authentication is
+ required
+
+
+
+ the PP/ST author should specify the list of conditions
+ requiring re-authentication. This list could include a
+ specified user inactivity period that has elapsed, the
+ user requesting a change in active security
+ attributes, or the user requesting the TSF to perform
+ some security critical function.
+
+ The PP/ST author might give the boundaries within
+ which the reauthentication should occur and leave the
+ specifics to the authorised administrator. An example
+ of such a rule is: ``the user shall always
+ be re-authenticated at least once a day; the
+ administrator might specify that the re-authentication
+ should happen more often but not more often than once
+ every 10 minutes.''
+
+ .
+
+
+
+
+
+
+
+
+
+ This component addresses the feedback on the
+ authentication process that will be provided to the
+ user. In some systems the feedback consists of indicating
+ how many characters have been typed but not showing the
+ characters themselves, in other systems even this
+ information might not be appropriate.
+
+ This component requires that the authentication data is
+ not provided as-is back to the user. In a workstation
+ environment, it could display a
+ ``dummy'' (e.g. star) for each
+ password character provided, and not the original
+ character.
+
+
+
+ , requires that only limited
+ feedback information is provided to the user during the
+ authentication.
+
+
+ The TSF shall provide only
+
+
+ list of feedback
+
+
+
+ the PP/ST author should specify the feedback related
+ to the authentication process that will be provided to
+ the user. An example of a feedback assignment is
+ ``the number of characters
+ typed'', another type of feedback is
+ ``the authentication mechanism that failed
+ the authentication''.
+
+
+ to the user while the authentication is in progress.
+
+
+
+
+
+
+
+ This family defines the conditions under which users shall
+ be required to identify themselves before performing any
+ other actions that are to be mediated by the TSF and which
+ require user identification.
+
+
+
+ This family defines the conditions under which users are
+ required to identify themselves before performing any other
+ actions that are to be mediated by the TSF and that require
+ user identification.
+
+
+
+
+
+ This component poses requirements for the user to be
+ identified. The PP/ST author can indicate specific actions
+ that can be performed before the identification takes
+ place.
+
+ If is used, the TSF-mediated
+ actions mentioned in should also
+ appear in this .
+
+
+
+ , allows users to perform certain
+ actions before being identified by the TSF.
+
+
+ the management of the user identities;
+
+
+ if an authorised administrator can change the actions
+ allowed before identification, the managing of the action
+ lists.
+
+
+ Unsuccessful use of the user identification mechanism,
+ including the user identity provided;
+
+
+ All use of the user identification mechanism, including the
+ user identity provided.
+
+
+ The TSF shall allow
+
+
+ list of TSF-mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the user has to identify itself. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ identified.
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ In this component users will be identified. A user is not
+ allowed by the TSF to perform any action before being
+ identified.
+
+
+
+ , requires that users identify
+ themselves before any other action will be allowed by the TSF.
+
+
+ the management of the user identities.
+
+
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ It is intended that a subject is
+ acting on behalf of the user who caused the subject to come into
+ being or to be activated to perform a certain task.
+ Therefore, when a subject is created, that subject is acting on
+ behalf of the user who initiated the creation. In cases where
+ anonymity is used, the subject is still acting on behalf of a
+ user, but the identity of that user is unknown. A special
+ category of subjects are those subjects that serve multiple
+ users (e.g. a server process). In such cases the user that
+ created this subject is assumed to be the ``owner''., requires the specification of any rules
+ governing the association between user attributes and the
+ subject attributes into which they are mapped.
+ an authorised administrator can define default subject security
+ attributes.
+
+ an authorised administrator can change subject security
+ attributes.
+
+ Unsuccessful binding of user security attributes to a subject
+ (e.g. creation of a subject).
+
+ Success and failure of binding of user security attributes to a
+ subject (e.g. success or failure to create a subject).
+
+ The TSF shall associate the following user security attributes
+ with subjects acting on the behalf of that user:
+
+ list of user security attributes
+
+ the PP/ST author should specify a list of the user security
+ attributes that are to be bound to subjects..
+
+ The TSF shall enforce the following rules on the initial
+ association of user security attributes with subjects acting on
+ the behalf of users:
+
+ rules for the initial association of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ upon initial association of attributes with subjects, or
+ ``none''..
+
+ The TSF shall enforce the following rules governing changes to the
+ user security attributes associated with subjects acting on the
+ behalf of users:
+
+ rules for the changing of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ when changes are made to the user security attributes
+ associated with subjects acting on behalf of users, or
+ ``none''..
+
+
+
+
+
+
+ This class is intended to specify the management of several
+ aspects of the TSF: security attributes, TSF data and
+ functions. The different management roles and their
+ interaction, such as separation of capability, can be
+ specified.
+
+ This class has several objectives:
+
+
+ management of TSF data, which include, for example,
+ banners;
+
+
+ management of security attributes, which include, for
+ example, the Access Control Lists, and Capability Lists;
+
+
+ management of functions of the TSF, which includes, for
+ example, the selection of functions, and rules or
+ conditions influencing the behaviour of the TSF;
+
+
+ definition of security roles.
+
+
+
+
+
+ This class specifies the management of several aspects of the
+ TSF: security attributes, TSF data and functions in the
+ TSF. The different management roles and their interaction,
+ such as separation of capability, can also be specified
+
+ In an environment where the TOE is made up of multiple
+ physically separated parts, the timing issues with respect to
+ propagation of security attributes, TSF data, and function
+ modification become very complex, especially if the
+ information is required to be replicated across the parts of
+ the TOE. This should be considered when selecting components
+ such as , or , where the behaviour might be
+ impaired. In such situations, use of components from is advisable.
+
+
+
+
+
+ This family allows authorised users control over the
+ management of functions in the TSF. Examples of functions in
+ the TSF include the audit functions and the multiple
+ authentication functions.
+
+
+
+ The TSF management functions enable authorised users to set
+ up and control the secure operation of the TOE. These
+ administrative functions typically fall into a number of
+ different categories:
+
+
+ Management functions that relate to access control,
+ accountability and authentication controls enforced by
+ the TOE. For example, definition and update of user
+ security characteristics (e.g. unique identifiers
+ associated with user names, user accounts, system entry
+ parameters) or definition and update of auditing system
+ controls (e.g. selection of audit events, management of
+ audit trails, audit trail analysis, and audit report
+ generation), definition and update of per-user policy
+ attributes (such as user clearance), definition of known
+ system access control labels, and control and management
+ of user groups.
+
+
+ Management functions that relate to controls over
+ availability. For example, definition and update of
+ availability parameters or resource quotas.
+
+
+ Management functions that relate to general installation
+ and configuration. For example, TOE configuration,
+ manual recovery, installation of TOE security fixes (if
+ any), repair and reinstallation of hardware.
+
+
+ Management functions that relate to routine control and
+ maintenance of TOE resources. For example, enabling and
+ disabling peripheral devices, mounting of removable
+ storage media, backup and recovery.
+
+
+
+ Note that these functions need to be present in a TOE based
+ on the families included in the PP or ST. It is the
+ responsibility of the PP/ST author to ensure that adequate
+ functions will be provided to manage the TOE in a secure
+ fashion.
+
+ The TSF might contain functions that can be controlled by an
+ administrator. For example, the auditing functions could be
+ switched off, the time synchronisation could be switchable,
+ and/or the authentication mechanism could be modifiable.
+
+
+
+
+
+
+
+
+
+ This component allows identified roles to manage the
+ security functions of the TSF. This might entail obtaining
+ the current status of a security function, disabling or
+ enabling the security function, or modifying the behaviour
+ of the security function. An example of modifying the
+ behaviour of the security functions is changing of
+ authentication mechanisms.
+
+
+
+ allows the authorised users (roles)
+ to manage the behaviour of functions in the TSF that use
+ rules or have specified conditions that may be manageable.
+
+
+ managing the group of roles that can interact with the
+ functions in the TSF;
+
+
+ All modifications in the behaviour of the functions in the
+ TSF.
+
+
+ The TSF shall restrict the ability to
+
+
+ determine the behaviour of
+
+
+ disable
+
+
+ enable
+
+
+ modify the behaviour of
+
+
+
+ the PP/ST author should select whether the role can
+ determine the behaviour of, disable, enable, and/or
+ modify the behaviour of the security functions.
+
+
+ the functions
+
+
+ list of functions
+
+
+
+ the PP/ST author should specify the functions that can
+ be modified by the identified roles. Examples include
+ auditing and time determination.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the functions in the TSF. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+ This family allows authorised users control over the
+ management of security attributes. This management might
+ include capabilities for viewing and modifying of security
+ attributes.
+
+
+
+ This family defines the requirements on the management of
+ security attributes.
+
+ Security attributes affect the behaviour of the TSF. Examples of
+ security attributes are the groups to which a user belongs, the
+ roles he/she might assume, the priority of a process (subject),
+ and the rights belonging to a role or a user. These security
+ attributes might need to be managed by the user, a subject, a
+ specific authorised user (a user with explicitly given rights
+ for this management) or inherit values according to a given
+ policy/set of rules.
+
+ It is noted that the right to assign rights to users is
+ itself a security attribute and/or potentially subject to
+ management by .
+ can be used to ensure that any
+ accepted combination of security attributes is within a
+ secure state. The definition of what
+ ``secure'' means is left to the TOE guidance.
+
+ In some instances subjects, objects or user accounts are
+ created. If no explicit values for the related security
+ attributes are given, default values need to be used. can be used to specify that these default
+ values can be managed.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component allows users acting in certain roles to
+ manage identified security attributes. The users are
+ assigned to a role within the component .
+
+ The default value of a parameter is the value the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter, and
+ overrides the default value.
+
+
+
+ allows authorised users (roles) to
+ manage the specified security attributes.
+
+
+ managing the group of roles that can interact with the
+ security attributes;
+
+ management of rules by which security attributes inherit
+ specified values.
+
+
+ All modifications of the values of security attributes.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s), information flow control SFP(s)
+
+ the PP/ST author should list the access control SFP(s) or
+ the information flow control SFP(s) for which the security
+ attributes are applicable.
+ to restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example of such an operation could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified security
+ attributes. The PP/ST author can specify that the role
+ can modify the default value (change_default), query,
+ modify the security attribute, delete the security
+ attributes entirely or define their own operation.
+
+
+ the security attributes
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that can be operated on by the identified
+ roles. It is possible for the PP/ST author to specify
+ that the default value such as default access-rights
+ can be managed. Examples of these security attributes
+ are user-clearance, priority of service level, access
+ control list, default access rights.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the security attributes. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component contains requirements on the values that
+ can be assigned to security attributes. The assigned
+ values should be such that the TOE will remain in a secure
+ state.
+
+ The definition of what ``secure'' means is
+ not answered in this component but is left to the
+ development of the TOE and the resulting information in the
+ guidance. An example could be that if a user account is
+ created, it should have a non-trivial password.
+
+
+
+ ensures that values assigned to
+ security attributes are valid with respect to the secure
+ state.
+
+ management of rules by which security attributes inherit
+ specified values.
+
+
+ All offered and rejected values for a security attribute;
+
+
+ All offered and accepted secure values for a security
+ attribute.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for
+ list of security attributes
+
+ the PP/ST author should specify the list of security
+ attributes that require only secure values to be provided..
+
+
+
+
+
+
+
+
+
+
+ This component requires that the TSF provide default
+ values for relevant object security attributes, which can
+ be overridden by an initial value. It may still be
+ possible for a new object to have different security
+ attributes at creation, if a mechanism exists to specify
+ the permissions at time of creation.
+
+
+
+ ensures that the default values of
+ security attributes are appropriately either permissive or
+ restrictive in nature.
+
+
+ managing the group of roles that can specify initial values;
+
+
+ managing the permissive or restrictive setting of default values
+ for a given access control SFP;
+
+ management of rules by which security attributes inherit specified values.
+
+
+ Modifications of the default setting of permissive or
+ restrictive rules.
+
+
+ All modifications of the initial values of security
+ attributes.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP, information flow control SFP
+
+
+
+ the PP/ST author should list the access control SFP or
+ the information flow control SFP for which the
+ security attributes are applicable.
+
+
+ to provide
+
+
+ restrictive
+
+
+ permissive
+
+
+ other property
+
+ if the PP/ST author selects another property, the PP/ST
+ author should specify the desired characteristics of the
+ default values.
+
+
+ the PP/ST author should select whether the default property
+ of the access control attribute will be restrictive,
+ permissive, or another property. Only one of these options
+ may be chosen.
+
+
+ default values for security attributes that are used to
+ enforce the SFP.
+
+
+ The TSF shall allow the
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the values of the security
+ attributes. The possible roles are specified in .
+
+
+ to specify alternative initial values to override the
+ default values when an object or information is created.
+
+
+ This component requires specification of the set of rules
+ through which the security attribute inherits values and the
+ conditions to be met for these rules to be applied. allows the rules/policies
+ to be specified that will dictate the value to be inherited
+ by a security attribute.
+ specification of the role permitted to establish or modify
+ security attributes.
+
+ Modifications of security attributes, possibly with the old
+ and/or values of security attributes that were modified.
+
+ The TSF shall use the following rules to set the value of security attributes:
+
+ rules for setting the values of security attributes
+
+ the PP/ST author specifies the rules governing the value
+ that will be inherited by the specified security
+ attribute, including the conditions that are to be met
+ for the rules to be applied. For example, if a new file
+ or directory is created (in a multilevel filesystem),
+ its label is the label at which the user is logged in at
+ the time it is created.
+
+
+
+
+
+ This family allows authorised users (roles) control over the
+ management of TSF data. Examples of TSF data include audit
+ information, clock and other TSF
+ configuration parameters.
+
+
+
+ This component imposes requirements on the management of TSF
+ data. Examples of TSF data are the current time and the
+ audit trail. So, for example, this family allows the
+ specification of whom can read, delete or create the audit
+ trail.
+
+
+
+
+
+
+
+
+ This component allows users with a certain role to manage
+ values of TSF data. The users are assigned to a role
+ within the component .
+
+ The default value of a parameter is the values the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter and
+ overrides the default value.
+
+
+
+ allows authorised users to manage
+ TSF data.
+
+
+ managing the group of roles that can interact with the TSF
+ data.
+
+
+ All modifications to the values of TSF data.
+
+
+ The TSF shall restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+ clear
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified TSF data. The PP/ST
+ author can specify that the role can modify the
+ default value (change_default), clear, query or modify
+ the TSF data, or delete the TSF data entirely. If so
+ desired the PP/ST author could specify any type of
+ operation. To clarify ``clear TSF data'' means that
+ the content of the TSF data is removed, but that the
+ entity that stores the TSF data remains in the
+ TOE.
+
+
+ the
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ be operated on by the identified roles. It is possible
+ for the PP/ST author to specify that the default value
+ can be managed.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the TSF data. The possible roles
+ are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies limits on TSF data, and actions
+ to be taken if these limits are exceeded. This component,
+ for example, will allow limits on the size of the audit
+ trail to be defined, and specification of the actions to
+ be taken when these limits are exceeded.
+
+
+
+ specifies the action to be taken if
+ limits on TSF data are reached or exceeded.
+
+
+ managing the group of roles that can interact with the
+ limits on the TSF data.
+
+
+ All modifications to the limits on TSF data;
+
+
+ All modifications in the actions to be taken in case of
+ violation of the limits.
+
+
+ The TSF shall restrict the specification of the limits for
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ have limits, and the value of those limits. An example
+ of such TSF data is the number of users logged-in.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the limits on the TSF data and the
+ actions to be taken. The possible roles are specified
+ in .
+
+ .
+
+
+ The TSF shall take the following actions, if the TSF data
+ are at, or exceed, the indicated limits:
+
+
+ actions to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken if the specified limit on the specified TSF data
+ is exceeded. An example of such TSF action is that the
+ authorised user is informed and an audit record is
+ generated.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component covers requirements on the values that can
+ be assigned to TSF data. The assigned values should be
+ such that the TOE will remain in a secure state.
+
+ The definition of what ``secure'' means is not
+ answered in this component but is left to the development of
+ the TOE and the
+ resulting information in the guidance.
+
+
+
+ ensures that values assigned to TSF
+ data are valid with respect to the secure state.
+
+
+ All rejected values of TSF data.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for
+ list of TSF data
+
+ the PP/ST author should specify what TSF data require only
+ secure values to be accepted..
+
+
+
+
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+
+
+
+
+
+ This component specifies requirements on the revocation of
+ rights. It requires the specification of the revocation
+ rules. Examples are:
+
+
+ Revocation will take place on the next login of the
+ user;
+
+
+ Revocation will take place on the next attempt to open
+ the file;
+
+
+ Revocation will take place within a fixed time. This
+ might mean that all open connections are re-evaluated
+ every x minutes.
+
+
+
+
+
+ provides for revocation of security
+ attributes to be enforced at some point in time.
+
+
+ managing the group of roles that can invoke revocation of
+ security attributes;
+
+
+ managing the lists of users, subjects, objects and other
+ resources for which revocation is possible;
+
+
+ managing the revocation rules.
+
+
+ Unsuccessful revocation of security attributes;
+
+
+ All attempts to revoke security attributes.
+
+
+ The TSF shall restrict the ability to revoke
+
+ list of security attributes
+
+ the PP/ST author should specify which security attributes
+ are to be revoked when a change is made to the associated
+ object/subject/user/other resource.
+ associated with the
+
+ users
+
+ subjects
+
+ objects
+ other additional resources
+ the PP/ST author should, if additional resources is
+ selected, specify whether the ability to revoke their
+ security attributes shall be provided by the
+ TSF.
+ the PP/ST author should specify whether the ability to
+ revoke security attributes from users, subjects, objects,
+ or any additional resources shall be provided by the
+ TSF.
+ under the control of the TSF to
+
+ the authorised identified roles
+
+ the PP/ST author should specify the roles that are allowed
+ to modify the functions in the TSF. The possible roles are
+ specified in ..
+
+
+ The TSF shall enforce the rules
+
+
+ specification of revocation rules
+
+
+
+ the PP/ST author should specify the revocation
+ rules. Examples of these rules could include:
+ ``prior to the next operation on the
+ associated resource'', or ``for
+ all new subject creations''.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes.
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes. This family can be
+ applied to specify expiration requirements for access
+ control attributes, identification and authentication
+ attributes, certificates (key certificates such as ANSI X509
+ for example), audit attributes, etc.
+
+
+
+
+
+
+
+
+
+ provides the capability for an
+ authorised user to specify an expiration time on specified
+ security attributes.
+
+
+ managing the list of security attributes for which
+ expiration is to be supported;
+
+
+ the actions to be taken if the expiration time has passed.
+
+
+ Specification of the expiration time for an attribute;
+
+
+ Action taken due to attribute expiration.
+
+
+ The TSF shall restrict the capability to specify an
+ expiration time for
+
+
+ list of security attributes for which expiration is to
+ be supported
+
+
+
+ the PP/ST author should provide the list of security
+ attributes for which expiration is to be supported. An
+ example of such an attribute might be a
+ user's security clearance.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the security attributes in the
+ TSF. The possible roles are specified in .
+
+ .
+
+
+ For each of these security attributes, the TSF shall be able
+ to
+
+
+ list of actions to be taken for each security attribute
+
+
+
+ the PP/ST author should provide a list of actions to
+ be taken for each security attribute when it
+ expires. An example might be that the
+ user's security clearance, when it expires,
+ is set to the lowest allowable clearance on the
+ TOE. If immediate revocation is desired by the PP/ST,
+ the action ``immediate
+ revocation'' should be specified.
+
+
+ after the expiration time for the indicated security
+ attribute has passed.
+
+
+
+ This family allows the specification of the management
+ functions to be provided by the TOE. Management functions
+ provide TSFI that allow administrators to define the
+ parameters that control the operation of security-related
+ aspects of the TOE, such as data protection attributes, TOE
+ protection attributes, audit attributes, and identification
+ and authentication attributes. Management functions also
+ include those functions performed by an operator to ensure
+ continued operation of the TOE, such as backup and
+ recovery. This family works in conjunction with the other
+ components in the class: the component in
+ this family calls out the management functions, and other
+ families in restrict the ability to use
+ these management functions.
+ This family allows the specification of the management
+ functions to be provided by the TOE. Each security
+ management function that is listed in fulfilling the
+ assignment is either security attribute management, TSF data
+ management, or security function management.
+ This component specifies the management functions to be
+ provided.
+ PP/ST authors should consult the ``Management'' sections
+ for components included in their PP/ST to provide a basis
+ for the management functions to be listed via this
+ component. requires that the TSF provide
+ specific management functions.
+ Use of the management functions.
+
+ The TSF shall be capable of performing the following
+ management functions:
+
+ list of management functions to be provided by
+ the TSF
+
+ the PP/ST author should specify the management
+ functions to be provided by the TSF, either security
+ attribute management, TSF data management, or security
+ function management..
+
+
+
+
+
+ This family is intended to control the assignment of
+ different roles to users. The capabilities of these roles
+ with respect to security management are described in the
+ other families in this class.
+
+
+
+ This family reduces the likelihood of damage resulting from
+ users abusing their authority by taking actions outside
+ their assigned functional responsibilities. It also
+ addresses the threat that inadequate mechanisms have been
+ provided to securely administer the TSF.
+
+ This family requires that information be maintained to
+ identify whether a user is authorised to use a particular
+ security-relevant administrative function.
+
+ Some management actions can be performed by users, others
+ only by designated people within the organisation. This
+ family allows the definition of different roles, such as
+ owner, auditor, administrator, daily-management.
+
+ The roles as used in this family are security related
+ roles. Each role can encompass an extensive set of
+ capabilities (e.g. root in UNIX), or can be a single right
+ (e.g. right to read a single object such as the
+ helpfile). This family defines the roles. The capabilities
+ of the role are defined in , and .
+
+ Some type of roles might be mutually exclusive. For example
+ the daily-management might be able to define and activate
+ users, but might not be able to remove users (which is
+ reserved for the administrator (role)). This class will
+ allow policies such as two-person control to be specified.
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise. Often the system distinguishes between
+ the owner of an entity, an administrator and other users.
+
+
+
+ specifies the roles with respect to
+ security that the TSF recognises.
+
+
+ managing the group of users that are part of a role.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor and administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise, and conditions on how those roles could
+ be managed. Often the system distinguishes between the
+ owner of an entity, an administrator and other users.
+
+ The conditions on those roles specify the
+ interrelationship between the different roles, as well as
+ restrictions on when the role can be assumed by a user.
+
+
+
+ specifies that in addition to the
+ specification of the roles, there are rules that control
+ the relationship between the roles.
+
+
+ managing the group of users that are part of a role;
+
+
+ managing the conditions that the roles must satisfy.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ unsuccessful attempts to use a role due to the given
+ conditions on the roles;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles:
+
+
+ authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor, administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+ The TSF shall ensure that the conditions
+
+
+ conditions for the different roles
+
+
+
+ the PP/ST author should specify the conditions that
+ govern role assignment. Examples of these conditions
+ are: ``an account cannot have both the
+ auditor and administrator role'' or
+ ``a user with the assistant role must also
+ have the owner role''.
+
+
+ are satisfied.
+
+
+
+
+
+
+
+
+
+ This component specifies that an explicit request must be
+ given to assume the specific role.
+
+
+
+ , requires that an explicit request
+ is given to the TSF to assume a role.
+
+
+ explicit request to assume a role.
+
+
+ The TSF shall require an explicit request to assume the
+ following roles:
+
+
+ the roles
+
+
+
+ the PP/ST author should specify the roles that require
+ an explicit request to be assumed. Examples are:
+ auditor and administrator.
+
+ .
+
+
+
+
+
+
+
+ This class contains privacy requirements. These requirements
+ provide a user protection against discovery and misuse of
+ identity by other users.
+
+
+
+ This class describes the requirements that could be levied to
+ satisfy the users' privacy needs, while still allowing
+ the system flexibility as far as possible to maintain
+ sufficient control over the operation of the system.
+
+ In the components of this class there is flexibility as to
+ whether or not authorised users are covered by the required
+ security functionality. For example, a PP/ST author might
+ consider it appropriate not to require protection of the privacy
+ of users against a suitably authorised user.
+
+ This class, together with other classes (such as those
+ concerned with audit, access control, trusted path, and
+ non-repudiation) provides the flexibility to specify the
+ desired privacy behaviour. On the other hand, the requirements
+ in this class might impose limitations on the use of the
+ components of other classes, such as or . For example, if
+ authorised users are not allowed to see the user identity
+ (e.g. Anonymity or Pseudonymity), it will obviously not be
+ possible to hold individual users accountable for any security
+ relevant actions they perform that are covered by the privacy
+ requirements. However, it may still be possible to include
+ audit requirements in a PP/ST, where the fact that a
+ particular security relevant event has occurred is more
+ important than knowing who was responsible for it.
+
+ Additional information is provided in the application notes
+ for class , where it is explained that the
+ definition of ``identity'' in the context of
+ auditing can also be an alias or other information that could
+ identify a user.
+
+ This class describes four families: Anonymity, Pseudonymity,
+ Unlinkability and Unobservability. Anonymity, Pseudonymity and
+ Unlinkability have a complex interrelationship. When choosing
+ a family, the choice should depend on the threats
+ identified. For some types of privacy threats, pseudonymity
+ will be more appropriate than anonymity (e.g. if there is a
+ requirement for auditing). In addition, some types of privacy
+ threats are best countered by a combination of components from
+ several families.
+
+ All families assume that a user does not explicitly perform an
+ action that discloses the user's own identity. For
+ example, the TSF is not expected to screen the user name in
+ electronic messages or databases.
+
+ All families in this class have components that can be scoped
+ through operations. These operations allow the PP/ST author to
+ state the cooperating users/subjects to which the TSF must be
+ resistant. An example of an instantiation of anonymity could
+ be: `` The TSF shall ensure that the users and/or
+ subjects are unable to determine the user identity bound to
+ the teleconsulting application''.
+
+ It is noted that the TSF should not only provide this
+ protection against individual users, but also against users
+ cooperating to obtain the information.
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing the user's identity. The
+ requirements for Anonymity provide protection of the user
+ identity. Anonymity is not intended to protect the subject
+ identity.
+
+
+
+ Anonymity ensures that a subject may use a resource or
+ service without disclosing its user identity.
+
+ The intention of this family is to specify that a user or
+ subject might take action without releasing its user
+ identity to others such as users, subjects, or objects. The
+ family provides the PP/ST author with a means to identify
+ the set of users that cannot see the identity of someone
+ performing certain actions.
+
+ Therefore if a subject, using anonymity, performs an action,
+ another subject will not be able to determine either the
+ identity or even a reference to the identity of the user
+ employing the subject. The focus of the anonymity is on the
+ protection of the users identity, not on the protection of
+ the subject identity; hence, the identity of the subject is
+ not protected from disclosure.
+
+ Although the identity of the subject is not released to
+ other subjects or users, the TSF is not explicitly
+ prohibited from obtaining the users identity. In case the
+ TSF is not allowed to know the identity of the user, could be invoked. In that case
+ the TSF should not request the user information.
+
+ The interpretation of ``determine'' should be
+ taken in the broadest sense of the word.
+
+ The component levelling distinguishes between the users and
+ an authorised user. An authorised user is often excluded
+ from the component, and therefore allowed to retrieve a
+ user's identity. However, there is no specific
+ requirement that an authorised user must be able to have the
+ capability to determine the user's identity. For
+ ultimate privacy the components would be used to say that no
+ user or authorised user can see the identity of anyone
+ performing any action.
+
+ Although some systems will provide anonymity for all
+ services that are provided, other systems provide anonymity
+ for certain subjects/operations. To provide this
+ flexibility, an operation is included where the scope of the
+ requirement is defined. If the PP/ST author wants to address
+ all subjects/operations, the words ``all subjects and
+ all operations'' could be provided.
+
+ Possible applications include the ability to make enquiries
+ of a confidential nature to public databases, respond to
+ electronic polls, or make anonymous payments or donations.
+
+ Examples of potential hostile users or subjects are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts (e.g. Trojan Horses) into
+ systems. All of these users can investigate usage patterns
+ (e.g. which users used which services) and misuse this
+ information.
+
+
+
+
+
+ This component ensures that the identity of a user is
+ protected from disclosure. There may be instances,
+ however, that a given authorised user can determine who
+ performed certain actions. This component gives the
+ flexibility to capture either a limited or total privacy
+ policy.
+
+
+
+ , requires that other users or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation.
+
+
+ The invocation of the anonymity mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+
+
+
+
+
+ This component is used to ensure that the TSF is not
+ allowed to know the identity of the user.
+
+
+
+ enhances the
+ requirements of by
+ ensuring that the TSF does not ask for the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the anonymity requirement, for
+ example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which the real user name of the subject should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to the real user name.
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing its user identity, but can still
+ be accountable for that use.
+
+
+
+ Pseudonymity ensures that a user may use a resource or
+ service without disclosing its identity, but can still be
+ accountable for that use. The user can be accountable by
+ directly being related to a reference (alias) held by the
+ TSF, or by providing an alias that will be used for
+ processing purposes, such as an account number.
+
+ In several respects, pseudonymity resembles anonymity. Both
+ pseudonymity and anonymity protect the identity of the user,
+ but in pseudonymity a reference to the user's
+ identity is maintained for accountability or other purposes.
+
+ The component does not
+ specify the requirements on the reference to the user's
+ identity. For the purpose of specifying requirements on this
+ reference two sets of requirements are presented: and .
+
+ A way to use the reference is by being able to obtain the
+ original user identity. For example, in a digital cash
+ environment it would be advantageous to be able to trace the
+ user's identity when a check has been issued multiple times
+ (i.e. fraud). In general, the user's identity needs to be
+ retrieved under specific conditions. The PP/ST author might
+ want to incorporate to
+ describe those services.
+
+ Another usage of the reference is as an alias for a
+ user. For example, a user who does not wish to be
+ identified, can provide an account to which the resource
+ utilisation should be charged. In such cases, the reference
+ to the user identity is an alias for the user, where other
+ users or subjects can use the alias for performing their
+ functions without ever obtaining the user's
+ identity (for example, statistical operations on use of the
+ system). In this case, the PP/ST author might wish to
+ incorporate to specify the rules to
+ which the reference must conform.
+
+ Using these constructs above, digital money can be created
+ using specifying that the user
+ identity will be protected and, if so specified in the
+ condition, that there be a requirement to trace the user
+ identity if the digital money is spent twice. When the user
+ is honest, the user identity is protected; if the user tries
+ to cheat, the user identity can be traced.
+
+ A different kind of system could be a digital credit card,
+ where the user will provide a pseudonym that indicates an
+ account from which the cash can be subtracted. In such
+ cases, for example, could be
+ used. This component would specify that the user identity
+ will be protected and, furthermore, that the same user will
+ only get assigned values for which he/she has provided money
+ (if so specified in the conditions).
+
+ It should be realised that the more stringent components
+ potentially cannot be combined with other requirements, such
+ as identification and authentication or audit. The
+ interpretation of ``determine the identity''
+ should be taken in the broadest sense of the word. The
+ information is not provided by the TSF during the operation,
+ nor can the entity determine the subject or the owner of the
+ subject that invoked the operation, nor will the TSF record
+ information, available to the users or subjects, which might
+ release the user identity in the future.
+
+ The intent is that the TSF not reveal any information that
+ would compromise the identity of the user, e.g. the identity
+ of subjects acting on the user's behalf. The
+ information that is considered to be sensitive depends on
+ the effort an attacker is capable of spending.
+
+ Possible applications include the ability to charge a caller
+ for premium rate telephone services without disclosing his
+ or her identity, or to be charged for the anonymous use of
+ an electronic payment system.
+
+ Examples of potential hostile users are providers, system
+ operators, communication partners and users, who smuggle
+ malicious parts (e.g. Trojan Horses) into systems. All of
+ these attackers can investigate which users used which
+ services and misuse this information. Additionally to
+ Anonymity services, Pseudonymity Services contains methods
+ for authorisation without identification, especially for
+ anonymous payment (``Digital Cash''). This
+ helps providers to obtain their payment in a secure way
+ while maintaining customer anonymity.
+
+
+
+
+
+ This component provides the user protection against
+ disclosure of identity to other users. The user will
+ remain accountable for its actions.
+
+
+
+ requires that a set of users and/or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation, but that this user is
+ still accountable for its actions.
+
+
+ The subject/user that requested resolution of the user
+ identity should be audited.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that under
+ specified conditions the user identity related to a
+ provided reference can be determined.
+
+ In the TSF shall provide an alias
+ instead of the user identity. When the specified
+ conditions are satisfied, the user identity to which the
+ alias belong can be determined. An example of such a
+ condition in an electronic cash environment is: ``
+ The TSF shall provide the notary a capability to determine
+ the user identity based on the provided alias only under
+ the conditions that a check has been issued
+ twice.''.
+
+
+
+ , requires the TSF to provide a
+ capability to determine the original user identity based
+ on a provided alias.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF, is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide
+
+
+ an authorised user
+
+
+
+
+ list of trusted subjects
+
+
+
+ the PP/ST author should identify the list of trusted
+ subjects that can obtain the real user name under a
+ specified condition, for example, a notary or
+ special authorised user.
+
+
+
+
+
+ the PP/ST author should select whether the authorised
+ user and/or trusted subjects can determine the real
+ user name.
+
+
+ a capability to determine the user identity based on the
+ provided alias only under the following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions under which the trusted subjects and
+ authorised user can determine the real user name based
+ on the provided reference. These conditions can be
+ conditions such as time of day, or they can be
+ administrative such as on a court order.
+
+ .
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that the provided
+ reference meets certain construction rules, and thereby
+ can be used in a secure way by potentially insecure
+ subjects.
+
+ If a user wants to use disk resources without disclosing
+ its identity, pseudonymity can be used. However, every
+ time the user accesses the system, the same alias must be
+ used. Such conditions can be specified in this component.
+
+
+
+ , requires the TSF to
+ follow certain construction rules for the alias to the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes which might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide an alias to the real user name which
+ shall be identical to an alias provided previously under the
+ following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions that indicate when the used reference for
+ the real user name shall be identical and when it
+ shall be different, for example, ``when the
+ user logs on to the same host'' it will use a
+ unique alias.
+
+
+ otherwise the alias provided shall be unrelated to
+ previously provided aliases.
+
+
+
+
+
+
+ This family ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together.
+
+
+
+ Unlinkability ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together. Unlinkability differs from pseudonymity
+ that, although in pseudonymity the user is also not known,
+ relations between different actions can be provided.
+
+ The requirements for unlinkability are intended to protect
+ the user identity against the use of profiling of the
+ operations. For example, when a telephone smart card is
+ employed with a unique number, the telephone company can
+ determine the behaviour of the user of this telephone
+ card. When a telephone profile of the users is known, the
+ card can be linked to a specific user. Hiding the
+ relationship between different invocations of a service or
+ access of a resource will prevent this kind of information
+ gathering.
+
+ As a result, a requirement for unlinkability could imply
+ that the subject and user identity of an operation must be
+ protected. Otherwise this information might be used to link
+ operations together.
+
+ Unlinkability requires that different operations cannot be
+ related. This relationship can take several forms. For
+ example, the user associated with the operation, or the
+ terminal which initiated the action, or the time the action
+ was executed. The PP/ST author can specify what kind of
+ relationships are present that must be countered.
+
+ Possible applications include the ability to make multiple
+ use of a pseudonym without creating a usage pattern that
+ might disclose the user's identity.
+
+ Examples for potential hostile subjects and users are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts, (e.g. Trojan Horses)
+ into systems, they do not operate but want to get
+ information about. All of these attackers can investigate
+ (e.g. which users used which services) and misuse this
+ information. Unlinkability protects users from linkages,
+ which could be drawn between several actions of a
+ customer. An example is a series of phone calls made by an
+ anonymous customer to different partners, where the
+ combination of the partner's identities might disclose the
+ identity of the customer.
+
+
+
+
+
+ This component ensures that users cannot link different
+ operations in the system and thereby obtain information.
+
+
+
+ , requires that users and/or subjects
+ are unable to determine whether the same user caused
+ certain specific operations.
+
+
+ the management of the unlinkability function.
+
+
+ The invocation of the unlinkability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine whether
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations which should be subjected to the
+ unlinkability requirement, for example,
+ ``sending email''.
+
+
+
+
+ were caused by the same user
+
+
+ are related as follows
+
+
+ list of relations
+
+
+
+ the PP/ST author should identify the list of
+ relations which should be protected against, for
+ example, ``originate from the same
+ terminal''.
+
+
+
+
+
+ the PP/ST author should select the relationships that
+ should be obscured. The selection allows either the
+ user identity or an assignment of relations to be
+ specified.
+
+ .
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+
+
+ Unobservability ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+ Unobservability approaches the user identity from a
+ different direction than the previous families Anonymity,
+ Pseudonymity and Unlinkability. In this case, the intent is
+ to hide the use of a resource or service, rather than to
+ hide the user's identity.
+
+ A number of techniques can be applied to implement
+ unobservability. Examples of techniques to provide
+ unobservability are:
+
+
+ Allocation of information impacting unobservability:
+ Unobservability relevant information (e.g. information
+ that describes that an operation occurred) can be
+ allocated in several locations within the TOE. The
+ information might be allocated to a single randomly
+ chosen part of the TOE such that an attacker does not
+ know which part of the TOE should be attacked. An
+ alternative system might distribute the information such
+ that no single part of the TOE has sufficient
+ information that, if circumvented, the privacy of the
+ user would be compromised. This technique is explicitly
+ addressed in .
+
+
+ Broadcast: When information is broadcast (e.g. ethernet,
+ radio), users cannot determine who actually received and
+ used that information. This technique is especially
+ useful when information should reach receivers which
+ have to fear a stigma for being interested in that
+ information (e.g. sensitive medical information).
+
+
+ Cryptographic protection and message padding: People
+ observing a message stream might obtain information from
+ the fact that a message is transferred and from
+ attributes on that message. By traffic padding, message
+ padding and encrypting the message stream, the
+ transmission of a message and its attributes can be
+ protected.
+
+
+
+ Sometimes, users should not see the use of a resource, but an
+ authorised user must be allowed to see the use of the resource
+ in order to perform his duties. In such cases, the could be used, which provides the
+ capability for one or more authorised users to see the
+ usage.
+
+ This family makes use of the concept ``parts of the
+ TOE''. This is considered any part of the TOE that is either
+ physically or logically separated from other parts of the
+ TOE.
+
+ Unobservability of communications may be an important factor
+ in many areas, such as the enforcement of constitutional
+ rights, organisational policies, or in defence related
+ applications.
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by unauthorised users.
+
+
+
+ , requires that users and/or
+ subjects cannot determine whether an operation is being
+ performed.
+
+
+ the management of the behaviour of the unobservability
+ function.
+
+
+ The invocation of the unobservability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users and/or
+ subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual user
+ or subject, but must protect with respect to cooperating
+ users and/or subjects. A set of users, for example,
+ could be a group of users which can operate under the
+ same role or can all use the same process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by specified users or
+ subjects. Furthermore this component specifies that
+ information related to the privacy of the user is
+ distributed within the TOE such that attackers might not
+ know which part of the TOE to target, or they need to
+ attack multiple parts of the TOE.
+
+ An example of the use of this component is the use of a
+ randomly allocated node to provide a function. In such a
+ case the component might require that the privacy related
+ information shall only be available to one identified part
+ of the TOE, and will not be communicated outside this part
+ of the TOE.
+
+ A more complex example can be found in some
+ ``voting algorithms''. Several parts of the
+ TOE will be involved in the service, but no individual
+ part of the TOE will be able to violate the policy. So a
+ person may cast a vote (or not) without the TOE being able
+ to determine whether a vote has been cast and what the
+ vote happened to be (unless the vote was unanimous).
+
+
+
+
+ , requires that the TSF
+ provide specific mechanisms to avoid the concentration of
+ privacy related information within the TOE. Such
+ concentrations might impact unobservability if a security
+ compromise occurs.
+
+
+
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+ The TSF shall allocate the
+
+
+ unobservability related information
+
+
+
+ the PP/ST author should identify which privacy related
+ information should be distributed in a controlled
+ manner. Examples of this information could be: IP
+ address of subject, IP address of object, time, used
+ encryption keys.
+
+
+ among different parts of the TOE such that the following
+ conditions hold during the lifetime of the information:
+
+
+ list of conditions
+
+
+
+ the PP/ST author should specify the conditions to
+ which the dissemination of the information should
+ adhere. These conditions should be maintained
+ throughout the lifetime of the privacy related
+ information of each instance. Examples of these
+ conditions could be: ``the information shall
+ only be present at a single separated part of the TOE
+ and shall not be communicated outside this part of the
+ TOE.'', ``the information shall only
+ reside in a single separated part of the TOE, but
+ shall be moved to another part of the TOE
+ periodically'', ``the information shall
+ be distributed between the different parts of the TOE
+ such that compromise of any 5 separated parts of the
+ TOE will not compromise the security policy''.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component is used to require that the TSF does not
+ try to obtain information that might compromise
+ unobservability when provided specific services. Therefore
+ the TSF will not solicit (i.e. try to obtain from other
+ entities) any information that might be used to compromise
+ unobservability.
+
+
+
+ , requires that the TSF
+ does not try to obtain privacy related information that
+ might be used to compromise unobservability.
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the unobservability requirement,
+ for example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which privacy related information should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to
+
+
+ privacy related information
+
+
+
+ the PP/ST author should specify the privacy related
+ information that will be protected from the specified
+ subjects. Examples include the identity of the subject
+ that used a service and the quantity of a service that
+ has been used such as memory resource
+ utilisation.
+
+ .
+
+
+
+
+
+
+ This component is used to require that there will be one
+ or more authorised users with the rights to view the
+ resource utilisation. Without this component, this review
+ is allowed, but not mandated.
+
+
+
+ , requires the TSF to
+ provide one or more authorised users with a capability to
+ observe the usage of resources and/or services.
+
+
+ the list of authorised users that are capable of determining
+ the occurrence of operations.
+
+
+ The observation of the use of a resource or service by a
+ user or subject.
+
+
+ The TSF shall provide
+
+
+ set of authorised users
+
+
+
+ the PP/ST author should specify the set of authorised
+ users for which the TSF must provide the capability to
+ observe the resource utilisation. A set of authorised
+ users, for example, could be a group of authorised users
+ which can operate under the same role or can all use the
+ same process(es).
+
+
+ with the capability to observe the usage of
+
+
+ list of resources and/or services
+
+
+
+ the PP/ST author should specify the set of resources
+ and/or services that the authorised user must be able
+ to observe.
+
+ .
+
+
+
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the integrity of TSF data. In some
+ sense, families in this class may appear to duplicate
+ components in the class; they may
+ even be implemented using the same mechanisms. However, focuses on user data protection, while
+ focuses on TSF data
+ protection. In fact, components from the class are necessary to provide requirements that
+ the SFPs in the TOE cannot be tampered with or
+ bypassed.
+
+ From the point of view of this class, regarding to the
+ TSF there are three significant elements:
+
+ The TSF's implementation, which executes and implements the
+ mechanisms that enforce the SFRs.
+
+ The TSF's data, which are the administrative databases that guide the
+ enforcement of the SFRs.
+
+ The external entities that the TSF may interact with in order to
+ enforce the SFRs.
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the
+ integrity of TSF data. In some sense, families in this class may
+ appear to duplicate components in the
+ class; they may even be implemented using the
+ same mechanisms. However, focuses on user
+ data protection, while focuses on TSF data
+ protection. In fact, components from the
+ class are necessary to provide requirements that the SFPs in
+ the TOE cannot be tampered with or bypassed.
+
+ From the point of view of this class, regarding to the
+ TSF there are three significant elements:
+
+ The TSF's implementation, which executes and implements the
+ mechanisms that enforce the SFRs.
+
+ The TSF's data, which are the administrative databases that guide the
+ enforcement of the SFRs.
+
+ The external entities that the TSF may interact with in order to
+ enforce the SFRs.
+
+
+ All of the families in the class can be
+ related to these areas, and fall into the following groupings:
+ , which provides an authorised user
+ with the ability to detect external attacks on the parts
+ of the TOE that comprise the TSF.
+ and ,
+ which provide an authorised user with the ability to verify the correct
+ operation of the external entities interacting with the TSF to enforce
+ the SFRs, and the integrity of the TSF data and TSF itself.
+ , , and , which address the behaviour of the TSF
+ when failure occurs and immediately after.
+ , , ,
+ which address the protection and availability of TSF data between the TSF and another trusted IT product.
+ , which addresses protection of TSF
+ data when it is transmitted between physically-separated
+ parts of the TOE.
+ , which addresses the replay of
+ various types of information and/or operations.
+ , which addresses the synchronisation
+ of states, based upon TSF data, between different parts of
+ a distributed TSF.
+ , which addresses reliable timing.
+ , which addresses the consistency of
+ TSF data shared between the TSF and another trusted IT product.
+
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TOE will always enforce
+ its SFRs in the event of identified categories of
+ failures in the TSF.
+
+
+
+ The requirements of this family ensure that the TOE will
+ always enforce its SFRs in the event of certain
+ types of failures in the TSF.
+
+
+
+
+
+ The term ``secure state'' refers to a state in which the
+ TSF data are consistent and the TSF continues correct
+ enforcement of the SFRs.
+
+ Although it is desirable to audit situations in which
+ failure with preservation of secure state occurs, it is
+ not possible in all situations. The PP/ST author should
+ specify those situations in which audit is desired and
+ feasible.
+
+ Failures in the TSF may include
+ ``hard'' failures, which indicate an
+ equipment malfunction and which may require maintenance,
+ service or repair of the TSF. Failures in the TSF may also
+ include recoverable ``soft'' failures,
+ which may only require initialisation or resetting of the
+ TSF.
+
+
+
+ This family consists of only one component, , which requires that the TSF preserve a
+ secure state in the face of the identified failures.
+
+
+ Failure of the TSF.
+
+
+ The TSF shall preserve a secure state when the following
+ types of failures occur:
+
+
+ list of types of failures in the TSF
+
+
+
+ the PP/ST author should list the types of failures in
+ the TSF for which the TSF should ``fail
+ secure,'' that is, should preserve a secure
+ state and continue to correctly enforce the SFRs.
+
+ .
+
+
+
+
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and another
+ trusted IT product. This data could, for example, be TSF
+ critical data such as passwords, keys, audit data, or TSF
+ executable code.
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and another
+ trusted IT product. This data could be TSF critical data
+ such as passwords, keys, audit data, or TSF executable code.
+
+ This family is used in a distributed context where the TSF
+ is providing TSF data to another trusted IT product. The
+ TSF can only take the measures at its site and cannot be
+ held responsible for the TSF at the other trusted IT
+ product.
+
+ If there are different availability metrics for different
+ types of TSF data, then this component should be iterated
+ for each unique pairing of metrics and types of TSF data.
+
+
+
+
+
+ This family consists of only one component, .
+ This component requires that the TSF ensure, to an identified degree of probability, the
+ availability of TSF data provided to another trusted IT product.
+
+
+ management of the list of types of TSF data that must be
+ available to another trusted IT product.
+
+
+ the absence of TSF data when required by a TOE.
+
+
+ The TSF shall ensure the availability of
+
+ list of types of TSF data
+
+ the PP/ST author should specify the types of TSF data
+ that are subject to the availability metric.
+ provided to another trusted IT product within
+
+ a defined availability metric
+
+ the PP/ST should specify the availability metric for
+ the applicable TSF data.
+ given the following conditions
+
+ conditions to ensure availability
+
+ the PP/ST author should specify the conditions under
+ which availability must be ensured. For example:
+ there must be a connection between the TOE and
+ another trusted IT product..
+
+
+
+
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data during transmission
+ between the TSF and another trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data moving between the TSF
+ and another trusted IT product. Examples of this data are
+ TSF critical data such as passwords, keys, audit data, or
+ TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is providing TSF data to another trusted IT
+ product. The TSF can only take the measures at its site and
+ cannot be held responsible for the behaviour of the other
+ trusted IT product.
+
+
+
+
+
+ Confidentiality of TSF Data during transmission is
+ necessary to protect such information from
+ disclosure. Some possible implementations that could
+ provide confidentiality include the use of cryptographic
+ algorithms as well as spread spectrum techniques.
+
+
+
+ This family consists of only one component, ,
+ which requires that the TSF ensure that data transmitted between the TSF and another trusted IT
+ product is protected from disclosure while in transit.
+
+
+ The TSF shall protect all TSF data transmitted from the TSF
+ to another trusted IT product from unauthorised disclosure
+ during transmission.
+
+
+
+
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and another trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and another trusted IT product. Examples of
+ this data are TSF critical data such as passwords, keys,
+ audit data, or TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is exchanging TSF data with another trusted IT
+ product. Note that a requirement that addresses
+ modification, detection, or recovery at another trusted
+ IT product cannot be specified, as the mechanisms that
+ another trusted IT product will use to protect its data
+ cannot be determined in advance. For this reason, these
+ requirements are expressed in terms of the ``TSF
+ providing a capability'' which another trusted
+ IT product can use.
+
+
+
+
+
+ This component should be used in situations where it is
+ sufficient to detect when data have been modified. An
+ example of such a situation is one in which another
+ trusted IT product can request the TOE's TSF to
+ retransmit data when modification has been detected, or
+ respond to such types of request.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a weak checksum
+ and parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches.
+
+
+ , provides the ability to detect
+ modification of TSF data during transmission between the
+ TSF and another trusted IT product, under the assumption
+ that another trusted IT product is cognisant of the mechanism used.
+
+
+ the detection of modification of transmitted TSF data.
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and
+ another trusted IT product within the following metric:
+
+ a defined modification metric
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection..
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and another
+ trusted IT product and perform
+
+ action to be taken
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+ if modifications are detected.
+
+
+
+
+
+
+
+ This component should be used in situations where it is
+ necessary to detect or correct modifications of TSF
+ critical data.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a checksum and
+ parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches. The metric that needs to be defined can either
+ refer to the attacks it will resist (e.g. only 1 in a 1000
+ random messages will be accepted), or to mechanisms that
+ are well known in the public literature (e.g. the strength
+ must be conformant to the strength offered by Secure Hash
+ Algorithm).
+
+ The approach taken to correct modification might be done
+ through some form of error correcting checksum.
+
+
+
+ Some possible means of satisfying this requirement
+ involves the use of cryptographic functions or some form
+ of checksum.
+
+
+ , provides the ability for
+ another trusted IT product not only to detect modification,
+ but to correct modified TSF data under the assumption that
+ another trusted IT product is cognisant of the mechanism used.
+
+
+ management of the types of TSF data that the TSF should try
+ to correct if modified in transit;
+
+
+ management of the types of action that the TSF could take if
+ TSF data is modified in transit.
+
+
+ the detection of modification of transmitted TSF data;
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ the use of the correction mechanism.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and
+ another trusted IT product within the following metric:
+
+ a defined modification metric
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection..
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and another
+ trusted IT product and perform
+
+ action to be taken
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+ if modifications are detected.
+
+
+ The TSF shall provide the capability to correct
+
+ type of modification
+
+ the PP/ST author should define the types of
+ modification from which the TSF should be capable of
+ recovering.
+ of all TSF data transmitted between the TSF and another
+ trusted IT product.
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+ The determination of the degree of separation (i.e.,
+ physical or logical) that would make application of this
+ family useful depends on the intended environment of use. In
+ a hostile environment, there may be risks arising from
+ transfers between parts of the TOE separated by only a
+ system bus or an inter-process communications channel. In
+ more benign environments, the transfers may be across more
+ traditional network media.
+
+
+
+ One practical mechanism available to a TSF to provide this
+ protection is cryptographically-based.
+
+
+
+
+
+ , requires that TSF data be
+ protected when transmitted between separate parts of the
+ TOE.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+ One of the ways to achieve separation of TSF data based on
+ SFP-relevant attributes is through the use of separate
+ logical or physical channels.
+
+
+
+ , requires that the TSF separate
+ user data from TSF data during transmission.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the separation mechanism.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+ The TSF shall separate user data from TSF data when such
+ data is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+
+
+ , requires that the TSF data
+ transmitted between separate parts of the TOE is monitored
+ for identified integrity errors.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the types of modification of TSF data the TSF
+ should try to detect;
+
+
+ management of the action>s that will be taken.
+
+
+ the detection of modification of TSF data;
+
+
+ the action taken following detection of an integrity error.
+
+
+ The TSF shall be able to detect
+
+
+ modification of data
+
+
+ substitution of data
+
+
+ re-ordering of data
+
+
+ deletion of data
+
+
+
+
+ other integrity errors
+
+
+
+ if the PP/ST author chooses the latter selection
+ noted in the preceding paragraph, then the author
+ should also specify what those other integrity
+ errors are that the TSF should be capable of
+ detecting.
+
+
+
+
+
+ the PP/ST author should specify the desired type of
+ modification that the TSF shall be able to detect. The
+ PP/ST author should select from: modification of data,
+ substitution of data, re-ordering of data, deletion of
+ data, or any other integrity errors.
+
+
+ for TSF data transmitted between separate parts of the TOE.
+
+
+ Upon detection of a data integrity error, the TSF shall take
+ the following actions:
+
+
+ specify the action to be taken
+
+
+
+ the PP/ST author should specify the action to be taken
+ when an integrity error is identified.
+
+ .
+
+
+
+
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements of components in this family ensure that
+ the TSF is protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is enforced. Without these
+ components, the protection functions of a TSF lose their
+ effectiveness in environments where physical damage cannot
+ be prevented. This family also provides requirements
+ regarding how the TSF shall respond to physical tampering
+ attempts.
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements in this family ensure that the TSF is
+ protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is measurable based on
+ defined work factors. Without these components, the
+ protection functions of a TSF lose their effectiveness in
+ environments where physical damage cannot be prevented. This
+ component also provides requirements regarding how the TSF
+ must respond to physical tampering attempts.
+
+ Examples of physical tampering scenarios include mechanical
+ attack, radiation, changing the temperature.
+
+ It is acceptable for the functions that are available to an
+ authorised user for detecting physical tampering to be
+ available only in an off-line or maintenance mode. Controls
+ should be in place to limit access during such modes to
+ authorised users. As the TSF may not be
+ ``operational'' during those modes, it
+ may not be able to provide normal enforcement for authorised
+ user access. The physical implementation of a TOE might
+ consist of several structures: for example an outer
+ shielding, cards, and chips. This set of
+ ``elements'' as a whole must protect
+ (protect, notify and resist) the TSF from physical
+ tampering. This does not mean that all devices must provide
+ these features, but the complete physical construct as a
+ whole should.
+
+ Although there is only minimal auditing associating with
+ these components, this is solely because there is the
+ potential that the detection and alarm mechanisms may be
+ implemented completely in hardware, below the level of
+ interaction with an audit subsystem (for example, a
+ hardware-based detection system based on breaking a circuit
+ and lighting a light emitting diode (LED) if the circuit is
+ broken when a button is pressed by the authorised
+ user). Nevertheless, a PP/ST author may determine that for a
+ particular anticipated threat environment, there is a need
+ to audit physical tampering. If this is the case, the PP/ST
+ author should include appropriate requirements in the list
+ of audit events. Note that inclusion of these requirements
+ may have implications on the hardware design and its
+ interface to the software.
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are not
+ countered by procedural methods. It addresses the threat of
+ undetected physical tampering with the TSF. Typically, an
+ authorised user would be given the function to verify whether
+ tampering took place. As written, this component simply provides
+ a TSF capability to detect tampering. Specification of
+ management functions in should be
+ considered to specify who can make use of that capability, and
+ how they can make use of that capability. If this is done by non-IT mechanisms
+ (e.g. physical inspection) management functions are not required.
+
+
+
+ , provides for features that
+ indicate when a TSF device or TSF element is subject to
+ tampering. However, notification of tampering is not
+ automatic; an authorised user must invoke a security
+ administrative function or perform manual inspection to
+ determining if tampering has occurred.
+
+ management of the user or role that determines whether physical
+ tampering has occurred.
+
+
+ if detection by IT means, detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether
+ physical tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+
+
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are
+ not countered by procedural methods, and it is required
+ that designated individuals be notified of physical
+ tampering. It addresses the threat that physical tampering
+ with TSF elements, although detected, may not be noticed.
+ Specification of management functions in FMT_MOF.1 Management of
+ security functions behaviour should be considered to specify who
+ can make use of that capability, and how they can make use of that capability.
+
+
+
+ , provides for automatic
+ notification of tampering for an identified subset of
+ physical penetrations.
+
+
+ management of the user or role that gets informed about
+ intrusions;
+
+
+ management of the list of devices that should inform the
+ indicated user or role about the intrusion.
+
+
+ detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether physical
+ tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+ For
+
+
+ list of TSF devices/elements for which active detection
+ is required
+
+
+
+ the PP/ST author should provide a list of TSF
+ devices/elements for which active detection of
+ physical tampering is required.
+
+ , the TSF shall monitor the devices and
+ elements and notify
+
+
+ a designated user or role
+
+
+
+ the PP/ST author should designate a user or role that
+ is to be notified when tampering is detected. The type
+ of user or role may vary depending on the particular
+ security administration component (from the family) included in the PP/ST.
+
+
+ when physical tampering with the
+ TSF's devices or TSF's elements has
+ occurred.
+
+
+
+
+
+
+ For some forms of tampering, it is necessary that the TSF
+ not only detects the tampering, but actually resists it or
+ delays the attacker.
+
+ This component should be used when TSF devices and TSF
+ elements are expected to operate in an environment where a
+ physical tampering (e.g. observation, analysis, or
+ modification) of the internals of a TSF device or TSF
+ element itself is a threat.
+
+
+
+ , provides for features that prevent
+ or resist physical tampering with TSF devices and TSF
+ elements.
+
+
+ management of the automatic responses to physical tampering.
+
+
+ The TSF shall resist
+
+
+ physical tampering scenarios
+
+
+
+ the PP/ST author should specify tampering scenarios to
+ a list of TSF devices/elements for which the TSF
+ should resist physical tampering. This list may be
+ applied to a defined subset of the TSF physical
+ devices and elements based on considerations such as
+ technology limitations and relative physical exposure
+ of the device. Such subsetting should be clearly
+ defined and justified. Furthermore, the TSF should
+ automatically respond to physical tampering. The
+ automatic response should be such that the policy of
+ the device is preserved; for example, with a
+ confidentiality policy, it would be acceptable to
+ physically disable the device so that the protected
+ information may not be retrieved.
+
+
+ to the
+
+
+ list of TSF devices/elements
+
+
+
+ the PP/ST author should specify the list of TSF
+ devices/elements for which the TSF should resist
+ physical tampering in the scenarios that have been
+ identified.
+
+
+ by responding automatically such that the SFRs are always enforced.
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started-up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+ Recovery components reconstruct the TSF secure states, or
+ prevent transitions to insecure states, as a direct response
+ to occurrences of expected failures, discontinuity of
+ operation or start-up. Failures that must be generally
+ anticipated include the following:
+
+
+ Unmaskable action failures that always result in a
+ system crash (e.g. persistent inconsistency of critical
+ system tables, uncontrolled transfers within the TSF
+ code caused by transient failures of hardware or
+ firmware, power failures, processor failures,
+ communication failures).
+
+
+ Media failures causing part or all of the media
+ representing the TSF objects to become inaccessible or
+ corrupt (e.g. parity errors, disk head crash, persistent
+ read/write failure caused by misaligned disk heads,
+ worn-out magnetic coating, dust on the disk surface).
+
+
+ Discontinuity of operation caused by erroneous
+ administrative action or lack of timely administrative
+ action (e.g. unexpected shutdowns by turning off power,
+ ignoring the exhaustion of critical resources,
+ inadequate installed configuration).
+
+
+
+ Note that recovery may be from either a complete or partial
+ failure scenario. Although a complete failure might occur in
+ a monolithic operating system, it is less likely to occur in
+ a distributed environment. In such environments, subsystems
+ may fail, but other portions remain operational. Further,
+ critical components may be redundant (disk mirroring,
+ alternative routes), and checkpoints may be available. Thus,
+ recovery is expressed in terms of recovery to a secure
+ state.
+ There are different interactions between
+ and components to be considered when
+ selecting :
+
+ The need for trusted recovery may be indicated through
+ the results of TSF self-testing, where the results of
+ the self-tests indicate that the TSF is in an insecure
+ state and return to a secure state or entrance in
+ maintenance mode is required.
+
+ A failure, as discussed above, may be identified by an
+ administrator. Either the administrator may perform
+ the actions to return the TOE to a secure state and
+ then invoke TSF self-tests to confirm that the secure
+ state has been achieved. Or, the TSF self-tests may be
+ invoked to complete the recovery process.
+
+ A combination of a. and b. above, where the need for
+ trusted recovery is indicated through the results of
+ TSF self-testing, the administrator performs the
+ actions to return the TOE to a secure state and then
+ invokes TSF self-tests to confirm that the secure
+ state has been achieved.
+
+ Self tests detect a failure/service discontinuity,
+ then either automated recovery or entrance to a
+ maintenance mode.
+
+
+ This family identifies a maintenance mode. In this
+ maintenance mode normal operation might be impossible or
+ severely restricted, as otherwise insecure situations might
+ occur. Typically, only authorised users should be allowed
+ access to this mode but the real details of who can access
+ this mode is a function of . If does not put any controls on who can access this
+ mode, then it may be acceptable to allow any user to restore
+ the system if the TOE enters such a state. However, in
+ practice, this is probably not desirable as the user
+ restoring the system has an opportunity to configure the TOE
+ in such a way as to violate the SFRs.
+
+ Mechanisms designed to detect exceptional conditions during
+ operation fall under , , and other areas that address the
+ concept of ``Software Safety.'' It is likely that the use of
+ one of these families will be required to support the adoption
+ of . This is to ensure that
+ the TOE will be able to detect when recovery is
+ required.
+
+ Throughout this family, the phrase ``secure state'' is
+ used. This refers to some state in which the TOE has
+ consistent TSF data and a TSF that can correctly enforce the
+ policy. This state may be the initial ``boot'' of a clean
+ system, or it might be some checkpointed state.
+
+ Following recovery, it may be necessary to confirm that the
+ secure state has been achieved through self-testing of the
+ TSF. However, if the recovery is performed in a manner such
+ that only a secure state can be achieved, else recovery
+ fails, then the dependency to the TSF
+ self-test component may be argued away.
+
+
+
+
+
+
+
+
+ In the hierarchy of the trusted recovery family, recovery
+ that requires only manual intervention is the least
+ desirable, for it precludes the use of the system in an
+ unattended fashion.
+
+ This component is intended for use in TOEs that do not
+ require unattended recovery to a secure state. The
+ requirements of this component reduce the threat of
+ protection compromise resulting from an attended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+
+
+ , allows a TOE to only provide
+ mechanisms that involve human intervention to return to a
+ secure state.
+
+
+ management of who can access the restore capability within
+ the maintenance mode.
+
+
+ the fact that a failure or service discontinuity occurred;
+
+
+ resumption of the regular operation;
+
+
+ type of failure or service discontinuity.
+
+
+ After
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion, any failure or discontinuity)
+ following which the TOE will enter a maintenance mode. the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, as it allows the machine to operate in an
+ unattended fashion.
+
+ The component extends the feature
+ coverage of by requiring that there
+ be at least one automated method of recovery from failure
+ or service discontinuity. It addresses the threat of
+ protection compromise resulting from an unattended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ For , it is the responsibility of
+ the developer of the TSF to determine the set of
+ recoverable failures and service discontinuities.
+
+ It is assumed that the robustness of the automated
+ recovery mechanisms will be verified.
+
+
+
+ , provides, for at least one type of
+ service discontinuity, recovery to a secure state without
+ human intervention; recovery for other discontinuities may
+ require human intervention.
+
+
+ management of who can access the restore capability within
+ the maintenance mode;
+
+
+ management of the list of failures/service discontinuities
+ that will be handled through the automatic procedures.
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode. is not possible, the TSF shall enter a
+ maintenance mode where the ability to return to a secure state
+ is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, but it runs the risk of losing a
+ substantial number of objects. Preventing undue loss of
+ objects provides additional utility to the recovery
+ effort.
+
+ The component extends the feature
+ coverage of by requiring that there
+ not be undue loss of TSF data or objects under the control
+ of the TSF. At , the automated recovery
+ mechanisms could conceivably recover by deleting all
+ objects and returning the TSF to a known secure
+ state. This type of drastic automated recovery is
+ precluded in .
+
+ This component addresses the threat of protection
+ compromise resulting from an unattended TOE returning to
+ an insecure state after recovery from a failure or other
+ discontinuity with a large loss of TSF data or objects
+ under the control of the TSF.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ It is assumed that the evaluators will verify the
+ robustness of the automated recovery mechanisms.
+
+
+
+ , also provides for automated
+ recovery, but strengthens the requirements by disallowing
+ undue loss of protected objects.
+
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode.
+ is not possible, the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+ The functions provided by the TSF to recover from failure or
+ service discontinuity shall ensure that the secure initial
+ state is restored without exceeding
+
+
+ quantification
+
+
+
+ the PP/ST author should provide a quantification for
+ the amount of loss of TSF data or objects that is
+ acceptable.
+
+
+ for loss of TSF data or objects under the control of the TSF.
+
+
+ The TSF shall provide the capability to determine the
+ objects that were or were not capable of being recovered.
+
+
+
+
+
+
+ Function recovery requires that if there should be some
+ failure in the TSF, that certain functions in the TSF should
+ either complete successfully or recover to a secure state.
+
+
+
+ , provides for recovery at the level
+ of particular functions, ensuring either successful completion
+ or rollback of TSF data to a secure state.
+
+
+ if possible, the impossibility to return to a secure state
+ after a failure of the TSF;
+
+
+ if possible, the detection of a failure of a function.
+
+
+ The TSF shall ensure that
+
+
+ list of functions and failure scenarios
+
+
+
+ the PP/ST author should specify a list the functions and
+ failure scenarios. In the event that any of the
+ identified failure scenarios happen, the functions that have
+ been specified must either complete successfully or
+ recover to a consistent and secure state.
+
+
+ have the property that the function either completes successfully,
+ or for the indicated failure scenarios, recovers to a
+ consistent and secure state.
+
+
+
+
+
+
+
+ This family addresses detection of replay for various types
+ of entities (e.g. messages, service requests, service
+ responses) and subsequent actions to correct. In the case
+ where replay may be detected, this effectively prevents it.
+
+
+
+ This family addresses detection of replay for various types
+ of entities and subsequent actions to correct.
+
+
+
+
+
+ The entities included here are, for example, messages,
+ service requests, service responses, or sessions.
+
+
+
+ The family consists of only one component, , which requires that the TSF shall be
+ able to detect the replay of identified entities.
+
+
+ management of the list of identified entities for which
+ replay shall be detected;
+
+
+ management of the list of actions that need to be taken in
+ case of replay.
+
+
+ Detected replay attacks.
+
+
+ Action to be taken based on the specific actions.
+
+
+ The TSF shall detect replay for the following entities:
+
+
+ list of identified entities
+
+
+
+ the PP/ST author should provide a list of identified
+ entities for which detection of replay should be
+ possible. Examples of such entities might include:
+ messages, service requests, service responses, and
+ user sessions.
+
+ .
+
+
+ The TSF shall perform
+
+
+ list of specific actions
+
+
+
+ the PP/ST author should specify the list of actions to
+ be taken by the TSF when replay is detected. The
+ potential set of actions that can be taken includes:
+ ignoring the replayed entity, requesting confirmation
+ of the entity from the identified source, and
+ terminating the subject from which the re-played
+ entity originated.
+
+
+ when replay is detected.
+
+
+
+
+
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use this trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases, synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use a trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+ Some states may never be synchronised, or the transaction
+ cost may be too high for practical use; encryption key
+ revocation is an example, where knowing the state after the
+ revocation action is initiated can never be known. Either
+ the action was taken and acknowledgment cannot be sent, or
+ the message was ignored by hostile communication partners
+ and the revocation never occurred. Indeterminacy is unique
+ to distributed TOEs. Indeterminacy and state synchrony
+ are related, and the same solution may apply. It is futile
+ to design for indeterminate states; the PP/ST author should
+ express other requirements in such cases (e.g. raise an
+ alarm, audit the event).
+
+
+
+
+
+
+
+
+ In this component, the TSF must supply an acknowledgement
+ to another part of the TSF when requested. This
+ acknowledgement should indicate that one part of a
+ distributed TOE successfully received an unmodified
+ transmission from a different part of the distributed TOE.
+
+
+
+ , requires only a simple
+ acknowledgment by the data recipient.
+
+
+ failure to receive an acknowledgement when expected.
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data transmission.
+
+
+
+
+
+
+
+
+
+
+ In this component, in addition to the TSF being able to
+ provide an acknowledgement for the receipt of a data
+ transmission, the TSF must comply with a request from
+ another part of the TSF for an acknowledgement to the
+ acknowledgement.
+
+ For example, the local TSF transmits some data to a remote
+ part of the TSF. The remote part of the TSF acknowledges
+ the successful receipt of the data and requests that the
+ sending TSF confirm that it receives the
+ acknowledgement. This mechanism provides additional
+ confidence that both parts of the TSF involved in the data
+ transmission know that the transmission completed
+ successfully.
+
+
+
+ , requires mutual acknowledgment of
+ the data exchange.
+
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data
+ transmission.
+
+
+ The TSF shall ensure that the relevant parts of the TSF know
+ the correct status of transmitted data among its different
+ parts, using acknowledgements.
+
+
+
+
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+ It is the responsibility of the PP/ST author to clarify the
+ meaning of the phrase ``reliable time
+ stamp'', and to indicate where the responsibility
+ lies in determining the acceptance of trust.
+
+
+
+
+
+ Some possible uses of this component include providing
+ reliable time stamps for the purposes of audit as well as
+ for security attribute expiration.
+
+
+
+ This family consists of only one component, , which requires that the TSF provide
+ reliable time stamps for TSF functions.
+
+
+ management of the time.
+
+
+ changes to the time;
+
+
+ providing a timestamp.
+
+
+ The TSF shall be able to provide reliable time stamps.
+
+
+
+
+
+
+
+ In a distributed environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and a different trusted IT product.
+
+
+
+ In a distributed or composite environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT Product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and that of a different trusted IT Product.
+
+ The components in this family are intended to provide
+ requirements for automated support for TSF data consistency
+ when such data is transmitted between the TSF of the TOE and
+ another trusted IT Product. It is also possible that wholly
+ procedural means could be used to produce security attribute
+ consistency, but they are not provided for here.
+
+ This family is different from FDP_ETC and FDP_ITC, as those
+ two families are concerned only with resolving the security
+ attributes between the TSF and its import/export medium.
+
+ If the integrity of the TSF data is of concern, requirements
+ should be chosen from the family. These
+ components specify requirements for the TSF to be able to
+ detect or detect and correct modifications to TSF data in
+ transit.
+
+
+
+
+
+ The TSF is responsible for maintaining the consistency of
+ TSF data used by or associated with the specified function
+ and that are common between two or more trusted
+ systems. For example, the TSF data of two different
+ systems may have different conventions internally. For the
+ TSF data to be used properly (e.g. to afford the user data
+ the same protection as within the TOE) by the receiving
+ trusted IT product, the TOE and the other trusted IT
+ product must use a pre-established protocol to exchange
+ TSF data.
+
+
+
+ , requires that the TSF provide the
+ capability to ensure consistency of attributes between
+ TSFs.
+
+
+ Successful use of TSF data consistency mechanisms.
+
+
+ Use of the TSF data consistency mechanisms.
+
+
+ Identification of which TSF data have been interpreted.
+
+
+ Detection of modified TSF data.
+
+
+ The TSF shall provide the capability to consistently
+ interpret
+
+
+ list of TSF data types
+
+
+
+ the PP/ST author should define the list of TSF data
+ types, for which the TSF shall provide the capability
+ to consistently interpret, when shared between the TSF
+ and another trusted IT product.
+
+
+ when shared between the TSF and another trusted IT product.
+
+
+ The TSF shall use
+
+
+ list of interpretation rules to be applied by the TSF
+
+
+
+ the PP/ST should assign the list of interpretation
+ rules to be applied by the TSF,
+
+
+ when interpreting the TSF data from another trusted IT
+ product.
+
+
+
+ This family defines requirements for the TSF to perform tests
+ on one or more external entities.
+ This component is not intended to be applied to human users.
+ External entities may include applications running on the TOE, hardware or
+ software running ``underneath'' the TOE (platforms, operating systems etc.)
+ or applications/boxes connected to the TOE (intrusion detection systems,
+ firewalls, login servers, time servers etc.).
+ This family defines requirements for the testing of one or more external
+ entities by the TSF. These external entities are not human users, and they can
+ include combinations of software and/or hardware interacting with the TOE.
+ Examples of the types of tests that may be run are:
+
+ Tests for the presence of a firewall, and possibly whether it is
+ correctly configured;
+
+ Tests of some of the properties of the operating system that an
+ application TOE runs on;
+
+ Tests of some of the properties of the IC that a smart card OS TOE
+ runs on (e.g. the random number generator).
+
+ Note that the external entity may ``lie'' about the test results, either on
+ purpose or because it is not working correctly.
+ These tests can be carried out either in some maintenance state, at start-up,
+ on-line, or continuously. The actions to be taken by the TOE as the result of
+ testing are defined also in this family.
+ The tests of external entities should be sufficient to test all of the
+ characteristics of them upon which the TSF relies.
+ This component is not intended to be applied to human users.
+ This component provides support for the periodic testing of properties
+ related to external entities upon which the TSF's operation depends, by
+ requiring the ability to periodically invoke testing functions.
+ The PP/ST author may refine the requirement to state whether the function
+ should be available in off-line, on-line or maintenance mode.
+ It is acceptable for the functions for periodic testing to be available only in
+ an off-line or maintenance mode. Controls should be in place to limit access,
+ during maintenance, to authorised users., provides for testing of the
+ external entities by the TSF.
+ management of the conditions under which the testing of external
+ entities occurs, such as during initial start-up, regular interval, or
+ under specified conditions;
+
+ management of the time interval if appropriate.
+
+ Execution of the tests of the external entities and the results of
+ the tests.
+
+ The TSF shall run a suite of tests
+
+ during initial start-up
+
+ periodically during normal operation
+
+ at the request of an authorised user
+
+ other conditions
+
+ the PP/ST author should, if other conditions are
+ selected, specify the frequency with which the testing of external entities will be run.
+ An example of this other frecuency or condition may be to run the
+ tests each time a user requests to initiate a session with the TOE. For
+ instance, this could be the case of testing a directory server before its
+ interaction with the TSF during the user authentication process.
+ the PP/ST author should specify when the TSF will
+ run the testing of external entities, during initial start-up, periodically
+ during normal operation, at the request of an authorised user, or under
+ other conditions. If the tests are run often, then the end users should
+ have more confidence that the TOE is operating correctly than if the
+ tests are run less frequently. However, this need for confidence that
+ the TOE is operating correctly must be balanced with the potential
+ impact on the availability of the TOE, as often times, the testing of external entities may
+ delay the normal operation of a TOE.
+ to check the fulfillment of
+
+ list of properties of the external entities
+
+ the PP/ST author should specify the properties of the
+ external entities to be checked by the tests. Examples of these
+ properties may include configuration or availability properties of
+ a directory server supporting some access control part of the TSF.
+ .
+
+ If the test fails, the TSF shall
+
+ action(s)
+
+ the PP/ST author should specify what are the action(s)
+ that the TSF shall perform when the testing fails. Examples of these
+ action(s), illustrated by a directory server instance, may include to
+ connect to an alternative available server or otherwise to look for a
+ backup server.
+ .
+
+
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if
+ the internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network and parts of the TOE network connections are broken,
+ this may occur when parts become disabled.
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if an
+ internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network of parts of the TOE, this can occur when parts
+ become disabled, network connections are broken, and so on.
+
+ The method of ensuring consistency is not specified in this
+ component. It could be attained through a form of
+ transaction logging (where appropriate transactions are
+ ``rolled back'' to a site upon
+ reconnection); it could be updating the replicated data
+ through a synchronisation protocol. If a particular protocol
+ is necessary for a PP/ST, it can be specified through
+ refinement.
+
+ It may be impossible to synchronise some states, or the cost
+ of such synchronisation may be too high. Examples of this
+ situation are communication channel and encryption key
+ revocations. Indeterminate states may also occur; if a
+ specific behaviour is desired, it should be specified via
+ refinement.
+
+
+
+
+
+
+
+
+ This family consists of only one component, , which requires that the TSF ensure the
+ consistency of TSF data that is replicated in multiple
+ locations.
+
+
+ restoring consistency upon reconnection.
+
+
+ Detected inconsistency between TSF data.
+
+
+ The TSF shall ensure that TSF data is consistent when
+ replicated between parts of the TOE.
+
+
+ When parts of the TOE containing replicated TSF data are
+ disconnected, the TSF shall ensure the consistency of the
+ replicated TSF data upon reconnection before processing any
+ requests for
+
+
+ list of functions dependent on TSF data replication
+ consistency
+
+
+
+ the PP/ST author should specify the list of functions
+ dependent on TSF data replication consistency.
+
+ .
+
+
+
+
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of the authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF data and TSF itself (i.e. TSF executable code or
+ TSF hardware component) by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of an authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF data and TSF itself (i.e. TSF executable code or
+ TSF hardware component) by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+ In addition, use of this component may, with appropriate
+ conditions, help to prevent inappropriate or damaging TSF
+ changes being applied to an operational TOE as the result of
+ maintenance activities.
+
+ The term ``correct operation of the TSF'' refers primarily to
+ the operation of the TSF and the integrity of the TSF data.
+
+
+
+
+
+
+ This component provides support for the testing of the
+ critical functions of the TSF's operation by
+ requiring the ability to invoke testing functions and
+ check the integrity of TSF data and executable code.
+
+
+
+ It is acceptable for the functions that are available to
+ the authorised user for periodic testing to be available
+ only in an off-line or maintenance mode. Controls should
+ be in place to limit access during these modes to
+ authorised users.
+
+
+ , provides the ability to test the
+ TSF's correct operation. These tests may be
+ performed at start-up, periodically, at the request of the
+ authorised user, or when other conditions are met. It also
+ provides the ability to verify the integrity of TSF data
+ and TSF itself.
+
+
+ management of the conditions under which TSF self testing
+ occurs, such as during initial start-up, regular interval,
+ or under specified conditions;
+
+
+ management of the time interval if appropriate.
+
+
+ Execution of the TSF self tests and the results of the
+ tests.
+
+
+ The TSF shall run a suite of self tests
+
+ during initial start-up
+
+ periodically during normal operation
+
+ at the request of the authorised user
+
+ at the conditions
+
+ conditions under which self test should occur
+
+ the PP/ST author should, if selected, specify the
+ conditions under which the self test should take
+ place.
+ the PP/ST author should specify when the TSF will execute
+ the TSF test; during initial start-up, periodically during
+ normal operation, at the request of an authorised user, at
+ other conditions. In the case of the latter option, the
+ PP/ST author should also assign what those conditions are
+ via the following assignment.
+ to demonstrate the correct operation of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of parts of the TSF that will be subject to TSF
+ self-testing.
+ the TSF
+
+ the PP/ST author should specify whether the self tests
+ are to be carried out to demonstrate the correct
+ operation of the entire TSF, or of only specified parts
+ of TSF..
+
+
+ The TSF shall provide authorised users with the capability to
+ verify the integrity of
+
+ parts of TSF data
+
+ the PP/ST author should, if selected, specify the
+ list of TSF data that will be verified for
+ integrity.
+ TSF data
+
+ the PP/ST author should specify whether data integrity
+ is to be verified for all TSF data, or only for selected
+ data..
+
+
+ The TSF shall provide authorised users with the capability to
+ verify the integrity of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of TSF that will be verified for
+ integrity.
+ TSF
+
+ the PP/ST author should specify whether TSF integrity
+ is to be verified for all TSF, or only for selected
+ TSF..
+
+
+
+
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks, and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+
+
+ The requirements of this family ensure that the TOE will
+ maintain correct operation even in the event of failures.
+
+
+
+ This family provides requirements for the availability of
+ capabilities even in the case of failures. Examples of such
+ failures are power failure, hardware failure, or software
+ error. In case of these errors, if so specified, the TOE
+ will maintain the specified capabilities. The PP/ST author
+ could specify, for example, that a TOE used in a nuclear
+ plant will continue the operation of the shut-down procedure
+ in the case of power-failure or communication-failure.
+
+ Because the TOE can only continue its correct operation if
+ the SFRs are enforced, there is a requirement that the system
+ must remain in a secure state after a failure. This
+ capability is provided by .
+
+ The mechanisms to provide fault tolerance could be active or
+ passive. In case of an active mechanism, specific functions
+ are in place that are activated in case the error
+ occurs. For example, a fire alarm is an active mechanism:
+ the TSF will detect the fire and can take action such as
+ switching operation to a backup. In a passive scheme, the
+ architecture of the TOE is capable of handling the
+ error. For example, the use of a majority voting scheme with
+ multiple processors is a passive solution; failure of one
+ processor will not disrupt the operation of the TOE
+ (although it needs to be detected to allow correction).
+
+ For this family, it does not matter whether the failure has
+ been initiated accidentally (such as flooding or unplugging
+ the wrong device) or intentionally (such as monopolising).
+
+
+
+
+
+
+
+
+ This component is intended to specify which capabilities
+ the TOE will still provide after a failure of the
+ system. Since it would be difficult to describe all
+ specific failures, categories of failures may be
+ specified. Examples of general failures are flooding of
+ the computer room, short term power interruption,
+ breakdown of a CPU or host, software failure, or buffer
+ overflow.
+
+
+
+ , requires the TOE to continue
+ correct operation of identified capabilities in the event
+ of identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ All TOE capabilities being discontinued due to a failure.
+
+
+ The TSF shall ensure the operation of
+
+
+ list of TOE capabilities
+
+
+
+ the PP/ST author should specify the list of TOE
+ capabilities the TOE will maintain during and after a
+ specified failure.
+
+
+ when the following failures occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component is intended to specify against what type of
+ failures the TOE must be resistant. Since it would be
+ difficult to describe all specific failures, categories of
+ failures may be specified. Examples of general failures
+ are flooding of the computer room, short term power
+ interruption, breakdown of a CPU or host, software
+ failure, or overflow of buffer.
+
+
+
+ , requires the TOE to continue
+ correct operation of all capabilities in the event of
+ identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ The TSF shall ensure the operation of all the
+ TOE's capabilities when the following failures
+ occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without undue interference or delay caused by
+ low priority activities.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without interference or delay due to low
+ priority activities. In other words, time critical tasks
+ will not be delayed by tasks that are less time critical.
+
+ This family could be applicable to several types of
+ resources, for example, processing capacity, and
+ communication channel capacity.
+
+ The Priority of Service mechanism might be passive or
+ active. In a passive Priority of Service system, the system
+ will select the task with the highest priority when given a
+ choice between two waiting applications. While using passive
+ Priority of Service mechanisms, when a low priority task is
+ running, it cannot be interrupted by a high priority
+ task. While using an active Priority of Service mechanisms,
+ lower priority tasks might be interrupted by new high
+ priority tasks.
+
+ The audit requirement states that all reasons for rejection
+ should be audited. It is left to the developer to argue that
+ an operation is not rejected but delayed.
+
+
+
+
+
+ This component defines priorities for a subject, and the
+ resources for which this priority will be used. If a
+ subject attempts to take action on a resource controlled
+ by the Priority of Service requirements, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of a subset of the resources
+ under the control of the TSF.
+
+
+ assignment of priorities to each subject in the TSF.
+
+
+ Rejection of operation based on the use of priority within
+ an allocation.
+
+
+ All attempted uses of the allocation function which involves
+ the priority of the service functions.
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which the TSF enforces priority of service
+ (e.g. resources such as processes, disk space, memory,
+ bandwidth).
+
+
+ shall be mediated on the basis of the subjects assigned
+ priority.
+
+
+
+
+
+
+
+ This component defines priorities for a subject. All
+ shareable resources under the control of the TSF will be subjected to the
+ Priority of Service mechanism. If a subject attempts to
+ take action on a shareable TSF resource, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of all of the resources under the control of the TSF.
+
+
+
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to all shareable
+ resources shall be mediated on the basis of the subjects
+ assigned priority.
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources by users and subjects such that denial of
+ service will not occur because of unauthorised
+ monopolisation of resources.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that unauthorised denial of service will not take place by
+ means of monopolisation of resources by other users or
+ subjects.
+
+ Resource allocation rules allow the creation of quotas or
+ other means of defining limits on the amount of resource
+ space or time that may be allocated on behalf of a specific
+ user or subjects. These rules may, for example:
+
+
+ Provide for object quotas that constrain the number
+ and/or size of objects a specific user may allocate.
+
+
+ Control the allocation/deallocation of preassigned
+ resource units where these units are under the control
+ of the TSF.
+
+
+
+ In general, these functions will be implemented through the
+ use of attributes assigned to users and resources.
+
+ The objective of these components is to ensure a certain
+ amount of fairness among the users (e.g. a single user
+ should not allocate all the available space) and
+ subjects. Since resource allocation often goes beyond the
+ lifespan of a subject (i.e. files often exist longer than
+ the applications that generated them), and multiple
+ instantiations of subjects by the same user should not
+ negatively affect other users too much, the components allow
+ that the allocation limits are related to the users. In some
+ situations the resources are allocated by a subject
+ (e.g. main memory or CPU cycles). In those instances the
+ components allow that the resource allocation be on the
+ level of subjects.
+
+ This family imposes requirements on resource allocation, not
+ on the use of the resource itself. The audit requirements
+ therefore, as stated, also apply to the allocation of the
+ resource, not to the use of the resource.
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to only a specified set of the shareable
+ resources in the TOE. The requirements allow the quotas to
+ be associated with a user, possibly assigned to groups of
+ users or subjects as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will not
+ monopolise a controlled resource.
+
+
+ specifying maximum limits for a resource for groups and/or
+ individual users and/or subjects by an administrator.
+
+
+ Rejection of allocation operation due to resource limits.
+
+
+ All attempted uses of the resource allocation functions for
+ resources that are under control of the TSF.
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources:
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which maximum resource allocation limits
+ are required (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to a specified set of the shareable resources
+ in the TOE. The requirements allow the quotas to be
+ associated with a user, or possibly assigned to groups of
+ users as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will always
+ have at least a minimum of a specified resource and that
+ they will not be able to monopolise a controlled resource.
+
+
+ specifying minimum and maximum limits for a resource for
+ groups and/or individual users and/or subjects by an
+ administrator.
+
+
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which maximum and minimum resource
+ allocation limits are required (e.g. processes, disk
+ space, memory, bandwidth). If all resources under the control of the TSF
+ need to be included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+ The TSF shall ensure the provision of minimum quantity of
+ each
+
+
+ controlled resource
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which a minimum allocation limit needs
+ to be set (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included the words ``all TSF resources''
+ can be specified.
+
+
+ that is available for
+
+
+ an individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ to use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This family specifies functional requirements for controlling
+ the establishment of a user's session.
+
+
+
+ The establishment of a user's session typically
+ consists of the creation of one or more subjects that perform
+ operations in the TOE on behalf of the user. At the end of the
+ session establishment procedure, provided the TOE access
+ requirements are satisfied, the created subjects bear the
+ attributes determined by the identification and authentication
+ functions. This family specifies functional requirements for
+ controlling the establishment of a user's session.
+
+ A user session is defined as the period starting at the time
+ of the identification/authentication, or if more appropriate,
+ the start of an interaction between the user and the system,
+ up to the moment that all subjects (resources and attributes)
+ related to that session have been deallocated.
+
+
+
+
+
+ This family defines requirements to limit the scope of
+ session security attributes that a user may select for a
+ session.
+
+
+
+ This family defines requirements that will limit the session
+ security attributes a user may select, and the subjects to
+ which a user may be bound, based on: the method of access;
+ the location or port of access; and/or the time
+ (e.g. time-of-day, day-of-week).
+
+ This family provides the capability for a PP/ST author to
+ specify requirements for the TSF to place limits on the
+ domain of an authorised user's security attributes
+ based on an environmental condition. For example, a user may
+ be allowed to establish a ``secret session''
+ during normal business hours but outside those hours the
+ same user may be constrained to only establishing
+ ``unclassified sessions''. The identification of
+ relevant constraints on the domain of selectable attributes
+ can be achieved through the use of the selection
+ operation. These constraints can be applied on an
+ attribute-by-attribute basis. When there exists a need to
+ specify constraints on multiple attributes this component
+ will have to be replicated for each attribute. Examples of
+ attributes that could be used to limit the session security
+ attributes are:
+
+
+ The method of access can be used to specify in which
+ type of environment the user will be operating
+ (e.g. file transfer protocol, terminal, vtam).
+
+
+ The location of access can be used to constrain the
+ domain of a user's selectable attributes based
+ on a user's location or port of access. This
+ capability is of particular use in environments where
+ dial-up facilities or network facilities are available.
+
+
+ The time of access can be used to constrain the domain
+ of a user's selectable attributes. For example,
+ ranges may be based upon time-of-day, day-of-week, or
+ calendar dates. This constraint provides some
+ operational protection against user actions that could
+ occur at a time where proper monitoring or where proper
+ procedural measures may not be in place.
+
+
+
+
+
+
+
+ , provides the requirement for a TOE
+ to limit the scope of the session security attributes
+ during session establishment.
+
+
+ management of the scope of the session security attributes
+ by an administrator.
+
+
+ All failed attempts at selecting a session security
+ attributes;
+
+
+ All attempts at selecting a session security attributes;
+
+
+ Capture of the values of each session security attributes.
+
+
+ The TSF shall restrict the scope of the session security
+ attributes
+
+
+ session security attributes
+
+
+
+ the PP/ST author should specify the set of session
+ security attributes that are to be
+ constrained. Examples of these session security
+ attributes are user clearance level, integrity level
+ and roles.
+
+ , based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the set of attributes
+ that can be use to determine the scope of the session
+ security attributes. Examples of such attributes are
+ user identity, originating location, time of access,
+ and method of access.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements to place limits on the
+ number of concurrent sessions that belong to the same user.
+
+
+
+ This family defines how many sessions a user may have at the
+ same time (concurrent sessions). This number of concurrent
+ sessions can either be set for a group of users or for each
+ individual user.
+
+
+
+
+
+
+
+
+ This component allows the system to limit the number of
+ sessions in order to effectively use the resources of the
+ TOE.
+
+
+
+ , provides limitations that apply to
+ all users of the TSF.
+
+
+ management of the maximum allowed number of concurrent user
+ sessions by an administrator.
+
+
+ Rejection of a new session based on the limitation of
+ multiple concurrent sessions.
+
+
+ Capture of the number of currently concurrent user sessions
+ and the user security attribute(s).
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user.
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+
+
+
+ This component provides additional capabilities over those
+ of , by allowing further constraints
+ to be placed on the number of concurrent sessions that
+ users are able to invoke. These constraints are in terms
+ of a user's security attributes, such as a
+ user's identity, or membership of a role.
+
+
+
+ extends by
+ requiring the ability to specify limitations on the number
+ of concurrent sessions based on the related security
+ attributes.
+
+
+ management of the rules that govern the maximum allowed
+ number of concurrent user sessions by an administrator.
+
+
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user according to the rules
+
+
+ rules for the number of maximum concurrent sessions
+
+
+
+ the PP/ST author should specify the rules that
+ determine the maximum number of concurrent
+ sessions. An example of a rule is ``maximum
+ number of concurrent sessions is one if the user has a
+ classification level of ``secret''
+ and five otherwise''.
+
+ .
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to provide the
+ capability for TSF-initiated and user-initiated locking,
+ unlocking, and termination of interactive sessions.
+
+
+ This family defines requirements for the TSF to provide the
+ capability for TSF-initiated and user-initiated locking,
+ unlocking, and termination of interactive sessions.
+ When a user is directly interacting with subjects in the TOE
+ (interactive session), the user's terminal is vulnerable if
+ left unattended. This family provides requirements for the TSF
+ to disable (lock) the terminal or terminate the session after
+ a specified period of inactivity, and for the user to initiate
+ the disabling (locking) of the terminal or terminate the
+ session. To reactivate the terminal, an event specified by the
+ PP/ST author, such as the user re-authentication must
+ occur.
+ A user is considered inactive, if he/she has not provided any
+ stimulus to the TOE for a specified period of time.
+ A PP/ST author should consider whether
+ should be included. In that case, the function ``session
+ locking'' should be included in the operation in .
+
+
+
+
+
+
+
+ , provides the capability for the
+ TSF to lock an active user session after a specified
+ period of time. Locking a terminal would prevent any
+ further interaction with an existing active session
+ through the use of the locked terminal.
+
+ If display devices are overwritten, the replacement
+ contents need not be static (i.e. ``screen
+ savers'' are permitted).
+
+ This component allows the PP/ST author to specify what
+ events will unlock the session. These events may be
+ related to the terminal (e.g. fixed set of keystrokes to
+ unlock the session), the user (e.g. reauthentication), or
+ time.
+
+
+
+ includes system initiated locking
+ of an interactive session after a specified period of user
+ inactivity.
+
+
+ specification of the time of user inactivity after which
+ lock-out occurs for an individual user;
+
+
+ specification of the default time of user inactivity after
+ which lock-out occurs;
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+ Locking of an interactive session by the session locking
+ mechanism.
+
+
+ Successful unlocking of an interactive session.
+
+
+ Any attempts at unlocking an interactive session.
+
+
+ The TSF shall lock an interactive session after
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the locking of an
+ interactive session. If so desired the PP/ST author
+ could, through the assignment, specify that the time
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+
+ by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'' or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+
+
+ , provides the capability for
+ an authorised user to lock and unlock his/her own interactive
+ session. This would provide authorised users with the ability to
+ effectively block further use of their active sessions without
+ having to terminate the active session.
+
+ If devices are overwritten, the replacement contents need
+ not be static (i.e. ``screen savers''
+ are permitted).
+
+
+
+ , provides capabilities for the user
+ to lock and unlock the user's own interactive
+ sessions.
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+
+
+ The TSF shall allow user-initiated locking of the
+ user's own interactive session, by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'', or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+ , requires that the TSF terminate an
+ interactive user session after a period of inactivity.
+
+ The PP/ST author should be aware that a session may
+ continue after the user terminated his/her activity, for
+ example, background processing. This requirement would
+ terminate this background subject after a period of
+ inactivity of the user without regard to the status of the
+ subject.
+
+
+ , provides requirements for
+ the TSF to terminate the session after a specified period of
+ user inactivity.
+
+
+ specification of the time of user inactivity after which
+ termination of the interactive session occurs for an
+ individual user;
+
+
+ specification of the default time of user inactivity after
+ which termination of the interactive session occurs.
+
+
+ Termination of an interactive session by the session locking
+ mechanism.
+
+
+ The TSF shall terminate an interactive session after a
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the termination of an
+ interactive session. If so desired, the PP/ST author
+ could, through the assignment, specify that the
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+ .
+
+ , provides the capability for an
+ authorised user to terminate his/her interactive
+ session..
+ The PP/ST author should be aware that a session may continue
+ after the user terminated his/her activity, for example,
+ background processing. This requirement would allow the user
+ to terminate this background subject without regard to the
+ status of the subject., provides capabilities for the user
+ to terminate the user's own interactive sessions.
+ Termination of an interactive session by the user.
+
+ The TSF shall allow user-initiated termination of the user's own
+ interactive session.
+
+
+
+
+
+
+ This family defines requirements to display a configurable
+ advisory warning message to users regarding the appropriate
+ use of the TOE.
+
+
+
+ Prior to identification and authentication, TOE access
+ requirements provide the ability for the TOE to display an
+ advisory warning message to potential users pertaining to
+ appropriate use of the TOE.
+
+
+
+
+
+ This component requires that there is an advisory warning
+ regarding the unauthorised use of the TOE. A PP/ST author
+ could refine the requirement to include a default banner.
+
+
+
+ , provides the requirement for a TOE
+ Access Banner. This banner is displayed prior to the
+ establishment dialogue for a session.
+
+
+ maintenance of the banner by the authorised administrator.
+
+
+ Before establishing a user session, the TSF shall display an
+ advisory warning message regarding unauthorised use of the
+ TOE.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to display to a
+ user, upon successful session establishment, a history of
+ successful and unsuccessful attempts to access the
+ user's account.
+
+
+
+ This family defines requirements for the TSF to display to
+ users, upon successful session establishment to the TOE, a
+ history of unsuccessful attempts to access the account. This
+ history may include the date, time, means of access, and
+ port of the last successful access to the TOE, as well as
+ the number of unsuccessful attempts to access the TOE since
+ the last successful access by the identified user.
+
+
+
+
+
+
+ This family can provide authorised users with information
+ that may indicate the possible misuse of their user
+ account.
+
+ This component request that the user is presented with the
+ information. The user should be able to review the
+ information, but is not forced to do so. If a user so
+ desires he might, for example, create scripts that ignore
+ this information and start other processes.
+
+
+
+ , provides the requirement for a TOE
+ to display information related to previous attempts to
+ establish a session.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last successful session establishment that will
+ be shown at the user interface. The items are: date,
+ time, method of access (such as ftp), and/or location
+ (e.g. terminal 50).
+
+
+ of the last successful session establishment to the user.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last unsuccessful session establishment that
+ will be shown at the user interface. The items are:
+ date, time, method of access (such as ftp), and/or
+ location (e.g. terminal 50).
+
+
+ of the last unsuccessful attempt to session establishment
+ and the number of unsuccessful attempts since the last
+ successful session establishment.
+
+
+ The TSF shall not erase the access history information from
+ the user interface without giving the user an opportunity to
+ review the information.
+
+
+
+
+
+
+ This family defines requirements to deny a user permission
+ to establish a session with the TOE.
+
+
+
+ This family defines requirements to deny an user permission
+ to establish a session with the TOE based on attributes such
+ as the location or port of access, the user's security
+ attribute (e.g. identity, clearance level, integrity level,
+ membership in a role), ranges of time (e.g. time-of-day,
+ day-of-week, calendar dates) or combinations of parameters.
+
+ This family provides the capability for the PP/ST author to
+ specify requirements for the TOE to place constraints on the
+ ability of an authorised user to establish a session with
+ the TOE. The identification of relevant constraints can be
+ achieved through the use of the selection
+ operation. Examples of attributes that could be used to
+ specify the session establishment constraints are:
+
+
+ The location of access can be used to constrain the
+ ability of a user to establish an active session with
+ the TOE, based on the user's location or port
+ of access. This capability is of particular use in
+ environments where dial-up facilities or network
+ facilities are available.
+
+
+ The user's security attributes can be used to
+ place constraints on the ability of a user to establish
+ an active session with the TOE. For example, these
+ attributes would provide the capability to deny session
+ establishment based on any of the following:
+
+
+ a user's identity;
+
+
+ a user's clearance level;
+
+
+ a user's integrity level; and
+
+
+ a user's membership in a role.
+
+
+
+
+
+ This capability is particularly relevant in situations where
+ authorisation or login may take place at a different
+ location from where TOE access checks are performed.
+
+
+ The time of access can be used to constrain the ability
+ of a user to establish an active session with the TOE
+ based on ranges of time. For example, ranges may be
+ based upon time-of-day, day-of-week, or calendar
+ dates. This constraint provides some operational
+ protection against actions that could occur at a time
+ where proper monitoring or where proper procedural
+ measures may not be in place.
+
+
+
+
+
+
+
+ , provides requirements for denying
+ users access to the TOE based on attributes.
+
+
+ management of the session establishment conditions by the
+ authorised administrator.
+
+
+ Denial of a session establishment due to the session
+ establishment mechanism.
+
+
+ All attempts at establishment of a user session.
+
+
+ Capture of the value of the selected access parameters
+ (e.g. location of access, time of access).
+
+
+ The TSF shall be able to deny session establishment based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the attributes that
+ can be used to restrict the session
+ establishment. Example of possible attributes are user
+ identity, originating location (e.g. no remote
+ terminals), time of access (e.g. outside hours), or
+ method of access (e.g. X-windows).
+
+ .
+
+
+
+
+
+
+
+ Families in this class provide requirements for a trusted
+ communication path between users and the TSF, and for a
+ trusted communication channel between the TSF and other
+ trusted IT products. Trusted paths and channels have the
+ following general characteristics:
+
+
+ The communications path is constructed using internal and
+ external communications channels (as appropriate for the
+ component) that isolate an identified subset of TSF data
+ and commands from the remainder of the TSF and user data.
+
+
+ Use of the communications path may be initiated by the
+ user and/or the TSF (as appropriate for the component).
+
+
+ The communications path is capable of providing assurance
+ that the user is communicating with the correct TSF, and
+ that the TSF is communicating with the correct user (as
+ appropriate for the component).
+
+
+
+ In this paradigm, a trusted channel is a communication channel
+ that may be initiated by either side of the channel, and
+ provides non-repudiation characteristics with respect to the
+ identity of the sides of the channel.
+
+ A trusted path provides a means for users to perform functions
+ through an assured direct interaction with the TSF. Trusted
+ path is usually desired for user actions such as initial
+ identification and/or authentication, but may also be desired
+ at other times during a user's session. Trusted
+ path exchanges may be initiated by a user or the TSF. User
+ responses via the trusted path are guaranteed to be protected
+ from modification by or disclosure to untrusted applications.
+
+
+
+ Users often need to perform functions through direct
+ interaction with the TSF. A trusted path provides confidence
+ that a user is communicating directly with the TSF whenever it
+ is invoked. A user's response via the trusted path
+ guarantees that untrusted applications cannot intercept or
+ modify the user's response. Similarly, trusted
+ channels are one approach for secure communication between the
+ TSF and another trusted IT product.
+
+ Absence of a trusted path may allow breaches of accountability
+ or access control in environments where untrusted applications
+ are used. These applications can intercept user-private
+ information, such as passwords, and use it to impersonate
+ other users. As a consequence, responsibility for any system
+ actions cannot be reliably assigned to an accountable
+ entity. Also, these applications could output erroneous
+ information on an unsuspecting user's display,
+ resulting in subsequent user actions that may be erroneous and
+ may lead to a security breach.
+
+
+
+
+
+ This family defines requirements for the creation of a
+ trusted channel between the TSF and other trusted IT
+ products for the performance of security critical
+ operations. This family should be included whenever there
+ are requirements for the secure communication of user or TSF
+ data between the TOE and other trusted IT products.
+
+
+
+ This family defines the rules for the creation of a trusted
+ channel connection that goes between the TSF and another
+ trusted IT product for the performance of security critical
+ operations between the products. An example of such a
+ security critical operation is the updating of the TSF
+ authentication database by the transfer of data from a
+ trusted product whose function is the collection of audit
+ data.
+
+
+
+
+
+ This component should be used when a trusted communication
+ channel between the TSF and another trusted IT product is
+ required.
+
+
+
+ , requires that the TSF provide a
+ trusted communication channel between itself and another
+ trusted IT product.
+
+
+ Configuring the actions that require trusted channel, if
+ supported.
+
+
+ Failure of the trusted channel functions.
+
+
+ Identification of the initiator and target of failed trusted
+ channel functions.
+
+
+ All attempted uses of the trusted channel functions.
+
+
+ Identification of the initiator and target of all trusted
+ channel functions.
+
+
+ The TSF shall provide a communication channel between itself
+ and another trusted IT product that is logically distinct
+ from other communication channels and provides assured
+ identification of its end points and protection of the
+ channel data from modification or disclosure.
+
+
+ The TSF shall permit
+
+ the TSF
+
+ another trusted IT product
+
+ the PP/ST author must specify whether the local TSF,
+ another trusted IT product, or both shall have the
+ capability to initiate the trusted channel.
+ to initiate communication via the trusted channel.
+
+
+ The TSF shall initiate communication via the trusted channel
+ for
+
+
+ list of functions for which a trusted channel is
+ required
+
+
+
+ the PP/ST author should specify the functions for
+ which a trusted channel is required. Examples of these
+ functions may include transfer of user, subject,
+ and/or object security attributes and ensuring
+ consistency of TSF data.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+
+
+ This component should be used when trusted communication
+ between a user and the TSF is required, either for initial
+ authentication purposes only or for additional specified
+ user operations.
+
+
+
+ , requires that a trusted path
+ between the TSF and a user be provided for a set of events
+ defined by a PP/ST author. The user and/or the TSF may
+ have the ability to initiate the trusted path.
+
+
+ Configuring the actions that require trusted path, if
+ supported.
+
+
+ Failures of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ failures, if available.
+
+
+ All attempted uses of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ invocations, if available.
+
+
+ The TSF shall provide a communication path between itself and
+
+ remote
+
+ local
+
+ the PP/ST author should specify whether the trusted path
+ must be extended to remote and/or local users.
+ users that is logically distinct from other communication
+ paths and provides assured identification of its end points
+ and protection of the communicated data from
+
+ modification
+
+ disclosure
+
+ other types of integrity or confidentiality violation
+
+ if selected, the PP/ST author should identify any
+ additional types of integrity or confidentiality
+ violation against which the trusted path shall protect
+ the data.
+ the PP/ST author should specify whether the trusted path
+ shall protect the data from modification, disclosure,
+ and/or other types of integrity or confidentiality
+ violation..
+
+
+ The TSF shall permit
+
+
+ the TSF
+
+
+ local users
+
+
+ remote users
+
+
+
+ the PP/ST author should specify whether the TSF, local
+ users, and/or remote users should be able to initiate
+ the trusted path.
+
+
+ to initiate communication via the trusted path.
+
+
+ The TSF shall require the use of the trusted path for
+
+
+ initial user authentication
+
+
+
+
+ other services for which trusted path is required
+
+
+
+ if selected, the PP/ST author should identify
+ other services for which trusted path is required,
+ if any.
+
+
+
+
+
+ the PP/ST author should specify whether the trusted
+ path is to be used for initial user authentication
+ and/or for other specified services.
+
+ .
+
+
+
+
+
+
+
+ The class encompasses five
+ families. These families specify assurance requirements that
+ are designed to provide confidence that a composed TOE will
+ operate securely when relying upon security functionality
+ provided by previously evaluated software, firmware or
+ hardware components.
+
+ Composition involves taking two or more IT entities
+ successfully evaluated against CC security assurance
+ requirements packages (base components and dependent
+ components, see ) and
+ combining them for use, with no further development of either
+ IT entity. The development of additional IT entities is not
+ included (entities that have not previously been the subject
+ of a component evaluation). The composed TOE forms a new
+ product that can be installed and integrated into any specific
+ environment instance that meets the objectives for the
+ environment.
+
+ This approach does not provide an alternative approach for the
+ evaluation of components. Composition under provides a composed TOE integrator a method, which
+ can be used as an alternative to other assurance levels
+ specified in the CC, to gain confidence in a TOE that is the
+ combination of two or more successfully evaluated components
+ without having to re-evaluate the composite TSF. (The composed
+ TOE integrator is referred to as ``developer'' throughout the
+ class, with any references to the
+ developer of the base or dependent components clarified as
+ such.)
+
+ Composed Assurance Packages, as defined in Clauses and , is an
+ assurance scale for composed TOEs. This assurance scale is
+ required in addition to EALs because to combine components
+ evaluated against EALs and gain a resulting EAL assurance, all
+ SARs in the EAL have to be applied to the composed
+ TOE. Although reuse can be made of the component TOE
+ evaluation results, there are often additional aspects of the
+ components that have to be considered in the composed TOE, as
+ described in Annex . Due to the different parties involved in a
+ composed TOE evaluation activity it is generally not possible
+ to gain all necessary evidence about these additional aspects
+ of the components to apply the appropriate EAL. Hence, CAPs
+ have been defined to address the issue of combining evaluated
+ components and gaining a meaningful result. This is discussed
+ further in .
+
+
+
+
+ In a composed TOE it is generally the case that one component
+ relies on the services provided by another component. The
+ component requiring services is termed the dependent component
+ and the component providing the services is termed the base
+ component. This interaction and distinct is discussed further
+ in Annex B. It is assumed to be the case that the developer of
+ the dependent component is supporting the composed TOE
+ evaluation in some manner (as developer, sponsor, or just
+ cooperating and providing the necessary evaluation evidence
+ from the dependent component evaluation) The components included in the CAP assurance packages
+ should not be used as augmentations for component TOE
+ evaluations, as this would provide no meaningful assurance for
+ the component.
+
+ The families within the class
+ interact in a similar manner to the , and classes in a component TOE evaluation and hence
+ leverage from the specification of requirements from those
+ classes where applicable. There are however a few items
+ specific to composed TOE evaluations. To determine how the
+ components interact and identify any deviations from the
+ evaluations of the components, the dependencies that the
+ dependent component has upon the underlying base component are
+ identified (). This reliance on
+ the base component is specified in terms of the interfaces
+ through which the dependent component makes calls for services
+ in support of the dependent component SFRs. The interfaces,
+ and at higher levels the supporting behaviour, provided by the
+ base component in response to those service requests are
+ analysed in . The family is based on the family, as at the simplest level the
+ TSF of each component can be viewed as a subsystem of the
+ composed TOE, with additional portions of each component seen
+ as additional subsystems. Therefore, the interfaces between
+ the components are seen as interactions between subsystems in
+ a component TOE evaluation.
+
+ It is possible that the interfaces and supporting behaviour
+ descriptions provided for are
+ incomplete. This is determined during the conduct of . The
+ family takes the outputs of and
+ and determines whether the
+ components are being used in their evaluated configuration and
+ identifies where any specifications are incomplete, which are
+ then identified as inputs into testing () and vulnerability analysis () activities of the composed TOE.
+
+ Testing of the composed TOE is performed to determine that the
+ composed TOE exhibits the expected behaviour as determined by
+ the composed TOE SFRs, and at higher levels demonstrates the
+ compatibility of the interfaces between the components of the
+ composed TOE.
+
+ The vulnerability analysis of the composed TOE leverages from
+ the outputs of the vulnerability analysis of the component
+ evaluations. The composed TOE vulnerability analysis considers
+ any residual vulnerabilities from the component evaluations to
+ determine that the residual vulnerabilities are not applicable
+ to the composed TOE. A search of publicly available
+ information relating to the components is also performed to
+ identify any issues reported in the components since the
+ completion of the respective evaluations.
+
+ The interaction between the
+ families is depicted in Figure below. This shows by solid arrowed lines where
+ the evidence and understanding gained in one family feeds into
+ the next activity and the dashed arrows identify where an
+ activity explicitly traces back to the composed TOE SFRs, as
+ described above.
+
+
+
+
+ Further discussion of the definition and interactions within
+ composed TOEs is provided in .
+
+
+
+ Assurance class defines
+ requirements of the information necessary to ensure that two
+ or more components, which have themselves been the subject of
+ a CC evaluation, can be integrated in a secure manner.
+
+ The assurance requirements will
+ be applied to the composed TOE to:
+
+
+ determine that the required assurance is provided by the
+ base component;
+
+ determine that the base component and dependent component
+ are compatible; and
+
+ search for any vulnerabilities introduced through
+ composing the base and dependent components into a single
+ composed TOE entity.
+
+
+
+ The goal of this activity is to determine whether the
+ components can be integrated in a secure manner, as defined in
+ the ST for the composed TOE. This is achieved through
+ examination and testing of the interfaces between the
+ components, supported by examination of the design of the
+ components and the conduct of vulnerability analysis.
+
+
+
+ The family identifies where
+ the dependent component is reliant upon IT in its operational
+ environment (satisfied by a base component in the composed TOE
+ evaluation) in order to provide its own security
+ services. This reliance is identified in terms of the
+ interfaces expected by the dependent component to be provided
+ by the base component. then
+ determines which interfaces of the base component were
+ considered (as TSFI) during the component evaluation of the
+ base component.
+
+ It should be noted that does
+ not cover other evidence that may be needed to address the
+ technical integration problem of composing components
+ (e.g. descriptions of non-TSF interfaces of the operating
+ system, rules for integration, etc.). This is outside the
+ security assessment of the composition and is a functional
+ composition issue.
+
+ As part of the evaluator will
+ perform testing of the composed TOE SFRs at the composed TOE
+ interfaces and of the interfaces of the base component relied
+ upon by the dependent component to confirm they operate as
+ specified. The subset selected will consider the possible
+ effects of changes to the configuration/use of the base
+ component as used in the composed TOE. These changes are
+ identified from the configuration of the base component
+ determined during the base component evaluation. The developer
+ will provide test evidence for each of the base component
+ interfaces (the requirements for coverage are consistent with
+ those applied to the evaluation of the base component).
+
+ requires the evaluator to
+ determine whether the appropriate assurance measures have been
+ applied to the base component, and whether the base component
+ is being used in its evaluated configuration. This includes
+ determination of whether all security functionality required
+ by the dependent component was within the TSF of the base
+ component. The requirement
+ may be met through the production of evidence that each of
+ these is demonstrated to be upheld. This evidence may be in
+ the form of the security target and a public report of the
+ component evaluation (e.g. certification report).
+
+ If, on the other hand, one of the above have not been upheld,
+ then it may be possible that an argument can be made as to why
+ the assurance gained during an original evaluation is
+ unaffected. If this is not possible then additional evaluation
+ evidence for those aspects of the base component not covered
+ may have to be provided. This material is then assessed in
+ .
+
+ For example, it may be the case as described in the
+ Interactions between entities (see Annex in CC Part 3) that the
+ dependent component requires the base component to provide
+ more security functionality in the composed TOE than included
+ in the base component evaluation. This would be determined
+ during the application of the
+ and families. In this case
+ the composition rationale evidence provided for would demonstrate that the
+ assurance gained from the base component evaluation is
+ unaffected. This may be achieved by means including:
+
+
+ Performing a re-evaluation of the base component focusing
+ on the evidence relating to the extended part of the
+ TSF;
+
+ Demonstrating that the extended part of the TSF cannot
+ affect other portions of the TSF, and providing evidence
+ that the extended part of the TSF provides the necessary
+ security functionality.
+
+
+
+
+ This family addresses the requirement to demonstrate that
+ the base component can provide an appropriate level of
+ assurance for use in composition.
+
+
+
+ The family is used to
+ determine whether or not the appropriate assurance measures
+ have been applied to the base component for successful
+ integration in the composed TOE. That is, the SARs claimed
+ by the base component are consistent with the SARs in the
+ assurance package for the composed TOE. (e.g. if the
+ assurance package for the composed TOE included , a base component that was
+ evaluated against would
+ not have had the appropriate assurance measures applied, as
+ insufficient design evidence would have been
+ examined.)
+
+ The family calls for
+ evidence that the appropriate assurance is provided, without
+ being specific about how this is achieved. If the
+ appropriate evidence is not available, then it may be
+ necessary to report an assessment of the residual risk to
+ assist consumers of the composed TOE
+ (e.g. accreditors). This report would need to identify the
+ change to the base component that may have an effect on the
+ assurance gained during the original evaluation, along with
+ any known effects.
+
+
+
+
+ There is only a single component in this family.
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+ the composition rationale;
+
+ the reliance information;
+
+ the development information;
+
+ unique identifier.
+
+
+
+
+ The developer shall provide composition rationale for the
+ base component.
+
+
+ The composition rationale shall demonstrate that a level of
+ assurance at least as high as that of the dependent
+ component has been obtained for the support functionality of
+ the base component, when the base component is configured as
+ required to support the TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the correspondence analysis
+ with the development information and the reliance
+ information to identify the interfaces that are relied
+ upon by the dependent component which are not detailed
+ in the development information.
+
+ The evaluator's goal in this work unit is two fold:
+
+
+ to determine which interfaces relied upon by the
+ dependent component have had the appropriate
+ assurance measures applied.
+
+ to determine that the assurance package applied to
+ the base component during the base component
+ evaluation contained either the same assurance
+ requirements as those in the package applied to the
+ dependent component during its' evaluation, or
+ hierarchically higher assurance requirements.
+
+
+ The evaluator may use the correspondence tracing in the
+ development information developed during the activities (e.g. , , ) to
+ help identify the interfaces identified in the reliance
+ information that are not considered in the development
+ information.
+
+ The evaluator will record the SFR-enforcing interfaces
+ described in the reliance information that are not
+ included in the development information. These will
+ provide input to
+ work unit, helping to identify the portions of the base
+ component in which further assurance is required.
+
+ If the both the base and dependent components were
+ evaluated against the same assurance package, then the
+ determination of whether the level of assurance in the
+ portions within the base component evaluation is at
+ least as high as that of the dependent component is
+ trivial. If however, the assurance packages applied to
+ the components during the component evaluations differ,
+ the evaluator needs to determine that the assurance
+ requirements applied to the base component are all
+ hierarchically higher to the assurance requirements
+ applied to the dependent component.
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine, for those included base component interfaces
+ on which the dependent TSF relies, whether the interface
+ was considered during the evaluation of the base
+ component.
+
+ The ST, component public evaluation report (e.g. certification
+ report) and guidance documents for the base component all
+ provide information on the scope and boundary of the base
+ component. The ST provides details of the logical scope and
+ boundary of the composed TOE, allowing the evaluator to
+ determine whether an interface relates to a portion of the
+ product that was within the scope of the evaluation. The
+ guidance documentation provides details of use of all interfaces
+ for the composed TOE. Although the guidance documentation may
+ include details of interfaces in the product that are not within
+ the scope of the evaluation, any such interfaces should be
+ identifiable, either from the scoping information in the ST or
+ through a portion of the guidance that deals with the evaluated
+ configuration. The public evaluation report may provide any
+ additional constraints on the use of the composed TOE that are
+ necessary.
+
+ Therefore, the combination of these inputs allows the
+ evaluator to determine whether an interface described in
+ the composition rationale has the necessary assurance
+ associated with it, or whether further assurance is
+ required. The evaluator will record those interfaces of
+ the base component for which additional assurance is
+ required, for consideration during .
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine that the necessary assurance measures have
+ been applied to the base component.
+
+ The evaluation verdicts, and resultant assurance, for
+ the base component can be reused provided the same
+ portions of the base component are used in the composed
+ TOE and they are used in a consistent manner.
+
+ In order to determine whether the necessary assurance
+ measures have already been applied to the component, and
+ the portions of the component for which assurance
+ measures still need to be applied, the evaluator should
+ use the output of the .*.2E action and the work units and :
+
+
+
+ For those interfaces identified in the reliance
+ information (), but
+ not discussed in development information (), additional information
+ is required. (Identified in .)
+
+ For those interfaces used inconsistently in the
+ composed TOE from the base component (difference
+ between the information provided in and the impact of the differences in use
+ need to be considered. (Identified in .*.2E.)
+
+ For those interfaces identified in composition
+ rationale for which no assurance has previously been
+ gained, additional information is
+ required. (Identified in .)
+
+ For those interfaces consistently described in the
+ reliance information, composition rationale and the
+ development information, no further action is
+ required as the results from the base component
+ evaluation can be re-used.
+
+ The interfaces of the base component reported to be
+ required by the reliance information but not included in
+ the development information indicate the portions of the
+ base component where further assurance is required. The
+ interfaces identify the entry points into the base
+ component.
+
+ For those interfaces included in both the development
+ information and reliance information, the evaluator is
+ to determine whether the interfaces are being used in
+ the composed TOE in a manner that is consistent with the
+ base component evaluation. The method of use of the
+ interface will be considered during the activities to determine that
+ the use of the interface is consistent in both the base
+ component and the composed TOE. The remaining
+ consideration is the determination of whether the
+ configurations of the base component and the composed
+ TOE are consistent. To determine this, the evaluator
+ will consider the guidance documentation of each to
+ ensure they are consistent (see further guidance below
+ regarding consistent guidance documentation). Any
+ deviation in the documentation will be further analysed
+ by the evaluation to determine the possible
+ effects.
+
+ For those interfaces that are consistently described in
+ the reliance information and development information,
+ and for which the guidance is consistent for the base
+ component and the composed TOE, the required level of
+ assurance has been provided.
+
+ The following subsubclauses provide guidance on how to
+ determine consistency between assurance gained in the
+ base component, the evidence provided for the composed
+ TOE, and the analysis performed by the evaluator in the
+ instances where inconsistencies are identified.
+
+
+ The reliance information identifies the interfaces in
+ the dependent component that are to be matched by the
+ base component. If an interface identified in the
+ reliance information is not identified in the
+ development information, then the composition
+ rationale is to provide a justification of how the
+ base component provides the required
+ interfaces.
+
+ If an interface identified in the reliance information
+ is identified in the development information, but
+ there are inconsistencies between the descriptions,
+ further analysis is required. The evaluator identifies
+ the differences in use of the base component as
+ considered in the base component evaluation and the
+ composed TOE evaluation. The evaluator will devise
+ testing to be performed (during the conduct of ) to test the
+ interface.
+
+ The patch status of the base and dependent components
+ as used in the composed TOE should be compared to the
+ patch status of the components during the component
+ evaluations. If any patches have been applied to the
+ components, the composition rationale is to include
+ details of the patches, including any potential impact
+ to the SFRs of the evaluated component. The evaluator
+ should consider the details of the changes provided
+ and verify the accuracy of the potential impact of the
+ change on the component SFRs. The evaluator should
+ then consider whether the changes made by the patch
+ should be verified through testing, and will identify
+ the necessary testing approach. The testing may take
+ the form of repeating the applicable
+ evaluator/developer testing performed for the
+ component evaluation of the component or it may be
+ necessary for the evaluator to devise new tests to
+ confirm the modified component.
+
+ If any of the individual components have been the
+ subject of assurance continuity activities since the
+ completion of the component evaluation, the evaluator
+ will consider the changes assessed in the assurance
+ continuity activities during the independent
+ vulnerability analysis activity for the composed TOE
+ (in ).
+
+
+
+ The guidance for the composed TOE is likely to make
+ substantial reference out to the guidance for the
+ individual components. The minimal guidance expected
+ to be necessary is the identification of any ordering
+ dependencies in the application of guidance for the
+ dependent and base components, particularly during the
+ preparation (installation) of the composed TOE.
+
+ In addition to the application of the and families to the guidance for the
+ composed TOE, it is necessary to analyse the
+ consistency between the guidance for the components
+ and the composed TOE, to identify any
+ deviations.
+
+ If the composed TOE guidance refers out to the base
+ component and dependent component guidance, then the
+ consideration for consistency is limited to
+ consistency between the guidance documentation
+ provided for each of the components (i.e. consistency
+ between the base component guidance and the dependent
+ component guidance). However, if additional guidance
+ is provided for the composed TOE, to that provided for
+ the components, greater analysis is required, as
+ consistency is also required between the guidance
+ documentation for the components and guidance
+ documentation for the composed TOE.
+
+ Consistent in this instance is
+ understood to mean that either the guidance is the
+ same or it places additional constraints on the
+ operation of the individual components when combined,
+ in a similar manner to refinement of
+ functional/assurance components.
+
+ With the information available (that used as input for
+ or the development
+ aspects discussed above) the evaluator may be able to
+ determine all possible impacts of the deviation from
+ the configuration of the base component specified in
+ the component evaluation. However, for high EALs
+ (where evaluation of the base component included requirements) it is
+ possible that, unless detailed design abstractions for
+ the base component are delivered as part of the
+ development information for the composed TOE, the
+ possible impacts of the modification to the guidance
+ cannot be fully determined as the internals are
+ unknown. In this case the evaluator will report the
+ residual risk of the analysis.
+
+ These residual risks are to be included in any public
+ evaluation report for the composed TOE.
+
+ The evaluator will note these variances in the
+ guidance for input into evaluator independent testing
+ activities ().
+
+ The guidance for the composed TOE may add to the
+ guidance for the components, particularly in terms of
+ installation and the ordering of installation steps
+ for the base component in relation to the installation
+ steps for the dependent component. The ordering of
+ the steps for the installation of the individual
+ components should not change, however they may need to
+ be interleaved. The evaluator will examine this
+ guidance to ensure that it still meets the requirement
+ of the activity
+ performed during the evaluations of the
+ components.
+
+ It may be the case that the reliance information
+ identifies that interfaces of the base component, in
+ addition to those identified as TSFIs of the base
+ component, are relied upon by the dependent component
+ are identified in the reliance information. It may be
+ necessary for guidance to be provided for the use of
+ any such additional interfaces in the base
+ component. Provided the consumer of the composed TOE
+ is to receive the guidance documentation for the base
+ component, then the results of the and
+ verdicts for the base component can be reused for
+ those interfaces considered in the evaluation of the
+ base component. However, for the additional interfaces
+ relied upon by the dependent component, the evaluator
+ will need to determine that the guidance documentation
+ for the base component meets the requirements of and , as applied in the base component
+ evaluations.
+
+ For those interfaces considered during the base
+ component evaluation, and therefore, for which
+ assurance has already been gained, the evaluator will
+ ensure that the guidance for the use of each interface
+ for the composed TOE is consistent with that provided
+ for the base component. To determine the guidance for
+ the composed TOE is consistent with that for the base
+ component, the evaluator should perform a mapping for
+ each interface to the guidance provided for both the
+ composed TOE and the base component. The evaluator
+ then compares the guidance to determine
+ consistency.
+
+ Examples of additional constraints provided in
+ composed TOE guidance that would be considered to be
+ consistent with component guidance are (guidance for a
+ component is given followed by an example of guidance
+ for a composed TOE that would be considered to provide
+ additional constraints):
+
+
+ Component: The password length must be set to a
+ minimum of 8 characters length, including
+ alphabetic and numeric characters.
+
+ Composed TOE: The password length must be set to a
+ minimum of 10 characters in length, including
+ alphabetic and numeric characters and at
+ least one of the following special characters: ( )
+ { } ^ < > - _
+
+ NOTE: It would only be acceptable to increase the
+ password length to [integer >
+ 8] characters while removing the mandate
+ for the inclusion of both alphabetic and numeric
+ characters for the composed TOE, if the same or a
+ higher metric was achieved for the strength rating
+ (taking into account the likelihood of the
+ password being guessed).
+
+ Component: The following services are to be
+ disabled in the registry settings: WWW Publishing
+ Service and ICDBReporter service.
+
+ Composed TOE: The following services are to be
+ disabled in the registry settings:
+ Publishing Service, ICDBReporter service,
+ Remote Procedure Call (RPC) Locator and Procedure
+ Call (RPC) Service.
+
+ Component: Select the following attributes to be
+ included in the accounting log files: date, time,
+ type of event, subject identity and
+ success/failure.
+
+ Composed TOE: Select the following attributes to
+ be included in the accounting log files: date,
+ time, type of event, subject identity,
+ success/failure, event message and process
+ thread.
+
+ If the guidance for the composed TOE deviates (is not
+ a refinement) from that provided for the base
+ component, the evaluator will assess the potential
+ risks of the modification to the guidance. The
+ evaluator will use the information available
+ (including that provided in the public domain, the
+ architectural description of the base component in the
+ public evaluation report (e.g. certification report),
+ the context of the guidance from the remainder of the
+ guidance documentation) to identify likely impact of
+ the modification to the guidance on the SFRs of the
+ composed TOE.
+
+ If during the dependent component evaluation the trial
+ installation used the base component to satisfy the
+ environment requirements of the dependent component
+ this work unit for the composed TOE is considered to
+ be satisfied. If the base component was not used in
+ satisfaction of the work unit during the dependent component
+ evaluation, the evaluator will apply the user
+ procedures provided for the composed TOE to prepare
+ the composed TOE, in accordance with the guidance
+ specified in . This will allow the evaluator to
+ determine that the preparative guidance provided for
+ the composed TOE is sufficient to prepare the composed
+ TOE and its operational environment securely.
+
+
+
+
+ If there is a different delivery mechanism used for
+ the delivery of the composed TOE (i.e. the
+ components are not delivered to the consumer in
+ accordance with the secure delivery procedures
+ defined and assessed during the evaluation of the
+ components), the delivery procedures for the
+ composed TOE will require evaluation against the
+ requirements
+ applied during the components evaluations.
+
+ The composed TOE may be delivered as an integrated
+ product or may require the components to be
+ delivered separately.
+
+ If the components are delivered separately, the
+ results of the delivery of the base component and
+ dependent component are reused. The delivery of the
+ base component is checked during the evaluator trial
+ installation of the dependent component, using the
+ specified guidance and checking the aspects of
+ delivery that are the responsibility of the user, as
+ described in the guidance documentation for the base
+ component.
+
+ If the composed TOE is delivered as a new entity,
+ then the method of delivery of that entity must be
+ considered in the composed TOE evaluation
+ activities.
+
+ The assessment of the delivery procedures for
+ composed TOE items is to be performed in accordance
+ with the methodology for as for any other [component] TOE,
+ ensuring any additional items (e.g. additional
+ guidance documents for the composed TOE) are
+ considered in the delivery procedures.
+
+
+
+ The unique identification of the composed TOE is
+ considered during the application of and the items from
+ which that composed TOE is comprised are considered
+ during the application of .
+
+ Although additional guidance may be produced for the
+ composed TOE, the unique identification of this
+ guidance (considered as part of the unique
+ identification of the composed TOE during ) is considered
+ sufficient control of the guidance.
+
+ The verdicts of the remaining (not considered above)
+ activities can be
+ reused from the base component evaluation, as no
+ further development is performed during integration
+ of the composed TOE.
+
+ There are no additional considerations for
+ development security as the integration is assumed
+ to take place at either the consumer's site or, in
+ the instance that the composed TOE is delivered as
+ an integrated product, at the site of the dependent
+ component developer. Control at the consumer's site
+ is outside the consideration of the CC. No
+ additional requirements or guidance are necessary if
+ integration is at the same site as that for the
+ dependent component, as all components are
+ considered to be configuration items for the
+ composed TOE, and should therefore be considered
+ under the dependent component developer's security
+ procedures anyway.
+
+ Tools and techniques adopted during integration will
+ be considered in the evidence provided by the
+ dependent component developer. Any tools/techniques
+ relevant to the base component will have been
+ considered during the evaluation of the base
+ component. For example, if the base component is
+ delivered as source code and requires compilation by
+ the consumer (e.g. dependent component developer who
+ is performing integration) the compiler would have
+ been specified and assessed, along with the
+ appropriate arguments, during evaluation of the base
+ component.
+
+ There is no life-cycle definition applicable to the
+ composed TOE, as no further development of items is
+ taking place.
+
+ The results of flaw remediation for a component are
+ not applicable to the composed TOE. If flaw
+ remediation is included in the assurance package for
+ the composed TOE, then the requirements are to be applied during
+ the composed TOE evaluation (as for any
+ augmentation).
+
+
+
+
+ The composed TOE will have been tested during the
+ conduct of the activities
+ for evaluation of the dependent component, as the
+ configurations used for testing of the dependent
+ component should have included the base component to
+ satisfy the requirements for IT in the operational
+ environment. If the base component was not used in the
+ testing of the dependent component for the dependent
+ component evaluation, or the configuration of either
+ component varied from their evaluated configurations,
+ then the developer testing performed for evaluation of
+ the dependent component to satisfy the requirements is to be repeated
+ on the composed TOE.
+
+
+
+
+
+
+
+
+ This family sets out requirements for a specification of the
+ base component in increasing levels of detail. Such
+ information is required to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component (as identified
+ in the reliance information).
+
+
+
+ provides details of the
+ base component interfaces and internals in increasing levels
+ of detail, mirroring the level of detail provided by . The application of these two
+ families will provide the specifications of security
+ services from each perspective of the TSF making the call
+ and the TSF servicing the call.
+
+ Having the two descriptions then allows a determination to
+ be made, as part of the
+ activities (.*.2E actions),
+ that these two descriptions are consistent.
+
+
+
+ The components are levelled on the basis of increasing
+ amounts of detail about the interfaces provided, and how
+ they are implemented.
+
+
+
+ The TSF of the base component is often defined without
+ knowledge of the dependencies of the possible applications
+ with which it may by composed. The TSF of this base
+ component is defined to include all parts of the base
+ component that have to be relied upon for enforcement of the
+ base component SFRs. This will include all parts of the base
+ component required to implement the base component
+ SFRs.
+
+ The functional specification of the base component will
+ describe the TSFI in terms of the interfaces the base
+ component provides to allow an external entity to invoke
+ operations of the TSF. This includes interfaces to the
+ human user to permit interaction with the operation of the
+ TSF invoking SFRs and also interfaces allowing an external
+ IT entity to make calls into the TSF.
+
+ The functional specification only provides a description of
+ what the TSF provides at its interface and the means by
+ which that TSF functionality are invoked. Therefore, the
+ functional specification does not necessarily provide a
+ complete interface specification of all possible interfaces
+ available between an external entity and the base
+ component. It does not include what the TSF expects/requires
+ from the operational environment. The description of what a
+ dependent component TSF relies upon of a base component is
+ considered in and the
+ development information evidence provides a response to the
+ interfaces specified.
+
+ The development information evidence includes a
+ specification of the base component. This may be the
+ evidence used during evaluation of the base component to
+ satisfy the requirements, or may
+ be another form of evidence produced by either the base
+ component developer or the composed TOE developer. This
+ specification of the base component is used during to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component. The level of
+ detail required of this evidence increases to reflect the
+ level of required assurance in the composed TOE. This is
+ expected to broadly reflect the increasing confidence gained
+ from the application of the assurance packages to the
+ components. The evaluator determines that this description
+ of the base component is consistent with the reliance
+ information provided for the dependent component.
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces of the base
+ component to determine that they are consistent with the
+ interfaces specified in the reliance information; those
+ required by the dependent component.
+
+ The description of the interfaces into the base component
+ is to be provided at a level of detail consistent with
+ although not all of the
+ aspects necessary for satisfaction of are required for , as once the interface has been identified
+ and the purpose described the remaining detail of the
+ interface specification can be reused from evaluation of
+ the base component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose of
+ each interface of the base component used in the composed
+ TOE.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during activity).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ In addition, the security behaviour of the base component
+ that supports the dependent component TSF is
+ described.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component, which
+ supports the enforcement of the dependent component SFRs.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component that supports the enforcement of the dependent
+ component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ The interface description of the architecture of the base
+ component is provided to enable the evaluator to determine
+ whether or not that interface formed part of the TSF of
+ the base component.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+ In addition to the interface description, the subsystems
+ of the base component that provide the security
+ functionality required by the dependent component will be
+ described to enable the evaluator to determine whether or
+ not that interface formed part of the TSF of the base
+ component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall identify the subsystems of
+ the base component that provide interfaces of the base
+ component used in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component
+ subsystems, which support the enforcement of the dependent
+ component SFRs.
+
+
+ The development information shall provide a mapping from the
+ interfaces to the subsystems of the base component.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that all subsystems of the base component
+ that provide interfaces to the dependent component are
+ identified.
+
+ For those interfaces that are considered to form part of
+ the TSFI of the base component, the subsystems
+ associated with the interface will be subsystems
+ considered in the
+ activity during the base component evaluation. The
+ interfaces on which the dependent component relies that
+ did not form part of the TSFI of the base component will
+ map to subsystems outside of the base component
+ TSF.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component subsystems that support the enforcement of the
+ dependent component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that the correspondence between the
+ interfaces and subsystems of the base component is
+ accurate.
+
+ If the TOE design and functional specification evidence
+ from the base component evaluation is available, this
+ can be used to verify the accuracy of the correspondence
+ between the interfaces and subsystems of the base
+ component as used in the composed TOE. Those interfaces
+ of the base component, which formed part of the base
+ component TSFI will be described in the base component
+ functional specification, and the associated subsystems
+ will be described in the base component TOE design
+ evidence. The tracing between the two will be provided
+ in the base component TOE design evidence.
+
+ If, however, the base component interface did not form
+ part of the TSFI of the base component, the description
+ of the subsystem behaviour provided in the development
+ information will be used to verify the accuracy of the
+ correspondence.
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+ The purpose of this family is to provide evidence that
+ describes the reliance that a dependent component has upon
+ the base component. This information is useful to persons
+ responsible for integrating the component with other
+ evaluated IT components to form the composed TOE, and for
+ providing insight into the security properties of the
+ resulting composition.
+
+ This provides a description of the interface between the
+ dependent and base components of the composed TOE that may
+ not have been analysed during evaluation of the individual
+ components, as the interfaces were not TSFIs of the
+ individual component TOEs.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant during
+ evaluation of the component, either because of the inherent
+ purpose of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces when evaluating the base component, and are in
+ addition to the security interfaces (TSFIs) considered in
+ the functional specification.
+
+
+
+ The components in this family are levelled according to the
+ amount of detail provided in the description of the reliance
+ by the dependent component upon the base component.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant in the
+ component evaluation, either because of the inherent purpose
+ of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces in the evaluation of the base component, and are
+ in addition to the security interfaces (TSFI) considered in
+ the functional specification.
+
+ In summary, the TSFIs described in the functional
+ specification only include the calls made into a TSF by
+ external entities and responses to those calls. Calls made
+ by a TSF, which were not explicitly considered during
+ evaluation of the components, are described by the reliance
+ information provided to satisfy .
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. These are
+ provided in terms of a high-level description.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF protects
+ itself from interference and tampering by the base
+ component.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. This is
+ provided in terms of the interfaces between the
+ dependent and base component and the return values from
+ those interfaces called by the dependent component.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component implementation representation;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe each interaction in
+ terms of the interface used and the return values from those
+ interfaces.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see Annex in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The reliance information shall describe each interaction
+ in terms of the interface used and the return values
+ from those interfaces.
+
+ The identification of the interfaces used by the
+ dependent component TSF when making services requests of
+ the base component allows an integrator to determine
+ whether the base component provides all the necessary
+ corresponding interfaces. This understanding is further
+ gained through the specification of the return values
+ expected by the dependent component. The evaluator
+ ensures that interfaces are described for each
+ interaction specified (as analysed in ).
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF protects
+ itself from interference and tampering by the base
+ component.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ This family requires that testing of composed TOE and
+ testing of the base component, as used in the composed TOE,
+ is performed.
+
+
+
+ The family details
+ requirements for testing to demonstrate that the composed
+ TOE operates as specified in the composed TOE SFRs and the
+ base component interfaces match the design descriptions as
+ provided in the development information (). Testing evidence is to be provided of all
+ SFRs specified in the composed TOE ST and to exercise all
+ base component interfaces used by the dependent component,
+ as identified in .
+
+
+
+ The components in this family are levelled on the basis of
+ increasing rigour of interface testing and increasing rigour
+ of the analysis of the sufficiency of the tests to
+ demonstrate that the composed TSF operates in accordance
+ with the reliance information and the composed TOE
+ SFRs.
+
+
+
+ There are two distinct aspects of testing associated with
+ this family:
+
+
+ testing of the interfaces between the base component and
+ the dependent component, which the dependent component
+ rely upon for enforcement of security functionality, to
+ demonstrate their compatibility;
+
+
+ testing of the composed TOE to demonstrate that the TOE
+ behaves in accordance with the SFRs for the composed
+ TOE.
+
+
+
+ If the test configurations used during evaluation of the
+ dependent component included use of the base component as a
+ ``platform'' and the test analysis sufficiently demonstrates
+ that the TSF behaves in accordance with the SFRs, the
+ developer need perform no further testing of the composed
+ TOE functionality. However, if the base component was not
+ used in the testing of the dependent component, or the
+ configuration of either component varied, then the developer
+ is to perform testing of the composed TOE. This may take
+ the form of repeating the dependent component developer
+ testing of the dependent component, provided this adequately
+ demonstrates the composed TOE TSF behaves in accordance with
+ the SFRs.
+
+ The developer is to provide evidence of testing the base
+ component interfaces used in the composition. The operation
+ of base component TSFIs would have been tested as part of
+ the activities during
+ evaluation of the base component. Therefore, provided the
+ appropriate interfaces were included within the test sample
+ of the base component evaluation and it was determined in
+ that the base component is
+ operating in accordance with the base component evaluated
+ configuration, with all security functionality required by
+ the dependent component included in the TSF, the evaluator
+ action may be met
+ through reuse of the base component verdicts.
+
+ If this is not the case, the base component interfaces used
+ relevant to the composition that are affected by any
+ variations to the evaluated configuration and any additional
+ security functionally will be tested to ensure they
+ demonstrate the expected behaviour. The expected behaviour
+ to be tested is that described in the reliance information
+ ( evidence).
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to ensure the expected behaviour of all composed TOE SFRs
+ and interfaces of the base component relied upon by the
+ dependent component is demonstrated.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the SFRs specified
+ for the composed TOE to identify which SFRs have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the interfaces of
+ the base component relied upon by the dependent
+ component (as specified in the reliance information,
+ examined under ) to
+ identify which base component interfaces have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to verify the
+ developer test results.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to confirm that the
+ TSF operates as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to fully demonstrate the expected behaviour of the
+ composed TOE and the interfaces of the base component
+ relied upon by the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified and is complete.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified and is complete.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the composed TOE and the composed TOE
+ SFRs in the composed TOE security target.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and SFRs presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the base component interfaces relied upon
+ by the dependent component and the interfaces specified
+ in the reliance information.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and interfaces presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The tests are to be selected and executed in accordance
+ with , to
+ demonstrate the correct behaviour of the SFRs specified
+ in the composed TOE security target.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to confirm that the
+ TSF operates as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+ The evaluator shall perform testing, in accordance with
+ , for a subset of the
+ interfaces to the base component to confirm they operate
+ as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the base component to test,
+ the evaluator should take into account any modifications
+ to the base component from the evaluated version or
+ configuration. In particular, the evaluator should
+ consider the development of tests to demonstrate the
+ correct behaviour of interfaces of the base component
+ that were not considered during the evaluation of the
+ base component. These additional interfaces and other
+ modifications to the base component will have been
+ identified during the
+ activity.
+
+
+
+
+
+
+
+ This family calls for an analysis of vulnerability
+ information available in the public domain and of
+ vulnerabilities that may be introduced as a result of the
+ composition.
+
+
+
+ The vulnerability analysis in includes determination of two different
+ aspects of resistance by the composed TOE, namely:
+
+
+ Residual vulnerabilities in the base and dependent
+ components remain unexploitable in the operational
+ environment of the composed TOE;
+
+ The composed TOE is resistant to attackers with a given
+ level of attack potential.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing scrutiny of vulnerability information from the
+ public domain and independent vulnerability analysis.
+
+
+
+ The developer will provide details of any residual
+ vulnerabilities reported during evaluation of the
+ components. These may be gained from the component
+ developers or evaluation reports for the components. These
+ will be used as inputs into the evaluator's vulnerability
+ analysis of the composed TOE in the operational
+ environment.
+
+
+ The operational environment of the composed TOE is examined
+ to ensure that the assumptions and objectives for the
+ component operational environment (specified in each
+ component ST) are satisfied in the composed TOE. An initial
+ analysis of the consistency of assumptions and objectives
+ between the components and the composed TOE STs will have
+ been performed during the conduct of the activities for the composed TOE. However, this
+ analysis is revisited with the knowledge acquired during the
+ , and the
+ activities to ensure that, for example, assumptions of the
+ dependent component that were addressed by the environment
+ in the dependent component ST are not reintroduced as a
+ result of composition (i.e. that the base component
+ adequately addresses the assumptions of the dependent
+ component ST in the composed TOE).
+
+ A search by the evaluator for issues in each component will
+ identify potential vulnerabilities reported in the public
+ domain since completion of the evaluation of the components.
+ Any potential vulnerabilities will then be subject to
+ testing.
+
+ If the base component used in the composed TOE has been the
+ subject of assurance continuity activities since
+ certification, the evaluator will consider during the
+ composed TOE vulnerability analysis activities the changes
+ made in base component.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ easily exploitable vulnerabilities.
+
+ The developer provides details of any residual
+ vulnerabilities reported from evaluation of the
+ components. The evaluator performs an analysis of the
+ disposition the residual vulnerabilities reported and also
+ performs a search of the public domain, to identify any
+ new potential vulnerabilities in the components
+ (i.e. those issues that have been reported in the public
+ domain since evaluation of the base component). The
+ evaluator then performs penetration testing to demonstrate
+ that the potential vulnerabilities cannot be exploited in
+ the TOE, in its operational environment, by an attacker
+ with basic attack potential.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities;
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes a component from the
+ family, then the
+ evaluator may refer to the result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the base component
+ that have become known since the completion of
+ evaluation of the base component.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the
+ dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (i.e. ), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing basic
+ attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the evaluation
+ of the components). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information publicly
+ available to support the identification of possible security
+ vulnerabilities in the base component that have become known
+ since the completion of the base component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public domain as
+ described in to search for
+ vulnerabilities in the dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components of the composed TOE
+ in the independent evaluator vulnerability analysis will
+ take a slightly different form to that documented in
+ for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the components, but the evidence may
+ not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the individual
+ components. The focus of the vulnerability analysis
+ during the composed TOE evaluation is to identify any
+ vulnerabilities introduced as a result of the
+ integration of the components or due to any changes in
+ the use of the components between the evaluated
+ component configuration to the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ development information and composition rationale for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact and
+ identify potential vulnerabilities that may be
+ introduced as a result of this interaction.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch(es) in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report) will be the main source of
+ input material of the change. This will be supplemented
+ by any updates to the guidance documentation resulting
+ from the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether the
+ composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Enhanced-Basic attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the component
+ evaluations). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information publicly
+ available to support the identification of possible security
+ vulnerabilities in the base component that have become known
+ since the completion of the base component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since completion of the
+ dependent component evaluation.
+
+ The evaluator will use the information in the public domain as
+ described in to search for
+ vulnerabilities in the dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components in the independent
+ evaluator vulnerability analysis will take a slightly
+ different form to that documented in for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the base component, but the evidence
+ may not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the components. The focus
+ of the vulnerability analysis during the composed TOE
+ evaluation is to identify any vulnerabilities introduced
+ as a result of the integration of the components or due
+ to any changes in the use of the components between the
+ configuration of the component determined during the
+ component evaluation and the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ composition rationale and development information for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report). This will be supplemented by
+ any updates to the guidance documentation resulting from
+ the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on the
+ identified vulnerabilities, to demonstrate that the composed TOE
+ is resistant to attacks by an attacker with Enhanced-Basic
+ attack potential.
+
+ The evaluator shall conduct penetration testing as detailed
+ for .
+ The evaluator will apply all work units necessary for the
+ satisfaction of evaluator action , reporting in the ETR for the composed TOE all
+ analysis and verdicts as dictated by the work units.
+ The evaluator will also apply the work units for the
+ evaluator action to
+ determine that the composed TOE provided by the developer is
+ suitable for testing.
+
+
+
+
+
+
+ The requirements of the Development class provide information
+ about the TOE. The knowledge obtained by this information is
+ used as the basis for conducting vulnerability analysis and
+ testing upon the TOE, as described in the and classes.
+
+ The Development class encompasses six families of requirements
+ for structuring and representing the TSF at various levels and
+ varying forms of abstraction. These families include:
+
+ requirements for the description (at the various
+ levels of abstraction) of the design and implementation of
+ the SFRs (, , )
+ requirements for the description of the
+ architecture-oriented features of domain separation, TSF
+ self-protection and non-bypassability of the security
+ functionality ()
+ requirements for a security policy model and for correspondence
+ mappings between security policy model and the functional
+ specification ()
+ requirements on the internal structure of the TSF,
+ which covers aspects such as modularity, layering, and
+ minimisation of complexity ()
+
+ When documenting the security functionality of a TOE, there
+ are two properties that need to be demonstrated. The first
+ property is that the security functionality works correctly;
+ that is, it performs as specified. The second property, and
+ one that is arguably harder to demonstrate, is that the TOE
+ cannot be used in a way such that the security functionality
+ can be corrupted or bypassed. These two properties require
+ somewhat different approaches in analysis, and so the families
+ in are structured to support these
+ different approaches. The families , , , and deal with the first property: the specification
+ of the security functionality. The families and deal with
+ the second property: the specification of the design of the
+ TOE demonstrating the security functionality cannot be
+ corrupted or bypassed. It should be noted that both properties
+ need to be realised: the more confidence one has that the
+ properties are satisfied, the more trustworthy the TOE is. The
+ components in the families are designed so that more assurance
+ can be gained as the components hierarchically
+ increase.
+
+ The paradigm for the families targeted at the first property
+ is one of design decomposition. At the highest level, there is
+ a functional specification of the TSF in terms of its
+ interfaces (describing what the TSF does in
+ terms of requests to the TSF for services and resulting
+ responses), decomposing the TSF into smaller units (dependent
+ on the assurance desired and the complexity of the TOE) and
+ describing how the TSF accomplishes its
+ functions (to a level of detail commensurate with the
+ assurance level), and showing the implementation of the TSF. A
+ formal model of the security behaviour also may be given. All
+ levels of decomposition are used in determining the
+ completeness and accuracy of all other levels, ensuring that
+ the levels are mutually supportive. The requirements for the
+ various TSF representations are separated into different
+ families, to allow the PP/ST author to specify which TSF
+ representations are required. The level chosen will dictate
+ the assurance desired/gained.
+
+ Figure indicates the
+ relationships among the various TSF representations of the
+ class, as well as their
+ relationships with other classes. As the figure indicates, the
+ and
+ classes define the requirements for the correspondence between
+ the SFRs and the security objectives for the TOE. Class also defines requirements for the
+ correspondence between both the security objectives and SFRs,
+ and for the TOE summary specification which explains how the
+ TOE meets its SFRs. The activities of include the verification that the TSF that is
+ tested under the and classes is in fact the one described by all of the
+ decomposition levels.
+
+
+ The requirements for all other correspondence shown in Figure
+ are defined in the
+ class. The family defines the requirements for formally
+ modelling selected SFRs, and providing correspondence between
+ the functional specification and the formal model. Each
+ assurance family specific to a TSF representation (i.e., ,
+ and ) defines requirements
+ relating that TSF representation to the SFRs. All
+ decompositions must accurately reflect all other
+ decompositions (i.e., be mutually supportive); the developer
+ supplies the tracings in the last .C elements of the
+ components. Assurance relating to this factor is obtained
+ during the analysis for each of the levels of decomposition by
+ referring to other levels of decomposition (in a recursive
+ fashion) while the analysis of a particular level of
+ decomposition is being performed; the evaluator verifies the
+ correspondence as part of the second E element. The
+ understanding gained from these levels of decomposition form
+ the basis of the functional and penetration testing
+ efforts.
+
+ The family is not represented
+ in this figure, as it is related to the internal structure of
+ the TSF, and is only indirectly related to the process of
+ refinement of the TSF representations. Similarly, the family is not represented in the
+ figure because it relates to the architectural soundness,
+ rather than representation, of the TSF. Both and
+ relate to the analysis of the property that the TOE cannot be
+ made to circumvent or corrupt its security
+ functionality.
+
+ The TOE security functionality (TSF) consists of all parts of
+ the TOE that have to be relied upon for enforcement of the
+ SFRs. The TSF includes both functionality that directly
+ enforces the SFRs, as well as functionality that, while not
+ directly enforcing the SFRs, contributes to their enforcement
+ in a more indirect manner, including functionality with the
+ capability to cause the SFRs to be violated. This includes
+ portions of the TOE that are invoked on start-up that are
+ responsible for putting the TSF into its initial secure
+ state.
+
+ Several important concepts were used in the development of the
+ components of the families. These
+ concepts, while introduced briefly here, are explained more
+ fully in the application notes for the families.
+
+ One over-riding notion is that, as more information becomes
+ available, greater assurance can be obtained that the security
+ functionality 1) is correctly implemented; 2) cannot be
+ corrupted; and 3) cannot be bypassed. This is done through the
+ verification that the documentation is correct and consistent
+ with other documentation, and by providing information that
+ can be used to ensure that the testing activities (both
+ functional and penetration testing) are comprehensive. This is
+ reflected in the levelling of the components of the
+ families. In general, components are levelled based on the
+ amount of information that is to be provided (and subsequently
+ analysed).
+
+ While not true for all TOEs, it is generally the case that the
+ TSF is sufficiently complex that there are portions of the TSF
+ that deserve more intense examination than other portions of
+ the TSF. Determining those portions is unfortunately somewhat
+ subjective, thus terminology and components have been defined
+ such that as the level of assurance increases, the
+ responsibility for determining what portions of the TSF need
+ to be examined in detail shifts from the developer to the
+ evaluator. To aid in expressing this concept, the following
+ terminology is introduced. It should be noted that in the
+ families of the class, this terminology is used when
+ expressing SFR-related portions of the TOE (that is, elements
+ and work units embodied in the , , and families). While the general
+ concept (that some portions of the TOE are more
+ interesting than others) applies to other
+ families, the criteria are expressed differently in order to
+ obtain the assurance required.
+
+ All portions of the TSF are security
+ relevant, meaning that they must preserve the
+ security of the TOE as expressed by the SFRs and
+ requirements for domain separation and
+ non-bypassability. One aspect of security relevance is the
+ degree to which a portion of the TSF enforces a security
+ requirement. Since different portions of the TOE play
+ different roles (or no apparent role at all) in enforcing
+ security requirements, this creates a continuum of SFR
+ relevance: at one end of this continuum are portions of the
+ TOE that are termed SFR-enforcing. Such
+ portions play a direct role in implementing any SFR on the
+ TOE. Such SFRs refer to any functionality provided by one of
+ the SFRs contained in the ST. It should be noted that the
+ definition of plays a role in for
+ SFR-enforcing functionality is impossible to express
+ quantitatively. For example, in the implementation of a
+ Discretionary Access Control (DAC) mechanism, a very narrow
+ view of SFR-enforcing might be the several
+ lines of code that actually perform the check of a subject's
+ attributes against the object's attributes. A broader view
+ would include the software entity (e.g., C function) that
+ contained the several lines of code. A broader view still
+ would include callers of the C function, since they would be
+ responsible for enforcing the decision returned by the
+ attribute check. A still broader view would include any code
+ in the call tree (or programming equivalent for the
+ implementation language used) for that C function (e.g., a
+ sort function that sorted access control list entries in a
+ first-match algorithm implementation). At some point, the
+ component is not so much enforcing the
+ security policy but rather plays a
+ supporting role; such components are termed
+ SFR supporting.
+
+ One of the characteristics of SFR-supporting functionality is
+ that it is trusted to preserve the correctness of the SFR
+ implementation by operating without error. Such functionality
+ may be depended on by SFR-enforcing functionality, but the
+ dependence is generally at a functional level; for example,
+ memory management, buffer management, etc. Further down on the
+ security relevance continuum is functionality termed
+ SFR non-interfering. Such functionality has
+ no role in implementing the SFRs, and is likely part of the
+ TSF because of its environment; for example, any code running
+ in a privileged hardware mode on an operating system. It needs
+ to be considered part of the TSF because, if compromised (or
+ replaced by malicious code), it could compromise the correct
+ operation of an SFR by virtue of its operating in the
+ privileged hardware mode. An example of SFR non-interfering
+ functionality might be a set of mathematical floating point
+ operations implemented in kernel mode for speed
+ considerations.
+
+ The architecture family ()
+ provides for requirements and analysis of the TOE based on
+ properties of domain separation, self-protection, and
+ non-bypassability. These properties relate to the SFRs in
+ that, if these properties are not present, it will likely lead
+ to the failure of mechanisms implementing SFRs. Functionality
+ and design relating to these properties is
+ not considered a part of the continuum described
+ above, but instead is treated separately due to its
+ fundamentally different nature and analysis
+ requirements.
+
+ The difference in analysis of the implementation of SFRs
+ (SFR-enforcing and SFR-supporting functionality) and the
+ implementation of somewhat fundamental security properties of
+ the TOE, which include the initialisation, self-protection,
+ and non-bypassability concerns, is that the SFR-related
+ functionality is more or less directly visible and relatively
+ easy to test, while the above-mentioned properties require
+ varying degrees of analysis on a much broader set of
+ functionality. Further, the depth of analysis for such
+ properties will vary depending on the design of the TOE. The
+ families are constructed to address
+ this by a separate family ()
+ devoted to analysis of the initialisation, self-protection,
+ and non-bypassability requirements, while the other families
+ are concerned with analysis of the functionality supporting
+ SFRs.
+
+ Even in cases where different descriptions are necessary for
+ the multiple levels of abstraction, it is not absolutely
+ necessary for each and every TSF representation to be in a
+ separate document. Indeed, it may be the case that a single
+ document meets the documentation requirements for more than
+ one TSF representation, since it is the information about each
+ of these TSF representations that is required, rather than the
+ resulting document structure. In cases where multiple TSF
+ representations are combined within a single document, the
+ developer should indicate which portions of the documents meet
+ which requirements.
+
+ Three types of specification style are mandated by this class:
+ informal, semiformal and formal. The functional specification
+ and TOE design documentation are always written in either
+ informal or semiformal style. A semiformal style reduces the
+ ambiguity in these documents over an informal presentation. A
+ formal specification may also be required in addition
+ to the semi-formal presentation; the value is that a
+ description of the TSF in more than one way will add increased
+ assurance that the TSF has been completely and accurately
+ specified.
+
+ An informal specification is written as prose in natural
+ language. Natural language is used here as meaning
+ communication in any commonly spoken tongue (e.g. Spanish,
+ German, French, English, Dutch). An informal specification is
+ not subject to any notational or special restrictions other
+ than those required as ordinary conventions for that language
+ (e.g. grammar and syntax). While no notational restrictions
+ apply, the informal specification is also required to provide
+ defined meanings for terms that are used in a context other
+ than that accepted by normal usage.
+
+ The difference between semiformal and informal documents is
+ only a matter of formatting or presentation: a semiformal
+ notation includes such things as an explicit glossary of
+ terms, a standardised presentation format, etc. A semiformal
+ specification is written to a standard presentation
+ template. The presentation should use terms consistently if
+ written in a natural language. The presentation may also use
+ more structured languages/diagrams (e.g. data-flow diagrams,
+ state transition diagrams, entity-relationship diagrams, data
+ structure diagrams, and process or program structure
+ diagrams). Whether based on diagrams or natural language, a
+ set of conventions must be used in the presentation. The
+ glossary explicitly identifies the words that are being used
+ in a precise and constant manner; similarly, the standardised
+ format implies that extreme care has been taken in
+ methodically preparing the document in a manner that maximises
+ clarity. It should be noted that fundamentally different
+ portions of the TSF may have different semiformal notation
+ conventions and presentation styles (as long as the number of
+ different ``semiformal notations'' is small); this still
+ conforms to the concept of a semiformal
+ presentation.
+
+ A formal specification is written in a notation based upon
+ well-established mathematical concepts, and is typically
+ accompanied by supporting explanatory (informal) prose. These
+ mathematical concepts are used to define the syntax and
+ semantics of the notation and the proof rules that support
+ logical reasoning. The syntactic and semantic rules supporting
+ a formal notation should define how to recognise constructs
+ unambiguously and determine their meaning. There needs to be
+ evidence that it is impossible to derive contradictions, and
+ all rules supporting the notation need to be defined or
+ referenced.
+
+
+
+ The purpose of the Development class is to provide evidence
+ about the TOE. Without the knowledge about the TOE that is
+ gained from this information, there could be no useful
+ vulnerability analysis or testing conducted upon the TOE (as
+ described in the and classes).
+
+
+ The purpose of the development activity is to assess the
+ design documentation in terms of its adequacy to understand
+ how the TSF meets the SFRs and how the implementation of these
+ SFRs cannot be tampered with or bypassed. This understanding
+ is achieved through examination of increasingly refined
+ descriptions of the TSF design documentation. Design
+ documentation consists of a functional specification (which
+ describes the interfaces of the TSF), a TOE design description
+ (which describes the architecture of the TSF in terms of how
+ it works in order to perform the functions related to the SFRs
+ being claimed), and an implementation description (a source
+ code level description). In addition, there is a security
+ architecture description (which describes the architectural
+ properties of the TSF to explain how its security enforcement
+ cannot be compromised or bypassed), an internals description
+ (which describes how the TSF was constructed in a manner that
+ encourages understandability), and a security policy model
+ (which formally describes the security policies enforced by
+ the TSF).
+
+
+
+ The CC requirements for design documentation are levelled by
+ the amount, and detail of information provided, and the degree
+ of formality of the presentation of the information. At lower
+ levels, the most security-critical portions of the TSF are
+ described with the most detail, while less security-critical
+ portions of the TSF are merely summarised; added assurance is
+ gained by increasing the amount of information about the most
+ security-critical portions of the TSF, and increasing the
+ details about the less security-critical portions. The most
+ assurance is achieved when thorough details and information of
+ all portions are provided.
+
+ The CC considers a document's degree of formality (that is,
+ whether it is informal or semiformal) to be hierarchical. An
+ informal document is one that is expressed in a natural
+ language. The methodology does not dictate the specific
+ language that must be used; that issue is left for the
+ scheme. The following paragraphs differentiate the contents of
+ the different informal documents.
+
+ A functional specification provides a description of the
+ purpose and method-of-use of interfaces to the TSF. For
+ example, if an operating system presents the user with a means
+ of self-identification, of creating files, of modifying or
+ deleting files, of setting permissions defining what other
+ users may access files, and of communicating with remote
+ machines, its functional specification would contain
+ descriptions of each of these and how they are realised
+ through interactions with the externally-visible interfaces to
+ the TSF. If there is also audit functionality that detects and
+ record the occurrences of such events, descriptions of this
+ audit functionality would also be expected to be part of the
+ functional specification; while this functionality is
+ technically not directly invoked by the user at the external
+ interface, it certainly is affected by what occurs at the
+ user's external interface.
+
+ A design description is expressed in terms of logical
+ divisions (subsystems or modules) that each provide a
+ comprehensible service or function. For example, a firewall
+ might be composed of subsystems that deal with packet
+ filtering, with remote administration, with auditing, and with
+ connection-level filtering. The design description of the
+ firewall would describe the actions that are taken, in terms
+ of what actions each subsystem takes when an incoming packet
+ arrives at the firewall.
+
+
+
+
+ The objective of this family is for the developer to provide
+ a description of the security architecture of the TSF. This
+ will allow analysis of the information that, when coupled
+ with the other evidence presented for the TSF, will confirm
+ the TSF achieves the desired properties. The security
+ architecture descriptions supports the implicit claim that
+ security analysis of the TOE can be achieved by examining
+ the TSF; without a sound architecture, the entire TOE
+ functionality would have to be examined.
+
+
+
+ The information presented for the security architecture of
+ the TOE is related to the information contained in other
+ decomposition documentation (functional specification and
+ TOE design documentation) provided for the TSF, but presents
+ the design in a manner that supports architectural arguments
+ (e.g., the TSF cannot be compromised; the TSF provides
+ security domains consistent with its SFRs; the TSF cannot be
+ bypassed).
+
+
+
+ This family contains only one component.
+
+
+
+ The properties of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed by Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the TSF
+ that are achieved through the design of the TOE and TSF, and
+ enforced by the correct implementation of that
+ design.
+
+ The approach used in this family is for the developer to
+ design and provide a TSF that exhibits the above-mentioned
+ properties, and to provide evidence (in the form of
+ documentation) that explains these properties of the
+ TSF. This explanation is provided at the same level of
+ detail as the description of the SFR-enforcing elements of
+ the TOE in the TOE design document. The evaluator has the
+ responsibility for looking at the evidence and, coupled with
+ other evidence delivered for the TOE and TSF, determining
+ that the properties are achieved.
+
+ Specification of security functionality implementing the
+ SFRs (in the and ) will not necessarily describe
+ mechanisms employed in implementing self-protection and
+ non-bypassability (e.g. memory management
+ mechanisms). Therefore, the material needed to provide the
+ assurance that these requirements are being achieved is
+ better suited to a presentation separate from the design
+ decomposition of the TSF as embodied in and . This is not
+ to imply that the security architecture description called
+ for by this component cannot reference or make use of the
+ design decomposition material; but it is likely that much of
+ the detail present in the decomposition documentation will
+ not be relevant to the argument being provided for the
+ security architecture description document.
+
+ The description of architectural soundness can be thought of
+ as a developer's vulnerability analysis, in that it provides
+ the justification for why the TSF is sound and enforces all
+ of its SFRs. Where the soundness is achieved through
+ specific security mechanisms, these will be tested as part
+ of the requirements; where
+ the soundness is achieved solely through the architecture,
+ the behaviour will be tested as part of the requirements.
+
+ This family consists of requirements for a security
+ architecture description that describes the self-protection,
+ domain separation, non-bypassability principles, including a
+ description of how these principles are supported by the
+ parts of the TOE that are used for TSF
+ initialisation.
+ Additional information on the security architecture
+ properties of self-protection, domain separation, and
+ non-bypassability can be found in Annex .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is structured such that it cannot be tampered with
+ or bypassed, and whether TSFs that provide security
+ domains isolate those domains from each other.
+
+
+
+ The notions of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed in Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the
+ TSF that are achieved through the design of the TOE, and
+ enforced by the correct implementation of that
+ design. Also, the evaluation of these properties is less
+ straight-forward than the evaluation of mechanisms; it is
+ more difficult to check for the absence of functionality
+ than for its presence. However, the determination that
+ these properties are being satisfied is just as critical
+ as the determination that the mechanisms are properly
+ implemented.
+
+ The overall approach used is that the developer provides a
+ TSF that meets the above-mentioned properties, and
+ provides evidence (in the form of documentation) that can
+ be analysed to show that the properties are indeed
+ met. The evaluator has the responsibility for looking at
+ the evidence and, coupled with other evidence delivered
+ for the TOE, determining that the properties are
+ achieved. The work units can be characterised as those
+ detailing with what information has to be provided, and
+ those dealing with the actual analysis the evaluator
+ performs.
+
+ The security architecture description describes how
+ domains are defined and how the TSF keeps them
+ separate. It describes what prevents untrusted processes
+ from getting to the TSF and modifying it. It describes
+ what ensures that all resources under the TSF's control
+ are adequately protected and that all actions related to
+ the SFRs are mediated by the TSF. It explains any role the
+ environment plays in any of these (e.g. presuming it gets
+ correctly invoked by its underlying environment, how is
+ its security functionality invoked?). In short, it
+ explains how the TOE is considered to be providing any
+ kind of security service.
+
+ The analyses the evaluator performs must be done in the
+ context of all of the development evidence provided for
+ the TOE, at the level of detail the evidence is
+ provided. At lower assurance levels there should not be
+ the expectation that, for example, TSF self-protection is
+ completely analysed, because only high-level design
+ representations will be available. The evaluator also
+ needs to be sure to use information gleaned from other
+ portions of their analysis (e.g., analysis of the TOE
+ design) in making their assessments for the properties
+ being examined in the following work units.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation (if available);
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall design and implement the TOE so that the
+ security features of the TSF cannot be bypassed.
+
+
+ The developer shall design and implement the TSF so that it
+ is able to protect itself from tampering by untrusted active
+ entities.
+
+
+ The developer shall provide a security architecture
+ description of the TSF.
+
+
+ The security architecture description shall be at a level of
+ detail commensurate with the description of the
+ SFR-enforcing abstractions described in the TOE design
+ document.
+
+
+ The security architecture description shall describe the
+ security domains maintained by the TSF consistently with the
+ SFRs.
+
+
+ The security architecture description shall describe how the
+ TSF initialisation process is secure.
+
+
+ The security architecture description shall demonstrate that
+ the TSF protects itself from tampering.
+
+
+ The security architecture description shall demonstrate that
+ the TSF prevents bypass of the SFR-enforcing functionality.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the information provided
+ in the evidence is presented at a level of detail
+ commensurate with the descriptions of the SFR-enforcing
+ abstractions contained in the functional specification
+ and TOE design document.
+
+ With respect to the functional specification, the
+ evaluator should ensure that the self-protection
+ functionality described cover those effects that are
+ evident at the TSFI. Such a description might include
+ protection placed upon the executable images of the TSF,
+ and protection placed on objects (e.g., files used by
+ the TSF). The evaluator ensures that the functionality
+ that might be invoked through the TSFI is
+ described.
+
+ If or is included, the evaluator
+ ensures the security architecture description contains
+ information on how any subsystems that contribute to TSF
+ domain separation work.
+
+ If or higher is
+ available, the evaluator ensures that the security
+ architecture description also contains
+ implementation-dependent information. For example, such
+ a description might contain information pertaining to
+ coding conventions for parameter checking that would
+ prevent TSF compromises (e.g. buffer overflows), and
+ information on stack management for call and return
+ operations. The evaluator checks the descriptions of the
+ mechanisms to ensure that the level of detail is such
+ that there is little ambiguity between the description
+ in the security architecture description and the
+ implementation representation.
+
+ The evaluator action related to this work unit is assigned a fail verdict
+ if the security architecture description mentions any module, subsystem, or interface
+ that is not described in the functional specification or TOE design document.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it describes the security
+ domains maintained by the TSF.
+
+ Security domains refer to environments supplied by the
+ TSF for use by potentially-harmful entities; for
+ example, a typical secure operating system supplies a
+ set of resources (address space, per-process environment
+ variables) for use by processes with limited access
+ rights and security properties. The evaluator determines
+ that the developer's description of the security domains
+ takes into account all of the SFRs claimed by the
+ TOE.
+
+ For some TOEs such domains do not exist because all of
+ the interactions available to users are severely
+ constrained by the TSF. A packet-filter firewall is an
+ example of such a TOE. Users on the LAN or WAN do not
+ interact with the TOE, so there need be no security
+ domains; there are only data structures maintained by
+ the TSF to keep the users' packets separated. The
+ evaluator ensures that any claim that there are no
+ domains is supported by the evidence and that no such
+ domains are, in fact, available.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the initialisation process
+ preserves security.
+
+ The information provided in the security architecture
+ description relating to TSF initialisation is directed
+ at the TOE components that are involved in bringing the
+ TSF into an initial secure state (i.e. when all parts of
+ the TSF are operational) when power-on or a reset is
+ applied. This discussion in the security architecture
+ description should list the system initialisation
+ components and the processing that occurs in
+ transitioning from the ``down'' state to the initial
+ secure state.
+
+ It is often the case that the components that perform
+ this initialisation function are not accessible after
+ the secure state is achieved; if this is the case then
+ the security architecture description identifies the components and
+ explains how they are not reachable by untrusted
+ entities after the TSF has been established. In this
+ respect, the property that needs to be preserved is that
+ these components either 1) cannot be accessed by
+ untrusted entities after the secure state is achieved,
+ or 2) if they provide interfaces to untrusted entities,
+ these TSFI cannot be used to tamper with the TSF.
+
+ The TOE components related to TSF initialisation, then,
+ are treated themselves as part of the TSF, and analysed
+ from that perspective. It should be noted that even
+ though these are treated as part of the TSF, it is
+ likely that a justification (as allowed by ) can be made that they do not
+ have to meet the internal structuring requirements of
+ .
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it contains information
+ sufficient to support a determination that the TSF is
+ able to protect itself from tampering by untrusted
+ active entities.
+
+ ''Self-protection'' refers to the ability of the TSF to
+ protect itself from manipulation from external entities
+ that may result in changes to the TSF. For TOEs that
+ have dependencies on other IT entities, it is often the
+ case that the TOE uses services supplied by the other IT
+ entities in order to perform its functions. In such
+ cases, the TSF alone does not protect itself because it
+ depends on the other IT entities to provide some of the
+ protection. For the purposes of the security
+ architecture description, the notion of
+ self-protection applies only to the
+ services provided by the TSF through its TSFI, and not
+ to services provided by underlying IT entities that it
+ uses.
+
+ Self-protection is typically achieved by a variety of
+ means, ranging from physical and logical restrictions on
+ access to the TOE; to hardware-based means (e.g.
+ ``execution rings'' and memory management
+ functionality); to software-based means (e.g. boundary
+ checking of inputs on a trusted server). The evaluator
+ determines that all such mechanisms are
+ described.
+
+ The evaluator determines that the design description
+ covers how user input is handled by the TSF in such a
+ way that the TSF does not subject itself to being
+ corrupted by that user input. For example, the TSF might
+ implement the notion of privilege and protect itself by
+ using privileged-mode routines to handle user input. The
+ TSF might make use of processor-based separation
+ mechanisms such as privilege levels or rings. The TSF
+ might implement software protection constructs or coding
+ conventions that contribute to implementing separation of
+ software domains, perhaps by delineating user address
+ space from system address space. And the TSF might have
+ reliance its environment to provide some support to the
+ protection of the TSF.
+
+ All of the mechanisms contributing to the domain
+ separation functions are described. The evaluator should
+ use knowledge gained from other evidence (functional
+ specification, TOE design, TSF internals description,
+ other parts of the security architecture description, or
+ implementation representation, as included in the
+ assurance package for the TOE) in determining if any
+ functionality contributing to self-protection was
+ described that is not present in the security
+ architecture description.
+
+ Accuracy of the description of the self-protection mechanisms is the property that the
+ description faithfully describes what is implemented. The evaluator should use other
+ evidence (functional specification, TOE design, TSF Internals documentation, other parts
+ of the security architecture description, implementation representation, as included in
+ the ST for the TOE) in determining whether there are discrepancies in any descriptions
+ of the self-protection mechanisms. If
+
+ is included in the assurance package for the TOE, the evaluator will choose a sample of
+ the implementation representation; the evaluator should also ensure that the descriptions
+ are accurate for the sample chosen. If an evaluator cannot understand how a certain
+ self-protection mechanism works or could work in the system architecture, it may be the
+ case that the description is not accurate.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it presents an analysis
+ that adequately describes how the SFR-enforcing
+ mechanisms cannot be bypassed.
+
+ Non-bypassability is a property that the security
+ functionality of the TSF (as specified by the SFRs) is
+ always invoked. For example, if access control to files
+ is specified as a capability of the TSF via an SFR,
+ there must be no interfaces through which files can be
+ accessed without invoking the TSF's access control
+ mechanism (such as an interface through which a raw disk
+ access takes place).
+
+ Describing how the TSF mechanisms cannot be bypassed
+ generally requires a systematic argument based on the
+ TSF and the TSFIs. The description of how the TSF works
+ (contained in the design decomposition evidence, such as
+ the functional specification, TOE design documentation)
+ - along with the information in the TSS - provides the
+ background necessary for the evaluator to understand
+ what resources are being protected and what security
+ functions are being provided. The functional
+ specification provides descriptions of the TSFIs through
+ which the resources/functions are accessed.
+
+ The evaluator assesses the description provided (and other
+ information provided by the developer, such as the functional
+ specification) to ensure that no available interface can be used
+ to bypass the TSF. This means that every available interface
+ must be either unrelated to the SFRs that are claimed in the ST
+ (and does not interact with anything that is used to satisfy
+ SFRs) or else uses the security functionality that is described
+ in other development evidence in the manner described. For
+ example, a game would likely be unrelated to the SFRs, so there
+ must be an explanation of how it cannot affect security. Access
+ to user data, however, is likely to be related to access control
+ SFRs, so the explanation would describe how the security
+ functionality works when invoked through the data-access
+ interfaces. Such a description is needed for every available
+ interface.
+
+ An example of a description follows. Suppose the TSF
+ provides file protection. Further suppose that although
+ the ``traditional'' system call TSFIs for open, read,
+ and write invoke the file protection mechanism described
+ in the TOE design, there exists a TSFI that allows
+ access to a batch job facility (creating batch jobs,
+ deleting jobs, modifying unprocessed jobs). The
+ evaluator should be able to determine from the
+ vendor-provided description that this TSFI invokes the
+ same protection mechanisms as do the ``traditional''
+ interfaces. This could be done, for example, by
+ referencing the appropriate subclauses of the TOE design
+ that discuss how the batch job facility
+ TSFI achieves its security objectives.
+
+ Using this same example, suppose there is a TSFI whose
+ sole purpose is to display the time of day. The
+ evaluator should determine that the description
+ adequately argues that this TSFI is not capable of
+ manipulating any protected resources and should not
+ invoke any security functionality.
+
+ Another example of bypass is when the TSF is supposed to
+ maintain confidentiality of a cryptographic key (one is
+ allowed to use it for cryptographic operations, but is
+ not allowed to read/write it). If an attacker has direct
+ physical access to the device, he might be able to
+ examine side-channels such as the power usage of the
+ device, the exact timing of the device, or even any
+ electromagnetic emanations of the device and, from this,
+ infer the key.
+
+ If such side-channels may be present, the demonstration
+ should address the mechanisms that prevent these
+ side-channels from occurring, such as random internal
+ clocks, dual-line technology etc. Verification of these
+ mechanisms would be verified by a combination of purely
+ design-based arguments and testing.
+
+ For a final example using security functionality rather
+ than a protected resource, consider an ST that contains
+ , which requires that
+ the TSF provides evidence of origination for information
+ types specified in the ST. Suppose that the
+ ``information types'' included all information that is
+ sent by the TOE via e-mail. In this case the evaluator
+ should examine the description to ensure that all TSFI
+ that can be invoked to send e-mail perform the
+ ``evidence of origination generation'' function are
+ detailed. The description might point to user guidance
+ to show all places where e-mail can originate (e.g.,
+ e-mail program, notification from scripts/batch jobs)
+ and then how each of these places invokes the evidence
+ generation function.
+
+ The evaluator should also ensure that the description is comprehensive, in that each
+ interface is analysed with respect to the entire set of claimed SFRs. This may require the
+ evaluator to examine supporting information (functional specification, TOE design, other
+ parts of the security architecture description, operational user guidance, and perhaps even
+ the implementation representation, as provided for the TOE) to determine that the description
+ has correctly capture all aspects of an interface. The evaluator should consider what SFRs each
+ TSFI might affect (from the description of the TSFI and its implementation in the supporting
+ documentation), and then examine the description to determine whether it covers those aspects.
+
+
+
+
+
+
+
+ This family levies requirements upon the functional specification,
+ which describes the TSF interfaces (TSFIs).
+ The TSFI consists of all means by which external entities (or
+ subjects in the TOE but outside of the TSF) supply data to the TSF,
+ receive data from the TSF and invoke services from the TSF.
+ It does not describe how the TSF processes those service
+ requests, nor does it describe the communication when the TSF invokes services
+ from its operational environment; this information is addressed by the
+ and
+ families, respectively.
+
+ This family provides assurance directly by allowing the
+ evaluator to understand how the TSF meets the claimed SFRs. It
+ also provides assurance indirectly, as input to other assurance
+ families and classes:
+ , where the description of
+ the TSFIs may be used to gain better understanding of how the
+ TSF is protected against corruption (i.e. subversion of
+ self-protection or domain separation) and/or bypass;
+ , where the description of the
+ TSFIs is an important input for both developer and evaluator
+ testing;
+ , where the description of the
+ TSFIs is used to search for vulnerabilities.
+
+
+
+
+ The information presented in the functional specification
+ describes the interfaces through which the TSF services are
+ invoked. At the lower levels of assurance, there is an
+ effort to reduce the amount of information that must be
+ supplied by requiring only the most security-critical
+ information.
+
+
+
+ The components in this family are levelled on the degree of
+ detail required of the description of the TSFIs, and the degree
+ of formalism required of the description of the TSFIs.
+
+
+
+ Once the TSFIs are determined (see for guidance and
+ examples of determining TSFI), they are described. At
+ lower-level components, developers focus their documentation
+ (and evaluators focus their analysis) on the more
+ security-relevant aspects of the TOE. Three categories of
+ TSFIs are defined, based upon the relevance the services
+ available through them have to the SFRs being claimed:
+ If a service available through an interface can be
+ traced to one of the SFRs levied on the TSF, then that
+ interface is termed SFR-enforcing.
+ Note that it is possible that an interface may have
+ various services and results, some of which may be
+ SFR-enforcing and some of which may not.
+ interfaces to (or services available through an
+ interface relating to) services that SFR-enforcing
+ functionality depends upon, but need only to function
+ correctly in order for the security policies of the TOE
+ to be preserved, are termed
+ SFR-supporting.
+ Interfaces to services on which SFR-enforcing
+ functionality has no dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR-supporting or SFR non-interfering it must have
+ no SFR-enforcing services or results. In
+ contrast, an SFR-enforcing interface may have SFR-supporting
+ services (for example, the ability to set the system clock
+ may be an SFR-enforcing service of an interface, but if that
+ same interface is used to display the system date that
+ service may be only SFR-supporting). An example of a purely
+ SFR-supporting interface is a system call interface that is
+ used both by users and by a portion of the TSF that is
+ running on behalf of users.
+
+ As more information about the TSFIs becomes available, the
+ greater the assurance that can be gained that the interfaces are
+ correctly categorised/analysed. The requirements are structured
+ such that, at the lowest level, the information required for SFR
+ non-interfering interfaces is the minimum necessary in order for
+ the evaluator to make this determination in an effective
+ manner. At higher levels, more information becomes available so
+ that the evaluator has greater confidence in the
+ designation.
+
+ The purpose in defining these labels (SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering) and for levying
+ different requirements upon each (at the lower assurance
+ components) is to provide a first approximation of where to
+ focus the analysis and the evidence upon which that analysis
+ is performed. If the developer's documentation of the TSF
+ interfaces describes all of the interfaces to the degree
+ specified in the requirements for the SFR-enforcing
+ interfaces (that is, if the documentation exceeds the
+ requirements), there is no need for the developer to create
+ new evidence to match the requirements. Similarly, because
+ the labels are merely a means of differentiating the
+ interface types within the requirements, there is no need
+ for the developer to update the evidence solely to label the
+ interfaces as SFR-enforcing, SFR-supporting, and
+ SFR-non-interfering. The primary purpose of this labelling
+ is to allow developers with less mature development
+ methodologies (and associated artifacts, such as detailed
+ interface and design documentation) to provide only the
+ necessary evidence without undue cost.
+
+ The last C element of each component within this family provides
+ a direct correspondence between the SFRs and the functional
+ specification; that is, an indication of which interfaces are
+ used to invoke each of the claimed SFRs. In the cases where the
+ ST contains such functional requirements as , whose functionality may not manifest itself at
+ the TSFIs, the functional specification and/or the tracing is
+ expected to identify these SFRs; including them in the functional
+ specification helps to ensure that they are not lost at lower
+ levels of decomposition, where they will be relevant.
+
+
+ The requirements define collections of details about TSFI
+ to be provided. For the purposes of the requirements,
+ interfaces are specified (in varying degrees of detail) in
+ terms of their purpose, method of use, parameters,
+ parameter descriptions, and error messages.
+
+ The purpose of an interface is a
+ high-level description of the general goal of the
+ interface (e.g. process GUI commands, receive network
+ packets, provide printer output, etc.)
+
+ The interface's method of use describes
+ how the interface is supposed to be used. This description
+ should be built around the various interactions available
+ at that interface. For instance, if the interface were a Unix
+ command shell, ls, mv
+ and cp would be interactions for that
+ interface. For each interaction the method of use
+ describes what the interaction does, both for behaviour
+ seen at the interface (e.g. the programmer calling the
+ API, the Windows users changing a setting in the registry,
+ etc.) as well as behaviour at other interfaces
+ (e.g. generating an audit record).
+
+ Parameters are explicit inputs to and
+ outputs from an interface that control the behaviour of
+ that interface. For example, parameters are the arguments
+ supplied to an API; the various fields in a packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; the flags that can be set for the
+ ls, etc. The parameters are
+ ``identified'' with a simple list of what they are.
+
+ A parameter description tells what the
+ parameter is in some meaningful way. For instance, an
+ acceptable parameter description for interface
+ foo(i) would be ``parameter i is an
+ integer that indicates the number of users currently
+ logged in to the system''. A description such as
+ ``parameter i is an integer'' is not an acceptable.
+
+ The description of an interface's actions
+ describes what the interface does. This is more detailed
+ than the purpose in that, while the ``purpose'' reveals
+ why one might want to use it, the ``actions'' reveals
+ everything that it does. These actions might be related to
+ the SFRs or not. In cases where the interface's action is
+ not related to SFRs, its description is said to be
+ summarised, meaning the description
+ merely makes clear that it is indeed not SFR-related.
+
+ The error message description identifies
+ the condition that generated it, what the message is, and
+ the meaning of any error codes. An error message is
+ generated by the TSF to signify that a problem or
+ irregularity of some degree has been encountered. The
+ requirements in this family refer to different kinds of
+ error messages:
+ a ``direct'' error message is a
+ security-relevant response through a specific TSFI
+ invocation.
+ an ``indirect'' error cannot be tied to a
+ specific TSFI invocation because it results from
+ system-wide conditions (e.g. resource exhaustion,
+ connectivity interruptions, etc.). Error messages that
+ are not security-relevant are also considered
+ ``indirect''.
+ ``remaining'' errors are any other errors, such as those
+ that might be referenced within the code. For example, the use of
+ condition-checking code that checks for conditions that would not
+ logically occur (e.g. a final ``else'' after a list of ``case''
+ statements), would provide for generating a catch-all error
+ message; in an operational TOE, these error messages should never
+ be seen.
+
+ An example functional specification is provided in .
+
+
+
+ Increasing assurance through increased completeness and
+ accuracy in the interface specification is reflected in
+ the documentation required from the developer as detailed
+ in the various hierarchical components of this
+ family.
+
+ At , the only
+ documentation required is a characterisation of all TSFIs
+ and a high level description of SFR-enforcing and
+ SFR-supporting TSFIs. To provide some assurance that the
+ ``important'' aspects of the TSF have been correctly
+ characterised at the TSFIs, the developer is required to
+ provide the purpose and method of use, parameters for the
+ SFR-enforcing and SFR-supporting TSFIs.
+
+ At , the developer is
+ required to provide the purpose, method of use,
+ parameters, and parameter descriptions for all
+ TSFIs. Additionally, for the SFR-enforcing TSFIs the
+ developer has to describe the SFR-enforcing actions and
+ direct error messages.
+
+ At , the developer must now,
+ in addition to the information required at , provide enough information about the SFR-supporting
+ and SFR-non-interfering actions to show that they are not
+ SFR-enforcing. Further, the developer must now document all of
+ the direct error messages resulting from the invocation of
+ SFR-enforcing TSFIs.
+
+ At , all TSFIs - whether
+ SFR-enforcing, SFR-supporting, SFR-non-interfering - must
+ be described to the same degree, including all of the
+ direct error messages.
+
+ At , the TSFIs descriptions
+ also include error messages that do not result from an
+ invocation of a TSFI.
+
+ At , in addition to the
+ information required by , all
+ remaining error messages are included. The developer must also
+ provide a formal description of the TSFI. This provides an
+ alternative view of the TSFI that may expose inconsistencies or
+ incomplete specification.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has provided a high-level description of at least the
+ SFR-enforcing and SFR-supporting TSFIs, in terms of descriptions
+ of their parameters. There is no other required evidence that
+ can be expected to be available to measure the accuracy of these
+ descriptions; the evaluator merely ensures the descriptions seem
+ plausible.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall describe the purpose and
+ method of use for each SFR-enforcing and SFR-supporting
+ TSFI.
+
+
+ The functional specification shall identify all parameters
+ associated with each SFR-enforcing and SFR-supporting TSFI.
+
+
+ The functional specification shall provide rationale for the
+ implicit categorisation of interfaces as
+ SFR-non-interfering.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ SFR-supporting and SFR-enforcing TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of the parameters; this can be done in
+ association with other work units for this
+ component.
+
+ If an action available through an interface plays a role in
+ enforcing any security policy on the TOE (that is, if one of the
+ actions of the interface can be traced to one of the SFRs levied
+ on the TSF), then that interface is
+ SFR-enforcing. Such policies are not limited to
+ the access control policies, but also refer to any functionality
+ specified by one of the SFRs contained in the ST. Note that it
+ is possible that an interface may have various actions and
+ results, some of which may be SFR-enforcing and some of which
+ may not.
+
+ Interfaces to (or actions available through an interface
+ relating to) actions that SFR-enforcing functionality
+ depends on, but need only to function correctly in order
+ for the security policies of the TOE to be preserved,
+ are termed SFR supporting. Interfaces
+ to actions on which SFR-enforcing functionality has no
+ dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR supporting or SFR non-interfering it must have
+ no SFR-enforcing actions or results. In
+ contrast, an SFR-enforcing interface may have
+ SFR-supporting actions (for example, the ability to set
+ the system clock may be an SFR-enforcing action of an
+ interface, but if that same interface is used to display
+ the system date that action may only be SFR
+ supporting). An example of a purely SFR-supporting
+ interface is a system call interface that is used both
+ by untrusted users and by a portion of the TSF that is
+ running in user mode.
+
+ At this level, it is unlikely that a developer will have
+ expended effort to label interfaces as SFR-enforcing and
+ SFR-supporting. In the case that this has been done,
+ the evaluator should verify to the extent that
+ supporting documentation (e.g., operational user
+ guidance) allows that this identification is correct.
+ Note that this identification activity is necessary for
+ several work units for this component.
+
+ In the more likely case that the developer has not
+ labelled the interfaces, the evaluator must perform
+ their own identification of the interfaces first, and
+ then determine whether the required information (for
+ this work unit, the purpose) is present. Again, because
+ of the lack of supporting evidence this identification
+ will be difficult and have low assurance that all
+ appropriate interfaces have been correctly identified,
+ but nonetheless the evaluator examines other evidence
+ available for the TOE to ensure as complete coverage as
+ is possible.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each
+ SFR-supporting and SFR-enforcing TSFI is given.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it identifies all parameters
+ associated with each SFR-enforcing and SFR-supporting
+ TSFI.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for
+ identified TSFI. Parameters are explicit inputs or
+ outputs to an interface that control the behaviour of
+ that interface. For examples, parameters are the
+ arguments supplied to an API; the various fields in
+ packet for a given network protocol; the individual key
+ values in the Windows Registry; the signals across a set
+ of pins on a chip; etc.
+
+ While difficult to obtain much assurance that all
+ parameters for the applicable TSFI have been identified,
+ the evaluator should also check other evidence provided
+ for the evaluation (e.g., operational user guidance) to
+ see if behaviour or additional parameters are described
+ there but not in the functional specification.
+
+
+
+
+ The evaluator shall examine the rationale provided by
+ the developer for the implicit categorisation of
+ interfaces as SFR-non-interfering to determine that it
+ is accurate.
+
+ In the case where the developer has provided adequate
+ documentation to perform the analysis called for by the
+ rest of the work units for this component without
+ explicitly identifying SFR-enforcing and SFR-supporting
+ interfaces, this work unit should be considered
+ satisfied.
+
+ This work unit is intended to apply to cases where the developer
+ has not described a portion of the TSFI, claiming that it is
+ SFR-non-interfering and therefore not subject to other
+ requirements of this component. In such a case, the developer
+ provides a rationale for this characterisation in sufficient
+ detail such that the evaluator understands the rationale, the
+ characteristics of the interfaces affected (e.g., their
+ high-level function with respect to the TOE, such as ``colour
+ palette manipulation''), and that the claim that these are
+ SFR-non-interfering is supported. Given the level of assurance
+ the evaluator should not expect more detail than is provided for
+ the SFR-enforcing or SFR-supporting interfaces, and in fact the
+ detail should be much less. In most cases, individual
+ interfaces should not need to be addressed in the
+ developer-provided rationale subclause.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis, the
+ evaluator may build upon the developer's tracing (see a map between the TOE security
+ functional requirements and the TSFI). Note that this map may
+ have to be at a level of detail below the component or even
+ element level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that have
+ little or no manifestation at the TSF boundary (e.g., ) it is not expected that they
+ completely map those requirements to the TSFI. The analysis for
+ those requirements will be performed in the analysis for the TOE
+ design () when included in the
+ ST. It is also important to note that since the parameters
+ associated with TSFIs must be fully specified, the evaluator
+ should be able to determine if all aspects of an SFR appear to
+ be implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the SFR-enforcing actions, results and error
+ messages of each TSFI that is SFR-enforcing are also
+ described.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe direct error messages resulting from processing
+ associated with the SFR-enforcing actions.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer"; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface can be
+ traced to one of the SFRs levied on the TSF, then that
+ interface is SFR-enforcing. Such
+ policies are not limited to the access control policies,
+ but also refer to any functionality specified by one of
+ the SFRs contained in the ST. Note that it is possible
+ that an interface may have various actions and results,
+ some of which may be SFR-enforcing and some of which may not.
+
+ The developer is not required to ``label'' interfaces as
+ SFR-enforcing, and likewise is not required to identify
+ actions available through an interface as SFR-enforcing.
+ It is the evaluator's responsibility to examine the
+ evidence provided by the developer and determine that
+ the required information is present. In the case where
+ the developer has identified the SFR-enforcing TSFI and
+ SFR-enforcing actions available through those TSFI, the
+ evaluator must judge completeness and accuracy based on
+ other information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and on the other information presented
+ for the interfaces (parameters and parameter
+ descriptions, error messages, etc.).
+
+ In this case (where the developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing.
+
+ In the case where the developer has provided the same
+ level of information on all interfaces, the evaluator
+ performs the same type of analysis mentioned in the
+ previous paragraphs. The evaluator should determine
+ which interfaces are SFR-enforcing and which are not,
+ and subsequently ensure that the SFR-enforcing aspects
+ of the SFR-enforcing actions are appropriately
+ described.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from SFR-enforcing
+ actions associated with each SFR-enforcing TSFI.
+
+ This work unit should be performed in conjunction with,
+ or after, work unit
+ in order to ensure the set of SFR-enforcing TSFI and
+ SFR-enforcing actions is correctly identified. The
+ developer may provide more information than is required
+ (for example, all error messages associated with each
+ interface), in which the case the evaluator should
+ restrict their assessment of completeness and accuracy
+ to only those that they determine to be associated with
+ SFR-enforcing actions of SFR-enforcing TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+ In order to determine that the description of the
+ error messages of a TSFI is accurate and complete, the
+ evaluator measures the interface description against the
+ other evidence provided for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), as well as other evidence available for
+ that TSFI (parameters, analysis from work unit ).
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the actions, results and error messages of each
+ TSFI are also described sufficiently that it can be
+ determined whether they are SFR-enforcing, with the
+ SFR-enforcing TSFI being described in more detail than
+ other TSFIs.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe direct error messages resulting from SFR-enforcing
+ actions and exceptions associated with invocation of the TSFI.
+
+
+ The functional specification shall summarise the SFR-supporting
+ and SFR-non-interfering actions associated with each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface plays a role
+ in enforcing any security policy on the TOE (that is, if
+ one of the actions of the interface can be traced to one
+ of the SFRs levied on the TSF), then that interface is
+ SFR-enforcing. Such policies are not
+ limited to the access control policies, but also refer
+ to any functionality specified by one of the SFRs
+ contained in the ST. Note that it is possible that an
+ interface may have various actions and results, some of
+ which may be SFR-enforcing and some of which may
+ not.
+ The developer is not required to ``label''
+ interfaces as SFR-enforcing, and likewise is not
+ required to identify actions available through an
+ interface as SFR-enforcing. It is the evaluator's
+ responsibility to examine the evidence provided by the
+ developer and determine that the required information is
+ present. In the case where the developer has identified
+ the SFR-enforcing TSFI and SFR-enforcing actions
+ available through those TSFI, the evaluator must judge
+ completeness and accuracy based on other information
+ supplied for the evaluation (e.g., TOE design, security
+ architecture description, operational user guidance),
+ and on the other information presented for the
+ interfaces (parameters and parameter descriptions, error
+ messages, etc.).
+
+ In this case (developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing. The analysis
+ done for work units
+ and are also used in
+ making this determination.
+ In the case where the developer has provided the
+ same level of information on all interfaces, the
+ evaluator performs the same type of analysis mentioned
+ in the previous paragraphs. The evaluator should
+ determine which interfaces are SFR-enforcing and which
+ are not, and subsequently ensure that the SFR-enforcing
+ aspects of the SFR-enforcing actions are appropriately
+ described. Note that in this case, the evaluator should
+ be able to perform the bulk of the work associated with
+ work unit in the
+ course of performing this SFR-enforcing analysis.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from an invocation of
+ each SFR-enforcing TSFI.
+
+ This work unit should be performed in conjunction with, or
+ after, work unit in order
+ to ensure the set of SFR-enforcing TSFI is correctly identified.
+ The evaluator should note that the requirement and associated
+ work unit is that all direct error messages associated with an
+ SFR-enforcing TSFI must be described, that are associated with
+ SFR-enforcing actions. This is because at this level of
+ assurance, the ``extra'' information provided by the error
+ message descriptions should be used in determining whether all
+ of the SFR-enforcing aspects of an interface have been
+ appropriately described. For instance, if an error message
+ associated with a TSFI (e.g., ``access denied'') indicated that
+ an SFR-enforcing decision or action had taken place, but in the
+ description of the SFR-enforcing actions there was no mention of
+ that particular SFR-enforcing mechanism, then the description
+ may not be complete.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+
+ In order to determine that the description of the error messages
+ of a TSFI is accurate and complete, the evaluator measures the
+ interface description against the other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance), as well as for other
+ evidence supplied for that TSFI (description of SFR-enforcing
+ actions, summary of SFR-supporting and SFR-non-interfering
+ actions and results).
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to
+ determine that it summarises the SFR-supporting and
+ SFR-non-interfering actions associated with each TSFI.
+
+ The purpose of this work unit is to supplement the details about
+ the SFR-enforcing actions (provided in work unit ) with a summary of the remaining
+ actions (i.e., those that are not SFR-enforcing). This covers
+ all SFR-supporting and SFR-non-interfering
+ actions, whether invokable through SFR-enforcing TSFI or through
+ SFR-supporting or SFR-non-interfering TSFI. Such a summary
+ about all SFR-supporting and SFR-non-interfering actions helps
+ to provide a more complete picture of the functions provided by
+ the TSF, and is to be used by the evaluator in determining
+ whether an action or TSFI may have been mis-categorised.
+
+ The information to be provided is more abstract than that
+ required for SFR-enforcing actions. While it should still be
+ detailed enough so that the reader can understand what the
+ action does, the description does not have to be detailed enough
+ to support writing tests against it, for instance. For the
+ evaluator, the key is that the information must be sufficient to
+ make a positive determination that the action is SFR-supporting
+ or SFR-non-interfering. If that level of information is
+ missing, the summary is insufficient and more information must
+ be obtained.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST.
+
+
+
+ The functional specification describes the interfaces to
+ the TSF (the TSFI) in a structured manner. Because of the
+ dependency on , the
+ evaluator is expected to have identified the TSF prior to
+ beginning work on this sub-activity. Without firm
+ knowledge of what comprises the TSF, it is not possible to
+ assess the completeness of the TSFI.
+
+ In performing the various work units included in this family,
+ the evaluator is asked to make assessments of accuracy and
+ completeness of several factors (the TSFI itself, as well as the
+ individual components (parameters, actions, error messages,
+ etc.) of the TSFI). In doing this analysis, the evaluator is
+ expected to use the documentation provided for the
+ evaluation. This includes the ST, the TOE design, and may
+ include other documentation such as the operational user
+ guidance, security architecture description, and implementation
+ representation. The documentation should be examined in an
+ iterative fashion. The evaluator may read, for example, in the
+ TOE design how a certain function is implemented, but see no way
+ to invoke that function from the interface. This might cause the
+ evaluator to question the completeness of a particular TSFI
+ description, or whether an interface has been left out of the
+ functional specification altogether. Describing analysis
+ activities of this sort in the ETR is a key method in providing
+ rationale that the work units have been performed
+ appropriately.
+
+ It should be recognised that there exist functional
+ requirements whose functionality is manifested wholly or
+ in part architecturally, rather than through a specific
+ mechanism. An example of this is the implementation of
+ mechanisms implementing the requirements. Such mechanisms typically are
+ implemented to ensure a behaviour isn't present, which is
+ difficult to test and typically is verified through
+ analysis. In the cases where such functional requirements
+ are included in the ST, it is expected that the evaluator
+ recognise that there may be SFRs of this type that have no
+ interfaces, and that this should not be considered a
+ deficiency in the functional specification.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+ The evaluator shall examine the functional specification to
+ determine the completeness of the TSFI
+ The evaluator shall use the design documentation to identify the possible types of
+ interfaces. The evaluator shall search the design documentation and the guidance
+ documentation for potential TSFI not contained in the developer's documentation,
+ thus indicating that the set of TSFI defined by the developer is incomplete. The
+ evaluator shall examine the arguments presented by the developer that the TSFI is
+ complete and check down to the lowest level of design or with the
+ implementation representation that no additional TSFI exist.
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ Actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to determine
+ that it completely and accurately describes the meaning of all
+ error messages resulting from an invocation of each TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation
+ (e.g. TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST. The completeness of the interfaces
+ is judged based upon the implementation
+ representation.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the implementation representation.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ semi-formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+ The functional specification
+ shall describe all error messages that do not result from an
+ invocation of a TSFI.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation yet
+ does not result from an invocation of a TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is presented using a semiformal
+ style.
+
+ A semi-formal presentation is characterised by a
+ standardised format with a well-defined syntax that
+ reduces ambiguity that may occur in informal
+ presentations. Since the intent of the semi-formal
+ format is to enhance the reader's ability to understand
+ the presentation, use of certain structured presentation
+ methods (pseudo-code, flow charts, block diagrams) are
+ appropriate, though not required.
+
+ For the purposes of this activity, the evaluator should
+ ensure that the interface descriptions are formatted in
+ a structured, consistent manner and use common
+ terminology. A semiformal presentation of the interfaces
+ also implies that the level of detail of the
+ presentation for the interfaces is largely consistent
+ across all TSFI. For the functional specification, it is
+ acceptable to refer to external specifications for
+ portions of the interface as long as those external
+ specifications are themselves semiformal.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+ The evaluator shall examine the functional specification to
+ determine the completeness of the TSFI
+ The evaluator shall use the design documentation to identify the possible types of
+ interfaces. The evaluator shall search the design documentation and the guidance
+ documentation for potential TSFI not contained in the developer's documentation,
+ thus indicating that the set of TSFI defined by the developer is incomplete. The
+ evaluator shall examine the arguments presented by the developer that the TSFI is
+ complete and check down to the lowest level of design or with the
+ implementation representation that no additional TSFI exist.
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system''. is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to determine
+ that it completely and accurately describes the meaning of all
+ error messages resulting from an invocation of each TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation (e.g.,
+ TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it completely and accurately describes
+ all errors messages that do not result from an
+ invocation of any TSFI.
+
+ This work unit complements work unit , which describes those
+ error messages that result from an invocation of the
+ TSFI. Taken together, these work units cover all error
+ messages that might be generated by the TSF.
+
+ The evaluator assesses the completeness and accuracy of
+ the functional specification by comparing its contents
+ to instances of error message generation within the
+ implementation representation. Most of these error
+ messages will have already been covered by work unit
+ .
+
+ The error messages related to this work unit are
+ typically those that are not expected to be generated,
+ but are constructed as a matter of good programming
+ practises. For example, a case statement that defines
+ actions resulting from each of a list of cases may end
+ with a final else statement to apply
+ to anything that might not be expected; this practise
+ ensures the TSF does not get into an undefined state.
+ However, it is not expected that the path of execution
+ would ever get to this else
+ statement; therefore, any error message generation
+ within this else statement would
+ never be generated. Although it would not get
+ generated, it must still be included in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it provides a rationale for each error
+ message contained in the TSF implementation yet does not
+ result from an invocation of a TSFI.
+
+ The evaluator ensures that every error message found
+ under work unit
+ contains a rationale describing why it cannot be invoked
+ from the TSFI.
+
+ As was described in the previous work unit, this
+ rationale might be as straightforward as the fact that
+ the error message in question is provided for
+ completeness of execution logic and that it is never
+ expected to be generated. The evaluator ensures that the
+ rationale for each such error message is logical.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ (Need Objectives text for FSP.6 methodology)
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a formal presentation of the
+ functional specification of the TSF.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+
+ The functional specification shall describe all error messages
+ contained in the TSF implementation representation.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation that
+ is not otherwise described in the functional specification
+ justifying why it is not associated with a TSFI.
+
+
+ The formal presentation of the functional specification of
+ the TSF shall describe the TSFI using a formal style,
+ supported by informal, explanatory text where appropriate.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+
+
+
+
+ The function of the family
+ is for the developer to make available the implementation
+ representation (and, at higher levels, the implementation
+ itself) of the TOE in a form that can be analysed by the
+ evaluator. The implementation representation is used in
+ analysis activities for other families (analysing the TOE
+ design, for instance) to demonstrate that the TOE conforms
+ its design and to provide a basis for analysis in other
+ areas of the evaluation (e.g., the search for
+ vulnerabilities). The implementation representation is
+ expected to be in a form that captures the detailed internal
+ workings of the TSF. This may be software source code,
+ firmware source code, hardware diagrams and/or IC hardware
+ design language code or layout data.
+
+
+
+ The implementation representation of the TOE is made
+ available so that it can be analysed by the evaluator to
+ demonstrate that the TOE conforms its design and to provide
+ a basis for analysis in other areas of the evaluation (e.g.,
+ the search for vulnerabilities). The implementation
+ representation captures the detailed internal workings of
+ the TSF. This may be software source code, firmware source
+ code, hardware diagrams and/or chip specifications.
+
+
+
+ The components in this family are levelled on the amount of
+ implementation that is mapped to the TOE design
+ description.
+
+
+
+ Source code or hardware diagrams and/or IC hardware design
+ language code or layout data that are used to build the
+ actual hardware are examples of parts of an implementation
+ representation. It is important to note that while the
+ implementation representation must be made available to the
+ evaluator, this does not imply that the evaluator needs to
+ possess that representation. For instance, the developer may
+ require that the evaluator review the implementation
+ representation at a site of the developer's choosing.
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due to
+ lack of information. This does not, however, imply that all
+ of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. The implementation representation is made
+ available to allow analysis of other TOE design
+ decompositions (e.g., functional specification, TOE design),
+ and to gain confidence that the security functionality
+ described at a higher level in the design actually appear to
+ be implemented in the TOE. Conventions in some forms of the
+ implementation representation may make it difficult or
+ impossible to determine from just the implementation
+ representation itself what the actual result of the
+ compilation or run-time interpretation will be. For example,
+ compiler directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code. For this reason, it is important that such ``extra''
+ information or related tools (scripts, compilers, etc.) be
+ provided so that the implementation representation can be
+ accurately determined.
+
+ The purpose of the mapping between the implementation
+ representation and the TOE design description is to aid the
+ evaluator's analysis. The internal workings of the TOE may
+ be better understood when the TOE design is analysed with
+ corresponding portions of the implementation representation.
+ The mapping serves as an index into the implementation
+ representation. At the lower component, only a subset of the
+ implementation representation is mapped to the TOE design
+ description. Because of the uncertainty of which portions of
+ the implementation representation will need such a mapping,
+ the developer may choose either to map the entire
+ implementation representation beforehand, or to wait to see
+ which portions of the implementation representation the
+ evaluator requires to be mapped.
+
+ The implementation representation is manipulated by the
+ developer in a form that is suitable for transformation to
+ the actual implementation. For instance, the developer may
+ work with files containing source code, which is eventually
+ compiled to become part of the TSF. The developer makes
+ available the implementation representation in the form used
+ by the developer, so that the evaluator may use automated
+ techniques in the analysis. This also increases the
+ confidence that the implementation representation examined
+ is actually the one used in the production of the TSF (as
+ opposed to the case where it is supplied in an alternate
+ presentation format, such as a word processor document). It
+ should be noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to supply
+ the evaluator with the information that will maximise the
+ effectiveness of the evaluator's analysis efforts.
+
+ Some forms of the implementation representation may require
+ additional information because they introduce significant
+ barriers to understanding and analysis. Examples include
+ ``shrouded'' source code or source code that has been
+ obfuscated in other ways such that it prevents understanding
+ and/or analysis. These forms of implementation
+ representation typically result from the TOE developer
+ taking a version of the implementation representation and
+ running a shrouding or obfuscation program on it. While the
+ shrouded representation is what is compiled and may be
+ closer to the implementation (in terms of structure) than
+ the original, un-shrouded representation, supplying such
+ obfuscated code may cause significantly more time to be
+ spent in analysis tasks involving the representation. When
+ such forms of representation are created, the components
+ require details on the shrouding tools/algorithms used so
+ that the un-shrouded representation can be supplied, and the
+ additional information can be used to gain confidence that
+ the shrouding process does not compromise any security
+ functionality.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer is suitable for use in other analysis
+ activities; suitability is judged by its
+ conformance to the requirements for this component.
+
+
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due
+ to lack of information. This does not, however, imply that
+ all of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. For this sub-activity, this is even
+ truer. It would not be productive for the evaluator to
+ spend large amounts of time verifying the requirements for
+ one portion of the implementation representation, and then
+ use a different portion of the implementation
+ representation in performing analysis for other work
+ units. Therefore, the evaluator is encouraged to select
+ the sample of the implementation representation from the
+ areas of the TOE that will be of most interest during the
+ analysis performed during work units from other families
+ (e.g. , and ).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the sample of the implementation
+ representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ sample of the implementation representation shall
+ demonstrate their correspondence.
+
+
+ The evaluator shall confirm that, for the selected sample of
+ the implementation representation, the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the implementation
+ representation defines the TSF to a level of detail such
+ that the TSF can be generated without further design
+ decisions.
+
+ Source code or hardware diagrams and/or IC hardware
+ design language code or layout data that are used to
+ build the actual hardware are examples of parts of an
+ implementation representation. The evaluator samples the
+ implementation representation to gain confidence that it
+ is at the appropriate level and not, for instance, a
+ pseudo-code level which requires additional design
+ decisions to be made. The evaluator is encouraged to
+ perform a quick check when first looking at the
+ implementation representation to assure themselves that
+ the developer is on the right track. However, the
+ evaluator is also encourage to perform the bulk of this
+ check while working on other work units that call for
+ examining the implementation; this will ensure the
+ sample examined for this work unit is relevant.
+
+
+
+
+ The evaluator shall check that the implementation
+ representation is in the form used by development
+ personnel.
+
+ The implementation representation is manipulated by the
+ developer in form that it suitable for transformation to
+ the actual implementation. For instance, the developer
+ may work with files containing source code, which is
+ eventually compiled to become part of the TSF. The
+ developer makes available the implementation
+ representation in the form they use, so that the
+ evaluator may use automated techniques in the
+ analysis. This also increases the confidence that the
+ implementation representation examined is actually the
+ one used in the production of the TSF (as opposed to the
+ case where it is supplied in an alternate presentation
+ format, such as a word processor document). It should be
+ noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to
+ supply the evaluator with the information that will
+ maximise the evaluator's analysis efforts.
+
+ The evaluator samples the implementation representation
+ to gain confidence that it is the version that is usable
+ by the developer. The sample is such that the evaluator
+ has assurance that all areas of the implementation
+ representation are in conformance with the requirement;
+ however, a complete examination of the entire
+ implementation representation is unnecessary.
+
+ Conventions in some forms of the implementation
+ representation may make it difficult or impossible to
+ determine from just the implementation representation
+ itself what the actual result of the compilation or
+ run-time interpretation will be. For example, compiler
+ directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code.
+
+ Some forms of the implementation representation may
+ require additional information because they introduce
+ significant barriers to understanding and
+ analysis. Examples include shrouded source code or
+ source code that has been obfuscated in other ways such
+ that it prevents understanding and/or analysis. These
+ forms of implementation representation typically result
+ from by taking a version of the implementation
+ representation that is used by the TOE developer and
+ running a shrouding or obfuscation program on it. While
+ the shrouded representation is what is compiled and may
+ be closer to the implementation (in terms of structure)
+ than the original, un-shrouded representation, supplying
+ such obfuscated code may cause significantly more time
+ to be spent in analysis tasks involving the
+ representation. When such forms of representation are
+ created, the components require details on the shrouding
+ tools/algorithms used so that the un-shrouded
+ representation can be supplied, and the additional
+ information can be used to gain confidence that the
+ shrouding process does not compromise any security
+ mechanisms.
+
+ The evaluator samples the implementation representation
+ to gain confidence that all of the information needed to
+ interpret the implementation representation has been
+ supplied. Note that the tools are among those referenced
+ by components. The
+ evaluator is encouraged to perform a quick check when
+ first looking at the implementation representation to
+ assure themselves that the developer is on the right
+ track. However, the evaluator is also encouraged to
+ perform the bulk of this check while working on other
+ work units that call for examining the implementation;
+ this will ensure the sample examined for this work unit
+ is relevant.
+
+
+
+
+ The evaluator shall examine the mapping between the TOE
+ design description and the sample of the implementation
+ representation to determine that it is accurate.
+
+ The evaluator augments the determination of existence
+ (specified in work unit ) by verifying the accuracy of a portion of
+ the implementation representation and the TOE design
+ description. For parts of the TOE design description
+ that are interesting, the evaluator would verify the
+ implementation representation accurately reflects the
+ description provided in the TOE design
+ description.
+
+ For example, the TOE design description might identify a
+ login module that is used to identify and authenticate
+ users. If user authentication is sufficiently
+ significant, the evaluator would verify that the
+ corresponding code in fact implements that service as
+ described in the TOE design description. It might also
+ be worthwhile to verify that the code accepts the
+ parameters as described in the functional
+ specification.
+
+ It is worth pointing out the developer must choose
+ whether to perform the mapping for the entire
+ implementation representation, thereby guaranteeing that
+ the chosen sample will be covered, or waiting for the
+ sample to be chosen before performing the mapping. The
+ first option is likely more work, but may be completed
+ before the evaluation begins. The second option is less
+ work, but will produce a suspension of evaluation
+ activity while the necessary evidence is being
+ produced.
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer can be transformed into the implementation that
+ is used in the testing activities.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the entire implementation representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ entire implementation representation shall demonstrate their
+ correspondence.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ This family addresses the assessment of the internal
+ structure of the TSF. A TSF whose internals are
+ well-structured is easier to implement and less likely to
+ contain flaws that could lead to vulnerabilities; it is also
+ easier to maintain without the introduction of flaws.
+
+
+
+ The internal structure of the TSF can aid or hamper
+ understandability of the implementation representation.
+ Source code that conforms to coding standards, that exhibit
+ a minimum of interactions, and that is written in modules
+ each with a single purpose, is much easier to understand
+ than poorly-structured code with unnecessary or
+ loosely-defined interactions.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of structure and minimisation of complexity
+ required. places
+ requirements for well-structured internals on only selected
+ parts of the TSF. This component is not included in an EAL
+ because this component is viewed for use in special
+ circumstances (e.g., the sponsor has a specific concern
+ regarding a cryptographic module, which is isolated from the
+ rest of the TSF) and would not be widely applicable.
+
+ At the next level, the requirements for well-structured
+ internals are placed on the entire TSF. Finally,
+ minimisation of complexity is introduced in the highest
+ component.
+
+
+
+ These requirements, when applied to the internal structure
+ of the TSF, typically result in improvements that aid both
+ the developer and the evaluator in understanding the TSF,
+ and also provide the basis for designing and evaluating test
+ suites. Further, improving understandability of the TSF
+ should assist the developer in simplifying its
+ maintainability.
+
+ The requirements in this family are presented at a fairly
+ abstract level. The wide variety of TOEs makes it impossible
+ to codify anything more specific than ``well-structured'' or
+ ``minimum complexity''. Judgements on structure and
+ complexity are expected to be derived from the specific
+ technologies used in the TOE. For example, software is
+ likely to be considered well-structured if it exhibits the
+ characteristics cited in the software engineering
+ disciplines. The components within this family call for
+ identifying the standards for measuring the characteristic
+ of being well-structured and not overly-complex.
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring specific portions of the TSF to be
+ well-structured. The intent is that the entire TSF has
+ been designed and implemented using sound engineering
+ principles, but the analysis is performed upon only a
+ specific subset.
+
+
+
+ This component requires the PP or ST author to fill in an
+ assignment with the subset of the TSF. This subset may be
+ identified in terms of the internals of the TSF at any
+ layer of abstraction. For example:
+
+ the structural elements of the TSF as identified
+ in the TOE design (e.g. ``The developer shall design
+ and implement the audit subsystem
+ such that it has well-structured internals.'')
+ the implementation (e.g. ``The developer shall
+ design and implement the encrypt.c and
+ decrypt.c files such that it has
+ well-structured internals.'' or ``The developer shall
+ design and implement the 6227 IC chip
+ such that it has well-structured
+ internals.'')
+
+ It is likely this would not be readily accomplished by
+ referencing the claimed SFRs (e.g. ``The developer shall
+ design and implement the portion of the TSF that
+ provide anonymity as defined in
+ such that it has well-structured
+ internals.'') because this does not indicate where to
+ focus the analysis.
+
+ This component has limited value and would be suitable in cases
+ where potentially-malicious users/subjects have limited or
+ strictly controlled access to the TSFIs or where there is
+ another means of protection (e.g., domain separation) that
+ ensures the chosen subset of the TSF cannot be adversely
+ affected by the rest of the TSF (e.g., the cryptographic
+ functionality, which is isolated from the rest of the TSF, is
+ well-structured).
+
+
+
+ The objective of this sub-activity is to determine whether
+ the defined subset of the TSF is designed and structured
+ such that the likelihood of flaws is reduced and that
+ maintenance can be more readily performed without the
+ introduction of flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The use of the assignment in this component levies stricter
+ constraints on the subset of the TSF that is explicitly
+ identified in the assignment
+ than on the remainder of the TSF.
+ While the entire TSF is to be designed using good
+ engineering principles and result in a well-structured TSF, only
+ the specified subset is specifically analysed for this
+ characteristic. The evaluator determines that the developer's
+ application of coding standards result in a TSF that is
+ understandable.
+
+ The primary goal of this component is to ensure the TSF
+ subset's implementation representation is understandable
+ to facilitate maintenance and analysis (of both the
+ developer and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance);
+
+
+ the TSF internals description and justification;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement subset
+ of the TSF such that it has well-structured
+ internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall explain the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ assigned subset of the TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF subset:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ subset
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the TSF
+ subset
+
+ For other types of technologies used in the TOE - such as
+ non-procedural software (e.g. object-oriented programming),
+ widespread commodity hardware (e.g. PC microprocessors), and
+ special-purpose hardware (e.g. smart-card processors) - the
+ evaluator should seek guidance from the evaluation authority for
+ determining the adequacy of criteria for being
+ ``well-structured''.
+
+
+
+ The evaluator shall check the TSF internals
+ description to determine that it identifies the Assigned
+ subset of the TSF.
+
+ This subset may be identified in terms of the internals
+ of the TSF at any layer of abstraction. For example, it
+ may be in terms of the structural elements of the TSF as
+ identified in the TOE design (e.g. the audit subsystem),
+ or in terms of the implementation
+ (e.g. encrypt.c and
+ decrypt.c files, or the 6227 IC
+ chip).
+
+ It is insufficient to identify this subset in terms of
+ the claimed SFRs (e.g. the portion of the TSF that
+ provide anonymity as defined in ) because this does not indicate where to
+ focus the analysis.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ assigned TSF subset is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF subset meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF subset meets the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF subset and
+ the modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ assigned subset of the TSF.
+
+
+ The evaluator shall determine that the TOE design for
+ the assigned TSF subset is well-structured.
+
+ The evaluator examines a sample of the TOE design to
+ verify the accuracy of the justification. For example, a
+ sample of the TOE design is analysed to determine its
+ adherence to the design standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the assigned TSF
+ subset is well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF subset to
+ verify the accuracy of the internals description. For
+ example, a sample of the procedural software portions of
+ the TSF subset is analysed to determine its cohesion and
+ coupling, its adherence to the coding standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured. The intent is
+ that the entire TSF has been designed and implemented
+ using sound engineering principles.
+
+
+
+ Judgements on the adequacy of the structure are expected to
+ be derived from the specific technologies used in the TOE.
+ This component calls for identifying the standards for
+ measuring the characteristic of being
+ well-structured.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is designed and structured such that the
+ likelihood of flaws is reduced and that maintenance can be
+ more readily performed without the introduction of
+ flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The primary goal of this component is to ensure the TSF's
+ implementation representation is understandable to
+ facilitate maintenance and analysis (of both the developer
+ and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance));
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall describe the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the
+ TSF
+
+ For other types of technologies used in the TOE - such
+ as non-procedural software (e.g. object-oriented
+ programming), widespread commodity hardware (e.g. PC
+ microprocessors), and special-purpose hardware
+ (e.g. smart-card processors) - the evaluation authority
+ should be consulted for determining the adequacy of
+ criteria for being ``well-structured''.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ TSF is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF meet the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF and the
+ modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ TSF.
+
+
+ The evaluator shall determine that the TOE design is
+ well-structured.
+
+ The evaluator examines the TOE design of a sample of the
+ TSF to verify the accuracy of the justification. For
+ example, a sample of the TOE design is analysed to
+ determine its adherence to the design standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the TSF is
+ well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF to verify the
+ accuracy of the internals description. For example, a
+ sample of the procedural software portions of the TSF is
+ analysed to determine its cohesion and coupling, its
+ adherence to the coding standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured and of minimal
+ complexity. The intent is that the entire TSF has been
+ designed and implemented using sound engineering
+ principles.
+
+
+
+ Judgements on the adequacy of the structure and complexity
+ are expected to be derived from the specific technologies
+ used in the TOE. This component calls for identifying the
+ standards for measuring the structure and
+ complexity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall describe the characteristics used to
+ judge the meaning of ``well-structured'' and ``complex''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured and is not overly complex.
+
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform an internals analysis on the
+ entire TSF.
+
+
+
+
+
+
+ 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.
+
+
+
+ A formal security model precisely describes important
+ aspects of security and their relationship to the behaviour
+ of the TSF. Formalism helps to prove mathematically the
+ thoroughness of the security.
+
+
+
+ This family contains only one component.
+
+
+
+ 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.
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+ 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.
+
+ 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. contains an assignment for identifying these
+ policies that are formally modelled.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the formal TOE security policy model clearly and
+ consistently describes the rules of operation, states,
+ transition, invariants, and other security properties of
+ the claimed SFRs and whether this description corresponds
+ with the description of the security functionality in the
+ functional specification.
+
+
+
+ This activity applies to cases where the developer has
+ formally modelled all security policies of the TOE that
+ are capable of being modelled formally.
+
+ A formal TOE security policy model is a representation of
+ the rules (synonymously termed ``principles'') and
+ characteristics of security policies in mathematical
+ terms. Their formal counterparts are called security
+ properties and security features, respectively. The
+ representation includes but is not limited to algebraic
+ specifications, finite state machines and logic formalisms
+ strong enough to formally infer the properties from the
+ features. The formal security policy model is accompanied
+ by an informal interpretation explaining how the rules and
+ characteristics are mapped to the respective properties
+ and features.
+
+ It is recognised that not all policies (see work unit
+ ) can be formally
+ modelled for all TOEs. This is because either the state of
+ the art is insufficient to formally model a given policy,
+ or because the nature of the TOE renders impossible the
+ modelling of policies that would otherwise be possible to
+ model. If none of the SFRs can be formally modelled, this
+ component cannot be met.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a formal security policy model for
+ the list of policies that are formally
+ modelled.
+
+ 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.
+
+
+ The developer shall provide a formal proof of correspondence
+ between the model and any formal functional specification.
+
+
+ The developer shall provide a demonstration of
+ correspondence between the model and the functional
+ specification.
+
+
+ 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.
+
+
+ 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.
+
+
+ The correspondence between the model and the functional
+ specification shall be at the correct level of formality.
+
+
+ The correspondence shall show that the functional
+ specification is consistent and complete with respect to the
+ model.
+
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it is written in a formal
+ style.
+
+ The evaluator identifies the formal framework upon which
+ the TOE security policy model is based and ensures that
+ it is founded on well established mathematical concepts,
+ and identifies the security properties and features
+ addressed in the application notes and ensures the
+ formalisation of at least one security policy. If no
+ policy is formally modelled, this component cannot be
+ successfully claimed.
+
+ For additional guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all necessary
+ informal explanatory text.
+
+ Supporting narrative descriptions are necessary for all
+ parts of the model (for example, to make clear the
+ meaning of any formal notation and how they are used)
+ including the security properties and features.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all policies that
+ can be formally modelled.
+
+ It is recognised that not all policies can be formally
+ modelled for all TOEs. This is because either the state
+ of the art is insufficient to formally model a given
+ policy, or because the nature of the TOE renders
+ impossible the modelling of policies that would
+ otherwise be possible to model.
+
+ While access control, information flow control, and data
+ integrity policies have all been formally modelled
+ successfully, the possibility of modelling other
+ policies is based on a case by case decision. Abstention
+ from formally modelling security relevant policies
+ requires argumentation and rests the burden of proof
+ entirely on the developer's side.
+
+ For any security policy where formal models are not
+ possible, the policy must be identified in the
+ assignment of .
+
+
+
+
+ The evaluator shall examine the model to determine that
+ the security behaviour of the TOE is clearly
+ articulated.
+
+ The security policy model's properties describe the
+ TOE's behaviour in enforcing the principles of the
+ policy. For example, a policy that is modelled on the
+ basis of state transitions would include principles of
+ its states, identify its initial state, and define what
+ it means to be a secure state.
+
+ The security policy model's features describe the
+ attributes and conditions of the TOE that come into
+ consideration when enforcing its policy's
+ characteristics. For example, a policy that is modelled
+ on the basis of state transitions would describe the
+ necessary conditions to transform the TOE from one state
+ to the next.
+
+ An informal interpretation of all formal concepts
+ (including attributes, predicates and variables, if
+ available) must also be provided in order to make clear
+ their intended meaning.
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the formal functional
+ specification to determine that it is presented in a
+ formal style.
+
+ If no part of the functional specification is formal,
+ this work unit is not applicable and is therefore
+ considered to be satisfied. The corresponding work will
+ be performed under work unit .
+
+ For any part of the functional specification that is
+ formally presented, the correspondence between that part
+ of the functional specification and the security policy
+ model must be formal. Analysis of the content is
+ performed as part of work units through .
+
+ For guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the semiformal functional
+ specification to determine that it is presented in a
+ semiformal style.
+
+ If the entire functional specification is formal, this
+ work unit is not applicable and is therefore considered
+ to be satisfied. The corresponding work will be
+ performed under work unit .
+
+ For formally-modelled policies whose corresponding
+ description in the functional specification is not
+ formally presented, the correspondence between the model
+ and the functional specification must be a semiformal
+ demonstration. Analysis of the content is performed as
+ part of work units
+ through .
+
+ If a security policy model exists, either this work unit
+ or the previous work unit (or both) will be
+ applicable.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it formally proves the
+ correspondence between the security properties and the
+ security features.
+
+ The proof shall show that the security features enforce
+ the security properties. To determine the enforcement,
+ the evaluator considers the security properties and the
+ security features and verifies that the arguments used
+ in the proof are valid. The proof of correspondence
+ between the security properties and the security
+ features shall be formal.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it proves the internal
+ consistency of the TOE security policy model.
+
+ The proof shall show the absence of contradictions
+ within the TOE security policy model. In determining the
+ absence of contradictions, the evaluator verifies that
+ the arguments used in the proof are valid.
+
+ Since the TOE security policy model is formal, the proof
+ of its internal consistency shall be formal. It is
+ recognised that a complete formal proof of the internal
+ consistency of the TOE security policy model usually is
+ not possible due to the fundamental nature of formal
+ frameworks. Generally, it is sufficient to generate
+ evidence using formal proofs based on the specific TOE
+ security policy model that prove the internal
+ consistency by means of a combination with generic
+ arguments of the formal framework.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is consistent with respect to policies described by the
+ security policies (as articulated by the functional
+ requirements in the ST).
+
+ The examination considers the informal relationships of
+ the model. Hence the meaning of consistency reflects
+ the conventional understanding in contrast to the
+ internal consistency concept of the previous work
+ unit.
+
+ In determining consistency, the evaluator verifies that
+ the rationale shows that each description of properties
+ and features in the security policy model accurately
+ reflects the intent of the security policies. For
+ example, if a policy stated that access control was
+ necessary to the granularity of a single individual,
+ then a security policy model describing the security
+ behaviour of a TOE in the context of controlling groups
+ of users would not be consistent. Likewise, if the
+ policy stated that access control for groups of users
+ was necessary, then a security policy model describing
+ the security behaviour of a TOE in the context of
+ controlling individual users would also not be
+ consistent.
+
+ The evaluator also examines whether the security
+ policies are reflected within their formal counterparts
+ of the security policy model.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is complete with respect to the policies described by
+ the security policies (i.e. as articulated by the
+ functional requirements in the ST).
+
+ In determining completeness of this rationale, the
+ evaluator considers the properties and features of the
+ security policy model and maps those properties and
+ features to explicit policy statements (i.e. functional
+ requirements). The rationale should show that all
+ policies that are required to be modelled have an
+ associated property or feature description in the TOE
+ security policy model.
+
+ Abstention from formally modelling policy statements
+ always calls for justification on the developer's side
+ (also confer the application notes above).
+
+
+
+
+ The evaluator shall examine the demonstration of
+ correspondence to determine that all Assigned policies
+ are mapped to functions within the functional
+ specification.
+
+ If all policies are included within the security policy
+ model (i.e. they are all formally modelled) and the
+ assignment in is
+ therefore empty, this work unit is not applicable and is
+ therefore considered to be satisfied.
+
+ The evaluator verifies that the correspondence
+ demonstrates that the descriptions of the SFR-related
+ functions in the functional specification correspond to
+ the SFRs. This may be done as part of the work units addressing
+ correspondence to the SFRs. However, if the developer
+ provides a well-structured semiformal or informal
+ security policy model to better articulate the notions
+ of security enforced by the TOE, the evaluator will
+ verify that such a model is consistent with the
+ SFRs.
+
+
+
+
+
+
+
+ The design description of a TOE provides both context for a
+ description of the TSF, and a thorough description of the
+ TSF. As assurance needs increase, the level of detail
+ provided in the description also increases. As the size and
+ complexity of the TSF increase, multiple levels of
+ decomposition are appropriate. The design requirements are
+ intended to provide information (commensurate with the given
+ assurance level) so that a determination can be made that
+ the security functional requirements are realised.
+
+
+
+ The design description provides a further-refined
+ description of the TSF from that presented in the functional
+ specification. The functional specification provides a
+ description of what the TSF does at its
+ interface; the design description provides more insight into
+ the TSF by describing how the TSF works in
+ order to perform the functions supporting the SFRs. At lower
+ assurance levels, complete details relating to all portions
+ of the TSF are not required. As the desired assurance
+ increases, more detail is made available so that analysis
+ can be performed that supports the assurance claims being
+ made.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of information that is required to be presented
+ with respect to the TSF, and on the degree of formalism
+ required of the design description.
+
+
+
+ The goal of design documentation is to provide sufficient
+ information to determine the TSF boundary, and to describe
+ how the TSF implements the Security
+ Functional Requirements. The amount and structure of the
+ design documentation will depend on the complexity of the
+ TOE and the number of SFRs; in general, a very complex TOE
+ with a large number of SFRs will require more design
+ documentation than a very simple TOE implementing only a few
+ SFRs. Very complex TOEs will benefit (in terms of the
+ assurance provided) from the production of differing levels
+ of decomposition in describing the design, while very simple
+ TOEs do not require both high-level and low-level
+ descriptions of its implementation.
+
+ This family uses two levels of decomposition: the
+ subsystem and the module.
+ A module is the most specific description of functionality:
+ it is a description of the implementation. A developer
+ should be able to implement the part of the TOE described by
+ the module with no further design decisions. A subsystem is
+ a description of the design of the TOE; it helps to provide
+ a high-level description of what a portion of the TOE is
+ doing and how. As such, a subsystem may be further divided
+ into lower-level subsystems, or into modules. Very complex
+ TOEs might require several levels of subsystems in order to
+ adequately convey a useful description of how the TOE works.
+ Very simple TOEs, in contrast, might not require a subsystem
+ level of description; the module might clearly describe how
+ the TOE works.
+
+ The general approach adopted for design documentation is
+ that, as the level of assurance increases, the emphasis of
+ description shifts from the general (subsystem level) to
+ more (module level) detail. In cases where a module-level
+ of abstraction is appropriate because the TOE is simple
+ enough to be described at the module level, yet the level of
+ assurance calls for a subsystem level of description, the
+ module-level description alone will suffice. For complex
+ TOEs, however, this is not the case: an enormous amount of
+ (module-level) detail would be incomprehensible without an
+ accompanying subsystem level of description.
+
+ This approach follows the general paradigm that providing
+ additional detail about the implementation of the TSF will
+ result in greater assurance that the SFRs are implemented
+ correctly, and provide information that can be used to
+ demonstrate this in testing ().
+
+ In the requirements for this family, the term
+ interface is used as the means of
+ communication (between two subsystems or modules). It
+ describes how the communication is invoked; this is similar
+ to the details of TSFI (see ). The term interaction is
+ used to identify the purpose for communication; it
+ identifies why two subsystems or modules are
+ communicating.
+
+
+ The requirements define collections of details about
+ subsystems and modules to be provided:
+
+ The subsystems and modules are
+ identified with a simple list of what
+ they are.
+
+ Subsystems and modules may be categorised
+ (either implicitly or explicitly) as ``SFR-enforcing'',
+ ``SFR-supporting'', or ``SFR-non-interfering''; these terms are
+ used the same as they are used in .
+
+ A subsystem's behaviour is what it does. The
+ behaviour may also be categorised as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering. The behaviour of the
+ subsystem is never categorised as more SFR-relevant than the
+ category of the subsystem itself. For example, an SFR-enforcing
+ subsystem can have SFR-enforcing behaviour as well as
+ SFR-supporting or SFR-non-interfering behaviour.
+ A behaviour summary of a
+ subsystem is an overview of the actions it performs
+ (e.g. ``The TCP subsystem assembles IP datagrams into
+ reliable byte streams'').
+ A behaviour description of a
+ subsystem is an explanation of everything it
+ does. This description should be at a level of detail
+ that one can readily determine whether the behaviour
+ has any relevance to the enforcement of the
+ SFRs.
+
+ A description of interactions among or between
+ subsystems or modules identifies the reason that subsystems or
+ modules communicate, and characterises the information that is
+ passed. It need not define the information to the same level of
+ detail as an interface specification. For example, it would be
+ sufficient to say ``subsystem X requests a block of memory from
+ the memory manager, which responds with the location of the
+ allocated memory.
+ A description of interfaces provides the
+ details of how the interactions among modules are achieved.
+ Rather than describing the reason the modules are communicating
+ or the purpose of their communication (that is, the description
+ of interactions), the description of interfaces describes the
+ details of how that communication is accomplished, in terms of
+ the structure and contents of the messages, semaphores, internal
+ process communications, etc.
+
+
+ The purpose describes how a module provides
+ their functionality. It provides sufficient detail that no
+ further design decisions are needed. The correspondence between
+ the implementation representation that implements the module,
+ and the purpose of the module should be readily apparent.
+ A module is otherwise described
+ in terms of whatever is identified in the
+ element. Subsystems and modules, and
+ ``SFR-enforcing'', etc. are all further explained in
+ greater detail in .
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each
+ SFR-supporting or SFR-non-interfering TSF subsystem in
+ sufficient detail to determine that it is not SFR-enforcing.
+
+
+ The design shall summarise the SFR-enforcing behaviour of
+ the SFR-enforcing subsystems.
+
+
+ The design shall provide a description of the interactions
+ among SFR-enforcing subsystems of the TSF, and between the
+ SFR-enforcing subsystems of the TSF and other subsystems of
+ the TSF.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-supporting or SFR-non-interfering subsystem of the TSF
+ is described such that the evaluator can determine that the
+ subsystem is SFR-supporting or SFR-non-interfering.
+
+ SFR-supporting and SFR-non-interfering subsystems do not need to
+ be described in detail as to how they function in the system.
+ However, the evaluator makes a determination, based on the
+ evidence provided by the developer, that the subsystems that do
+ not have high-level descriptions are SFR-supporting or
+ SFR-non-interfering. Note that if the developer provides a
+ uniform level of detailed documentation then this work unit will
+ be largely satisfied, since the point of categorising the
+ subsystems is to allow the developer to provide less information
+ for SFR-supporting and SFR-non-interfering subsystems than for
+ SFR-enforcing subsystems.
+
+ An SFR-supporting subsystem is one that is depended on
+ by an SFR-enforcing subsystem in order to implement an
+ SFR, but does not play as direct a role as an
+ SFR-enforcing subsystem. An SFR-non-interfering
+ subsystem is one that is not depended upon, in either a
+ supporting or enforcing role, to implement an
+ SFR.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and high-level
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. A high-level description need not refer to
+ specific data structures (although it may), but instead
+ talks about more general data flow, message flow, and
+ control relationships within a subsystem. The goal of
+ these descriptions is to give the evaluator enough
+ information to understand how the
+ SFR-enforcing behaviour is achieved. Note that the
+ evaluator should find unacceptable asserts of
+ SFR-enforcement in the TOE design documentation for this
+ work unit. It should be noted that it is the
+ evaluator's determination with respect to what
+ ``high-level'' means for a particular TOE, and the
+ evaluator obtains enough information from the developer
+ to make a sound verdict for this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work
+ unit
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the
+ SFR-enforcing subsystems and other subsystems is to help provide
+ the reader a better understanding of how the TSF performs it
+ functions. These interactions do not need to be characterised at
+ the implementation level (e.g., parameters passed from one
+ routine in a subsystem to a routine in a different subsystem;
+ global variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem), but the
+ data elements identified for a particular subsystem that are
+ going to be used by another subsystem need to be covered in this
+ discussion. Any control relationships between subsystems (e.g.,
+ a subsystem responsible for configuring a rule base for a
+ firewall system and the subsystem that actually implements these
+ rules) should also be described.
+
+ The evaluators need to use their own judgement in assessing the
+ completeness of the description. If the reason for an
+ interaction is unclear, or if there are SFR-related interactions
+ (discovered, for instance, in examining the descriptions of
+ subsystem behaviour) that do not appear to be described, the
+ evaluator ensures that this information is provided by the
+ developer. However, if the evaluator can determine that
+ interactions among a particular set of subsystems, while
+ incompletely described by the developer, will not aid in
+ understanding the overall functionality nor security
+ functionality provided by the TSF, then the evaluator may choose
+ to consider the description sufficient, and not pursue
+ completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each SFR
+ non-interfering subsystem of the TSF in detail sufficient to
+ determine that it is SFR non-interfering.
+
+
+ The design shall describe the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+
+ The design shall summarise the SFR-supporting and
+ SFR-non-interfering behaviour of the SFR-enforcing subsystems.
+
+
+ The design shall summarise the behaviour of the
+ SFR-supporting subsystems.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each SFR-non-interfering subsystem of the TSF is
+ described such that the evaluator can determine that the
+ subsystem is SFR-non-interfering.
+
+ SFR-non-interfering subsystems do not need to be
+ described in detail as to how they function in the
+ system. However, the evaluator makes a determination,
+ based on the evidence provided by the developer, that
+ the subsystems that do not have detailed descriptions
+ are SFR-non-interfering. Note that if the developer
+ provides a uniform level of detailed documentation then
+ this work unit will be largely satisfied, since the
+ point of categorising the subsystems is to allow the
+ developer to provide less information for
+ SFR-non-interfering subsystems than for SFR-enforcing
+ and SFR-supporting subsystems.
+
+ An SFR-non-interfering subsystem is one on which the
+ SFR-enforcing and SFR-supporting subsystems have no
+ dependence; that is, they play no role in implementing
+ SFR functionality.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and detailed
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. While not at the level of an algorithmic
+ description, a detailed description of behaviour
+ typically discusses how the functionality is provided in
+ terms of what key data and data structures are, what
+ control relationships exist within a subsystem, and how
+ these elements work together to provide the
+ SFR-enforcing behaviour. Such a description also
+ references SFR-supporting behaviour, which the evaluator
+ should consider in performing subsequent work
+ units.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work unit.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that it
+ provides a complete and accurate high-level description of the
+ SFR-supporting and SFR-non-interfering behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous work unit, this work unit calls for
+ the evaluator to assess the information provided for
+ SFR-enforcing subsystems that is SFR-supporting or
+ SFR-non-interfering. The goal of this assessment is two-fold.
+ First, it should provide the evaluator greater understanding of
+ the way each subsystem works. Second, the evaluator determines
+ that all SFR-enforcing behaviour exhibited by a subsystem has
+ been described. Unlike the previous work unit, the information
+ provided for the SFR-supporting or SFR-non-interfering behaviour
+ does not have to be as detailed as that provided by the
+ SFR-enforcing behaviour. For example, data structures or data
+ items that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all. It is the
+ evaluator's determination, however, with respect to what
+ ``high-level'' means for a particular TOE, and the evaluator
+ obtains enough information from the developer (even if it turns
+ out to be equivalent to information provided for the parts of
+ the subsystem that are SFR-enforcing) to make a sound verdict
+ for this work unit.
+
+ The evaluator is cautioned, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator examines
+ other information available (e.g., functional specification,
+ security architecture description). Descriptions of functionality in these
+ documents should be consistent with what is provided for
+ evidence for this work unit. In particular, the functional
+ specification should be used to determine that the behaviour
+ required to implement the TSF Interfaces described by the
+ functional specification are completely described by the
+ subsystem, since the behaviour will either be SFR-enforcing,
+ SFR-supporting or SFR-non-interfering.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete and accurate high-level
+ description of the behaviour of the SFR-supporting
+ subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous two work units, this work
+ unit calls for the developer to provide (and the
+ evaluator to assess) information about SFR supporting
+ subsystems. Such subsystems should be referenced by the
+ descriptions of the SFR-enforcing subsystems, as well as
+ by the descriptions of interactions in work unit . The goal of evaluator's
+ assessment, like that for the previous work unit, is
+ two-fold. First, it should provide the evaluator with
+ an understanding of the way each SFR-supporting
+ subsystem works. Second, the evaluator determines that
+ the behaviour is described in enough detail so that the
+ way in which the subsystem supports the SFR-enforcing
+ behaviour is clear, and that the behaviour is not itself
+ SFR-enforcing. The information provided for
+ SFR-supporting subsystem's behaviour does not have to be
+ as detailed as that provided by the SFR-enforcing
+ behaviour. For example, data structures or data items
+ that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all.
+ It is the evaluator's determination, however, with
+ respect to what ``high-level'' means for a particular
+ TOE, and the evaluator obtains enough information from
+ the developer (even if it turns out to be equivalent to
+ information provided for the parts of the subsystem that
+ are SFR-enforcing) to make a sound verdict for this work
+ unit.
+
+ The evaluator is cautions, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work unit.
+ In particular, the functional specification should be
+ used to determine that the behaviour required to
+ implement the TSF Interfaces described by the functional
+ specification are completely described by the
+ subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs it functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem need to
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be
+ described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the descriptions of subsystem behaviour) that do not
+ appear to be described, the evaluator ensures that this
+ information is provided by the developer. However, if the
+ evaluator can determine that interactions among a particular set
+ of subsystems, while incompletely described by the developer,
+ will not aid in understanding the overall functionality nor
+ security functionality provided by the TSF, then the evaluator
+ may choose to consider the description sufficient, and not
+ pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing
+ modules and enough information about the SFR-supporting
+ and SFR-non-interfering modules for the evaluator to
+ determine that the SFRs are completely and accurately
+ implemented; as such, the TOE design provides an
+ explanation of the implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the evaluator
+ determines that the TSF boundary has been adequately
+ described. Second, the evaluator determines that the developer
+ has provided documentation that conforms to the content and
+ presentation requirements for this subsystem, and that is
+ consistent with other documentation provided for the
+ TOE. Finally, the evaluator must analyse the design information
+ provided for the SFR-enforcing modules (at a detailed level) and
+ the SFR-supporting and SFR-non-interfering modules (at a less detailed level) to
+ understand how the system is implemented, and with that
+ knowledge ensure that the TSFI in the functional specification
+ are adequately described, and that the test information
+ adequately tests the TSF (done in the work units).
+
+ It is important to note that while the developer is obligated to
+ provide a complete description of the TSF (although
+ SFR-enforcing modules will have more detail than the
+ SFR-supporting or SFR-non-interfering modules), the evaluator is
+ expected to use their judgement in performing their
+ analysis. While the evaluator is expected to look at every
+ module, the detail to which they examine each module may
+ vary. The evaluator analyses each module in order to gain enough
+ understanding to determine the effect of the functionality of
+ the module on the security of the system, and the depth to which
+ they need to analyse the module may vary depending on the
+ module's role in the system. An important aspect of this
+ analysis is that the evaluator should use the other
+ documentation provided (TSS, functional specification, security
+ architecture description, and the TSF internal document) in
+ order to determine that the functionality that is described is
+ correct, and that the implicit designation of SFR-supporting or
+ SFR-non-interfering modules (see below) is supported by their
+ role in the system architecture.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a description of each subsystem of
+ the TSF.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing module in terms of
+ its purpose and relationship with other modules.
+
+
+ The design shall describe each SFR-enforcing module in terms of
+ its SFR-related interfaces, return values from those interfaces,
+ interaction with other modules and called
+ SFR-related interfaces to other SFR-enforcing modules.
+
+
+ The design shall describe each SFR-supporting or
+ SFR-non-interfering module in terms of its purpose and
+ interaction with other modules.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules). Depending upon the
+ complexity of the TOE, its design may be described in terms of
+ subsystems and modules, as described in CC Part 3 . For a very simple TOE that can be
+ described solely at the ``module'' level (see ), this work unit is not
+ applicable and therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ security architecture description) in making this
+ determination. For example, if the
+ functional specification contains interfaces to
+ functionality that does not appear to be described in
+ the TOE design description, it may be the case that a
+ portion of the TSF has not been included
+ appropriately. Making this determination will likely be
+ an iterative process, where as more analysis is done on
+ the other evidence, more confidence can be gained with
+ respect to the completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation in a level of detail that can serve
+ as a guide to reviewing the implementation representation. A description of a module should
+ be such that one could create an implementation of the module from the description, and the
+ resulting implementation would be 1) identical to the actual TSF implementation in terms of
+ the interfaces presented, 2) identical in the use of interfaces that are mentioned in the
+ design, and 3) functionally equivalent to the description of the purpose of the TSF module.
+ For instance, RFC 793 provides a high-level description of the TCP protocol. It is
+ necessarily implementation independent. While it provides a wealth of detail, it is
+ not
+ a suitable design description because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC, and implementation choices (for
+ instance, the use of global data vs. local data in various parts of the implementation) may
+ have an impact on the analysis that is performed. The design description of the TCP module would
+ list the interfaces presented by the implementation (rather than just those defined in RFC 793),
+ as well as an algorithm description of the processing associated with the modules implementing
+ TCP (assuming it was part of the TSF).
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-non-interfering subsystem of the TSF is described such that
+ the evaluator can determine that the subsystem is SFR-non-interfering.
+ If the design is presented solely in terms of modules, then this work unit
+ will be considered satisfied by the assessment done in subsequent work units;
+ no explicit action on the part of the evaluator is necessary in this case.
+ An SFR-non-interfering subsystem is one on which the SFR-enforcing and
+ SFR-supporting subsystems have no dependence; that is, they play no role
+ in implementing SFR functionality.
+ The evaluator ensures that all subsystems of the TSF have a description.
+ While the description should focus on the role that the subsystem do not plays
+ in enforcing or supporting the implementation of the SFRs, enough information
+ must be present so that a context for understanding the SFR-non-interfering
+ functionality is provided.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a subsystem-level
+ description of the TSF in addition to the modular description,
+ the goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs its functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem should
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the module-level documentation) that do not appear to
+ be described, the evaluator ensures that this information is
+ provided by the developer. However, if the evaluator can
+ determine that interactions among a particular set of
+ subsystems, while incompletely described by the developer, and a
+ complete description will not aid in understanding the overall
+ functionality nor security functionality provided by the TSF,
+ then the evaluator may choose to consider the description
+ sufficient, and not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing module and relationship with other modules is complete and accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for component. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the TSF internals, or the security architecture
+ description. However, the evaluator uses the information present
+ in those documents to the extent possible to help ensure that
+ the purpose is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing module contain an accurate and complete
+ description of the SFR-related parameters, the
+ invocation conventions for each interface, and any
+ values returned directly by the interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are fixed)
+ need not be specified or described, since they are not a factor in testing.
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of SFR-related
+ parameters, and descriptions of these parameters. Note
+ that global data would also be considered parameters if
+ used by the module (either as inputs or outputs) when
+ invoked. If a parameter were expected to take on a set
+ of values (e.g., a ``flag'' parameter), the complete set
+ of values the parameter could take on that would have an
+ effect on module processing would be
+ specified. Likewise, parameters representing data
+ structures are described such that each field of the
+ data structure is identified and described. Note that
+ different programming languages may have additional
+ ``interfaces'' that would be non-obvious; an example
+ would be operator/function overloading in C++. This
+ ``implicit interface'' in the class description would
+ also be described as part of the low-level TOE
+ design. Note that although a module could present only
+ one interface, it is more common that a module presents
+ a small set of related interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TOE design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+
+
+
+
+ The evaluator shall examine the TOE design to determine that
+ SFR-supporting and SFR-non-interfering modules are correctly
+ categorised.
+
+ In the cases where the developer has provided different amounts
+ of information for different modules, an implicit categorisation
+ has been done. That is, modules (for instance) with detail
+ presented on their SFR-related interfaces (see ) are candidate SFR-enforcing
+ modules, although examination by the evaluator may lead to a
+ determination that some set of them are SFR-supporting or
+ SFR-non-interfering. Those with only a description of their
+ purpose and interaction with other modules (for instance) are
+ ``implicitly categorised'' as SFR-supporting or
+ SFR-non-interfering.
+
+ In these cases, a key focus of the evaluator for this work unit
+ is attempting to determine from the evidence provided for each
+ module implicitly categorised as SFR-supporting or
+ SFR-non-interfering and the evaluation information about other
+ modules (in the TOE design, the functional specification, the
+ security architecture description, and the operational user
+ guidance), whether the module is indeed SFR-supporting or
+ SFR-non-interfering. At this level of assurance some error
+ should be tolerated; the evaluator does not have to be
+ absolutely sure that a given module is SFR-supporting or
+ SFR-non-interfering, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ SFR-supporting or SFR-non-interfering module is SFR-enforcing,
+ the evaluator requests additional information from the developer
+ in order to resolve the apparent inconsistency. For instance,
+ suppose the documentation for Module A (an SFR-enforcing module)
+ indicates that it calls Module B to perform an access check on a
+ certain type of construct. When the evaluator examines the
+ information associated with Module B, they find that all the
+ developer has provided is a purpose and a set of interactions
+ (thus implicitly categorising Module B as SFR-supporting or
+ SFR-non-interfering). On examining the purpose and interactions
+ from Module A, the evaluator finds no mention of Module B
+ performing any access checks, and Module A is not listed as a
+ module with which Module B interacts. At this point the
+ evaluator should approach the developer to resolve the
+ discrepancies between the information provided in Module A and
+ that in Module B.
+
+ Another example would be where the evaluator examines the
+ mapping of the TSFI to the modules as provided by . This examination shows that
+ Module C is associated with an SFR requiring identification of
+ the user. Again, when the evaluator examines the information
+ associated with Module C, they find that all the developer has
+ provided is a purpose and a set of interactions (thus implicitly
+ categorising Module C as SFR-supporting or
+ SFR-non-interfering). Examining the purpose and interactions
+ presented for Module C, the evaluator is unable to determine why
+ Module C, listed as mapping to a TSFI concerned with user
+ identification, would not be classified as SFR-enforcing. Again,
+ the evaluator should approach the developer to resolve this
+ discrepancy.
+
+
+ A final example is from the opposite point of view. As
+ before, the developer has provided information associated
+ with Module D consisting of a purpose and a set of
+ interactions (thus implicitly categorising Module D as
+ SFR-supporting or SFR-non-interfering). The evaluator
+ examines all of the evidence provided, including the purpose
+ and interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the TOE,
+ the interactions are consistent with that description, and
+ there is nothing to indicate that Module D is
+ SFR-enforcing. In this case, the evaluator should not demand
+ more information about Module D ``just be to sure'' it is
+ correctly categorised. The developer has met their
+ obligations and the resulting assurance the evaluator has in
+ the implicit categorisation of Module D is (by definition)
+ appropriate for this assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that the
+ description of the purpose of each SFR-supporting or
+ SFR-non-interfering module is complete and accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ Because the modules are at such a low level, it may be difficult determine
+ completeness and accuracy impacts from other documentation,
+ such as administrative guidance, the functional specification,
+ the security architecture description, or the TSF internals document.
+ However, the evaluator uses the information present in those documents
+ to the extent possible to help ensure that the function is accurately
+ and completely described. This analysis can be aided by the analysis
+ performed for the work units for the ADV_TDS.3.10C element,
+ which maps the TSFI in the functional specification to the modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that the
+ description of a SFR-supporting or SFR-non-interfering module's
+ interaction with other modules is complete and accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the function is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a description of
+ the implementation of the TSF. The TSFI provide a description of
+ how the implementation is exercised. The evidence from the
+ developer identifies the module that is initially invoked when
+ an operation is requested at the TSFI, and identifies the chain
+ of modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However, a
+ complete call tree for each TSFI is not required for this work
+ unit. The cases in which more than one module would have to be
+ identified are where there are ``entry point'' modules or
+ wrapper modules that have no functionality other than
+ conditioning inputs or de-multiplexing an input. Mapping to one
+ of these modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped to a module at the TSF boundary.
+ This determination can be made by reviewing the module description and its
+ interfaces/interactions. The next aspect of accuracy is that each TSFI identifies
+ a chain of modules between the initial module identified and a module
+ that is primarily responsible for implementing the function presented at the TSF.
+ Note that this may be the initial module, or there may be several modules,
+ depending on how much pre-conditioning of the inputs is done. It should be noted that
+ one indicator of a pre-conditioning module is that it is invoked for a large number
+ of the TSFI, where the TSFI are all of similar type (e.g., system call).
+ The final aspect of accuracy is that the mapping makes sense. For instance,
+ mapping a TSFI dealing with access control to a module that checks passwords
+ is not accurate. The evaluator should again use judgement in making this determination.
+ The goal is that this information aids the evaluator in understanding the system and
+ implementation of the SFRs, and ways in which entities at the TSF boundary can interact
+ with the TSF. The bulk of the assessment of whether the SFRs are described accurately
+ by the modules is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems, and later to modules. Note that this map may have to be
+ at a level of detail below the component or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to modules x, y, and z of subsystem A;
+ (rule 2) to modules x, p, and q of subsystem A; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems, and modules that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and modules, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems, and modules implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems and modules have been identified, or if
+ adequate detail had been provided for those subsystems and modules.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing and
+ SFR-supporting modules and enough information about the
+ SFR-non-interfering modules for the evaluator to determine
+ that the SFRs are completely and accurately implemented;
+ as such, the TOE design provides an explanation of the
+ implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the evaluator
+ determines that the TSF boundary has been adequately
+ described. Second, the evaluator determines that the developer
+ has provided documentation that conforms to the content and
+ presentation requirements this subsystem, and that is consistent
+ with other documentation provided for the TOE. Finally, the
+ evaluator must analyse the design information provided for the
+ SFR-enforcing modules (at a detailed level) and the
+ SFR-supporting and SFR-non-interfering modules (at a less detailed level) to
+ understand how the system is implemented, and with that
+ knowledge ensure that the TSFI in the functional specification
+ are adequately described, and that the test information
+ adequately tests the TSF (done in the work units).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each subsystem of
+ the TSF, supported by informal, explanatory text where appropriate.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing and SFR-supporting
+ module in terms of its purpose and relationship with other
+ modules.
+
+
+ The design shall describe each SFR-enforcing and SFR-supporting module
+ in terms of its SFR-related interfaces, return values from those interfaces,
+ interaction with other modules and called SFR-related
+ interfaces to other SFR-enforcing or SFR-supporting modules.
+
+
+ The design shall describe each SFR-non-interfering module in
+ terms of its purpose and interaction with other modules.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . For a very
+ simple TOE that can be described solely at the
+ ``module'' level (see ), this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ architectural description) in making this
+ determination. For example, if the functional
+ specification contains interfaces to functionality that
+ does not appear to be described in the TOE design
+ description, it may be the case that a portion of the
+ TSF has not been included appropriately. Making this
+ determination will likely be an iterative process, where
+ as more analysis is done on the other evidence, more
+ confidence can be gained with respect to the
+ completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation in a level of detail that can serve
+ as a guide to reviewing the implementation representation. A description of a module should
+ be such that one could create an implementation of the module from the description, and the
+ resulting implementation would be 1) identical to the actual TSF implementation in terms of
+ the interfaces presented, 2) identical in the use of interfaces that are mentioned in the
+ design, and 3) functionally equivalent to the description of the purpose of the TSF module.
+ For instance, RFC 793 provides a high-level description of the TCP protocol. It is
+ necessarily implementation independent. While it provides a wealth of detail, it is
+ not
+ a suitable design description because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC, and implementation choices (for
+ instance, the use of global data vs. local data in various parts of the implementation) may
+ have an impact on the analysis that is performed. The design description of the TCP module would
+ list the interfaces presented by the implementation (rather than just those defined in RFC 793),
+ as well as an algorithm description of the processing associated with the modules implementing
+ TCP (assuming it was part of the TSF).
+
+
+
+
+ The evaluator shall check the TOE design to determine
+ that the TSF modules are identified as either
+ SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The purpose of designating each module (according to the role a
+ particular module plays in the enforcement of the SFRs) is to
+ allow developers to provide less information about the parts of
+ the TSF that have little role in security. It is always
+ permissible for the developer to provide more information or
+ detail than the requirements demand, as might occur when the
+ information has been gathered outside the evaluation context. In
+ such cases the developer must still designate the modules as
+ either SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The accuracy of these designations is continuously
+ reviewed as the evaluation progresses. The concern is
+ the mis-designation of modules as being less important
+ (and hence, having less information) than is really the
+ case. While blatant mis-designations may be immediately
+ apparent (e.g., designating an authentication module as
+ anything but SFR-enforcing when is one of the SFRs being claimed), other
+ mis-designations might not be discovered until the TSF
+ is better understood. The evaluator must therefore keep
+ in mind that these designations are the developer's
+ initial best effort, but are subject to change. Further
+ guidance is provided under work unit , which examines the
+ accuracy of these designations.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+ The evaluator shall examine the TDS documentation to determine
+ that the semiformal notation used for describing the subsystems, modules and
+ their interfaces is defined or referenced.A semiformal notation can be either defined by the sponsor or
+ a corresponding standard be referenced. The evaluator should provide a mapping
+ of security functions and their interfaces outlining in what part of the
+ documentation a function or interface is semiformal described and what notation
+ is used. The evaluator examines all semiformal notations used to make sure that
+ they are of a semiformal style and to justify the appropriateness of the manner
+ how the semiformal notations are used for the TOE.The evaluator is reminded that a semi-formal presentation is
+ characterised by a standardised format with a well-defined syntax that reduces
+ ambiguity that may occur in informal presentations. The syntax of all semiformal
+ notations used in the functional specification shall be defined or a corresponding
+ standard be referenced. The evaluator verifies that the semiformal notations used
+ for expressing the functional specification are capable of expressing features
+ relevant to security. In order to determine this, the evaluator can refer to the
+ SFR and compare the TSF security features stated in the ST and those described
+ in the FSP using the semiformal notations.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-non-interfering subsystem of the TSF is described such that
+ the evaluator can determine that the subsystem is SFR-non-interfering.
+ If the design is presented solely in terms of modules, then this work unit
+ will be considered satisfied by the assessment done in subsequent work units;
+ no explicit action on the part of the evaluator is necessary in this case.
+ An SFR-non-interfering subsystem is one on which the SFR-enforcing and
+ SFR-supporting subsystems have no dependence; that is, they play no role
+ in implementing SFR functionality.
+ The evaluator ensures that all subsystems of the TSF have a description.
+ While the description should focus on the role that the subsystem do not plays
+ in enforcing or supporting the implementation of the SFRs, enough information
+ must be present so that a context for understanding the SFR-non-interfering
+ functionality is provided.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a subsystem-level
+ description of the TSF in addition to the modular description,
+ the goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs it functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem need to
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be
+ described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the module-level documentation) that do not appear to
+ be described, the evaluator ensures that this information is
+ provided by the developer. However, if the evaluator can
+ determine that interactions among a particular set of
+ subsystems, while incompletely described by the developer, and a
+ complete description will not aid in understanding the overall
+ functionality nor security functionality provided by the TSF,
+ then the evaluator may choose to consider the description
+ sufficient, and not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF to
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing and SFR-supporting module, and relationship with other modules
+ is complete and accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the modules
+ have been categorised by the developer or not, it is the
+ evaluator's responsibility to determine that the modules
+ have the appropriate information for their role
+ (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for subsystems. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the TSF internals, or the security architecture
+ description. However, the evaluator uses the information present
+ in those documents to the extent possible to help ensure that
+ the purpose is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing and SFR-supporting module contain an
+ accurate and complete description of the SFR-related
+ parameters, the invocation conventions for each
+ interface, and any values returned directly by the
+ interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are
+ fixed).
+ SFR-related interfaces of SFR-supporting modules are all
+ interfaces of SFR-supporting modules that are called directly
+ or indirectly from SFR-enforcing modules. Those interfaces
+ need to be described with all the parameter used in such a
+ call. This allows the evaluator to understand the purpose of
+ the call to the SFR-supporting module in the context of
+ operation of the SFR-enforcing modules.
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of parameters, and
+ descriptions of these parameters. Note that global data
+ would also be considered parameters if used by the
+ module (either as inputs or outputs) when invoked. If a
+ parameter were expected to take on a set of values
+ (e.g., a ``flag'' parameter), the complete set of values
+ the parameter could take on that would have an effect on
+ module processing would be specified. Likewise,
+ parameters representing data structures are described
+ such that each field of the data structure is identified
+ and described. Note that different programming languages
+ may have additional ``interfaces'' that would be
+ non-obvious; an example would be operator/function
+ overloading in C++. This ``implicit interface'' in the
+ class description would also be described as part of the
+ low-level TOE design. Note that although a module could
+ present only one interface, it is more common that a
+ module presents a small set of related
+ interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TDS design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that SFR-non-interfering modules are correctly
+ categorised.
+
+ As mentioned in work unit ,
+ less information is required about modules that are
+ SFR-non-interfering. A key focus of the evaluator for this work
+ unit is attempting to determine from the evidence provided for
+ each module implicitly categorised as SFR-non-interfering and
+ the evaluation (information about other modules in the TOE
+ design, the functional specification, the security architecture
+ description, the operational user guidance, the TSF internals
+ document, and perhaps even the implementation representation)
+ whether the module is indeed SFR-non-interfering. At this level
+ of assurance some error should be tolerated; the evaluator does
+ not have to be absolutely sure that a given module is
+ SFR-non-interfering, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ SFR-non-interfering module is SFR-enforcing or SFR-supporting,
+ the evaluator requests additional information from the developer
+ in order to resolve the apparent inconsistency. For example,
+ suppose the documentation for Module A (an SFR-enforcing module)
+ indicates that it calls Module B to perform an access check on a
+ certain type of construct. When the evaluator examines the
+ information associated with Module B, it is discovered that the
+ only information the developer has provided is a purpose and a
+ set of interactions (thus implicitly categorising Module B as
+ SFR-supporting or SFR-non-interfering). On examining the purpose and interactions
+ from Module A, the evaluator finds no mention of Module B
+ performing any access checks, and Module A is not listed as a
+ module with which Module B interacts. At this point the
+ evaluator should approach the developer to resolve the
+ discrepancies between the information provided in Module A and
+ that in Module B.
+
+ Another example would be where the evaluator examines
+ the mapping of the TSFI to the modules as provided by
+ . This examination
+ shows that Module C is associated with an SFR requiring
+ identification of the user. Again, when the evaluator
+ examines the information associated with Module C, they
+ find that all the developer has provided is a purpose
+ and a set of interactions (thus implicitly categorising
+ Module C as SFR-non-interfering). Examining the purpose
+ and interactions presented for Module C, the evaluator
+ is unable to determine why Module C, listed as mapping
+ to a TSFI concerned with user identification, would not
+ be classified as SFR-enforcing or SFR-supporting. Again,
+ the evaluator should approach the developer to resolve
+ this discrepancy.
+
+ A final example illustrates the opposite situation. As
+ before, the developer has provided information
+ associated with Module D consisting of a purpose and a
+ set of interactions (thus implicitly categorising Module
+ D as SFR-non-interfering). The evaluator examines all of
+ the evidence provided, including the purpose and
+ interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the
+ TOE, the interactions are consistent with that
+ description, and there is nothing to indicate that
+ Module D is SFR-enforcing or SFR-supporting. In this
+ case, the evaluator should not demand more information
+ about Module D ``just be to sure'' it is correctly
+ categorised. The developer has met the obligations and
+ the resulting assurance the evaluator has in the
+ implicit categorisation of Module D is (by definition)
+ appropriate for this assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-non-interfering module is complete and
+ accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the function is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of a SFR-non-interfering module's
+ interaction with other modules is complete and
+ accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ A module's interaction with other modules can be captured in
+ many ways. The intent for the TOE design is to allow the
+ evaluator to understand (in part through analysis of module
+ interactions) the role of the SFR-supporting and
+ SFR-non-interfering modules in the overall TOE
+ design. Understanding of this role will aid the evaluator in
+ performing work unit .
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the interactions are accurately and completely
+ described.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a
+ description of the implementation of the TSF. The TSFI
+ provide a description of how the implementation is
+ exercised. The evidence from the developer identifies
+ the module that is initially invoked when an operation
+ is requested at the TSFI, and identify the chain of
+ modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However,
+ a complete call tree for each TSFI is not required for
+ this work unit. The cases in which more than one module
+ would have to be identified are where there are ``entry
+ point'' modules or wrapper modules that have no
+ functionality other than conditioning inputs or
+ de-multiplexing an input. Mapping to one of these
+ modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a module at the TSF boundary. This determination can
+ be made by reviewing the module description and its
+ interfaces/interactions. The next aspect of accuracy is
+ that each TSFI identifies a chain of modules between the
+ initial module identified and a module that is primarily
+ responsible for implementing the function presented at
+ the TSF. Note that this may be the initial module, or
+ there may be several modules, depending on how much
+ pre-conditioning of the inputs is done. It should be
+ noted that one indicator of a pre-conditioning module is
+ that it is invoked for a large number of the TSFI, where
+ the TSFI are all of similar type (e.g., system
+ call). The final aspect of accuracy is that the mapping
+ makes sense. For instance, mapping a TSFI dealing with
+ access control to a module that checks passwords is not
+ accurate. The evaluator should again use judgement in
+ making this determination. The goal is that this
+ information aids the evaluator in understanding the
+ system and implementation of the SFRs, and ways in which
+ entities at the TSF boundary can interact with the
+ TSF. The bulk of the assessment of whether the SFRs are
+ described accurately by the modules is performed in
+ other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems, and later to modules. Note that this map may have to be
+ at a level of detail below the component or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to modules x, y and z of subsystem A;
+ (rule 2) to x, p, and q of subsystem A; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems, and modules that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and modules, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems, and modules implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems and modules have been identified, or if
+ adequate detail had been provided for those subsystems and modules.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of all modules for the
+ evaluator to determine that the SFRs are completely and
+ accurately implemented; as such, the TOE design provides
+ an explanation of the implementation
+ representation.
+
+
+
+ At this level, there is no differentiation of required
+ information according to SFR-relevance.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each
+ subsystem of the TSF, supported by informal, explanatory text where
+ appropriate.
+
+
+ The design shall provide a description of the interactions among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall provide a semiformal description of each module
+ in terms of its purpose, interaction, interfaces, return values
+ from those interfaces, and called interfaces to other modules,
+ supported by informal, explanatory text where appropriate.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The developer shall provide a formal specification of the
+ TSF subsystems.
+
+
+ The developer shall provide a proof of correspondence
+ between the formal specifications of the TSF subsystems and
+ of the functional specification.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each
+ subsystem of the TSF, supported by informal, explanatory text where
+ appropriate.
+
+
+ The design shall provide a description of the interactions among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each module in semiformal style in terms
+ of its purpose, interaction, interfaces, return values from those interfaces,
+ and called interfaces to other modules, supported by informal, explanatory
+ text where appropriate.
+
+
+ The formal specification of the TSF subsystems shall
+ describe the TSF using a formal style, supported by
+ informal, explanatory text where appropriate.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The proof of correspondence between the formal
+ specifications of the TSF subsystems and of the functional
+ specification shall demonstrate that all behaviour described
+ in the TOE design is a correct and complete refinement of
+ the TSFI that invoked it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The guidance documents class provides the requirements for
+ guidance documentation for all user roles. For the secure
+ preparation and operation of the TOE it is necessary to
+ describe all relevant aspects for the secure handling of the
+ TOE. The class also addresses the possibility of unintended
+ incorrect configuration or handling of the TOE.
+
+ In many cases it may be appropriate that guidance is provided
+ in separate documents for preparation and operation of the
+ TOE, or even separate for different user roles as end-users,
+ administrators, application programmers using software or
+ hardware interfaces, etc.
+
+ The guidance documents class is subdivided into two families
+ which are concerned with the preparative user guidance (what
+ has to be done to transform the delivered TOE into its
+ evaluated configuration in the operational environment as
+ described in the ST) and with the operational user guidance
+ (what has to be done during the operation of the TOE in its
+ evaluated configuration).
+
+
+
+ Assurance class defines
+ requirements directed at the understandability, coverage and
+ completeness of the preparative and operational documentation
+ provided by the developer. This documentation, which provides
+ information for all user roles, is an important factor in the
+ secure preparation and operation of the TOE.
+
+
+
+ The purpose of the guidance document activity is to judge the
+ adequacy of the documentation describing how the user can
+ handle the TOE in a secure manner. Such documentation should
+ take into account the various types of users (e.g. those who
+ accept, install, administrate or operate the TOE) whose
+ incorrect actions could adversely affect the security of the
+ TOE or of their own data.
+
+ The guidance documents class is subdivided into two families
+ which are concerned firstly with the preparative procedures
+ (all that has to be done to transform the delivered TOE into
+ its evaluated configuration in the environment as described in
+ the ST, i.e. accepting and installing the TOE) and secondly
+ with the operational user guidance (all that has to be done
+ during the operation of the TOE in its evaluated
+ configuration, i.e. operation and administration).
+
+
+
+ The guidance documents activity applies to those functions and
+ interfaces which are related to the security of the TOE. The
+ secure configuration of the TOE is described in the ST.
+
+
+
+
+ Operational user guidance refers to written material that is
+ intended to be used by all types of users of the TOE in its
+ evaluated configuration: end-users, persons responsible for
+ maintaining and administering the TOE in a correct manner
+ for maximum security, and by others (e.g. programmers) using
+ the TOE's external interfaces. Operational user guidance
+ describes the security functionality provided by the TSF,
+ provides instructions and guidelines (including warnings),
+ helps to understand the TSF and includes the
+ security-critical information, and the security-critical
+ actions required, for its secure use. Misleading and
+ unreasonable guidance should be absent from the guidance
+ documentation, and secure procedures for all modes of
+ operation should be addressed. Insecure states should be
+ easy to detect.
+
+ The operational user guidance provides a measure of
+ confidence that non-malicious users, administrators,
+ application providers and others exercising the external
+ interfaces of the TOE will understand the secure operation
+ of the TOE and will use it as intended. The evaluation of
+ the user guidance includes investigating whether the TOE can
+ be used in a manner that is insecure but that the user of
+ the TOE would reasonably believe to be secure. The objective
+ is to minimise the risk of human or other errors in
+ operation that may deactivate, disable, or fail to activate
+ security functionality, resulting in an undetected insecure
+ state.
+
+
+
+ Requirements for operational user guidance help ensure that
+ all types of users are able to operate the TOE in a secure
+ manner (e.g. the usage constraints assumed by the PP or ST
+ must be clearly explained and illustrated). It should be
+ excluded that the TOE can be used in a manner that is
+ insecure but that the user of the TOE would reasonably
+ believe to be secure. Operational user guidance is the
+ primary vehicle available to the developer for providing the
+ TOE users with the necessary background and specific
+ information on how to correctly use the TOE's protection
+ functions.
+
+ Operational user guidance must do two things. First, it
+ needs to explain what the security functionality accessible
+ by the user does and how it is to be used, so that users are
+ able to consistently and effectively protect their
+ information. Second, it needs to explain the user's role in
+ maintaining the TOE's security.
+
+
+
+ This family contains only one component.
+
+
+
+ There may be different user roles or groups that are
+ recognised by the TOE and that can interact with the
+ TSF. These user roles and groups should be taken into
+ consideration by the operational user guidance. They may be
+ roughly grouped into administrators and non-administrative
+ users, or more specifically grouped into persons responsible
+ for receiving, accepting, installing and maintaining the
+ TOE, application programmers, revisors, auditors,
+ daily-management, end-users. Each role can encompass an
+ extensive set of capabilities, or can be a single
+ one.
+
+ The requirement
+ encompasses the aspect that any warnings to the users during
+ operation of a TOE with regard to the security problem
+ definition and the security objectives for the operational
+ environment described in the PP/ST are appropriately covered
+ in the user guidance.
+
+ The concept of secure values, as employed in , has relevance where a user
+ has control over security parameters. Guidance needs to be
+ provided on secure and insecure settings for such
+ parameters.
+
+ requires that the
+ user guidance describes the appropriate reactions to all
+ security-relevant events. Although many security-relevant
+ events are the result of performing functions, this need not
+ always be the case (e.g. the audit log fills up, an
+ intrusion is detected). Furthermore, a security-relevant
+ event may happen as a result of a specific chain of
+ functions or, conversely, several security-relevant events
+ may be triggered by one function.
+
+ requires that the
+ user guidance is clear and reasonable. Misleading or
+ unreasonable guidance may result in a user of the TOE
+ believing that the TOE is secure when it is not.
+
+ An example of misleading guidance would be the description
+ of a single guidance instruction that could be parsed in
+ more than one way, one of which may result in an insecure
+ state.
+
+ An example of unreasonable guidance would be a
+ recommendation to follow a procedure that is so complicated
+ that it cannot reasonably be expected that users will follow
+ this guidance.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the user guidance describes for each user role the
+ security functionality and interfaces provided by the TSF,
+ provides instructions and guidelines for the secure use of
+ the TOE, addresses secure procedures for all modes of
+ operation, facilitates prevention and detection of
+ insecure TOE states, or whether it is misleading or
+ unreasonable.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design, if applicable;
+
+
+ the user guidance;
+
+
+
+
+ The developer shall provide operational user guidance.
+
+
+ The operational user guidance shall describe, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+
+ The operational user guidance shall describe, for each user
+ role, how to use the available interfaces provided by the
+ TOE in a secure manner.
+
+
+ The operational user guidance shall describe, for each user
+ role, the available functions and interfaces, in particular
+ all security parameters under the control of the user,
+ indicating secure values as appropriate.
+
+
+ The operational user guidance shall, for each user role,
+ clearly present each type of security-relevant event
+ relative to the user-accessible functions that need to be
+ performed, including changing the security characteristics
+ of entities under the control of the TSF.
+
+
+ The operational user guidance shall identify all possible
+ modes of operation of the TOE (including operation following
+ failure or operational error), their consequences and
+ implications for maintaining secure operation.
+
+
+ The operational user guidance shall, for each user role,
+ describe the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+
+ The operational user guidance shall be clear and reasonable.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+ The configuration of the TOE may allow different user
+ roles to have dissimilar privileges in making use of the
+ different functions of the TOE. This means that some
+ users are authorised to perform certain functions, while
+ other users may not be so authorised. These functions
+ and privileges should be described, for each user role,
+ by the user guidance.
+
+ The user guidance identifies, for each user role, the
+ functions and privileges that must be controlled, the
+ types of commands required for them, and the reasons for
+ such commands. The user guidance should contain warnings
+ regarding the use of these functions and
+ privileges. Warnings should address expected effects,
+ possible side effects, and possible interactions with
+ other functions and privileges.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the secure use of the available interfaces
+ provided by the TOE.
+
+ The user guidance should provide advice regarding
+ effective use of the TSF (e.g. reviewing password
+ composition practises, suggested frequency of user file
+ backups, discussion on the effects of changing user
+ access privileges).
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the available security functionality and
+ interfaces, in particular all security parameters under
+ the control of the user, indicating secure values as
+ appropriate.
+
+ The user guidance should contain an overview of the
+ security functionality that is visible at the user
+ interfaces.
+
+ The user guidance should identify and describe the
+ purpose, behaviour, and interrelationships of the
+ security interfaces and functionality.
+
+ For each user-accessible interface, the user guidance
+ should:
+
+
+ describe the method(s) by which the interface is
+ invoked (e.g. command-line, programming-language
+ system call, menu selection, command button);
+
+
+ describe the parameters to be set by the user, their
+ particular purposes, valid and default values, and
+ secure and insecure use settings of such parameters,
+ both individually or in combination;
+
+
+ describe the immediate TSF response, message, or
+ code returned.
+
+
+
+ The evaluator should consider the functional
+ specification and the ST to determine that the TSF
+ described in these documents is consistent to the
+ operational user guidance. The evaluator has to ensure
+ that the operational user guidance is complete to allow
+ the secure use through the TSFI available to all types
+ of human users. The evaluator may, as an aid, prepare an
+ informal mapping between the guidance and these
+ documents. Any omissions in this mapping may indicate
+ incompleteness.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, each type of security-relevant event relative to
+ the user functions that need to be performed, including
+ changing the security characteristics of entities under
+ the control of the TSF and operation following failure
+ or operational error.
+
+ All types of security-relevant events are detailed for
+ each user role, such that each user knows what events
+ may occur and what action (if any) he may have to take
+ in order to maintain security. Security-relevant events
+ that may occur during operation of the TOE (e.g. audit
+ trail overflow, system crash, updates to user records,
+ such as when a user account is removed when the user
+ leaves the organisation) are adequately defined to allow
+ user intervention to maintain secure operation.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance and other evaluation evidence to determine that
+ the guidance identifies all possible modes of operation
+ of the TOE (including, if applicable, operation
+ following failure or operational error), their
+ consequences and implications for maintaining secure
+ operation.
+
+ Other evaluation evidence, particularly the functional
+ specification, provide an information source that the
+ evaluator should use to determine that the guidance
+ contains sufficient guidance information.
+
+ If test documentation is included in the assurance
+ package, then the information provided in this evidence
+ can also be used to determine that the guidance contains
+ sufficient guidance documentation. The detail provided
+ in the test steps can be used to confirm that the
+ guidance provided is sufficient for the use and
+ administration of the TOE.
+
+ The evaluator should focus on a single human visible
+ TSFI at a time, comparing the guidance for securely
+ using the TSFI with other evaluation evidence, to
+ determine that the guidance related to the TSFI is
+ sufficient for the secure usage (i.e. consistent with
+ the SFRs) of that TSFI. The evaluator should also
+ consider the relationships between interfaces, searching
+ for potential conflicts.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+ The evaluator analyses the security objectives for the
+ operational environment in the ST and determines that
+ for each user role, the relevant security measures are
+ described appropriately in the user guidance.
+
+ The security measures described in the user guidance
+ should include all relevant external procedural,
+ physical, personnel and connectivity measures.
+
+ Note that those measures relevant for secure
+ installation of the TOE are examined in .
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is clear.
+
+ The guidance is unclear if it can reasonably be
+ misconstrued by an administrator or user, and used in a
+ way detrimental to the TOE, or to the security provided
+ by the TOE.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is reasonable.
+
+ The guidance is unreasonable if it makes demands on the
+ TOE's usage or operational environment that are
+ inconsistent with the ST or unduly onerous to maintain
+ security.
+
+
+
+
+
+
+
+ Preparative procedures are useful for ensuring that the TOE
+ has been received and installed in a secure manner as
+ intended by the developer. The requirements for preparation
+ call for a secure transition from the delivered TOE to its
+ initial operational environment. This includes investigating
+ whether the TOE can be configured or installed in a manner
+ that is insecure but that the user of the TOE would
+ reasonably believe to be secure.
+
+
+
+ Preparation requires that the delivered copy of the TOE is
+ accepted, configured and activated by the user to exhibit
+ the protection properties as needed during operation of the
+ TOE. The preparative procedures provide confidence that the
+ user will be aware of the TOE configuration parameters and
+ how they can affect the TSF.
+
+
+
+ This family contains only one component.
+
+
+
+ It is recognised that the application of these requirements
+ will vary depending on aspects such as whether the TOE is
+ delivered in an operational state, or whether it has to be
+ installed at the TOE owner's site, etc.
+
+ The first process covered by the preparative procedures is
+ the consumer's secure acceptance of the received TOE in
+ accordance with the developer's delivery procedures. If the
+ developer has not defined delivery procedures, security of
+ the acceptance has to be ensured otherwise.
+
+ Installation of the TOE includes transforming its
+ operational environment into a state that conforms to the
+ security objectives for the operational environment provided
+ in the ST.
+
+ It might also be the case that no installation is necessary,
+ for example a smart card. In this case it may be
+ inappropriate to require and analyse installation
+ procedures.
+
+ The requirements in this assurance family are presented
+ separately from those in the family, due to the infrequent, possibly
+ one-time use of the preparative procedures.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the procedures and steps for the secure preparation of the
+ TOE have been documented and result in a secure
+ configuration.
+
+
+
+ The preparative procedures refer to all acceptance and
+ installation procedures, that are necessary to progress
+ the TOE to the secure configuration as described in the
+ ST.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE including its preparative procedures;
+
+
+ the description of developer's delivery procedures, if
+ applicable;
+
+
+
+
+ The developer shall provide the TOE including its
+ preparative procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure acceptance
+ of the delivered TOE in accordance with the developer's
+ delivery procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure
+ installation of the TOE and for the secure preparation of
+ the operational environment in accordance with the security
+ objectives for the operational environment as described in
+ the ST.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+ The evaluator shall examine the provided acceptance
+ procedures to determine that they describe the steps
+ necessary for secure acceptance of the TOE in accordance
+ with the developer's delivery procedures.
+ If it is not anticipated by the developer's delivery
+ procedures that acceptance procedures will or can be
+ applied, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+ The acceptance procedures should include as a minimum,
+ that the user has to check that all parts of the TOE as
+ indicated in the ST have been delivered in the correct
+ version.
+
+ The acceptance procedures should reflect the steps the
+ user has to perform in order to accept the delivered TOE
+ that are implied by the developer's delivery
+ procedures.
+
+ The acceptance procedures should provide detailed
+ information about the following, if applicable:
+
+
+ making sure that the delivered TOE is the complete
+ evaluated instance;
+
+
+ detecting modification/masquerading of the delivered
+ TOE.
+
+
+
+
+
+
+
+ The evaluator shall examine the provided installation
+ procedures to determine that they describe the steps
+ necessary for secure installation of the TOE and the
+ secure preparation of the operational environment in
+ accordance with the security objectives in the
+ ST.
+
+ If it is not anticipated that installation procedures
+ will or can be applied (e.g. because the TOE may already
+ be delivered in an operational state), this work unit is
+ not applicable, and is therefore considered to be
+ satisfied.
+
+ The installation procedures should provide detailed
+ information about the following, if applicable:
+
+
+ minimum system requirements for secure installation;
+
+
+ requirements for the operational environment in
+ accordance with the security objectives provided by
+ the ST;
+
+ the steps the user has to perform in order to get to an
+ operational TOE being commensurate with its evaluated
+ configuration. Such a description shall include - for each step
+ - a clear scheme for the decision on the next step depended on
+ success, failure or problems at the current step;
+
+
+ changing the installation specific security
+ characteristics of entities under the control of the
+ TSF (for example parameters, settings, passwords);
+
+
+ handling exceptions and problems.
+
+
+
+
+
+ The evaluator shall apply the preparative procedures to
+ confirm that the TOE can be prepared securely for operation.
+
+
+ The evaluator shall perform all user procedures
+ necessary to prepare the TOE to determine that the TOE
+ and its operational environment can be prepared securely
+ using only the supplied preparative procedures.
+ Preparation requires the evaluator to advance the
+ TOE from a deliverable state to the state in which it is
+ operational, including acceptance and installation of
+ the TOE, and enforcing the SFRs consistent with the
+ security objectives for the TOE specified in the
+ ST.
+
+ The evaluator should follow only the developer's
+ procedures and may perform the activities that customers
+ are usually expected to perform to accept and install
+ the TOE, using the supplied preparative procedures only.
+ Any difficulties encountered during such an exercise may
+ be indicative of incomplete, unclear or unreasonable guidance.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+ If it is known that the TOE will be used as a dependent
+ component for a composed TOE evaluation, then the
+ evaluator should ensure that the operational environment
+ is satisfied by the base component used in the composed
+ TOE.
+
+
+
+
+
+
+
+
+ Life-cycle support is an aspect of establishing discipline and
+ control in the processes of refinement of the TOE during its
+ development and maintenance. Confidence in the correspondence
+ between the TOE security requirements and the TOE is greater
+ if security analysis and the production of the evidence are
+ done on a regular basis as an integral part of the development
+ and maintenance activities.
+
+ In the product life-cycle it is distinguished whether the TOE
+ is under the responsibility of the developer or the user
+ rather than whether it is located in the development or user
+ environment. The point of transition is the moment where the
+ TOE is handed over to the user. This is also the point of
+ transition from the to the class.
+
+ The class consists of seven
+ families. is the high-level
+ description of the TOE life-cycle; a more detailed description of the management
+ of the configuration items.
+ requires a minimum set of configuration items to be managed in
+ the defined way. is
+ concerned with the developer's physical, procedural,
+ personnel, and other security measures; with the development tools and implementation
+ standards used by the developer; with the handling of security flaws. defines the procedures used for
+ the delivery of the TOE to the consumer. Delivery processes
+ occurring during the development of the TOE are denoted rather
+ as transportations, and are handled in the context of
+ integration and acceptance procedures in other families of
+ this class.
+
+ Throughout this class, development and related terms
+ (developer, develop) are meant in the more general sense to
+ comprise development and production, whereas
+ production specifically means the process of transforming the
+ implementation representation into the final TOE.
+
+
+
+ Assurance class defines
+ requirements for assurance through the adoption of a well
+ defined life-cycle model for all the steps of the TOE
+ development, including flaw remediation procedures and
+ policies, correct use of tools and techniques and the security
+ measures used to protect the development environment.
+
+ Configuration management (CM) helps to ensure that the
+ integrity of the TOE is preserved, by preventing unauthorised
+ modifications, additions, or deletions to the TOE, thus
+ providing assurance that the TOE and documentation used for
+ evaluation are the ones prepared for distribution.
+
+ The delivery procedures define requirements for the measures,
+ procedures, and standards concerned with secure delivery of
+ the TOE, ensuring that the security protection offered by the
+ TOE is not compromised during the transfer to the user.
+
+
+
+ The purpose of the life-cycle support activity is to determine
+ the adequacy of the security procedures that the developer
+ uses during the development and maintenance of the TOE. These
+ procedures include the life-cycle model used by the developer,
+ the configuration management, the security measures used
+ throughout TOE development, the tools used by the developer
+ throughout the life-cycle of the TOE, the handling of security
+ flaws, and the delivery activity.
+
+ Poorly controlled development and maintenance of the TOE can
+ result in vulnerabilities in the implementation. Conformance
+ to a defined life-cycle model can help to improve controls in
+ this area. A measurable life-cycle model used for the TOE can
+ remove ambiguity in assessing the development progress of the
+ TOE.
+
+ The purpose of the configuration management activity is to
+ assist the consumer in identifying the evaluated TOE, to
+ ensure that configuration items are uniquely identified, and
+ the adequacy of the procedures that are used by the developer
+ to control and track changes that are made to the TOE. This
+ includes details on what changes are tracked, how potential
+ changes are incorporated, and the degree to which automation
+ is used to reduce the scope for error.
+
+ Developer security procedures are intended to protect the TOE
+ and its associated design information from interference or
+ disclosure. Interference in the development process may allow
+ the deliberate introduction of vulnerabilities. Disclosure of
+ design information may allow vulnerabilities to be more easily
+ exploited. The adequacy of the procedures will depend on the
+ nature of the TOE and the development process.
+
+ The use of well-defined development tools and the application
+ of implementation standards by the developer and by third
+ parties involved in the development process help to ensure
+ that vulnerabilities are not inadvertently introduced during
+ refinement.
+
+ The flaw remediation activity is intended to track security
+ flaws, to identify corrective actions, and to distribute the
+ corrective action information to TOE users.
+
+ The purpose of the delivery activity is to judge the adequacy
+ of the documentation of the procedures used to ensure that the
+ TOE is delivered to the consumer without modification.
+
+
+
+
+ Configuration management (CM) is one means for increasing
+ assurance that the TOE meets the SFRs. CM establishes this
+ by requiring discipline and control in the processes of
+ refinement and modification of the TOE and the related
+ information. CM systems are put in place to ensure the
+ integrity of the portions of the TOE that they control, by
+ providing a method of tracking any changes, and by ensuring
+ that all changes are authorised.
+
+ The objective of this family is to require the developer's
+ CM system to have certain capabilities. These are meant to
+ reduce the likelihood that accidental or unauthorised
+ modifications of the configuration items will occur. The CM
+ system should ensure the integrity of the TOE from the early
+ design stages through all subsequent maintenance
+ efforts.
+
+ The objective of introducing automated CM tools is to
+ increase the effectiveness of the CM system. While both
+ automated and manual CM systems can be bypassed, ignored, or
+ proven insufficient to prevent unauthorised modification,
+ automated systems are less susceptible to human error or
+ negligence.
+
+ The objectives of this family include the following:
+
+
+ ensuring that the TOE is correct and complete before it
+ is sent to the consumer;
+
+
+ ensuring that no configuration items are missed during
+ evaluation;
+
+
+ preventing unauthorised modification, addition, or
+ deletion of TOE configuration items.
+
+
+
+
+
+ Configuration management capabilities define the
+ characteristics of the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ the CM system capabilities, the scope of the CM
+ documentation and the evidence provided by the
+ developer.
+
+
+
+ While it is desired that CM be applied from the early design
+ stages and continue into the future, this family requires
+ that CM be in place and in use prior to the end of the
+ evaluation.
+
+ In the case where the TOE is a subset of a product, the
+ requirements of this family apply only to the TOE
+ configuration items, not to the product as a whole.
+
+ For developers that have separate CM systems for different
+ life-cycle phases (for example development, production
+ and/or the final product), it is required to document all of
+ them. For evaluation purposes, the separate CM systems
+ should be regarded as parts of an overall CM system which is
+ addressed in the criteria.
+
+ Similarly, if parts of the TOE are produced by different
+ developers or at different sites, the CM systems being in
+ use at the different places should be regarded as parts of
+ an overall CM system which is addressed in the criteria. In
+ this situation, integration aspects have also to be taken
+ into account.
+
+ Several elements of this family refer to configuration
+ items. These elements identify CM requirements to be imposed
+ on all items identified in the configuration list, but leave
+ the contents of the list to the discretion of the
+ developer. can be used to
+ narrow this discretion by identifying specific items that
+ must be included in the configuration list, and hence
+ covered by CM.
+
+ introduces a
+ requirement that the CM system uniquely identify all
+ configuration items. This also requires that modifications
+ to configuration items result in a new, unique identifier
+ being assigned to the configuration item.
+
+ introduces the
+ requirement that the evidence shall demonstrate that the CM
+ system operates in accordance with the CM plan. Examples of
+ such evidence might be documentation such as screen
+ snapshots or audit trail output from the CM system, or a
+ detailed demonstration of the CM system by the
+ developer. The evaluator is responsible for determining that
+ this evidence is sufficient to show that the CM system
+ operates in accordance with the CM plan.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ support the production of the TOE. This requires that the CM
+ system provide an automated means to assist in determining
+ that the correct configuration items are used in generating
+ the TOE.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ ascertain the changes between the TOE and its preceding
+ version. If no previous version of the TOE exists, the
+ developer still needs to provide an automated means to
+ ascertain the changes between the TOE and a future version
+ of the TOE.
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the
+ TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items.
+
+
+
+ This component contains an implicit evaluator action to
+ determine that the CM system is being used. As the
+ requirements here are limited to identification of the TOE
+ and provision of a configuration list, this action is
+ already covered by, and limited to, the existing work
+ units. At the
+ requirements are expanded beyond these two items, and more
+ explicit evidence of operation is required.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+ Assurance that the CM system uniquely identifies
+ all configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items, and whether the
+ ability to modify these items is properly
+ controlled.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide measures such that only
+ authorised changes are made to the configuration items.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan to determine that they
+ are effective in preventing unauthorised access to the
+ configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan.
+ The CM plan needs not to be a connected document, but it is
+ recommended that there is a single document that describes where
+ the various parts of the CM plan can be found. If the CM plan is
+ no single document, the list in the following work unit gives
+ hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the composed TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For configuration
+ items identified under ,
+ the evaluator confirms that each configuration item possesses
+ a unique identifier in a manner consistent with the unique
+ identification method that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that they
+ are automated and effective in preventing unauthorised
+ access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan.
+ The CM plan does not need to be contained within a single
+ document, but it is recommended that there is a separate
+ document that describes where the various parts of the CM plan
+ can be found. If the CM plan is provided by a set of documents,
+ the list in the following work unit gives guidance regarding the
+ required content.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+ If this work unit is applied to a dependent component
+ that is going to be integrated in a composed TOE, the CM
+ plan should consider the control of base components
+ obtained by the dependent TOE developer.
+
+ When obtaining the components the evaluators are to
+ verify the following:
+
+
+ Transfer of each base component from the base
+ component developer to the integrator (dependent TOE
+ developer) was performed in accordance with the base
+ component TOE's secure delivery procedures, as
+ reported in the base component TOE certification
+ report.
+
+
+ The component received has the same identifiers as
+ those stated in the ST and Certification Report for
+ the component TOE.
+
+
+ All additional material required by a developer for
+ composition (integration) is provided. This is to
+ include the necessary extract of the component TOE's
+ functional specification.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+ Requiring that the CM system be able to identify the
+ version of the implementation representation from which
+ the TOE is generated helps to ensure that the integrity of
+ this material is preserved by the appropriate technical,
+ physical and procedural safeguards.
+
+ Providing an automated means of ascertaining changes
+ between versions of the TOE and identifying which
+ configuration items are affected by modifications to other
+ configuration items assists in determining the impact of
+ the changes between successive versions of the TOE. This
+ in turn can provide valuable information in determining
+ whether changes to the TOE result in all configuration
+ items being consistent with one another.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM documentation shall justify that the acceptance
+ procedures provide for an adequate and appropriate review of
+ changes to all configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM system shall ensure that the person responsible for
+ accepting a configuration item into CM is not the person who
+ developed it.
+
+
+ The CM system shall identify the configuration items that
+ comprise the TSF.
+
+
+ The CM system shall support the audit of all changes to the
+ TOE by automated means, including the originator, date, and
+ time in the audit trail.
+
+
+ The CM system shall provide an automated means to identify
+ all other configuration items that are affected by the
+ change of a given configuration item.
+
+
+ The CM system shall be able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the CM documentation to
+ determine that it justifies that the acceptance
+ procedures provide for an adequate and appropriate
+ review of changes to all configuration items.
+
+ The CM documentation should make it sufficiently clear
+ that by following the acceptance procedures only parts
+ of adequate quality are incorporated into the
+ TOE.
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that
+ they are automated and effective in preventing
+ unauthorised access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it ensures that the person responsible for
+ accepting a configuration item is not the person who
+ developed it.
+
+ The acceptance procedures describe who is responsible
+ for accepting a configuration item. From these
+ descriptions, the evaluator should be able to determine
+ that the person who developed a configuration item is in
+ no case responsible for its acceptance.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it identifies the configuration items that comprise
+ the TSF.
+
+ The CM documentation should describe how the CM system
+ identifies the configuration items that comprise the
+ TSF. The evaluator should select a sample of
+ configuration items covering each type of items,
+ particularly containing TSF and non-TSF items, and check
+ that they are correctly classified by the CM
+ system.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it supports the audit of all changes to the TOE by
+ automated means, including the originator, date, and
+ time in the audit trail.
+
+ The evaluator should inspect a sample of audit trails
+ and check, if they contain the minimum
+ information.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it provides an automated means to identify all
+ other configuration items that are affected by the
+ change of a given configuration item.
+
+ The CM documentation should describe how the CM system
+ identifies all other configuration items that are
+ affected by the change of a given configuration
+ item. The evaluator should select a sample of
+ configuration items, covering all types of items, and
+ exercise the automated means to determine that it
+ identifies all items that are affected by the change of
+ the selected item.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it is able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+ The CM documentation should describe how the CM system
+ identifies the version of the implementation
+ representation from which the TOE is generated. The
+ evaluator should select a sample of the parts used to
+ produce the TOE and should apply the CM system to verify
+ that it identifies the corresponding implementation
+ representation in the correct version.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check that the CM documentation provided
+ includes a CM plan.
+ The CM plan needs not to be a connected document, but it is
+ recommended that there is a single document that describes where
+ the various parts of the CM plan can be found. If the CM plan is
+ no single document, the list in the following work unit gives
+ hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include
+ change control forms, or configuration item access
+ approval forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+ The evaluator shall determine that the application of the
+ production support procedures results in a TOE as provided
+ by the developer for testing activities.
+
+
+ The evaluator shall examine the production support
+ procedures to determine that by following these
+ procedures a TOE would be produced like that one
+ provided by the developer for testing activities.
+
+ If the TOE is a small software TOE and production
+ consists of compiling and linking, the evaluator might
+ confirm the adequacy of the production support
+ procedures by reapplying them himself.
+
+ If the production process of the TOE is more complicated
+ (as for example in the case of a smart card), but has
+ already started, the evaluator should inspect the
+ application of the production support procedures during
+ a visit of the development site. He might compare a copy
+ of the TOE produced in his presence with the samples
+ used for his testing activities.
+
+ For guidance on site visits see .
+
+ Otherwise the evaluator's determination should be based
+ on the documentary evidence provided by the
+ developer.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+ The objective of this family is to identify items to be
+ included as configuration items and hence placed under the
+ CM requirements of .
+ Applying configuration management to these additional items
+ provides additional assurance that the integrity of TOE is
+ maintained.
+
+
+
+ Configuration management scope indicates the TOE items that
+ need to be controlled by the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ which of the following are required to be included as
+ configuration items: the TOE and the evaluation evidence
+ required by the SARs; the parts of the TOE; the
+ implementation representation; security flaws; and
+ development tools and related information.
+
+
+
+ While mandates a list of
+ configuration items and that each item on this list be under
+ CM, leaves the contents of
+ the configuration list to the discretion of the
+ developer. narrows this
+ discretion by identifying items that must be included in the
+ configuration list, and hence come under the CM requirements
+ of .
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself and the evaluation evidence required by the other
+ SARs in the ST under CM provides assurance that they have
+ been modified in a controlled manner with proper
+ authorisations.
+
+
+
+ introduces the
+ requirement that the TOE itself and the evaluation
+ evidence required by the other SARs in the ST be included
+ in the configuration list and hence be subject to the CM
+ requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer performs configuration management on the TOE
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; and the evaluation evidence required by the SARs.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, and the
+ evaluation evidence required by the other SARs under CM
+ provides assurance that they have been modified in a
+ controlled manner with proper authorisations.
+
+
+
+ introduces the
+ requirement that the parts that comprise the TOE (all
+ parts that are delivered to the consumer, for example
+ hardware parts or executable files) be included in the
+ configuration list and hence be subject to the CM
+ requirements of .
+
+ introduces the
+ requirement that the configuration list indicate the
+ developer of each TSF relevant configuration
+ item. ``Developer'' here does not refer to a person, but
+ to the organisation responsible for the development of the
+ item.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; and
+ the parts that comprise the TOE.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+ the TOE itself;
+
+ the parts that comprise the TOE;
+
+ the evaluation evidence required by the SARs.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+
+
+ introduces the
+ requirement that the TOE implementation representation be
+ included in the list of configuration items and hence be
+ subject to the CM requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; and the implementation
+ representation.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+
+
+ introduces the
+ requirement that security flaws be included in the
+ configuration list and hence be subject to the CM
+ requirements of . This
+ requires that information regarding previous security
+ flaws and their resolution be maintained, as well as
+ details regarding current security flaws.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; and security flaw reports and resolution
+ status.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database).
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+ Development tools play an important role in ensuring the
+ production of a quality version of the TOE. Therefore, it
+ is important to control modifications to these
+ tools.
+
+
+
+ introduces the
+ requirement that development tools and other related
+ information be included in the list of configuration items
+ and hence be subject to the CM requirements of . Examples of development tools
+ are programming languages and compilers. Information
+ pertaining to TOE generation items (such as compiler
+ options, generation options, and build options) is an
+ example of information relating to development
+ tools.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, development tools and related information,
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; security flaw reports and resolution status;
+ and development tools and related information.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database);
+
+
+ all tools (incl. test software, if applicable)
+ involved in the development and production of the
+ TOE including the names, versions, configurations
+ and roles of each development tool, and related
+ documentation.
+
+
+ For a software TOE, ``development tools'' are usually
+ programming languages and compiler and ``related documentation''
+ comprises compiler and linker options. For a hardware TOE,
+ ``development tools'' might be hardware design languages,
+ simulation and synthesis tools, compilers, and ``related
+ documentation'' might comprise compiler options again.
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ The concern of this family is the secure transfer of the
+ finished TOE from the development environment into the
+ responsibility of the user.
+
+ The requirements for delivery call for system control and
+ distribution facilities and procedures that detail the
+ measures necessary to provide assurance that the security of
+ the TOE is maintained during distribution of the TOE to the
+ user. For a valid distribution of the TOE, the procedures
+ used for the distribution of the TOE address the objectives
+ identified in the PP/ST relating to the security of the TOE
+ during delivery.
+
+
+
+ Delivery covers the procedures used to maintain security
+ during transfer of the TOE to the user, both on initial
+ delivery and as part of subsequent modification. It includes
+ special procedures or operations required to demonstrate the
+ authenticity of the delivered TOE. Such procedures and
+ measures are the basis for ensuring that the security
+ protection offered by the TOE is not compromised during
+ transfer. While compliance with the delivery requirements
+ cannot always be determined when a TOE is evaluated, it is
+ possible to evaluate the procedures that a developer has
+ developed to distribute the TOE to users.
+
+
+
+ This family contains only one component. An increasing level
+ of protection is established by requiring commensurability
+ of the delivery procedures with the assumed attack potential
+ in the family .
+
+
+
+ Transportations from subcontractors to the developer or
+ between different development sites are not considered here,
+ but in the family .
+
+ The end of the delivery phase is marked by the transfer of
+ the TOE into the responsibility of the user. This does not
+ necessarily coincide with the arrival of the TOE at the
+ user's location.
+
+ The delivery procedures should consider, if applicable,
+ issues such as:
+
+
+ ensuring that the TOE received by the consumer
+ corresponds precisely to the evaluated version of the
+ TOE;
+
+
+ avoiding or detecting any tampering with the actual
+ version of the TOE;
+
+
+ preventing submission of a false version of the TOE;
+
+
+ avoiding unwanted knowledge of distribution of the TOE
+ to the consumer: there might be cases where potential
+ attackers should not know when and how it is delivered;
+
+
+ avoiding or detecting the TOE being intercepted during
+ delivery; and
+
+
+ avoiding the TOE being delayed or stopped during
+ distribution.
+
+
+
+ The delivery procedures should include the recipient's
+ actions implied by these issues. The consistent description
+ of these implied actions is examined in the family, if present.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the delivery documentation describes all procedures used
+ to maintain security of the TOE when distributing the TOE
+ to the user.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the delivery documentation.
+
+
+
+
+ The developer shall document and provide procedures for delivery of the
+ TOE or parts of it to the consumer.
+
+
+ The developer shall use the delivery procedures.
+
+
+ The evaluator shall examine aspects of the delivery
+ process to determine that the delivery procedures are
+ used.
+
+ The approach taken by the evaluator to check the
+ application of delivery procedures will depend on the
+ nature of the TOE, and the delivery process itself. In
+ addition to examination of the procedures themselves,
+ the evaluator seeks some assurance that they are applied
+ in practise. Some possible approaches are:
+
+
+ a visit to the distribution site(s) where practical
+ application of the procedures may be observed;
+
+
+ examination of the TOE at some stage during
+ delivery, or after the user has received it
+ (e.g. checking for tamper proof seals);
+
+
+ observing that the process is applied in practise
+ when the evaluator obtains the TOE through regular
+ channels;
+
+
+ questioning end users as to how the TOE was
+ delivered.
+
+
+
+ For guidance on site visits see .
+
+ It may be the case of a newly developed TOE that the
+ delivery procedures have yet to be exercised. In these
+ cases, the evaluator has to be satisfied that
+ appropriate procedures and facilities are in place for
+ future deliveries and that all personnel involved are
+ aware of their responsibilities. The evaluator may
+ request a ``dry run'' of a delivery if this is
+ practical. If the developer has produced other similar
+ products, then an examination of procedures in their use
+ may be useful in providing assurance.
+
+
+
+ The delivery documentation shall describe all procedures
+ that are necessary to maintain security when distributing
+ versions of the TOE to the consumer.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the delivery documentation
+ to determine that it describes all procedures that are
+ necessary to maintain security when distributing
+ versions of the TOE or parts of it to the
+ consumer.
+
+ The delivery documentation describes proper procedures
+ to maintain security of the TOE during transfer of the
+ TOE or its component parts and to determine the
+ identification of the TOE.
+
+ The delivery documentation should cover the entire TOE,
+ but may contain different procedures for different parts
+ of the TOE. The evaluation should consider the totality
+ of procedures.
+
+ The delivery procedures should be applicable across all
+ phases of delivery from the production environment to
+ the installation environment (e.g. packaging, storage
+ and distribution). Standard commercial practise for
+ packaging and delivery may be acceptable. This includes
+ shrink wrapped packaging, a security tape or a sealed
+ envelope. For the distribution, physical (e.g. public
+ mail or a private distribution service) or electronic
+ (e.g. electronic mail or downloading off the Internet)
+ procedures may be used.
+
+ Cryptographic checksums or a software signature may be
+ used by the developer to ensure that tampering or
+ masquerading can be detected. Tamper proof seals
+ additionally indicate if the confidentiality has been
+ broken. For software TOEs, confidentiality might be
+ assured by using encryption. If availability is of
+ concern, a secure transportation might be
+ required.
+
+ Interpretation of the term ``necessary to maintain
+ security'' will need to consider:
+
+
+ The nature of the TOE (e.g. whether it is software
+ or hardware).
+
+
+ The overall security level stated for the TOE by the
+ chosen level of the Vulnerability Assessment. If the
+ TOE is required to be resistant against attackers of
+ a certain potential in its intended environment,
+ this should also apply to the delivery of the
+ TOE. The evaluator should determine that a balanced
+ approach has been taken, such that delivery does not
+ present a weak point in an otherwise secure
+ development process.
+
+
+ The security objectives provided by the ST. The emphasis in the
+ delivery documentation is likely to be on measures related to
+ integrity, as integrity of the TOE is always important. However,
+ confidentiality and availability of the delivery will be of
+ concern in the delivery of some TOEs; procedures relating to
+ these aspects of the secure delivery should also be discussed in
+ the procedures.
+
+
+
+
+
+
+
+
+
+ Development security is concerned with physical, procedural,
+ personnel, and other security measures that may be used in
+ the development environment to protect the TOE and its
+ parts. It includes the physical security of the development
+ location and any procedures used to select development
+ staff.
+
+
+
+ Development security covers the physical, procedural,
+ personnel, and other security measures used in the
+ development environment. It includes physical security of
+ the development location(s) and controls on the selection
+ and hiring of development staff.
+
+
+
+ The components in this family are levelled on the basis of
+ whether justification of the sufficiency of the security
+ measures is required.
+
+
+
+ This family deals with measures to remove or reduce threats
+ existing at the developer's site.
+
+ The evaluator should visit the site(s) in order to assess
+ evidence for development security. This may include sites of
+ subcontractors involved in the TOE development and
+ production. Any decision not to visit shall be agreed with
+ the evaluation authority.
+
+ Although development security deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, the requirements specify only that the
+ development security measures be in place at the time of
+ evaluation. Furthermore,
+ does not contain any requirements related to the sponsor's
+ intention to apply the development security measures in the
+ future, after completion of the evaluation.
+
+ It is recognised that confidentiality may not always be an
+ issue for the protection of the TOE in its development
+ environment. The use of the word ``necessary'' allows for
+ the selection of appropriate safeguards.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce and provide development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first referring to
+ the ST for any information that may assist in the determination
+ of necessary protection.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material within and out of
+ the development environment and between
+ different development sites in accordance with
+ defined acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ The evaluator should examine whether the following is included
+ in the policies:
+
+ what information relating to the TOE development needs to be
+ kept confidential, and which members of the development
+ staff are allowed to access such material;
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the ,
+ mandating only necessary measures, are dependent on the nature of the TOE,
+ and on information that may be provided in the ST. The evaluators would
+ then determine that such a policy had been applied under this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised. Additionally, sufficiency of the measures
+ as applied is intended be justified.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce and provide development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The development security documentation shall justify that
+ the security measures provide the necessary level of
+ protection to maintain the confidentiality and integrity of
+ the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first referring to
+ the ST for any information that may assist in the determination
+ of necessary protection.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material out of the
+ development environment and between different
+ development sites in accordance with defined
+ acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by the ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in the .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that an appropriate
+ justification is given why the security measures provide
+ the necessary level of protection to maintain the
+ confidentiality and integrity of the TOE.
+
+ Since attacks on the TOE or its related information are
+ assumed in different design and production stages,
+ measures and procedures need to have an appropriate
+ level necessary to prevent those attacks or to make them
+ more difficult.
+
+ Since this level depends on the overall attack potential
+ claimed for the TOE (cf. the component chosen), the development
+ security documentation should justify the necessary
+ level of protection to maintain the confidentiality and
+ integrity of the TOE. This level has to be achieved by
+ the security measures applied.
+
+ The concept of protection measures should be consistent,
+ and the justification should include an analysis of how
+ the measures are mutually supportive. All aspects of
+ development and production on all the different sites
+ with all roles involved up to delivery of the TOE should
+ be analysed.
+
+ Justification may include an analysis of potential
+ vulnerabilities taking the applied security measures
+ into account.
+
+ There may be a convincing argument showing that e.g.
+
+
+ The technical measures and mechanisms of the
+ developer's infrastructure are sufficient for
+ keeping the appropriate security level
+ (e.g. cryptographic mechanisms as well as physical
+ protection mechanisms, properties of the CM system
+ (cf. ));
+
+ The system containing the implementation
+ representation of the TOE (including concerning
+ guidance documents) provides effective protection
+ against logical attacks e.g. by ``Trojan'' code or
+ viruses. It might be adequate, if the implementation
+ representation is kept on an isolated system where
+ only the software necessary to maintain it is
+ installed and where no additional software is
+ installed afterwards.
+
+ Data brought into this system need to be carefully considered to
+ prevent the installation of hidden functionality onto the
+ system. The effectiveness of these measures need to be tested,
+ e.g. by independently trying to get access to the machine,
+ install some additional executable (program, macro etc.) or get
+ some information out of the machine using logical
+ attacks.
+
+ The appropriate organisational (procedural and
+ personal) measures are unconditionally
+ enforced.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ The evaluator should examine whether the following is included
+ in the policies:
+
+ what information relating to the TOE development needs to be
+ kept confidential, and which members of the development
+ staff are allowed to access such material;
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the , mandating only necessary measures, are
+ dependent on the nature of the TOE, and on information
+ that may be provided in the ST. For example, the ST may
+ identify a security objective for the development
+ environment that requires the TOE to be developed by
+ staff that has security clearance. The evaluators would
+ then determine that such a policy had been applied under
+ this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ Flaw remediation requires that discovered security flaws be
+ tracked and corrected by the developer. Although future
+ compliance with flaw remediation procedures cannot be
+ determined at the time of the TOE evaluation, it is possible
+ to evaluate the policies and procedures that a developer has
+ in place to track and correct flaws, and to distribute the
+ flaw information and corrections.
+
+
+
+ Flaw remediation ensures that flaws discovered by the TOE
+ consumers will be tracked and corrected while the TOE is
+ supported by the developer. While future compliance with the
+ flaw remediation requirements cannot be determined when a
+ TOE is evaluated, it is possible to evaluate the procedures
+ and policies that a developer has in place to track and
+ repair flaws, and to distribute the repairs to
+ consumers.
+
+
+
+ The components in this family are levelled on the basis of
+ the increasing extent in scope of the flaw remediation
+ procedures and the rigour of the flaw remediation
+ policies.
+
+
+
+ This family provides assurance that the TOE will be
+ maintained and supported in the future, requiring the TOE
+ developer to track and correct flaws in the
+ TOE. Additionally, requirements are included for the
+ distribution of flaw corrections. However, this family does
+ not impose evaluation requirements beyond the current
+ evaluation.
+
+ The TOE user is considered to be the focal point in the user
+ organisation that is responsible for receiving and
+ implementing fixes to security flaws. This is not
+ necessarily an individual user, but may be an organisational
+ representative who is responsible for the handling of
+ security flaws. The use of the term TOE user recognises that
+ different organisations have different procedures for
+ handling flaw reporting, which may be done either by an
+ individual user, or by a central administrative body.
+
+ The flaw remediation procedures should describe the methods
+ for dealing with all types of flaws encountered. These flaws
+ may be reported by the developer, by users of the TOE, or by
+ other parties with familiarity with the TOE. Some flaws may
+ not be reparable immediately. There may be some occasions
+ where a flaw cannot be fixed and other (e.g. procedural)
+ measures must be taken. The documentation provided should
+ cover the procedures for providing the operational sites
+ with fixes, and providing information on flaws where fixes
+ are delayed (and what to do in the interim) or when fixes
+ are not possible.
+
+ Changes applied to a TOE after its release render it
+ unevaluated; although some information from the original
+ evaluation may still apply. The phrase ``release of the
+ TOE'' used in this family therefore refers to a version of a
+ product that is a release of a certified TOE, to which
+ changes have been applied.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE users.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation.
+
+
+
+
+ The developer shall document and provide flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+ While these requirements do not mandate that there be a
+ publicised means for TOE users to report security flaws,
+ they do mandate that all security flaws that are
+ reported be tracked. That is, a reported security flaw
+ cannot be ignored simply because it comes from outside
+ the developer's organisation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACK DOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer. Flaw remediation guidance from the developer to
+ the TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, and for assurance that the corrections introduce no
+ new security flaws.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document and provide flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that they describe procedures
+ for the developer to accept reports of security flaws or
+ requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure every reported flaw is
+ corrected.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is corrected. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+
+ The procedures describe the process that is taken from
+ the point at which a security flaw is resolved to the
+ point at which the remediation procedures are
+ provided. The procedures for delivering corrective
+ actions should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer, and how to register themselves with the
+ developer so that they may receive these corrective
+ fixes. Flaw remediation guidance from the developer to the
+ TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, for assurance that the corrections introduce no new
+ security flaws, for the establishment of a point of
+ contact for each TOE user, and for the timely issue of
+ corrective actions to TOE users.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document and provide flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The flaw remediation procedures shall include a procedure
+ requiring timely response and the automatic distribution of
+ security flaw reports and the associated corrections to
+ registered users who might be affected by the security flaw.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users may register with the developer, to be
+ eligible to receive security flaw reports and corrections.
+
+
+ The flaw remediation guidance shall identify the specific
+ points of contact for all reports and enquiries about
+ security issues involving the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+ For TOE users who register with the developer (see work
+ unit ), the
+ passive availability of this information is not
+ sufficient. Developers must actively send the
+ information (or a notification of its availability) to
+ registered TOE users.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a means for the developer to
+ receive from TOE user reports of suspected security
+ flaws or requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a timely means of providing
+ the registered TOE users who might be affected with
+ reports about, and associated corrections to, each
+ security flaw.
+
+ The issue of timeliness applies to the issuance of both
+ security flaw reports and the associated
+ corrections. However, these need not be issued at the
+ same time. It is recognised that flaw reports should be
+ generated and issued as soon as an interim solution is
+ found, even if that solution is as drastic as turn off
+ the TOE. Likewise, when a more permanent (and less
+ drastic) solution is found, it should be issued without
+ undue delay.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done in a timely manner.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in automatic distribution of the
+ reports and associated corrections to the registered TOE
+ users who might be affected.
+
+ Automatic distribution does not mean
+ that human interaction with the distribution method is
+ not permitted. In fact, the distribution method could
+ consist entirely of manual procedures, perhaps through a
+ closely monitored procedure with prescribed escalation
+ upon the lack of issue of reports or corrections.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done automatically.
+
+
+
+
+ The evaluator shall examine the flaw remediation procedures to
+ determine that the application of these procedures would help to
+ ensure that every reported flaw is corrected.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is remediated. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+ The procedures describe the process that is taken
+ from the point at which a security flaw is resolved to
+ the point at which the remediation procedures are
+ provided. The procedures for delivering remediation
+ procedures should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it describes a means of
+ enabling the TOE users to register with the
+ developer.
+
+ Enabling the TOE users to register with the
+ developer simply means having a way for each
+ TOE user to provide the developer with a point of
+ contact; this point of contact is to be used to
+ provide the TOE user with information related to
+ security flaws that might affect that TOE user, along
+ with any corrections to the security flaw. Registering
+ the TOE user may be accomplished as part of the
+ standard procedures that TOE users undergo to identify
+ themselves to the developer, for the purposes of
+ registering a software licence, or for obtaining
+ update and other useful information.
+
+ There need not be one registered TOE user per
+ installation of the TOE; it would be sufficient if there
+ were one registered TOE user for an organisation. For
+ example, a corporate TOE user might have a centralised
+ acquisition office for all of its sites. In this case,
+ the acquisition office would be a sufficient point of
+ contact for all of that TOE user's sites, so that all of
+ the TOE user's installations of the TOE have a
+ registered point of contact.
+
+ In either case, it must be possible to associate each
+ TOE that is delivered with an organisation in order to
+ ensure that there is a registered user for each TOE. For
+ organisations that have many different addresses, this
+ assures that there will be no user who is erroneously
+ presumed to be covered by a registered TOE user.
+ It should be noted that TOE users need not
+ register; they must only be provided with a means of
+ doing so. However, users who choose to register must be
+ directly sent the information (or a notification of its
+ availability).
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it identifies specific points
+ of contact for user reports and enquiries about security
+ issues involving the TOE.
+
+ The guidance includes a means whereby registered TOE
+ users can interact with the developer to report
+ discovered security flaws in the TOE or to make
+ enquiries regarding discovered security flaws in the
+ TOE.
+
+
+
+
+
+
+
+ Poorly controlled development and maintenance of the TOE can
+ result in a TOE that does not meet all of its
+ SFRs. Therefore, it is important that a model for the
+ development and maintenance of a TOE be established as early
+ as possible in the TOE's life-cycle.
+
+ Using a model for the development and maintenance of a TOE
+ does not guarantee that the TOE meets all of its SFRs. It is
+ possible that the model chosen will be insufficient or
+ inadequate and therefore no benefits in the quality of the
+ TOE can be observed. Using a life-cycle model that has been
+ approved by a group of experts (e.g. academic experts,
+ standards bodies) improves the chances that the development
+ and maintenance models will contribute to the TOE meeting
+ its SFRs. The use of a life-cycle model including some
+ quantitative valuation adds further assurance in the overall
+ quality of the TOE development process.
+
+
+
+ Life-cycle definition establishes that the engineering
+ practises used by a developer to produce the TOE include the
+ considerations and activities identified in the development
+ process and operational support requirements. Confidence in
+ the correspondence between the requirements and the TOE is
+ greater when quality control and the production of evidence
+ are done on a regular basis as an integral part of the
+ development process and operational support activities. It
+ is not the intent of this component to dictate any specific
+ development process.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements for measurability of the life-cycle
+ model, and for compliance with that model.
+
+
+
+ A life-cycle model encompasses the procedures, tools and
+ techniques used to develop and maintain the TOE. Aspects of
+ the process that may be covered by such a model include
+ design methods, review procedures, project management
+ controls, change control procedures, test methods and
+ acceptance procedures. An effective life-cycle model will
+ address these aspects of the development and maintenance
+ process within an overall management structure that assigns
+ responsibilities and monitors progress.
+
+ There are different types of acceptance situations that are
+ dealt with at different locations in the criteria:
+ acceptance of parts delivered by subcontractors
+ (``integration'') should be treated in this family , acceptance subsequent to
+ internal transportations in , acceptance of parts into the CM system in
+ , and acceptance of the
+ delivered TOE by the consumer in . The first three types may overlap.
+
+ Although life-cycle definition deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, its evaluation adds assurance
+ through an analysis of the life-cycle information for the
+ TOE provided at the time of the evaluation.
+
+ A life-cycle model provides for the necessary control over
+ the development and maintenance of the TOE, if the model
+ enables sufficient minimisation of the danger that the TOE
+ will not meet its security requirement.
+
+ A measurable life-cycle model is a model using some
+ quantitative valuation (arithmetic parameters and/or
+ metrics) of the managed product in order to measure
+ development properties of the product. Typical metrics are
+ source code complexity metrics, defect density (errors per
+ size of code) or mean time to failure. For the security
+ evaluation all those metrics are of relevance, which are
+ used to increase quality by decreasing the probability of
+ faults and thereby in turn increasing assurance in the
+ security of the TOE.
+
+ One should take into account that there exist standardised
+ life cycle models on the one hand (like the waterfall model)
+ and standardised metrics on the other hand (like error
+ density), which may be combined. The CC does not require the
+ life cycle to follow exactly one standard defining both
+ aspects.
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented model of the
+ TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process.
+
+ The description of the life-cycle model should include:
+
+
+ information on the life-cycle phases of the TOE and
+ the boundaries between the subsequent phases;
+
+
+ information on the procedures, tools and techniques
+ used by the developer (e.g. for design, coding,
+ testing, bug-fixing);
+
+
+ overall management structure governing the
+ application of the procedures (e.g. an
+ identification and description of the individual
+ responsibilities for each of the procedures required
+ by the development and maintenance process covered
+ by the life-cycle model);
+
+
+ information on which parts of the TOE are delivered
+ by subcontractors, if subcontractors are involved.
+
+
+
+ does not require the
+ model used to conform to any standard life-cycle
+ model.
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented and measurable
+ model of the TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation;
+
+
+ information about the standard used;
+
+
+ the life-cycle output documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE, that is based
+ on a measurable life-cycle model.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The developer shall measure the TOE development using the
+ measurable life-cycle model.
+
+
+ The developer shall provide life-cycle output documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE, including the
+ details of its arithmetic parameters and/or metrics used to
+ measure the quality of the TOE and/or its development.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The life-cycle output documentation shall provide the
+ results of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process, including the
+ details of its arithmetic parameters and/or metrics used
+ to measure the TOE development.
+
+ The description of the life-cycle model includes:
+
+ information on the life-cycle phases of the TOE and the
+ boundaries between the subsequent phases;
+
+ information on the procedures, tools and techniques used by
+ the developer (e.g. for design, coding, testing,
+ bug-fixing);
+
+ overall management structure governing the application of
+ the procedures (e.g. an identification and description of
+ the individual responsibilities for each of the procedures
+ required by the development and maintenance process covered
+ by the life-cycle model);
+
+ information on which parts of the TOE are delivered by
+ subcontractors, if subcontractors are involved;
+
+ information on the parameters/metrics that are used to
+ measure the TOE development. Metrics standards typically
+ include guides for measuring and producing reliable products
+ and cover the aspects reliability, quality, performance,
+ complexity and cost. For the evaluation all those metrics
+ are of relevance, which are used to increase quality by
+ decreasing the probability of faults and thereby in turn
+ increase assurance in the security of the TOE.
+
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+ For the metrics/measurements used in the life-cycle
+ model, evidence has to be provided that shows how those
+ metrics/measurements usefully contribute to the
+ minimisation of the likelihood of flaws. This can be
+ viewed as the overall goal for measurement in an context. As a consequence the
+ metrics/measurements have to be selected based on their
+ capability to achieve that overall goal or contribute to
+ that. In the first place a metric/measure is suitable
+ with respect to if a
+ correlation between the metric/measure and the number of
+ flaws can be stated with a certain degree of
+ reliability. But also a metric/measure useful for
+ management purposes as for planning and monitoring the
+ TOE development are helpful since badly managed projects
+ are endangered to produce bad quality and to introduce
+ flaws.
+
+ It may be possible to use metrics for quality
+ improvement, for which this use is not obvious. For
+ example a metric to estimate the expected cost of a
+ product development may help quality, if the developer
+ can show that this is used to provide an adequate budget
+ for development projects and that this helps to avoid
+ quality problems arising from resource shortages.
+
+ It is not required that every single step in the life
+ cycle of the TOE is measurable. However the evaluator
+ should see from the description of the measures and
+ procedures that the metrics are appropriate to control
+ the overall quality of the TOE and to minimise possible
+ security flaws by this.
+
+
+
+
+ The evaluator shall examine the life-cycle output
+ documentation to determine that it provides the results
+ of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+ The results of the measurements and the life-cycle
+ progress of the TOE should be in accordance with the
+ life-cycle model.
+
+ The output documentation not only includes numeric values of the
+ metrics but also documents actions taken as a result of the
+ measurements and in accordance with the model. For example there
+ may be a requirement that a certain design phase needs to be
+ repeated, if some error rates measured during testing are
+ outside of a defined threshold. In this case the documentation
+ should show that such action was taken, if indeed the thresholds
+ were not met.
+
+ If the evaluation is conducted in parallel with the
+ development of the TOE it may be possible that quality
+ measurements have not been used in the past. In this
+ case the evaluator should use the documentation of the
+ planned procedures in order to gain confidence that
+ corrective actions are defined if results of quality
+ measurements deviate from some threshold.
+
+
+
+
+
+
+
+ Tools and techniques is an aspect of selecting tools that
+ are used to develop, analyse and implement the TOE. It
+ includes requirements to prevent ill-defined, inconsistent
+ or incorrect development tools from being used to develop
+ the TOE. This includes, but is not limited to, programming
+ languages, documentation, implementation standards, and
+ other parts of the TOE such as supporting runtime
+ libraries.
+
+
+
+ Tools and techniques addresses the need to define the
+ development tools being used to analyse and implement the
+ TOE. It includes requirements concerning the development
+ tools and implementation dependent options of those
+ tools.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements on the description and scope of the
+ implementation standards and the documentation of
+ implementation-dependent options.
+
+
+
+ There is a requirement for well-defined development
+ tools. These are tools that are clearly and completely
+ described. For example, programming languages and computer
+ aided design (CAD) systems that are based on a standard
+ published by standards bodies are considered to be
+ well-defined. Self-made tools would need further
+ investigation to clarify whether they are
+ well-defined.
+
+ The requirement in is
+ especially applicable to programming languages so as to
+ ensure that all statements in the source code have an
+ unambiguous meaning.
+
+ In and , implementation guidelines may be accepted
+ as an implementation standard if they have been approved by
+ some group of experts (e.g. academic experts, standards
+ bodies). Implementation standards are normally public, well
+ accepted and common practise in a specific industry, but
+ developer-specific implementation guidelines may also be
+ accepted as a standard; the emphasis is on the
+ expertise.
+ Tools and techniques distinguishes between the
+ implementation standards applied by the developer () and the implementation
+ standards for ``all parts of the TOE'' () which include third party software,
+ hardware, or firmware. The configuration list introduced in
+ requires that for each TSF
+ relevant configuration item to indicate if it has been
+ generated by the TOE developer or by third party
+ developers.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable
+ results.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the subset of the implementation representation.
+
+
+
+
+ The developer shall provide the documentation identifying each development tool being
+ used for the TOE.
+
+
+ The developer shall document and provide the selected
+ implementation-dependent options of each development tool.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tools is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable results,
+ and whether implementation standards have been
+ applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall provide the documentation identifying each development tool being
+ used for the TOE.
+
+
+ The developer shall document and provide the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe and provide the implementation standards
+ that are being applied by the developer.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is not required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, but only those parts
+ that are developed by the TOE developer himself. The
+ evaluator may consult the configuration list required by
+ the to get the
+ information which parts are developed by the TOE
+ developer, and which by third party developers.
+
+ If the referenced implementation standards are not
+ applied for at least parts of the provided implementation representation,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer and his subcontractors have used
+ well-defined development tools (e.g. programming languages
+ or computer-aided design (CAD) systems) that yield
+ consistent and predictable results, and whether
+ implementation standards have been applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall provide the documentation identifying each development tool being
+ used for the TOE.
+
+
+ The developer shall document and provide the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe and provide the implementation standards
+ that are being applied by the developer and by any
+ third-party providers for all parts of the TOE.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, including third party
+ contributions. This may require the evaluator to visit
+ the sites of contributors. The evaluator may consult the
+ configuration list required by the to see who has developed which part of
+ the TOE.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more other PPs or on packages, that the PP is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ writing an ST or another PP.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+ This standard defines two assurance packages for PP evaluation as follows:
+ Low assurance PP evaluation package;(Standard) PP evaluation package.
+ The assurance components for these packages are defined by table
+ .
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an PP to demonstrate that
+ the PP is sound and internally consistent, and, if the PP is
+ based on one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of a PP. The
+ requirements and methodology for PP evaluation are identical
+ for each PP evaluation, regardless of the EAL (or other set of
+ assurance requirements) that is claimed in the PP. The
+ evaluation methodology in this Clause is based on the
+ requirements on the PP as specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The PP is the description of a TOE type. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ an ST or another PP.
+
+
+
+
+ While evaluating a PP that is based on one or more certified
+ PPs, it may be possible to re-use the fact that these PPs were
+ certified. The potential for re-use of the result of a certified
+ PP is greater if the PP under evaluation does not add threats,
+ OSPs, security objectives and/or security requirements to those
+ of the PP that conformance is being claimed to. If the PP under
+ evaluation contains much more than the certified PP, re-use may
+ not be useful at all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP that conformance is being
+ claimed to contains a set of security requirements, and these
+ were determined to be internally consistent during its
+ evaluation. If the PP under evaluation uses the exact same
+ requirements, the consistency analysis does not have to be
+ repeated during the PP evaluation. If the PP under evaluation
+ adds one or more requirements, or performs operations on these
+ requirements, the analysis will have to be repeated. However, it
+ may be possible to save work in this consistency analysis by
+ using the fact that the original requirements are internally
+ consistent. If the original requirements are internally
+ consistent, the evaluator only has to determine that:
+
+ the set of all new and/or changed requirements is internally
+ consistent, and
+
+ the set of all new and/or changed requirements is consistent
+ with the original requirements.
+
+ The evaluator notes in the ETR each case where analyses
+ are not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way.
+
+ Evaluation of the PP introduction is required to demonstrate
+ that the PP is correctly identified, and that the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The PP introduction describes the TOE in a narrative
+ way.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the PP is correctly identified, and whether the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a PP introduction.
+
+
+ The PP introduction shall contain a PP reference and a TOE
+ overview.
+
+
+ The PP reference shall uniquely identify the PP.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware available to the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the PP introduction
+ contains a PP reference and a TOE overview.
+
+
+
+
+ The evaluator shall examine the PP reference to
+ determine that it uniquely identifies the PP.
+
+ The evaluator determines that the PP reference
+ identifies the PP itself, so that it may be easily
+ distinguished from other PPs, and that it also uniquely
+ identifies each version of the PP, e.g. by including a
+ version number and/or a date of publication.
+
+ The PP should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features expected of the TOE. The TOE overview should
+ enable consumers and potential TOE developers to quickly
+ determine whether the PP is of interest to them.
+
+ The evaluator determines that the overview is clear
+ enough for TOE developers and consumers, and sufficient
+ to give them a general understanding of the intended
+ usage and major security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware available to the TOE.
+
+ While some TOEs may run stand-alone, other TOEs (notably
+ software TOEs) need additional hardware, software or
+ firmware to operate. In this subclause of the PP, the PP
+ author lists all hardware, software, and/or firmware
+ that will be available for the TOE to run on.
+
+ This identification should be detailed enough for
+ potential consumers and TOE developers to determine
+ whether their TOE may operate with the listed hardware,
+ software and firmware.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs and other PPs are to claim conformance with the
+ PP.
+
+
+
+ Conformance claims describes how the Protection Profile
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the PP conforms to the CC, other PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP;
+
+
+ the PP(s) that the PP claims conformance to;
+
+
+ the package(s) that the PP claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The developer shall provide a conformance statement.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the PP claims
+ conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the PP claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ PP to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance statement shall describe the conformance
+ required of any PPs/STs to the PP as strict-PP or
+ demonstrable-PP conformance.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the PP claims
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this PP. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the PP.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the PP.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the PP claims conformance.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+ The evaluator determines that any referenced PPs
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the PP claims conformance.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The relation between the types may be simple: a firewall
+ PP claiming conformance to another firewall PP, or more
+ complex: a smart card PP claiming conformance to a number
+ of other PPs at the same time: a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the PP under evaluation does not claim conformance
+ with another PP, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If the PP to which conformance is being claimed does not
+ have a statement of security problem definition, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether
+
+
+ the threats in the PP under evaluation are a
+ superset of or identical to the threats in the PP to
+ which conformance is being claimed;
+
+
+ the OSPs in the PP under evaluation are a superset
+ of or identical to the OSPs in the PP to which
+ conformance is being claimed;
+
+
+ the assumptions in the PP claiming conformance are identical to the assumptions in the PP
+ to which conformance is being claimed, with two possible exceptions described
+ in the following two bullet points;
+
+ an assumption (or part of an assumption) from the PP to which conformance is claimed, can be omitted,
+ if all security objectives for the operational environment addressing this assumption (or part of an
+ assumption) are replaced by security objectives for the TOE;
+ an assumption can be added to the assumptions defined in the PP to which conformance is claimed,
+ if a justification is given, why the new assumption neither mitigates a threat (or a part of a threat)
+ meant to be addressed by security objectives for the TOE in the PP to which conformance is claimed,
+ nor fulfills an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the PP
+ to which conformance is claimed.
+ When examining a PP, which omits assumptions
+ from another PP to which conformance is claimed, or adds new assumptions, the evaluator shall carefully determine,
+ if the conditions given above are fulfilled.
+ The following discussion gives some motivation and examples for these cases:
+
+ Example for omitting an assumption: A PP to which conformance is claimed, may contain an assumption
+ stating that the operational environment prevents unauthorized modification or interception of data sent
+ to an external interface of the TOE. This may be the case if the TOE accepts data in clear text and without
+ integrity protection at this interface and is assumed to be located in a secure operational environment,
+ which will prevent attackers from accessing these data. The assumption will then be mapped in the PP,
+ to which conformance is claimed, to some objective for the operational environment stating that the data
+ interchanged at this interface are protected by adequate measures in the operational environment.
+ If a PP claiming this PP, defines a more secure TOE,
+ which has an additional security objective stating that the TOE itself protects these data, for example by
+ providing a secure channel for encryption and integrity protection of all data transferred via this interface,
+ the corresponding objective and assumption for the operational environment can be omitted from the PP claiming
+ conformance. This is also called re-assigning of the objective, since the objective is re-assigned
+ from the operational environment to the TOE. Note, that this TOE is still secure in an operational
+ environment fulfilling the omitted assumption and therefore still fulfills the PP to which conformance
+ is claimed.
+ Example for adding an assumption: In this example the PP to which conformance is claimed, is designed
+ to specify requirements for a TOE of type "Firewall" and the author of another PP wishes to claim conformance
+ to this PP for a TOE, which implements a firewall, but additionally provides
+ the functionality of a virtual private network (VPN) component. For the VPN functionality the TOE needs
+ cryptographic keys and these keys may also have to be handled securely by the operational environment
+ (e. g. if symmetric keys are used to secure the network connection and therefore need to be provided
+ in some secure way to other components in the network). In this case it is acceptable to add an assumption
+ that the cryptographic keys used by the VPN are handled securely by the operational environment.
+ This assumption does not address threats or OSPs of the PP to which conformance is claimed, and therefore
+ fulfills the conditions stated above.
+ Counterexample for adding an assumption: In a variant of the first example a PP to which conformance is
+ claimed, may already contain an objective for the TOE to provide a secure channel for one of its interfaces,
+ and this objective is mapped to a threat of unauthorized modification or reading of the data on this interface.
+ In this case it is clearly not allowed for another PP claiming this PP, to add an assumption for the operational
+ environment, which assumes that the operational
+ environment protects data on this interface against modification or unauthorized reading of the data.
+ This assumption would reduce a threat, which is meant to be addressed by the TOE. Therefore a TOE
+ fulfilling a PP with this added assumption would not automatically fulfill the PP
+ to which conformance is claimed, anymore and this addition is therefore not allowed.
+ Second counterexample for adding an assumption: In the example above of a TOE implementing a firewall it would
+ not be admissible to add a general assumption that the TOE is only connected to trusted devices, because this
+ would obviously remove essential threats relevant for a firewall (namely that there is untrusted IP traffic,
+ which needs to be filtered). Therefore this addition would not be allowed.
+
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ problem definition of the PP under evaluation is
+ equivalent or more restrictive than the statement of
+ security problem definition in the PP to which
+ conformance is being claimed.
+ For this, the conformance claim rationale needs to demonstrate
+ that the security problem definition in the PP claiming conformance is equivalent (or more restrictive) than the security
+ problem definition in the PP to which conformance is claimed. This means that:
+
+ all TOEs that would meet the security problem definition in the PP claiming conformance also meet the security problem
+ definition in the PP to which conformance is claimed. This can also be shown indirectly by demonstrating that every
+ event, which realizes a threat defined in the PP to which conformance is claimed, or violates an OSP defined in the PP
+ to which conformance is claimed, would also realize a threat stated in the PP claiming conformance or violate an OSP
+ defined in the PP claiming conformance.
+ Note that fulfilling an OSP stated in the PP claiming conformance may avert a threat stated in the PP to which
+ conformance is claimed, or that averting a threat stated in the PP claiming conformance may fulfill an OSP
+ stated in the PP to which conformance is claimed, so threats and OSPs can substitute each other;
+ all operational environments that would meet the security problem definition in the PP to which conformance
+ is claimed, would also meet the security problem definition in the PP claiming conformance (with one exception
+ in the next bullet);
+ besides a set of assumptions in the PP claiming conformance needed to demonstrate conformance to the SPD of the PP
+ to which conformance is claimed, an PP claiming conformance may specify further assumptions, but only if these
+ additional assumptions are independent of and do not affect the security problem definition as defined in the PP
+ to which conformance is claimed. More detailed, there are no assumptions in the PP claiming conformance that exclude
+ threats to the TOE that need to be countered by the TOE according to the PP to which conformance is claimed.
+ Similarly, there are no assumptions in the PP claiming conformance that realize aspects of an OSP stated in the PP
+ to which conformance is claimed, which are meant to be fulfilled by the TOE according to the PP to which conformance
+ is claimed.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PPs, with the statement of security
+ objectives in the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which conformance is being claimed, no
+ conformance claim rationale is required. Instead, the
+ evaluator determines whether:
+ The PP under evaluation contains all security
+ objectives for the TOE of the PP to which
+ conformance is being claimed. Note that it is
+ allowed for the PP under evaluation to have
+ additional security objectives for the TOE;
+ The security objectives for the operational environment in the PP claiming conformance are identical to the security objectives
+ for the operational environment in the PP to which conformance is being claimed, with two possible
+ exceptions described in the following two bullet points;
+
+ a security objective for the operational environment (or part of such security objective) from the PP
+ to which conformance is claimed, can be replaced by the same (part of the) security objective stated for the TOE;
+
+ a security objective for the operational environment can be added to the objectives defined in the PP
+ to which conformance is claimed, if a justification is given, why the new objective neither mitigates a threat
+ (or a part of a threat) meant to be addressed by security objectives for the TOE in the PP to which conformance
+ is claimed, nor fulfills an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in
+ the PP to which conformance is claimed.
+
+ When examining a PP claiming another PP which omits security objectives for the
+ operational environment from the PP to which conformance is claimed, or adds new security objectives for the
+ operational environment, the evaluator shall carefully determine, if the conditions given above are fulfilled.
+ The examples given for the case of assumptions in the preceding work unit are also valid here.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ objectives in the PP to which conformance is being
+ claimed.
+ For this the conformance claim rationale needs to demonstrate
+ that the security objectives in the PP claiming conformance are equivalent (or more restrictive) than the security
+ objectives in the PP to which conformance is claimed. This means that:
+
+ all TOEs that would meet the security objectives for the TOE in the PP claiming conformance also meet the
+ security objectives for the TOE in the PP to which conformance is claimed;
+ all operational environments that would meet the security objectives for the operational environment in the PP
+ to which conformance is claimed, would also meet the security objectives for the operational environment in the
+ PP claiming conformance (with one exception in the next bullet);
+ besides a set of security objectives for the operational environment in the PP claiming conformance, which
+ are used to demonstrate conformance to the set of security objectives defined in the PP to which conformance
+ is claimed, an PP claiming conformance may specify further security objectives for the operational environment,
+ but only if these security objectives neither affect the original set of security objectives for the TOE nor the
+ security objectives for the operational environment as defined in the PP to which conformance is claimed.
+
+
+
+
+ The evaluator shall examine the PP to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the PP
+ under evaluation is a superset of or identical to the
+ statement of security requirements in the PP to which
+ conformance is being claimed (for strict
+ conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ requirements in the PP to which conformance is being
+ claimed.
+ For:
+
+ SFRs: The conformance rationale in the PP claiming conformance shall demonstrate that the overall
+ set of requirements defined by the SFRs in the PP claiming conformance is equivalent (or more restrictive)
+ than the overall set of requirements defined by the SFRs in the PP to which conformance is claimed. This means
+ that all TOEs that would meet the requirements defined by the set of all SFRs in the PP claiming conformance
+ would also meet the requirements defined by the set of all SFRs in the PP to which conformance is claimed;
+ SARs: The PP claiming conformance shall contain all SARs in the PP to which conformance is claimed,
+ but may claim additional SARs or replace SARs by hierarchically stronger SARs. The completion of operations
+ in the PP claiming conformance must be consistent with that in the PP to which conformance is claimed; either
+ the same completion will be used in the PP claiming conformance as that in the PP to which conformance is
+ claimed or a completion that makes the SAR more restrictive (the rules of refinement apply).
+
+
+
+
+
+ The evaluator shall check that the PP conformance
+ statement states a claim of strict-PP or demonstrable-PP
+ conformance.
+
+
+
+
+
+
+
+ This part of the PP defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or its operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall examine that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and/or threats only, OSPs need not be present in the
+ PP. In this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition and that
+ the division of this problem between the TOE and its
+ operational environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat, the evaluator action
+ related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP, the evaluator action
+ related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ If no security objectives for the operational environment trace back to the assumption,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author. This family is used to determine that these extended
+ components are defined similarly to the existing CC Part 2
+ or CC Part 3 components.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the PP.
+
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the PP, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the PP defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+
+ a member of a new class defined in the PP.
+
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ PP, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the PP author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the PP does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations, the
+ evaluator determines that the extended functional component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the PP does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the PP does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the PP does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the PP does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance to
+ this requirement.
+
+
+
+ The evaluator shall confirm that no extended component may
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component may
+ not be clearly expressed using existing
+ components.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the PP, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is, or whether the SFRs are derived from
+ security objectives for the TOE.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it justifies that the SFRs are suitable to
+ meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the TOE,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ If the SFRs that trace back to a security objective for
+ the TOE have any uncompleted assignments, or uncompleted
+ or restricted selections, the evaluator determines that
+ for every conceivable completion or combination of
+ completions of these operations, the security objective
+ is still met.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+ The evaluator is reminded that any explanation is
+ correct, as long as it is coherent and neither the SARs
+ nor the explanation have obvious inconsistencies with
+ the remainder of the PP.
+ An example of an obvious inconsistency between the
+ SARs and the remainder of the PP would be to have threat
+ agents that are very capable, but an SAR that does not protect against these
+ threat agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an ST, to demonstrate that
+ the ST is sound and internally consistent, and, if the ST is
+ based on one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of an ST. The ST
+ evaluation should be started prior to any TOE evaluation
+ sub-activities since the ST provides the basis and context to
+ perform these sub-activities. The evaluation methodology in
+ this subclause is based on the requirements on the ST as
+ specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The ST describes the security features of a TOE. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+
+
+
+ While evaluating an ST that is based on one or more
+ certified PPs, it may be possible to re-use the fact that
+ these PPs were certified. The potential for re-use of the
+ result of a certified PP is greater if the ST does not add
+ threats, OSPs, assumptions, security objectives and/or
+ security requirements to those of the PP. If the ST
+ contains much more than the certified PP, re-use may not be
+ useful at all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP contains a set of security
+ requirements, and these were determined to be internally
+ consistent during the PP evaluation. If the ST uses the
+ exact same requirements, the consistency analysis does not
+ have to be repeated during the ST evaluation. If the ST adds
+ one or more requirements, or performs operations on these
+ requirements, the analysis will have to be
+ repeated. However, it may be possible to save work in this
+ consistency analysis by using the fact that the original
+ requirements are internally consistent. If the original
+ requirements are internally consistent, the evaluator only
+ has to determine that:
+
+
+ the set of all new and/or changed requirements is
+ internally consistent, and
+
+
+ the set of all new and/or changed requirements is
+ consistent with the original requirements.
+
+
+ The evaluator notes in the ETR each case where analyses are
+ not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way on three levels of abstraction: TOE reference,
+ TOE overview and TOE description.
+
+ Evaluation of the ST introduction is required to demonstrate
+ that the ST and the TOE are correctly identified, that the
+ TOE is correctly described at three levels of abstraction
+ and that these three descriptions are consistent with each
+ other.
+
+
+
+ The ST introduction describes the TOE in a narrative way on
+ three levels of abstraction: TOE reference, TOE overview and
+ TOE description.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the ST and the TOE are correctly identified, whether the
+ TOE is correctly described in a narrative way at three
+ levels of abstraction (TOE reference, TOE overview and TOE
+ description), and whether these three descriptions are
+ consistent with each other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide an ST introduction.
+
+
+ The ST introduction shall contain an ST reference, a TOE
+ reference, a TOE overview and a TOE description.
+
+
+ The ST reference shall uniquely identify the ST.
+
+
+ The TOE reference shall identify the TOE.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware required by the TOE.
+
+
+ The TOE description shall describe the physical scope of the
+ TOE.
+
+
+ The TOE description shall describe the logical scope of the
+ TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the ST introduction
+ contains an ST reference, a TOE reference, a TOE
+ overview and a TOE description.
+
+
+
+
+ The evaluator shall examine the ST reference to
+ determine that it uniquely identifies the ST.
+
+ The evaluator determines that the ST reference
+ identifies the ST itself, so that it may be easily
+ distinguished from other STs, and that it also uniquely
+ identifies each version of the ST, e.g. by including a
+ version number and/or a date of publication.
+
+ In evaluations where a CM system is provided, the
+ evaluator may validate the uniqueness of the reference
+ by checking the configuration list. In the other cases,
+ the ST should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it identifies the TOE.
+
+ The evaluator determines that the TOE reference
+ identifies the TOE, so that it is clear to which TOE the
+ ST refers, and that it also identifies the version of
+ the TOE, e.g. by including a version/release/build
+ number, or a date of release.
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it is not misleading.
+
+ If the TOE is related to one or more well-known
+ products, it is allowed to reflect this in the TOE
+ reference. However, this should not be used to mislead
+ consumers: situations where only a small part of a
+ product is evaluated, yet the TOE reference does not
+ reflect this, are not allowed.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features of the TOE. The TOE overview should enable
+ potential consumers to quickly determine whether the TOE
+ may be suitable for their security needs.
+
+ The TOE overview in an ST for a composed TOE should
+ describe the usage and major security feature of the
+ composed TOE, rather than those of the individual
+ component TOEs.
+
+ The evaluator determines that the overview is clear
+ enough for consumers, and sufficient to give them a
+ general understanding of the intended usage and major
+ security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that the TOE type is not misleading.
+
+ There are situations where the general consumer would
+ expect certain functionality of the TOE because of its
+ TOE type. If this functionality is absent in the TOE,
+ the evaluator determines that the TOE overview
+ adequately discusses this absence.
+
+ There are also TOEs where the general consumer would
+ expect that the TOE should be able to operate in a
+ certain operational environment because of its TOE
+ type. If the TOE is unable to operate in such an
+ operational environment, the evaluator determines that
+ the TOE overview adequately discusses this.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware required by the TOE.
+
+ While some TOEs are able to run stand-alone, other TOEs
+ (notably software TOEs) need additional hardware,
+ software or firmware to operate. If the TOE does not
+ require any hardware, software or firmware, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the TOE overview
+ identifies any additional hardware, software and
+ firmware needed by the TOE to operate. This
+ identification does not have to be exhaustive, but
+ detailed enough for potential consumers of the TOE to
+ determine whether their current hardware, software and
+ firmware support use of the TOE, and, if this is not the
+ case, which additional hardware, software and/or
+ firmware is needed.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the physical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description lists
+ the hardware, firmware, software and guidance parts that
+ constitute the TOE and describes them at a level of
+ detail that is sufficient to give the reader a general
+ understanding of those parts.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any hardware, firmware,
+ software or guidance part is part of the TOE or
+ not.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the logical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description
+ discusses the logical security features offered by the
+ TOE at a level of detail that is sufficient to give the
+ reader a general understanding of those features.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any logical security
+ feature is offered by the TOE or not.
+
+ An ST for a composed TOE may refer out to the
+ description of the logical scope of the component TOEs,
+ provided in the component TOE STs to provide the
+ majority of this description for the composed TOE.
+ However, the evaluator determines that the composed TOE
+ ST clearly discusses which features of the individual
+ components are not within the composed TOE, and
+ therefore not a feature of the composed TOE.
+
+
+
+ The evaluator shall confirm that the TOE reference, the TOE
+ overview, and the TOE description are consistent with each
+ other.
+
+
+ The evaluator shall examine the TOE reference, TOE
+ overview and TOE description to determine that they are
+ consistent with each other.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs are to claim conformance with the PP.
+
+
+
+ Conformance claims describes how the Security Target
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the ST and the TOE conform to the CC and how the ST
+ conforms to PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the PP(s) that the ST claims conformance to;
+
+
+ the package(s) that the ST claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the ST and
+ the TOE claim conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the ST claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ ST to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the ST and the TOE claim
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this ST. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+ For a composed TOE, the evaluator will consider any
+ differences between the version of the CC claimed for a
+ component and the version of the CC claimed for the
+ composed TOE. If the versions differ the evaluator will
+ assess whether the differences between the versions will
+ lead to conflicting claims.
+
+ For instances where the CC conformance claims for the
+ base TOE and dependent TOE are for different major
+ releases of the CC (e.g. one component TOE conformance
+ claim is CC v2.x and the other component TOE conformance
+ claim is CC v3.x), the conformance claim for the
+ composed TOE will be the earlier release of the CC, as
+ the CC is developed with an aim to provide backwards
+ compatibility (although this may not be achieved in the
+ strictest sense, it is understood to be achieved in
+ principle).
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the ST.
+
+ For a composed TOE, the evaluator will consider whether
+ this claim is consistent not only with the CC Part 2,
+ but also with the claims of conformance to CC Part 2 by
+ each of the component TOEs. I.e. if one or more
+ component TOEs claims to be CC Part 2 extended, then the
+ composed TOE should also claim to be CC Part 2
+ extended.
+
+ The CC conformance claim for the composed TOE may be CC
+ Part 2 extended, even though the component TOEs are Part
+ 2 conformant, in the event that additional SFRs are
+ claimed for the base TOE (see composed TOE guidance for
+ )
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the ST.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the ST claims conformance.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that any referenced PPs are
+ unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted. Therefore,
+ conformance to a PP requiring a composite solution may
+ be claimed in an ST for a composed TOE. Conformance to
+ such a PP would not have been possible during the
+ evaluation of the component TOEs, as these components
+ would not have satisfied the composed solution. This is
+ only possible in the instances where the ``composite'' PP
+ permits use of the composition evaluation approach (use
+ of components).
+
+ The ST for a composed TOE will identify the STs of the
+ component TOEs from which the composed ST is comprised.
+ The composed TOE is essentially claiming conformance to
+ the STs of the component TOEs.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the ST claims conformance.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator determines that the component TOE STs from
+ which the composed TOE is derived are also unambiguously
+ identified.
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the ST
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package then the ST
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The relation between the types may be simple: a firewall
+ ST claiming conformance to a firewall PP, or more
+ complex: a smart card ST claiming conformance to a number
+ of PPs at the same time (a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card).
+
+ For a composed TOE, the evaluator will determine whether
+ the conformance claim rationale demonstrates that the
+ TOE types of the component TOEs are consistent with the
+ composed TOE type. This does not mean that both the
+ component and the composed TOE types have to be the
+ same, but rather that the component TOEs are suitable
+ for integration to provide the composed TOE. It should be made clear in the composed TOE ST which SFRs are only included as a result of composition, and were not examined as SFRs in the base and dependent TOE (e.g. EALx) evaluation.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the ST does not claim conformance with a PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the PP does not have a statement of security problem
+ definition, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether:
+
+
+ the threats in the ST are a superset of or identical
+ to the threats in the PP to which conformance is
+ being claimed;
+
+
+ the OSPs in the ST are a superset of or identical to
+ the OSPs in the PP to which conformance is being
+ claimed;
+
+
+ the assumptions in the ST are identical to the assumptions in the PP to which conformance is being
+ claimed, with two possible exceptions described in the following two bullet points;
+
+ an assumption (or part of an assumption) from the PP can be omitted, if all security objectives for the
+ operational environment addressing this assumption (or part of an assumption) are replaced by
+ security objectives for the TOE;
+ an assumption can be added to the assumptions defined in the PP, if a rationale is given, why the new
+ assumption neither mitigates a threat (or a part of a threat) meant to be addressed by
+ security objectives for the TOE in the PP, nor fulfils an OSP (or part of an OSP) meant to be
+ addressed by security objectives for the TOE in the PP.
+ When examining an ST claiming a PP, which omits assumptions from the PP or adds new assumptions, the
+ evaluator shall carefully determine, if the conditions given above are fulfilled.
+ The following discussion gives some motivation and examples for these cases:
+
+ Example for omitting an assumption: A PP may contain an assumption stating that the operational
+ environment prevents unauthorised modification or interception of data sent to an external interface of
+ the TOE. This may be the case if the TOE accepts data in clear text and without integrity protection at
+ this interface and is assumed to be located in a secure operational environment, which will prevent
+ attackers from accessing these data. The assumption will then be mapped in the PP to some objective
+ for the operational environment stating that the data interchanged at this interface are protected by
+ adequate measures in the operational environment. If an ST claiming this PP defines a more secure
+ TOE, which has an additional security objective stating that the TOE itself protects these data, for
+ example by providing a secure channel for encryption and integrity protection of all data transferred via
+ this interface, the corresponding objective and assumption for the operational environment can be
+ omitted from the ST. This is also called re-assigning of the objective, since the objective is re-assigned
+ from the operational environment to the TOE. Note, that this TOE is still secure in an operational
+ environment fulfilling the omitted assumption and therefore still fulfils the PP.
+ Example for adding an assumption: In this example the PP is designed to specify requirements for a
+ TOE of type "Firewall" and an ST author wishes to claim this PP for a TOE, which implements a
+ firewall, but additionally provides the functionality of a virtual private network (VPN) component. For
+ the VPN functionality the TOE needs cryptographic keys and these keys may also have to be handled
+ securely by the operational environment (e. g. if symmetric keys are used to secure the network
+ connection and therefore need to be provided in some secure way to other components in the
+ network). In this case it is acceptable to add an assumption that the cryptographic keys used by the
+ VPN are handled securely by the operational environment. This assumption does not address threats or OSPs of the PP and
+ therefore fulfils the conditions stated above.
+ Counterexample for adding an assumption: In a variant of the first example a PP may already contain
+ an objective for the TOE to provide a secure channel for one of its interfaces, and this objective is
+ mapped to a threat of unauthorised modification or reading of the data on this interface. In this case it
+ is clearly not allowed for an ST claiming this PP to add an assumption for the operational environment,
+ which assumes that the operational environment protects data on this interface against modification or
+ unauthorised reading of the data. This assumption would reduce a threat, which is meant to be
+ addressed by the TOE. Therefore a TOE fulfilling an ST with this added assumption would not
+ automatically fulfil the PP any more and this addition is therefore not allowed.
+ Second counterexample for adding an assumption: In the example above of a TOE implementing a
+ firewall it would not be admissible to add a general assumption that the TOE is only connected to
+ trusted devices, because this would obviously remove essential threats relevant for a firewall (namely
+ that there is untrusted IP traffic, which needs to be filtered). Therefore this addition would not be
+ allowed.
+
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security problem definition of the ST is equivalent or
+ more restrictive than the statement of security problem
+ definition in the PP to which conformance is being
+ claimed.
+ For this, the conformance claim rationale needs to demonstrate that the security problem definition in
+ the ST is equivalent (or more restrictive) than the security problem definition in the PP. This means that:
+
+ all TOEs that would meet the security problem definition in the ST also meet the security problem
+ definition in the PP. This can also be shown indirectly by demonstrating that every event, which
+ realises a threat defined in the PP or violates an OSP defined in the PP, would also realise a threat
+ stated in the ST or violate an OSP defined in the ST.
+ Note that fulfilling an OSP stated in the ST may avert a threat stated in the PP or that averting a
+ threat stated in the ST may fulfil an OSP stated in the PP, so threats and OSPs can substitute
+ each other;
+ all operational environments that would meet the security problem definition in the PP would also
+ meet the security problem definition in the ST (with one exception in the next bullet);
+ besides a set of assumptions in the ST needed to demonstrate conformance to the SPD of the PP,
+ an ST may specify further assumptions, but only if these additional assumptions are independent
+ of and do not affect the security problem definition as defined in the PP. More detailed, there are
+ no assumptions in the ST that exclude threats to the TOE that need to be countered by the TOE
+ according to the PP. Similarly, there are no assumptions in the ST that realise aspects of an OSP
+ stated in the PP, which are meant to be fulfilled by the TOE according to the PP."
+
+ For a composed TOE, the evaluator will consider whether
+ the security problem definition of the composed TOE is
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ Threat statements and OSPs in the composed TOE ST do
+ not contradict those from the component STs.
+
+ Any assumptions made in the component STs are upheld
+ in the composed TOE ST. That is, either the
+ assumption should also be present in the composed
+ ST, or the assumption should be positively addressed
+ in the composed ST. The assumption may be
+ positively addressed through specification of
+ requirements in the composed TOE to provide
+ functionality fulfilling the concern captured in the
+ assumption.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PP, with the statement of security
+ objectives in the PPs to which conformance is being claimed.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP to which conformance is being claimed, no
+ conformance claim rationale is required. Instead, the
+ evaluator determines whether:
+ The ST contains all security objectives for the
+ TOE of the PP to which conformance is being
+ claimed. Note that it is allowed for the ST under
+ evaluation to have additional security objectives
+ for the TOE;
+ The security objectives for the operational environment in the ST are identical to the security
+ objectives for the operational environment in the PP to which conformance is being claimed, with two
+ possible exceptions described in the following two bullet points;
+
+ a security objective for the operational environment (or part of such security objective) from the PP can
+ be replaced by the same (part of the) security objective stated for the TOE;
+
+ a security objective for the operational environment can be added to the objectives defined in the PP,
+ if a justification is given, why the new objective neither mitigates a threat (or a part of a threat) meant to
+ be addressed by security objectives for the TOE in the PP, nor fulfils an OSP (or part of
+ an OSP) meant to be addressed by security objectives for the TOE in the PP.
+
+ When examining an ST claiming a PP, which omits security objectives for the operational environment from
+ the PP or adds new security objectives for the operational environment, the evaluator shall carefully
+ determine, if the conditions given above are fulfilled. The examples given for the case of assumptions in the
+ preceding work unit are also valid here.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the ST is equivalent or more restrictive
+ than the statement of security objectives in the PP to
+ which conformance is being claimed.
+ For this the conformance claim rationale needs to demonstrate that the security objectives in the ST are
+ equivalent (or more restrictive) than the security objectives in the PP. This means that:
+
+ all TOEs that would meet the security objectives for the TOE in the ST also meet the security
+ objectives for the TOE in the PP;
+ all operational environments that would meet the security objectives for the operational
+ environment in the PP would also meet the security objectives for the operational environment in
+ the ST (with one exception in the next bullet);
+ besides a set of security objectives for the operational environment in the ST, which are used to
+ demonstrate conformance to the set of security objectives defined in the PP, an ST may specify
+ further security objectives for the operational environment, but only if these security objectives
+ neither affect the original set of security objectives for the TOE nor the security objectives for the
+ operational environment as defined in the PP to which conformance is claimed."
+
+ For a composed TOE, the evaluator will consider whether
+ the security objectives of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment are consistent with the
+ statement of security objectives for the TOE in the
+ base TOE ST. It is not expected that the statement
+ of security objectives for the environment within in
+ the dependent TOE ST will cover all aspects of the
+ statement of security objectives for the TOE in the
+ base TOE ST.
+
+ The statement of security objectives in the composed
+ ST is consistent with the statements of security
+ objectives in the STs for the component TOEs.
+
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security objectives of the ST is at least equivalent to
+ the statement of security objectives in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+ The evaluator shall examine the ST to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the ST
+ is a superset of or identical to the statement of
+ security requirements in the PP to which conformance is
+ being claimed (for strict conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is equivalent or more restrictive
+ than the statement of security requirements in the PP to
+ which conformance is being claimed.
+ For:
+
+ SFRs: The conformance rationale in the ST shall demonstrate that the overall set of requirements
+ defined by the SFRs in the ST is equivalent (or more restrictive) than the overall set of
+ requirements defined by the SFRs in the PP. This means that all TOEs that would meet the
+ requirements defined by the set of all SFRs in the ST would also meet the requirements defined by
+ the set of all SFRs in the PP;
+ SARs: The ST shall contain all SARs in the PP, but may claim additional SARs or replace SARs by
+ hierarchically stronger SARs. The completion of operations in the ST must be consistent with that
+ in the PP; either the same completion will be used in the ST as that in the PP or a completion that
+ makes the SAR more restrictive (the rules of refinement apply).
+
+
+ For a composed TOE, the evaluator will consider whether
+ the security requirements of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance rationale to determine that:
+
+
+ The statement of security requirements in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security requirements for the
+ environment within in the dependent TOE ST will
+ cover all aspects of the statement of security
+ requirements for the TOE in the base TOE ST, as
+ some SFRs may need to be added to the statement of
+ security requirements in the composed TOE ST.
+ However, the statement of security requirements in
+ the base should support the operation of the dependent
+ component.
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security objectives for the environment
+ within in the dependent TOE ST will cover all
+ aspects of the statement of security requirements
+ for the TOE in the base TOE ST.
+
+ The statement of security requirements in the
+ composed is consistent with the statements of
+ security requirements in the STs for the component
+ TOEs.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is at least equivalent to the
+ statement of security requirements in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+
+
+
+ This part of the ST defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall examine that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and threats only, OSPs need not be present in the ST. In
+ this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition, that the
+ division of this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ If no security objectives for the operational environment trace back to the assumption,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the ST
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended components are defined wherever it is impossible to
+ clearly express requirements using only components from CC
+ Part 2 and/or CC Part 3.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the ST.
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the ST, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the ST defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+ a member of a new class defined in the ST.
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ ST, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the ST author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the ST does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations, the
+ evaluator determines that the extended functional component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the ST does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the ST does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the ST does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the ST does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance
+ with this requirement.
+
+
+
+ The evaluator shall confirm that no extended component can
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component can
+ not be clearly expressed using existing
+ components.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the ST, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and canonical
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that a
+ security requirements rationale is provided which justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+ All subjects, objects,
+ operations, security attributes, external entities and other
+ terms that are used in the SFRs and the SARs shall be
+ defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFRs is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that all SARs are identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it demonstrates that the SFRs are suitable
+ to meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the TOE,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+
+ The evaluator is reminded that any explanation is correct, as
+ long as it is coherent and neither the SARs nor the explanation
+ have obvious inconsistencies with the remainder of the ST.
+
+ An example of an obvious inconsistency between the SARs and the
+ remainder of the ST would be to have threat agents that are very
+ capable, but an SAR that does not
+ protect against these threat agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended assurance requirement
+ specifying an open source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+ The TOE summary specification enables evaluators and
+ potential consumers to gain a general understanding of how
+ the TOE is implemented.
+
+ Evaluation of the TOE summary specification is necessary to
+ determine whether it is adequately described how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass. and whether the TOE
+ summary specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The TOE Summary specification allows evaluators and
+ potential consumers of the TOE to gain a general
+ understanding of how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass.
+
+
+
+ The components in this family are levelled on whether the
+ TOE summary specification only needs to describe how the TOE
+ meets the SFRs, or whether the TOE summary specification
+ also needs to describe how the TOE protects itself against
+ logical tampering and bypass. This additional description
+ may be used in special circumstances where there might be a
+ specific concern regarding the TOE security architecture.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, and
+ whether the TOE summary specification is consistent with
+ other narrative descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each description is to provide
+ potential consumers of the TOE with a high-level view of how the developer intends
+ to satisfy each SFR and that the descriptions therefore should not be overly detailed.
+ Often several SFRs will be implemented in one context; for instance a password
+ authentication mechanism may implement ,
+ and .
+ Therefore usually the TSS will not consist of a long list with texts for each single
+ SFR, but complete groups of SFRs may be covered by one text passage.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, whether
+ the TOE summary specification addresses interference,
+ logical tampering and bypass, and whether the TOE summary
+ specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against interference and logical tampering.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against bypass.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each description is to provide
+ potential consumers of the TOE with a high-level view of how the developer intends
+ to satisfy each SFR and that the descriptions therefore should not be overly detailed.
+ Often several SFRs will be implemented in one context; for instance a password
+ authentication mechanism may implement ,
+ and .
+ Therefore usually the TSS will not consist of a long list with texts for each single
+ SFR, but complete groups of SFRs may be covered by one text passage.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against interference and logical
+ tampering.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against interference and logical
+ tampering and that the descriptions therefore should not
+ be overly detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against bypass.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against bypass and that the
+ descriptions therefore should not be overly
+ detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+ The class ``Tests'' encompasses four families: , ,
+ (i.e. functional testing
+ performed by evaluators), and . Testing provides assurance that the TSF
+ behaves as described (in the functional specification, TOE
+ design, and implementation representation).
+
+ The emphasis in this class is on confirmation that the TSF
+ operates according to its design descriptions. This class does
+ not address penetration testing, which is based upon an
+ analysis of the TSF that specifically seeks to identify
+ vulnerabilities in the design and implementation of the
+ TSF. Penetration testing is addressed separately as an aspect
+ of vulnerability assessment in the class.
+
+ The class separates testing into
+ developer testing and evaluator testing. The and families address the completeness of developer
+ testing. addresses the rigour
+ with which the functional specification is tested; addresses whether testing against
+ other design descriptions (security architecture, TOE design,
+ implementation representation) is required.
+
+ addresses the performing of
+ the tests by the developer and how this testing should be
+ documented. Finally, then
+ addresses evaluator testing: whether the evaluator should
+ repeat part or all of the developer testing and how much
+ independent testing the evaluator should do.
+
+
+
+ Assurance class states testing
+ requirements that demonstrate that the TOE matches its design
+ descriptions as provided in the
+ class.
+
+
+
+ The goal of this activity is to determine whether the TOE
+ behaves as described in the ST and as specified in the
+ evaluation evidence (described in the class). This determination is achieved through
+ some combination of the developer's own functional testing of
+ the TSF () and independent
+ testing the TSF by the evaluator (). At the lowest level of assurance, there is no
+ requirement for developer involvement, so the only testing is
+ conducted by the evaluator, using the limited available
+ information about the TOE. Additional assurance is gained as
+ the developer becomes increasingly involved both in testing
+ and in providing additional information about the TOE, and as
+ the evaluator increases the independent testing
+ activities.
+
+
+
+ Testing of the TSF is conducted by the evaluator and, in most
+ cases, by the developer. The evaluator's testing efforts
+ consist not only of creating and running original tests, but
+ also of assessing the adequacy of the developer's tests and
+ re-running a subset of them.
+
+ The evaluator analyses the developer's tests to determine the
+ extent to which they are sufficient to demonstrate that TSFI
+ (see ) perform as specified,
+ and to understand the developer's approach to
+ testing. Similarly, the evaluator analyses the developer's
+ tests to determine the extent to which they are sufficient to
+ demonstrate the internal behaviour and properties of the
+ TSF.
+ The evaluator also executes a subset of the developer's
+ tests as documented to gain confidence in the developer's test
+ results: the evaluator will use the results of this analysis
+ as an input to independently testing a subset of the TSF. With
+ respect to this subset, the evaluator takes a testing approach
+ that is different from that of the developer, particularly if
+ the developer's tests have shortcomings.
+
+ To determine the adequacy of developer's test documentation or
+ to create new tests, the evaluator needs to understand the
+ desired expected behaviour of the TSF, both internally and as
+ seen at the TSFI, in the context of the SFRs it is to
+ satisfy. The evaluator may choose to divide the TSF and TSFI
+ into subsets according to functional areas of the ST (audit
+ subsystem, audit-related TSFI, authentication module,
+ authentication-related TSFI, etc.) if they were not already
+ divided in the ST, and focus on one subset of the TSF and TSFI
+ at a time, examining the ST requirement and the relevant parts
+ of the development and guidance documentation to gain an
+ understanding of the way the TOE is expected to behave. This
+ reliance upon the development documentation underscores the need
+ for the dependencies on by and .
+
+ The CC has separated coverage and depth from functional tests
+ to increase the flexibility when applying the components of
+ the families. However, the requirements of the families are
+ intended to be applied together to confirm that the TSF
+ operates according to its specification. This tight coupling
+ of families has led to some duplication of evaluator work
+ units across sub-activities. These application notes are used
+ to minimise duplication of text between sub-activities.
+
+
+ Before the adequacy of test documentation can be accurately
+ evaluated, or before new tests can be created, the evaluator
+ has to understand the desired expected behaviour of a
+ security function in the context of the requirements it is
+ to satisfy.
+
+ As mentioned earlier, the evaluator may choose to subset the
+ TSF and TSFI according to SFRs (audit, authentication, etc.)
+ in the ST and focus on one subset at a time. The evaluator
+ examines each ST requirement and the relevant parts of the
+ functional specification and guidance documentation to gain
+ an understanding of the way the related TSFI is expected to
+ behave. Similarly, the evaluator examines the relevant parts
+ of the TOE design and security architecture documentation to
+ gain an understanding of the way the related modules or
+ subsystems of the TSF are expected to behave.
+
+ With an understanding of the expected behaviour, the
+ evaluator examines the test plan to gain an understanding of
+ the testing approach. In most cases, the testing approach
+ will entail a TSFI being stimulated and its responses
+ observed. Externally-visible functionality can be tested
+ directly; however, in cases where functionality is not
+ visible external to the TOE (for example, testing the
+ residual information protection functionality), other means
+ will need to be employed.
+
+
+
+ In cases where it is impractical or inadequate to test
+ specific functionality (where it provides no
+ externally-visible TSFI), the test plan should identify the
+ alternate approach to verify expected behaviour. It is the
+ evaluator's responsibility to determine the suitability of
+ the alternate approach. However, the following should be
+ considered when assessing the suitability of alternate
+ approaches:
+
+
+ an analysis of the implementation representation to
+ determine that the required behaviour should be
+ exhibited by the TOE is an acceptable alternate
+ approach. This could mean a code inspection for a
+ software TOE or perhaps a chip mask inspection for a
+ hardware TOE.
+
+
+ it is acceptable to use evidence of developer
+ integration or module testing, even if the claimed
+ assurance requirements do not include availability of
+ lower level descriptions of the TOE modules (e.g. ) or implementation (). If evidence of developer
+ integration or module testing is used in verifying the
+ expected behaviour of a security functionality, care
+ should be given to confirm that the testing evidence
+ reflects the current implementation of the TOE. If the
+ subsystems or modules have been changed since testing
+ occurred, evidence that the changes were tracked and
+ addressed by analysis or further testing will usually be
+ required.
+
+
+
+ It should be emphasised that supplementing the testing
+ effort with alternate approaches should only be undertaken
+ when both the developer and evaluator determine that there
+ exists no other practical means to test the expected
+ behaviour.
+
+
+
+ Test pre-requisites are necessary to establish the required
+ initial conditions for the test. They may be expressed in
+ terms of parameters that must be set or in terms of test
+ ordering in cases where the completion of one test
+ establishes the necessary pre-requisites for another
+ test. The evaluator must determine that the pre-requisites
+ are complete and appropriate in that they will not bias the
+ observed test results towards the expected test
+ results.
+
+ The test steps and expected results specify the actions and
+ parameters to be applied to the TSFI as well as how the
+ expected results should be verified and what they are. The
+ evaluator must determine that the test steps and expected
+ results are consistent with the descriptions of the TSFI in
+ the functional specification. This means that each
+ characteristic of the TSFI behaviour explicitly described in
+ the functional specification should have tests and expected
+ results to verify that behaviour.
+
+ The overall aim of this testing activity is to determine
+ that each subsystem, module, and TSFI has been sufficiently
+ tested against the behavioural claims in the functional
+ specification, TOE design, and architecture description. At
+ the higher assurance levels, testing also includes bounds
+ testing and negative testing. The test procedures will
+ provide insight as to how the TSFIs, modules, and subsystems
+ have been exercised by the developer during testing. The
+ evaluator uses this information when developing additional
+ tests to independently test the TSF.
+
+
+
+
+
+ This family establishes that the TSF has been tested against
+ its functional specification. This is achieved through an
+ examination of developer evidence of correspondence.
+
+
+
+ Coverage deals with the completeness of the functional tests
+ performed by the developer on the TOE. It addresses the
+ extent to which the TSF is tested.
+
+
+
+ The components in this family are levelled on the basis of
+ specification.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to establish that some
+ of the TSFIs have been tested.
+
+
+
+ In this component the developer shows how tests in the
+ test documentation correspond to TSFIs in the functional
+ specification. This can be achieved by a statement of
+ correspondence, perhaps using a table.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+ The coverage analysis provided by the developer is
+ required to show the correspondence between the tests
+ provided as evaluation evidence and the functional
+ specification. However, the coverage analysis need not
+ demonstrate that all TSFI have been tested, or that all
+ externally-visible interfaces to the TOE have been
+ tested. Such shortcomings are considered by the evaluator
+ during the independent testing () sub-activity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage evidence.
+
+
+
+
+ The developer shall provide evidence of the test coverage.
+
+
+ The evidence of the test coverage shall show the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage evidence
+ to determine that the correspondence between the tests
+ identified in the test documentation and the TSFIs
+ described in the functional specification is
+ accurate.
+
+ Correspondence may take the form of a table or
+ matrix. The coverage evidence required for this
+ component will reveal the extent of coverage, rather
+ than to show complete coverage. In cases where coverage
+ is shown to be poor the evaluator should increase the
+ level of independent testing to compensate.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to confirm that all of
+ the TSFIs have been tested.
+
+
+
+ In this component the developer confirms that tests in the
+ test documentation correspond to all of the TSFIs in the
+ functional specification. This can be achieved by a
+ statement of correspondence, perhaps using a table, but
+ the developer also provides an analysis of the test
+ coverage.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested all of the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage analysis.
+
+
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the tests
+ in the test documentation and the interfaces in the
+ functional specification is accurate.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ interfaces presented in the test coverage analysis has
+ to be unambiguous.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the testing approach for each interface
+ demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that the test prerequisites, test steps and
+ expected result(s) adequately test each
+ interface.
+
+ Guidance on this work units, as it pertains to the
+ functional specification, can be found in:
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the
+ interfaces in the functional specification and the tests
+ in the test documentation is complete.
+
+ All TSFIs that are described in the functional
+ specification have to be present in the test coverage
+ analysis and mapped to tests in order for completeness
+ to be claimed, although exhaustive specification testing
+ of interfaces is not required. Incomplete coverage would
+ be evident if an interface was identified in the
+ functional specification and no test was mapped to
+ it.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to confirm that the
+ developer performed exhaustive tests of all interfaces in
+ the functional specification.
+
+ The objective of this component is to confirm that all
+ parameters of all of the TSFIs have been tested.
+
+
+
+ In this component the developer is required to show how
+ tests in the test documentation correspond to all of the
+ TSFIs in the functional specification. This can be
+ achieved by a statement of correspondence, perhaps using a
+ table, but in addition the developer is required to
+ demonstrate that the tests exercise all of the parameters
+ of all TSFIs. This additional requirement includes bounds
+ testing (i.e. verifying that errors are generated when
+ stated limits are exceeded) and negative testing
+ (e.g. when access is given to User A, verifying not only
+ that User A now has access, but also that User B did not
+ suddenly gain access). This kind of testing is not,
+ strictly speaking, exhaustive because not
+ every possible value of the parameters is expected to be
+ checked.
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been completely
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The components in this family deal with the level of detail
+ to which the TSF is tested by the developer. Testing of the
+ TSF is based upon increasing depth of information derived
+ from additional design representations and descriptions (TOE
+ design, implementation representation, and security
+ architecture description).
+
+ The objective is to counter the risk of missing an error in
+ the development of the TOE. Testing that exercises specific
+ internal interfaces can provide assurance not only that the
+ TSF exhibits the desired external security behaviour, but
+ also that this behaviour stems from correctly operating
+ internal functionality.
+
+
+
+ Depth deals with the level of detail to which the developer
+ tests the TSF. Testing is based upon increasing depth of
+ information derived from analysis of the TSF
+ representations.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing detail provided in the TSF representations, from
+ the TOE design to the implementation representation. This
+ levelling reflects the TSF representations presented in the
+ class.
+
+
+
+ The TOE design describes the internal components
+ (e.g. subsystems) and, perhaps, modules of the TSF, together
+ with a description of the interfaces among these components and
+ modules. Evidence of testing of this TOE design must show that
+ the internal interfaces have been exercised and seen to behave
+ as described. This may be achieved through testing via the
+ external interfaces of the TSF, or by testing of the TOE
+ subsystem or module interfaces in isolation, perhaps employing a
+ test harness. In cases where some aspects of an internal
+ interface cannot be tested via the external interfaces, there
+ should either be justification that these aspects need not be
+ tested, or the internal interface needs to be tested
+ directly. In the latter case the TOE design needs to be
+ sufficiently detailed in order to facilitate direct
+ testing.
+
+ In cases where the description of the TSF's architectural
+ soundness (in ) cites
+ specific mechanisms, the tests performed by the developer
+ must show that the mechanisms have been exercised and seen
+ to behave as described.
+
+ At the highest component of this family, the testing is
+ performed not only against the TOE design, but also against
+ the implementation representation.
+
+
+
+
+
+
+
+ The subsystem descriptions of the TSF provide a high-level
+ description of the internal workings of the TSF. Testing
+ at the level of the TOE subsystems provides assurance that
+ the TSF subsystems behave and interact as described in the
+ TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSF subsystems against the
+ TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the descriptions of the
+ behaviour of TSF subsystems and of their interactions is
+ included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ When is combined with a component of , which includes descriptions at the module level
+ (e.g. ), the level of detail needed to map
+ the test cases to the behaviour of the subsystems may require
+ information from the module description to be used. This is
+ because allows the description of details
+ to be shifted from the subsystem level to the module level, or
+ even to omit the subsystems altogether.
+ In any case, the required level of detail in the provided
+ reference to the tested behaviour can be defined as ``the level
+ of detail required for the description of subsystem behaviour as
+ defined by (in particular work unit )''. It states that a detailed description of
+ the behaviour typically discusses how the functionality is
+ provided, in terms of what key data and data structures re
+ present; what control relationships exist within a subsytem and
+ how these elements work together to provide the SFR-enforcing
+ behaviour.
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ When is combined with a component of , which includes descriptions at the module level
+ (e.g. ), the level of detail needed to map
+ the test cases to the behaviour of the subsystems may require
+ information from the module description to be used. This is
+ because allows the description of details
+ to be shifted from the subsystem level to the module level, or
+ even to omit the subsystems altogether.
+ In any case, the required level of detail in the provided
+ reference to the tested behaviour can be defined as ``the level
+ of detail required for the description of subsystem behaviour as
+ defined by (in particular work unit )''. It states that a detailed description of
+ the behaviour typically discusses how the functionality is
+ provided, in terms of what key data and data structures re
+ present; what control relationships exist within a subsytem and
+ how these elements work together to provide the SFR-enforcing
+ behaviour.
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ When is combined with a component of , which includes descriptions at the module level
+ (e.g. ), the level of detail needed to map
+ the test cases to the behaviour of the subsystems may require
+ information from the module description to be used. This is
+ because allows the description of details
+ to be shifted from the subsystem level to the module level, or
+ even to omit the subsystems altogether.
+ In any case, the required level of detail in the provided
+ reference to the tested behaviour can be defined as ``the level
+ of detail required for the description of subsystem behaviour as
+ defined by (in particular work unit )''. It states that a detailed description of
+ the behaviour typically discusses how the functionality is
+ provided, in terms of what key data and data structures re
+ present; what control relationships exist within a subsytem and
+ how these elements work together to provide the SFR-enforcing
+ behaviour.
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to the subsystem behaviour
+ or interaction description in the TOE design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the SFR-enforcing
+ modules, of the TSF. Testing at this level of TOE
+ description provides assurance that the TSF subsystems and
+ SFR-enforcing modules behave and interact as described in
+ the TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has tested all the TSF subsystems and SFR-enforcing
+ modules against the TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation and
+ the TSF subsystems and SFR-enforcing modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the SFR-enforcing modules in the TOE design have been
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of
+ SFR-enforcing modules are included within the test
+ documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms at the modular
+ level, this work unit also verifies the correspondence
+ between the tests and the descriptions of the behaviour
+ of such mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ SFR-enforcing modules presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to the interfaces of SFR-enforcing modules.
+
+
+
+
+ The evaluator shall examine the test plan, test prerequisites,
+ test steps and expected result(s) to determine that the testing
+ approach for each SFR-enforcing module interface demonstrates
+ the expected behaviour of that interface.
+
+ While work unit addresses
+ expected behaviour of subsystems, this work unit addresses
+ expected behaviour of the SFR-enforcing module interfaces that
+ are covered by .
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to the subsystem behaviour
+ or interaction description in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all interfaces of SFR-enforcing modules
+ are tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of SFR-enforcing modules that are provided in the TOE
+ design have to be tested. Incomplete depth of testing
+ would be evident if any interface of any SFR-enforcing
+ modules was identified in the TOE design and no tests
+ could be attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of an SFR-enforcing module in the TOE
+ design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description.
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has tested the all the TSF subsystems and modules
+ against the TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that all
+ TSF modules in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are provided, the behaviour
+ of those subsystems may be performed directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ If TSF subsystem interfaces are provided, the
+ interactions with other subsystems may be performed
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of TSF modules
+ are included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for each TSF module
+ interface demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to the subsystem behaviour
+ or interaction description in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to determine
+ that all interfaces of all TSF modules are tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of TSF modules that are provided in the TOE design have
+ to be tested. Incomplete depth of testing would be
+ evident if any interface of any TSF module was
+ identified in the TOE design and no tests could be
+ attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of a TSF module in the TOE design.
+
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description, and in accordance with the
+ implementation representation.
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all modules in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the TSF operates in accordance with its implementation
+ representation.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ Functional testing performed by the developer provides
+ assurance that the tests in the test documentation are
+ performed and documented correctly. The correspondence of
+ these tests to the design descriptions of the TSF is
+ achieved through the and
+ families.
+
+ This family contributes to providing assurance that the
+ likelihood of undiscovered flaws is relatively small.
+
+ The families , and are used in combination to define the evidence
+ of testing to be supplied by a developer. Independent
+ functional testing by the evaluator is specified by .
+
+
+
+ Functional testing establishes that the tests performed by
+ the developer are performed and documented correctly.
+
+
+
+ This family contains two components, the higher requiring
+ that ordering dependencies are analysed.
+
+
+
+ Procedures for performing tests are expected to provide
+ instructions for using test programs and test suites,
+ including the test environment, test conditions, test data
+ parameters and values. The test procedures should also show
+ how the test results are derived from the test
+ inputs.
+
+ Ordering dependencies are relevant when the successful
+ execution of a particular test depends upon the existence of
+ a particular state. For example, this might require that
+ test A be executed immediately before test B, since the
+ state resulting from the successful execution of test A is a
+ prerequisite for the successful execution of test B. Thus,
+ failure of test B could be related to a problem with the
+ ordering dependencies. In the above example, test B could
+ fail because test C (rather than test A) was executed
+ immediately before it, or the failure of test B could be
+ related to a failure of test A.
+
+
+
+
+
+ The objective is for the developer to demonstrate that the
+ tests in the test documentation are performed and
+ documented correctly.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented the tests
+ in the test documentation.
+
+
+
+ The extent to which the test documentation is required to
+ cover the TSF is dependent upon the coverage assurance
+ component.
+
+ For the developer tests provided, the evaluator determines
+ whether the tests are repeatable, and the extent to which
+ the developer's tests can be used for the evaluator's
+ independent testing effort. Any TSFI for which the
+ developer's test results indicate that it might not
+ perform as specified should be tested independently by the
+ evaluator to determine whether or not it does.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation.
+
+
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the test documentation
+ includes test plans, expected test results and actual
+ test results.
+
+ The evaluator checks that test plans, expected tests
+ results and actual test results are included in the test
+ documentation.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that it describes the scenarios for performing each
+ test.
+
+ The evaluator determines that the test plan provides
+ information about the test configuration being used:
+ both on the configuration of the TOE and on any test
+ equipment being used. This information should be
+ detailed enough to ensure that the test configuration is
+ reproducible.
+
+ The evaluator also determines that the test plan
+ provides information about how to execute the test: any
+ necessary automated set-up procedures (and whether they
+ require privilege to run), inputs to be applied, how
+ these inputs are applied, how output is obtained, any
+ automated clean-up procedures (and whether they require
+ privilege to run), etc. This information should be
+ detailed enough to ensure that the test is
+ reproducible.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the TOE test configuration is consistent with the
+ ST.
+
+ The TOE referred to in the developer's test plan should
+ have the same unique reference as established by the
+ sub-activities and
+ identified in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The evaluator verifies
+ that all test configurations identified in the developer
+ test documentation are consistent with the ST. For
+ example, the ST might define configuration options that
+ must be set, which could have an impact upon what
+ constitutes the TOE by including or excluding additional
+ portions. The evaluator verifies that all such
+ variations of the TOE are considered.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+ If this work unit is applied to a component TOE that
+ might be used/integrated in a composed TOE (see ), the following will apply. In
+ the instances that the component TOE under evaluation
+ depends on other components in the operational
+ environment to support their operation, the developer
+ may wish to consider using the other component(s) that
+ will be used in the composed TOE to fulfil the
+ requirements of the operational environment as one of
+ the test configurations. This will reduce the amount an
+ additional testing that will be required for the
+ composed TOE evaluation.
+
+
+
+
+ The evaluator shall examine the test plans to determine
+ that sufficient instructions are provided for any
+ ordering dependencies.
+
+ Some steps may have to be performed to establish initial
+ conditions. For example, user accounts need to be added
+ before they can be deleted. An example of ordering
+ dependencies on the results of other tests is the need
+ to perform actions in a test that will result in the
+ generation of audit records, before performing a test to
+ consider the searching and sorting of those audit
+ records. Another example of an ordering dependency
+ would be where one test case generates a file of data to
+ be used as input for another test case.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that all expected tests results are
+ included.
+
+ The expected test results are needed to determine
+ whether or not a test has been successfully
+ performed. Expected test results are sufficient if they
+ are unambiguous and consistent with expected behaviour
+ given the testing approach.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall check that the actual test results
+ in the test documentation are consistent with the
+ expected test results in the test documentation.
+
+ A comparison of the actual and expected test results
+ provided by the developer will reveal any
+ inconsistencies between the results. It may be that a
+ direct comparison of actual results cannot be made until
+ some data reduction or synthesis has been first
+ performed. In such cases, the developer's test
+ documentation should describe the process to reduce or
+ synthesise the actual data.
+
+ For example, the developer may need to test the contents
+ of a message buffer after a network connection has
+ occurred to determine the contents of the buffer. The
+ message buffer will contain a binary number. This binary
+ number would have to be converted to another form of
+ data representation in order to make the test more
+ meaningful. The conversion of this binary representation
+ of data into a higher-level representation will have to
+ be described by the developer in enough detail to allow
+ an evaluator to perform the conversion process
+ (i.e. synchronous or asynchronous transmission, number
+ of stop bits, parity, etc.).
+
+ It should be noted that the description of the process
+ used to reduce or synthesise the actual data is used by
+ the evaluator not to actually perform the necessary
+ modification but to assess whether this process is
+ correct. It is up to the developer to transform the
+ expected test results into a format that allows an easy
+ comparison with the actual test results.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall report the developer testing effort,
+ outlining the testing approach, configuration, depth and
+ results.
+
+ The developer testing information recorded in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing of the TOE by the developer. The intent
+ of providing this information is to give a meaningful overview
+ of the developer testing effort. It is not intended that the
+ information regarding developer testing in the ETR be an exact
+ reproduction of specific test steps or results of individual
+ tests. The intention is to provide enough detail to allow other
+ evaluators and evaluation authorities to gain some insight about the
+ developer's testing approach, amount of testing performed, TOE
+ test configurations, and the overall results of the developer
+ testing.
+
+ Information that would typically be found in the ETR
+ subclause regarding the developer testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested,
+ including whether any privileged code was required
+ to set up the test or clean up afterwards;
+
+
+ testing approach. An account of the overall
+ developer testing strategy employed;
+
+
+ testing results. A description of the overall
+ developer testing results.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ developer testing effort.
+
+
+
+
+
+
+
+
+ The objectives are for the developer to demonstrate that
+ the tests in the test documentation are performed and
+ documented correctly, and to ensure that testing is
+ structured such as to avoid circular arguments about the
+ correctness of the interfaces being tested.
+
+
+
+ Although the test procedures may state pre-requisite
+ initial test conditions in terms of ordering of tests,
+ they may not provide a rationale for the ordering. An
+ analysis of test ordering is an important factor in
+ determining the adequacy of testing, as there is a
+ possibility of faults being concealed by the ordering of
+ tests.
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The test documentation shall include an analysis of the test
+ procedure ordering dependencies.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The objectives of this family are built upon the assurances
+ achieved in the , , and
+ families by verifying the developer testing and performing
+ additional tests by the evaluator.
+
+
+
+ Independent testing specifies the degree to which the
+ testing of the TSF must be performed by a party other than
+ the developer (e.g. a third party). This family adds value
+ by the introduction of tests that are not part of the
+ developer's tests.
+
+
+
+ Levelling is based upon the amount of developer test
+ documentation and test support and the amount of evaluator
+ testing.
+
+
+
+ This family deals with the degree to which there is
+ independent functional testing of the TSF. Independent
+ functional testing may take the form of repeating the
+ developer's functional tests (in whole or in part) or of
+ extending the scope or the depth of the developer's
+ tests. These activities are complementary, and an
+ appropriate mix must be planned for each TOE, which takes
+ into account the availability and coverage of test results,
+ and the functional complexity of the TSF.
+
+ Sampling of developer tests is intended to provide
+ confirmation that the developer has carried out his planned
+ test programme on the TSF, and has correctly recorded the
+ results. The size of sample selected will be influenced by
+ the detail and quality of the developer's functional test
+ results. The evaluator will also need to consider the scope
+ for devising additional tests, and the relative benefit that
+ may be gained from effort in these two areas. It is
+ recognised that repetition of all developer tests may be
+ feasible and desirable in some cases, but may be very
+ arduous and less productive in others. The highest component
+ in this family should therefore be used with
+ caution. Sampling will address the whole range of test
+ results available, including those supplied to meet the
+ requirements of both and
+ .
+
+ There is also a need to consider the different
+ configurations of the TOE that are included within the
+ evaluation. The evaluator will need to assess the
+ applicability of the results provided, and to plan his own
+ testing accordingly.
+
+ The suitability of the TOE for testing is based on the
+ access to the TOE, and the supporting documentation and
+ information required (including any test software or tools)
+ to run tests. The need for such support is addressed by the
+ dependencies to other assurance families.
+
+ Additionally, suitability of the TOE for testing may be
+ based on other considerations. For example, the version of
+ the TOE submitted by the developer may not be the final
+ version.
+
+ The term interfaces refers to interfaces
+ described in the functional specification and TOE design,
+ and parameters passed through invocations identified in the
+ implementation representation. The exact set of interfaces
+ to be used is selected through and the
+ components.
+
+ References to a subset of the interfaces are intended to
+ allow the evaluator to design an appropriate set of tests
+ which is consistent with the objectives of the evaluation
+ being conducted.
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents.
+
+
+
+ This component does not address the use of developer test
+ results. It is applicable where such results are not
+ available, and also in cases where the developer's testing
+ is accepted without validation. The evaluator is required
+ to devise and conduct tests with the objective of
+ confirming that the TOE operates in accordance with its
+ design representations, including but not limited to the
+ functional specification. The approach is to gain
+ confidence in correct operation through representative
+ testing, rather than to conduct every possible test. The
+ extent of testing to be planned for this purpose is a
+ methodology issue, and needs to be considered in the
+ context of a particular TOE and the balance of other
+ evaluation activities.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSFI, whether the
+ TOE behaves as specified in the functional specification
+ and guidance documentation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer should have the same
+ unique reference as established by the sub-activities and identified
+ in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state.
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall test a subset of the TSF to confirm that
+ the TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of the
+ interfaces. In other cases this may not be
+ cost-effective, and sampling is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of the interface. Complex interfaces may
+ require complex tests that impose onerous
+ requirements on the developer or evaluator, which
+ may not be conducive to cost-effective
+ evaluations. Conversely, they are a likely area to
+ find errors and are good candidates for the
+ subset. The evaluator will need to strike a balance
+ between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST and the functional specification, the
+ evaluator has to determine the most feasible way to test
+ the interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection, if the
+ implementation representation is available);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the behaviour of the
+ interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing activity during the evaluation. The
+ intent of providing this information is to give a meaningful
+ overview of the testing effort. It is not intended that the
+ information regarding testing in the ETR be an exact
+ reproduction of specific test instructions or results of
+ individual tests. The intention is to provide enough detail to
+ allow other evaluators and evaluation authorities to gain some insight about
+ the testing approach chosen, amount of testing performed, TOE
+ test configurations, and the overall results of the testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested;
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size;
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset;
+
+
+ interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset;
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ confirms that the developer performed some tests of some
+ interfaces in the functional specification.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ This component contains a requirement that the evaluator
+ has available test results from the developer to
+ supplement the programme of testing. The evaluator will
+ repeat a sample of the developer's tests to gain
+ confidence in the results obtained. Having established
+ such confidence the evaluator will build upon the
+ developer's testing by conducting additional tests that
+ exercise the TOE in a different manner. By using a
+ platform of validated developer test results the evaluator
+ is able to gain confidence that the TOE operates correctly
+ in a wider range of conditions than would be possible
+ purely using the developer's own efforts, given a fixed
+ level of resource. Having gained confidence that the
+ developer has tested the TOE, the evaluator will also have
+ more freedom, where appropriate, to concentrate testing in
+ areas where examination of documentation or specialist
+ knowledge has raised particular concerns.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSF, whether the TOE
+ behaves as specified in the design documentation, and to
+ gain confidence in the developer's test results by
+ performing a sample of the developer's tests.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design description;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the configuration management documentation;
+
+
+ the test documentation;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state.
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+
+ The evaluator shall examine the set of resources provided by the developer
+ to determine that they are equivalent to the set of resources used by the
+ developer to functionally test the TSF.
+
+ The set of resource used by the developer is documented
+ in the developer test plan, as considered in the family. The resource set may
+ include laboratory access and special test equipment,
+ among others. Resources that are not identical to those
+ used by the developer need to be equivalent in terms of
+ any impact they may have on test results.
+
+
+
+ The evaluator shall execute a sample of tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall conduct testing using a sample of
+ tests found in the developer test plan and
+ procedures.
+
+ The overall aim of this work unit is to perform a
+ sufficient number of the developer tests to confirm the
+ validity of the developer's test results. The evaluator
+ has to decide on the size of the sample, and the
+ developer tests that will compose the sample (see ).
+
+ All the developer tests can be traced back to specific
+ interfaces. Therefore, the factors to consider in the
+ selection of the tests to compose the sample are similar
+ to those listed for subset selection in work-unit . Additionally, the
+ evaluator may wish to employ a random sampling method to
+ select developer tests to include in the sample.
+
+
+
+ The evaluator shall check that all the actual test
+ results are consistent with the expected test
+ results.
+
+ Inconsistencies between the developer's expected test
+ results and actual test results will compel the
+ evaluator to resolve the discrepancies. Inconsistencies
+ encountered by the evaluator could be resolved by a
+ valid explanation and resolution of the inconsistencies
+ by the developer.
+
+ If a satisfactory explanation or resolution can not be reached,
+ the evaluator's confidence in the developer's test results may be
+ lessened and it may be necessary for the evaluator to increase
+ the sample size to the extent that the subset identified in work unit
+ is adequately tested:
+ deficiencies with the developer's tests need to result in either
+ corrective action to the TOE by the developer (e.g., if the inconsistency
+ is caused by incorrect behaviour) or to the developer's tests (e.g., if the
+ inconsistency is caused by an incorrect test), or in the production of new
+ tests by the evaluator.
+
+
+
+ The evaluator shall test a subset of the TSF to confirm that the
+ TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The developer test evidence. The developer test
+ evidence consists of: the test documentation, the
+ available test coverage analysis, and the available
+ depth of testing analysis. The developer test
+ evidence will provide insight as to how the TSF has
+ been exercised by the developer during testing. The
+ evaluator applies this information when developing
+ new tests to independently test the
+ TOE. Specifically the evaluator should consider:
+
+
+ augmentation of developer testing for
+ interfaces. The evaluator may wish to perform
+ more of the same type of tests by varying
+ parameters to more rigorously test the
+ interface.
+
+
+ supplementation of developer testing strategy
+ for interfaces. The evaluator may wish to vary
+ the testing approach of a specific interface by
+ testing it using another test strategy.
+
+
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of them. In other
+ cases this may not be cost-effective, and sampling
+ is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Rigour of developer testing of the interfaces. Those
+ interfaces that the evaluator determines require
+ additional testing should be included in the test
+ subset.
+
+
+ Developer test results. If the results of developer
+ tests cause the evaluator to doubt that an interface
+ is not properly implemented, then the evaluator
+ should include such interfaces in the test subset.
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of interfaces. Interfaces that require
+ complex implementation may require complex tests
+ that impose onerous requirements on the developer or
+ evaluator, which may not be conducive to
+ cost-effective evaluations. Conversely, they are a
+ likely area to find errors and are good candidates
+ for the subset. The evaluator will need to strike a
+ balance between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST, the functional specification, and the
+ TOE design description, the evaluator has to determine
+ the most feasible way to test the
+ interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour of that interface.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing activity during the evaluation. The
+ intent of providing this information is to give a meaningful
+ overview of the testing effort. It is not intended that the
+ information regarding testing in the ETR be an exact
+ reproduction of specific test instructions or results of
+ individual tests. The intention is to provide enough detail to
+ allow other evaluators and evaluation authorities to gain some insight about
+ the testing approach chosen, amount of evaluator testing
+ performed, amount of developer tests performed, TOE test
+ configurations, and the overall results of the testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested.
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size.
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset.
+
+
+ Interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset.
+
+
+ developer tests performed. The amount of developer
+ tests performed and a brief description of the
+ criteria used to select the tests.
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate
+ that the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ includes repeating all of the developer tests.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ In this component the evaluator must repeat all of the
+ developer's tests as part of the programme of testing. As
+ in the previous component the evaluator will also conduct
+ tests that aim to exercise the TSF in a different manner
+ from that achieved by the developer. In cases where
+ developer testing has been exhaustive, there may remain
+ little scope for this.
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall execute all tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall test the TSF to confirm that the entire
+ TSF operates as specified.
+
+
+
+
+
+
+
+ The class addresses the
+ possibility of exploitable vulnerabilities introduced in the
+ development or the operation of the TOE.
+
+
+
+ Assurance class defines
+ requirements directed at the identification of exploitable
+ vulnerabilities. Specifically, it addresses those
+ vulnerabilities introduced in the development, operation,
+ misuse, or incorrect configuration of the TOE.
+
+
+
+ Generally, the vulnerability assessment activity covers various
+ vulnerabilities in the development and operation of the
+ TOE. Development vulnerabilities take advantage of some property
+ of the TOE which was introduced during its development,
+ e.g. defeating the TSF self protection through tampering, direct
+ attack or monitoring of the TSF, defeating the TSF domain
+ separation through monitoring or direct attack the TSF, or
+ defeating non-bypassability through circumventing (bypassing)
+ the TSF. Operational vulnerabilities take advantage of
+ weaknesses in non-technical countermeasures to violate the TOE
+ SFRs, e.g. misuse or incorrect configuration. Misuse
+ investigates whether the TOE can be configured or used in a
+ manner that is insecure, but that an administrator or user of
+ the TOE would reasonably believe to be secure.
+
+ Assessment of development vulnerabilities is covered by the
+ assurance family . Basically,
+ all development vulnerabilities can be considered in the
+ context of due to the fact,
+ that this family allows application of a wide range of
+ assessment methodologies being unspecific to the kind of an
+ attack scenario. These unspecific assessment methodologies
+ comprise, among other, also the specific methodologies for
+ those TSF where covert channels are to be considered (a
+ channel capacity estimation can be done using informal
+ engineering measurements, as well as actual test measurements)
+ or can be overcome by the use of sufficient resources in the
+ form of a direct attack (underlying technical concept of those
+ TSF is based on probabilistic or permutational mechanisms; a
+ qualification of their security behaviour and the effort
+ required to overcome them can be made using a quantitative or
+ statistical analysis).
+
+ If there are security objectives specified in the ST to either
+ to prevent one user of the TOE from observing activity
+ associated with another user of the TOE, or to ensure that
+ information flows cannot be used to achieve enforced illicit
+ data signals, covert channel analysis should be considered
+ during the conduct of the vulnerability analysis. This is often
+ reflected by the inclusion of
+ and multilevel access control policies specified through and/or requirements in the ST.
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the exploitability of flaws or weaknesses in the TOE
+ in the operational environment. This determination is based
+ upon analysis of the evaluation evidence and a search of
+ publicly available material by the evaluator and is supported
+ by evaluator penetration testing.
+
+
+
+
+ Vulnerability analysis is an assessment to determine whether
+ potential vulnerabilities identified, during the evaluation
+ of the development and anticipated operation of the TOE or
+ by other methods (e.g. by flaw hypotheses or quantitative or
+ statistical analysis of the security behaviour of the
+ underlying security mechanisms), could allow attackers to
+ violate the SFRs.
+
+ Vulnerability analysis deals with the threats that an
+ attacker will be able to discover flaws that will allow
+ unauthorised access to data and functionality, allow the
+ ability to interfere with or alter the TSF, or interfere
+ with the authorised capabilities of other users.
+
+
+
+ Vulnerability analysis consists of the identification of
+ flaws potentially introduced in the different refinement
+ steps of the development (development vulnerabilities) or
+ through the application of the guidance in operation of the
+ TOE (operational vulnerabilities). It results in the
+ definition of penetration tests through the collection of
+ the necessary information concerning: (1) the completeness
+ of the TSF (does the TSF counter all the postulated
+ threats?), (2) the dependencies between all SFRs and (3)
+ whether any of the SFRs can be undermined through unexpected
+ behaviour of the TOE. These potential vulnerabilities are
+ assessed through penetration testing to determine whether
+ they could, in practise, be exploitable to compromise the
+ security of the TOE.
+
+ The characteristics of different levels of attack potential
+ are discussed in CEM .
+
+
+
+ Levelling is based on an increasing rigour of vulnerability
+ analysis by the evaluator and increased levels of attack
+ potential required by an attacker to identify and exploit
+ the potential vulnerabilities.
+
+
+
+
+
+
+
+ A vulnerability survey of information available in the
+ public domain is performed by the evaluator to ascertain
+ potential vulnerabilities that may be easily found by an
+ attacker.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has easily
+ identifiable exploitable vulnerabilities.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during the conduct of other parts of the
+ evaluation.
+
+ The use of the term guidance in this sub-activity refers
+ to the operational guidance and the preparative
+ guidance.
+
+ Potential vulnerabilities may be in information that is
+ publicly available, or not, and may require skill to
+ exploit, or not. These two aspects are related, but are
+ distinct. It should not be assumed that, simply because a
+ potential vulnerability is identifiable from information
+ that is publicly available, it can be easily
+ exploited.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the guidance documentation;
+
+
+ the TOE suitable for testing;
+
+
+ information publicly available to support the
+ identification of potential vulnerabilities.
+
+
+
+ Other input for this sub-activity is:
+
+
+ current information regarding potential
+ vulnerabilities (e.g. from an evaluation authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information, which
+ should be considered, e.g. mailing lists and security
+ forums on the world wide web that report known
+ vulnerabilities in specified technologies.
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks effectively operates to substantially
+ enhance the attack potential of a given attacker. The
+ accessibility of vulnerability information and
+ sophisticated attack tools on the Internet makes it more
+ likely that this information will be used in attempts to
+ identify potential vulnerabilities in the TOE and
+ exploit them. Modern search tools make such information
+ easily available to the evaluator, and the determination
+ of resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the information
+ publicly available. However, in this type of search, the
+ evaluator may not be able to describe the steps in
+ identifying potential vulnerabilities before the outset
+ of the examination, as the approach may evolve as a
+ result of findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses;
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing Basic
+ attack potential.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during other parts of the evaluation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the TOE using the guidance documentation,
+ functional specification, TOE design and security
+ architecture description to identify potential
+ vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a search of ST, guidance
+ documentation, functional specification, TOE design and
+ security architecture description evidence to identify
+ possible potential vulnerabilities in the TOE.
+
+ A search of the evidence should be completed whereby
+ specifications and documentation for the TOE are
+ analysed and then potential vulnerabilities in the TOE
+ are hypothesised, or speculated. The list of
+ hypothesised potential vulnerabilities is then
+ prioritised on the basis of the estimated probability
+ that a potential vulnerability exists and, assuming an
+ exploitable vulnerability does exist the attack
+ potential required to exploit it, and on the extent of
+ control or compromise it would provide. The prioritised
+ list of potential vulnerabilities is used to direct
+ penetration testing against the TOE.
+
+ The security architecture description provides the
+ developer vulnerability analysis, as it documents how
+ the TSF protects itself from interference from untrusted
+ subjects and prevents the bypass of security enforcement
+ functionality. Therefore, the evaluator should use this
+ description of the protection of the TSF as a basis for
+ the search for possible ways to undermine the
+ TSF.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the security
+ architecture description in the search for vulnerabilities (as
+ detailed in ), testing should
+ be performed to confirm the architectural properties. This is
+ likely to require negative tests attempting to disprove the
+ properties of the security architecture. In developing the
+ strategy for penetration testing, the evaluator will ensure that
+ each of the major characteristics of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ Basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Enhanced-Basic, Moderate or
+ High attack potential do not result in a failure of this
+ evaluator action. Where analysis supports the
+ hypothesis, these need not be considered further as an
+ input to penetration testing. However, such
+ vulnerabilities are reported in the ETR as residual
+ vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic attack potential and
+ resulting in a violation of the security objectives
+ should be the highest priority potential vulnerabilities
+ comprising the list used to direct penetration testing
+ against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than an Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Enhanced-Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Enhanced-Basic attack potential.
+
+
+
+ During the conduct of evaluation activities the evaluator
+ may also identify areas of concern. These are specific
+ portions of the TOE evidence that the evaluator has some
+ reservation about, although the evidence meets the
+ requirements for the activity with which the evidence is
+ associated. For example, a particular interface
+ specification looks particularly complex, and therefore
+ may be prone to error either in the development of the TOE
+ or in the operation of the TOE. There is no potential
+ vulnerability apparent at this stage, further
+ investigation is required. This is beyond the bounds of
+ encountered, as further investigation is required.
+
+ The focused approach to the identification of potential
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. Further
+ guidance on focused vulnerability analysis can be found in
+ Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation subset selected;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the identification of possible potential vulnerabilities;
+
+ the results of the testing of the basic design.
+
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent, focused vulnerability analysis of the
+ TOE using the guidance documentation, functional specification, TOE design, security
+ architecture description and implementation representation to identify potential
+ vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a focused search of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ A flaw hypothesis methodology needs to be used whereby
+ specifications and development and guidance evidence are
+ analysed and then potential vulnerabilities in the TOE are
+ hypothesised, or speculated.
+
+ The evaluator uses the knowledge of the TOE design and operation
+ gained from the TOE deliverables to conduct a flaw hypothesis to
+ identify potential flaws in the development of the TOE and
+ potential errors in the specified method of operation of the
+ TOE.
+
+ The security architecture description provides the developer
+ vulnerability analysis, as it documents how the TSF protects
+ itself from interference from untrusted subjects and prevents
+ the bypass of security enforcement functionality. Therefore, the
+ evaluator should build upon the understanding of the TSF
+ protection gained from the analysis of this evidence and then
+ develop this in the knowledge gained from other development
+ evidence.
+
+
+ The approach taken is directed by areas of concern
+ identified during examination of the evidence during the
+ conduct of evaluation activities and ensuring a
+ representative sample of the development and guidance
+ evidence provided for the evaluation is searched.
+
+ For guidance on sampling see Annex . This guidance
+ should be considered when selecting the subset, giving
+ reasons for:
+
+
+ the approach used in selection;
+
+
+ qualification that the evidence to be examined
+ supports that approach.
+
+
+
+ The areas of concern may relate to the sufficiency of
+ specific protection features detailed in the security
+ architecture description.
+
+ The evidence to be considered during the vulnerability analysis
+ may be linked to the evidence the attacker is assumed to be able
+ to obtain. For example, the developer may protect the TOE design
+ and implementation representations, so the only information
+ assumed to be available to an attacker is the functional
+ specification and guidance (publicly available). So, although
+ the objectives for assurance in the TOE ensure the TOE design
+ and implementation representation requirements are met, these
+ design representations may only be searched to further
+ investigate areas of concerns.
+
+ On the other hand, if the source is publicly available it would
+ be reasonable to assume that the attacker has access to the
+ source and can use this in attempts to attack the
+ TOE. Therefore, the source should be considered in the focused
+ examination approach.
+
+ The following indicates examples for the selection of
+ the subset of evidence to be considered:
+
+
+ For an evaluation where all levels of design
+ abstraction from functional specification to
+ implementation representation are provided,
+ examination of information in the functional
+ specification and the implementation representation
+ may be selected, as the functional specification
+ provides detail of interfaces available to an
+ attacker, and the implementation representation
+ incorporates the design decisions made at all other
+ design abstractions. Therefore, the TOE design
+ information will be considered as part of the
+ implementation representation.
+
+
+ Examination of a particular subset of information in
+ each of the design representations provided for the
+ evaluation.
+
+
+ Coverage of particular SFRs through each of the
+ design representations provided for the evaluation.
+
+
+ Examination of each of the design representations
+ provided for the evaluation, considering different
+ SFRs within each design representations.
+
+
+ Examination of aspects of the evidence provided for
+ the evaluation relating to current potential
+ vulnerability information the evaluator has received
+ (e.g. from a scheme).
+
+
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach; applying a system to the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered and the
+ hypothesis that is to be created.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be searched to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examine in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Enhanced-Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the security
+ architecture description in the search for vulnerabilities (as
+ detailed in ), testing should
+ be performed to confirm the architectural properties. If
+ requirements from are included in
+ the SARs, the developer testing evidence will include testing
+ performed to confirm the correct implementation of any specific
+ mechanisms detailed in the security architecture
+ description. However, the developer testing will not necessarily
+ include testing of all aspects of the architectural properties
+ that protect the TSF, as much of this testing will be negative
+ testing in nature, attempting to disprove the properties. In
+ developing the strategy for penetration testing, the evaluator
+ will ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ It will probably be practical to carry out penetration
+ test using a series of test cases, where each test case
+ will test for a specific potential vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Moderate or High attack
+ potential do not result in a failure of this evaluator
+ action. Where analysis supports the hypothesis, these
+ need not be considered further as an input to
+ penetration testing. However, such vulnerabilities are
+ reported in the ETR as residual vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic or Enhanced-Basic attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which an Enhanced-Basic attack potential is
+ required to effect an attack. However, as a result of
+ evaluation expertise, the evaluator may discover a
+ potential vulnerability that is exploitable only by an
+ attacker with greater than Enhanced-Basic attack
+ potential. Such vulnerabilities are to be reported in
+ the ETR as residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming an Enhanced-Basic attack
+ potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing an Enhanced-Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Moderate attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Moderate.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Moderate.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Moderate attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the identification of possible potential vulnerabilities;
+
+ the results of the testing of the basic design.
+
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will describe the approach to be taken to
+ identify potential vulnerabilities in the publicly
+ available material, detailing the search to be
+ performed. This may be driven by factors such as areas
+ of concern identified by the evaluator, linked to the
+ evidence the attacker is assumed to be able to obtain.
+ However, it is recognised that in this type of search
+ the approach may further evolve as a result of findings
+ during the search. Therefore, the evaluator will also
+ report any actions taken in addition to those described
+ in the approach to further investigate issues thought to
+ lead to potential vulnerabilities, and will report the
+ evidence examined in completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct a methodical analysis of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ Guidance on methodical vulnerability analysis is
+ provided in Annex .
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach. A system is to be applied in the
+ examination. The evaluator is to describe the method to
+ be used in terms of the manner in which this information
+ is to be considered and the hypothesis that is to be
+ created.
+
+ A flaw hypothesis methodology needs to be used whereby the ST,
+ development (functional specification, TOE design and
+ implementation representation) and guidance evidence are
+ analysed and then vulnerabilities in the TOE are hypothesised,
+ or speculated.
+
+ The evaluator uses the knowledge of the TOE design and operation
+ gained from the TOE deliverables to conduct a flaw hypothesis to
+ identify potential flaws in the development of the TOE and
+ potential errors in the specified method of operation of the
+ TOE.
+
+ The security architecture description provides the developer
+ vulnerability analysis, as it documents how the TSF protects
+ itself from interference from untrusted subjects and prevents
+ the bypass of security enforcement functionality. Therefore, the
+ evaluator should build upon the understanding of the TSF
+ protection gained from the analysis of this evidence and then
+ develop this in the knowledge gained from other development
+ evidence.
+
+ The approach taken to the methodical search for vulnerabilities
+ is to consider any areas of concern identified in the results of
+ the evaluator's assessment of the development and guidance
+ evidence. However, the evaluator should also consider each
+ aspect of the security architecture analysis to search for any
+ ways in which the protection of the TSF can be undermined. It
+ may be helpful to structure the methodical analysis on the basis
+ of the material presented in the security architecture
+ description, introducing concerns from other evidence as appropriate. The analysis can then be
+ further developed to ensure all other material from the evidence is considered.
+
+ The following provide some examples of hypotheses that
+ may be created when examining the evidence:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that 'all interface
+ specifications in the evidence provided will be searched
+ to hypothesise potential vulnerabilities' and go on to
+ explain the methods used in the hypothesis.
+
+ In addition, areas of concern the evaluator has identified
+ during examination of the evidence during the conduct of
+ evaluation activities. Areas of concern may also be identified
+ during the conduct of other work units associated with this
+ component, in particular ,
+ and where the development and conduct of penetration
+ tests may identify further areas of concerns for investigation,
+ or potential vulnerabilities.
+
+ However, examination of only a subset of the development
+ and guidance evidence or their contents is not permitted
+ in this level of rigour. The approach description should
+ provide a demonstration that the methodical approach
+ used is complete, providing confidence that the approach
+ used to search the deliverables has considered all of
+ the information provided in those deliverables.
+
+ This approach to identification of potential vulnerabilities is
+ to take an ordered and planned approach; applying a system to
+ the examination. The evaluator is to describe the method to be
+ used in terms of how the evidence will be considered; the manner
+ in which this information is to be considered and the hypothesis
+ that is to be created. This approach should be agreed with the
+ evaluation authority, and the evaluation authority may
+ provide detail of any additional approaches the evaluator should
+ take to the vulnerability analysis and identify any additional
+ information that should be considered by the evaluator.
+
+ Although a system to identifying potential
+ vulnerabilities is predefined, the identification
+ process may still be iterative, where the identification
+ of one potential vulnerability may lead to identifying
+ another area of concern that requires further
+ investigation.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing Moderate attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the
+ security architecture description in the search for
+ vulnerabilities (as detailed in ), testing should be performed to confirm the
+ architectural properties. If requirements from are included in the SARs, the
+ developer testing evidence will include testing
+ performed to confirm the correct implementation of any
+ specific mechanisms detailed in the security
+ architecture description. However, the developer testing
+ will not necessarily include testing of all aspects of
+ the architectural properties that protect the TSF, as
+ much of this testing will be negative testing in nature,
+ attempting to disprove the properties. In developing the
+ strategy for penetration testing, the evaluator will
+ ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Moderate (or less) attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Moderate attack potential is required
+ to effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Moderate attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI;
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Moderate attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than a High attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than High.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of High.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing High
+ attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+ If the TOE SFRs include and
+ requirements such that
+ actions and data of one subject cannot be observed and
+ linked with another subject, the evaluator should consider
+ performing a covert channel analysis. This will build
+ upon the design evidence provided by the developer in
+ satisfaction of and requirements. The design evidence
+ will include details of how the TOE architecture prevents
+ observation by subjects of actions performed by other
+ subjects. the evaluator should seek guidance from the
+ evaluation authority on the conduct of such a covert
+ channel analysis.
+
+ The analysis of the guidance documentation is to include
+ consideration of whether it is possible to unknowingly
+ configure the TOE insecurely. Therefore, the analysis will
+ consider warning prompts provided by the TOE when
+ configuration options are selected by the user that may
+ render the TOE in an insecure state, not just in the
+ guidance but also in the use of the TOE. An example may be
+ when access control rules are amended from a remote
+ administration console, which will not take effect until
+ the TOE has been restarted. The evaluator will determine
+ whether the TOE issues a suitable warning when the changes
+ are made to ensure the user is aware that a restart must
+ be completed before the changes take effect.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing High attack potential.
+
+
+
+
+
+
+
+ EAL1 is applicable where some confidence in correct operation
+ is required, but the threats to security are not viewed as
+ serious. It will be of value where independent assurance is
+ required to support the contention that due care has been
+ exercised with respect to the protection of personal or
+ similar information.
+
+ EAL1 requires only a limited security target. It is sufficient
+ to simply state the SFRs that the TOE must meet, rather than
+ deriving them from threats, OSPs and assumptions through
+ security objectives.
+
+ EAL1 provides an evaluation of the TOE as made available to
+ the customer, including independent testing against a
+ specification, and an examination of the guidance
+ documentation provided. It is intended that an EAL1 evaluation
+ could be successfully conducted without assistance from the
+ developer of the TOE, and for minimal outlay.
+
+ An evaluation at this level should provide evidence that the
+ TOE functions in a manner consistent with its
+ documentation.
+
+
+
+ EAL1 provides a basic level of assurance by a limited security
+ target and an analysis of the SFRs in that ST using a
+ functional and interface specification and guidance
+ documentation, to understand the security behaviour.
+
+ The analysis is supported by a search for potential
+ vulnerabilities in the public domain and independent testing
+ (functional and penetration) of the TSF.
+
+ EAL1 also provides assurance through unique identification of
+ the TOE and of the relevant evaluation documents.
+
+ This EAL provides a meaningful increase in assurance over
+ unevaluated IT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL2 requires the co-operation of the developer in terms of
+ the delivery of design information and test results, but
+ should not demand more effort on the part of the developer
+ than is consistent with good commercial practise. As such it
+ should not require a substantially increased investment of
+ cost or time.
+
+ EAL2 is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record. Such a
+ situation may arise when securing legacy systems, or where
+ access to the developer may be limited.
+
+
+
+ EAL2 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation and a basic
+ description of the architecture of the TOE, to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, selective independent confirmation of the
+ developer test results, and a vulnerability analysis (based
+ upon the functional specification, TOE design, security architecture
+ description and guidance evidence provided) demonstrating
+ resistance to penetration attackers with a basic attack
+ potential.
+
+ EAL2 also provides assurance through use of a configuration
+ management system and evidence of secure delivery
+ procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL1 by requiring developer testing, a vulnerability analysis
+ (in addition to the search of the public domain), and
+ independent testing based upon more detailed TOE
+ specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL3 permits a conscientious developer to gain maximum
+ assurance from positive security engineering at the design
+ stage without substantial alteration of existing sound
+ development practises.
+
+ EAL3 is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the TOE and
+ its development without substantial re-engineering.
+
+
+
+ EAL3 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation, and an
+ architectural description of the design of the TOE, to
+ understand the security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent
+ confirmation of the developer test results, and a
+ vulnerability analysis (based upon the functional
+ specification, TOE design, security architecture description and guidance
+ evidence provided) demonstrating resistance to penetration
+ attackers with a basic attack potential.
+
+ EAL3 also provides assurance through the use of development
+ environment controls, TOE configuration management, and
+ evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL2 by requiring more complete testing coverage of the
+ security functionality and mechanisms and/or procedures that
+ provide some confidence that the TOE will not be tampered with
+ during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL4 permits a developer to gain maximum assurance from
+ positive security engineering based on good commercial
+ development practises which, though rigorous, do not require
+ substantial specialist knowledge, skills, and other
+ resources. EAL4 is the highest level at which it is likely to
+ be economically feasible to retrofit to an existing product
+ line.
+
+ EAL4 is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity TOEs
+ and are prepared to incur additional security-specific
+ engineering costs.
+
+
+
+ EAL4 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the basic modular design of the TOE, and a
+ subset of the implementation, to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent confirmation
+ of the developer test results, and a vulnerability analysis (based upon
+ the functional specification, TOE design, implementation
+ representation, security architecture description and guidance
+ evidence provided) demonstrating resistance to penetration
+ attackers with an Enhanced-Basic attack potential.
+
+ EAL4 also provides assurance through the use of development
+ environment controls and additional TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from EAL3
+ by requiring more design description, the implementation
+ representation for the entire TSF, and improved mechanisms
+ and/or procedures that provide confidence that the TOE will not
+ be tampered with during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL5 permits a developer to gain maximum assurance from
+ security engineering based upon rigorous commercial
+ development practises supported by moderate application of
+ specialist security engineering techniques. Such a TOE will
+ probably be designed and developed with the intent of
+ achieving EAL5 assurance. It is likely that the additional
+ costs attributable to the EAL5 requirements, relative to
+ rigorous development without the application of specialised
+ techniques, will not be large.
+
+ EAL5 is therefore applicable in those circumstances where
+ developers or users require a high level of independently
+ assured security in a planned development and require a
+ rigorous development approach without incurring unreasonable
+ costs attributable to specialist security engineering
+ techniques.
+
+
+
+ EAL5 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the design of the TOE, and the implementation,
+ to understand the security behaviour. A modular TSF design is
+ also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a moderate attack potential.
+
+ EAL5 also provides assurance through the use of a development
+ environment controls, and comprehensive TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from EAL4
+ by requiring semiformal design descriptions, a more structured
+ (and hence analysable) architecture, and improved mechanisms
+ and/or procedures that provide confidence that the TOE will not
+ be tampered with during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL6 permits developers to gain high assurance from
+ application of security engineering techniques to a rigorous
+ development environment in order to produce a premium TOE for
+ protecting high value assets against significant risks.
+
+ EAL6 is therefore applicable to the development of security
+ TOEs for application in high risk situations where the value
+ of the protected assets justifies the additional costs.
+
+
+
+ EAL6 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and the implementation to understand the
+ security behaviour. Assurance is additionally gained through a
+ formal model of select TOE security policies and a semiformal
+ presentation of the functional specification and TOE design. A
+ modular, layered and simple TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a high attack potential.
+
+ EAL6 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL5 by requiring more comprehensive analysis, a structured
+ representation of the implementation, more architectural
+ structure (e.g. layering), more comprehensive independent
+ vulnerability analysis, and improved configuration management
+ and development environment controls.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL7 is applicable to the development of security TOEs for
+ application in extremely high risk situations and/or where the
+ high value of the assets justifies the higher costs. Practical
+ application of EAL7 is currently limited to TOEs with tightly
+ focused security functionality that is amenable to extensive
+ formal analysis.
+
+
+
+ EAL7 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and a structured presentation of the
+ implementation to understand the security behaviour. Assurance
+ is additionally gained through a formal model of select TOE
+ security policies and a semiformal presentation of the
+ functional specification and TOE design. A modular, layered
+ and simple TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design and implementation representation,
+ complete independent confirmation of the developer test
+ results, and an independent vulnerability analysis
+ demonstrating resistance to penetration attackers with a high
+ attack potential.
+
+ EAL7 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL6 by requiring more comprehensive analysis using formal
+ representations and formal correspondence, and comprehensive
+ testing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-A is applicable when a composed TOE is integrated and
+ confidence in the correct security operation of the resulting
+ composite is required. This requires the cooperation of the
+ developer of the dependent component in terms of delivery of
+ design information and test results from the dependent
+ component certification, without requiring the involvement of
+ the base component developer.
+
+ CAP-A is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record.
+
+
+
+ CAP-A provides assurance by analysis of a security target for
+ the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation) and a
+ specification for the interfaces between the component TOEs in
+ the composed TOE to understand the security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information,
+ evidence of developer testing based on the reliance
+ information, development information and composition
+ rationale, and selective independent confirmation of the
+ developer test results. The analysis is also supported by a
+ vulnerability review of the composed TOE by the
+ evaluator.
+
+ CAP-A also provides assurance through unique identification of
+ the composed TOE (i.e. IT TOE and guidance
+ documentation).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-B permits a conscientious developer to gain maximum
+ assurance from understanding, at a subsystem level, the
+ affects of interactions between component TOEs integrated in
+ the composed TOE, whilst minimising the demand of involvement
+ of the base component developer.
+
+ CAP-B is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the composed
+ TOE and its development without substantial
+ re-engineering.
+
+
+
+ CAP-B provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF subsystems) contained in
+ the composed development information to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now also including TOE design), evidence of developer testing
+ based on the reliance information, development information and
+ composition rationale, and selective independent confirmation
+ of the developer test results. The analysis is also supported
+ by a vulnerability analysis of the composed TOE by the
+ evaluator demonstrating resistance to attackers with basic
+ attack potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-A by requiring more complete testing coverage of the
+ security functionality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-C permits a developer to gain maximum assurance from
+ positive analysis of the interactions between the components
+ of the composed TOE, which, though rigorous, do not require
+ full access to all evaluation evidence of the base
+ component.
+
+ CAP-C is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity
+ composed TOEs and are prepared to incur additional
+ security-specific engineering costs.
+
+
+
+ CAP-C provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF modules) contained in the
+ composed development information to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now including TOE design), evidence of developer testing based
+ on the reliance information, development information and
+ composition rationale, and selective independent confirmation of
+ the developer test results. The analysis is also supported by a
+ vulnerability analysis of the composed TOE by the evaluator
+ demonstrating resistance to attackers with Enhanced-Basic attack
+ potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-B by requiring more design description and demonstration
+ of resistance to a higher attack potential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/c5dec/assets/database/SecurityControls/cc3R5.dtd b/c5dec/assets/database/SecurityControls/cc3R5.dtd
new file mode 100644
index 0000000..2ab04ea
--- /dev/null
+++ b/c5dec/assets/database/SecurityControls/cc3R5.dtd
@@ -0,0 +1,498 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/c5dec/assets/database/SecurityControls/cc3R5.xml b/c5dec/assets/database/SecurityControls/cc3R5.xml
new file mode 100644
index 0000000..fa8ff97
--- /dev/null
+++ b/c5dec/assets/database/SecurityControls/cc3R5.xml
@@ -0,0 +1,54377 @@
+
+
+
+
+
+
+
+
+ For the purposes of this document, the terms, definitions,
+ symbols and abbreviated terms given in CC Part 1 apply.
+
+
+
+ Security assurance components, as defined in this CC Part 3, are
+ the basis for the security assurance requirements expressed in a
+ Protection Profile (PP) or a Security Target (ST).
+
+ These requirements establish a standard way of expressing the
+ assurance requirements for TOEs. This CC Part 3 catalogues the
+ set of assurance components, families and classes. This CC Part
+ 3 also defines evaluation criteria for PPs and STs and presents
+ evaluation assurance levels that define the predefined CC scale
+ for rating assurance for TOEs, which is called the Evaluation
+ Assurance Levels (EALs).
+
+ The audience for this CC Part 3 includes consumers, developers,
+ and evaluators of secure IT products. CC Part 1 Clause provides additional information
+ on the target audience of the CC, and on the use of the CC by
+ the groups that comprise the target audience. These groups may
+ use this part of the CC as follows:
+
+
+ Consumers, who use this CC Part 3 when selecting components
+ to express assurance requirements to satisfy the security
+ objectives expressed in a PP or ST, determining required
+ levels of security assurance of the TOE.
+
+
+ Developers, who respond to actual or perceived consumer
+ security requirements in constructing a TOE, reference this
+ CC Part 3 when interpreting statements of assurance
+ requirements and determining assurance approaches of TOEs.
+
+
+ Evaluators, who use the assurance requirements defined in
+ this part of the CC as mandatory statement of evaluation
+ criteria when determining the assurance of TOEs and when
+ evaluating PPs and STs.
+
+
+
+
+
+
+ Clause describes the paradigm
+ used in the security assurance requirements of CC Part
+ 3.
+
+ Clause describes the
+ presentation structure of the assurance classes, families,
+ components, evaluation assurance levels along with their
+ relationships, and the structure of the composed assurance
+ packages. It also characterises the assurance classes and
+ families found in Clauses through
+ .
+
+ Clause provides detailed
+ definitions of the EALs.
+
+ Clause provides detailed
+ definitions of the CAPs.
+
+ Clauses through provide the detailed definitions of the CC Part 3
+ assurance classes.
+
+ provides further
+ explanations and examples of the concepts behind the
+ Development class.
+
+ provides an explanation of
+ the concepts behind composed TOE evaluations and the
+ Composition class.
+
+ provides
+ a summary of the dependencies between the assurance
+ components.
+
+ provides a cross
+ reference between PPs and the families and components of the
+ class.
+
+ provides a cross reference
+ between the EALs and the assurance components.
+
+ provides a cross reference
+ between the CAPs and the assurance components.
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CC-1
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 1: Introduction and general model.
+
+
+
+ CC-2
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 2: Functional security components.
+
+
+
+
+
+ This CC Part 3 defines the assurance requirements of the CC. It
+ includes the evaluation assurance levels (EALs) that define a
+ scale for measuring assurance for component TOEs, the composed
+ assurance packages (CAPs) that define a scale for measuring
+ assurance for composed TOEs, the individual assurance components
+ from which the assurance levels and packages are composed, and
+ the criteria for evaluation of PPs and STs.
+
+
+
+ The goal of this annex is to explain the concepts behind
+ composition evaluations and the
+ criteria. This annex does not define the criteria; this definition can be found in clause
+ .
+
+
+ The IT market is, on the whole, made up of vendors offering a
+ particular type of product/technology. Although there is some
+ overlap, where a PC hardware vendor may also offer application
+ software and/or operating systems or a chip manufacturer may
+ also develop a dedicated operating system for their own
+ chipset, it is often the case that an IT solution is
+ implemented by a variety of vendors.
+
+ There is sometimes a need for assurance in the combination
+ (composition) of components in addition to the assurance of
+ the individual components. Although there is cooperation
+ between these vendors, in the dissemination of certain
+ material required for the technical integration of the
+ components, the agreements rarely stretch to the extent of
+ providing detailed design information and development
+ process/procedure evidence. This lack of information from the
+ developer of a component on which another component relies
+ means that the dependent component developer does not have
+ access to the type of information necessary to perform an
+ evaluation of both the dependent and base components at EAL2
+ or above. Therefore, while an evaluation of the dependent
+ component can still be performed at any assurance level, to
+ compose components with assurance at EAL2 or above it is
+ necessary to reuse the evaluation evidence and results of
+ evaluations performed for the component developer.
+
+ It is intended that the criteria
+ are applicable in the situation where one IT entity is
+ dependent on another for the provision of security
+ services. The entity providing the services is termed the
+ ``base component'', and that receiving the services is termed
+ the ``dependent component''. This relationship may exist in a
+ number of contexts. For example, an application (dependent
+ component) may use services provided by an operating system
+ (base component). Alternatively, the relationship may be
+ peer-to-peer, in the sense of two linked applications, either
+ running in a common operating system environment, or on
+ separate hardware platforms. If there is a dominant peer
+ providing the services to the minor peer, the dominant peer is
+ considered to be the base component and the minor peer the
+ dependent component. If the peers provide services to each
+ other in a mutual manner, each peer will be considered to be
+ the base component for the services offered and dependent
+ component for the services required. This will require
+ iterations of the components
+ applying all requirements to each type of component
+ peer.
+
+ The criteria are also intended to be more broadly applicable,
+ stepwise (where a composed TOE comprised of a dependent
+ component and a base component itself becomes the base
+ component of another composed TOE), in more complex
+ relationships, but this may require further
+ interpretation.
+
+ It is still required for composed TOE evaluations that the
+ individual components are evaluated independently, as the
+ composition evaluation builds on the results of the individual
+ component evaluations. The evaluation of the dependent
+ component may still be in progress when the composed TOE
+ evaluation commences. However, the dependent component
+ evaluation must complete before the composed TOE evaluation
+ completes.
+
+ The composed evaluation activities may take place at the same
+ time as the dependent component evaluation. This is due to two
+ factors:
+
+
+ Economic/business drivers - the dependent component
+ developer will either be sponsoring the composition
+ evaluation activities or supporting these activities as
+ the evaluation deliverables from the dependent component
+ evaluation are required for composed evaluation
+ activities.
+
+ Technical drivers - the components consider whether the
+ requisite assurance is provided by the base component
+ (e.g. considering the changes to the base component since
+ completion of the component evaluation) with the
+ understanding that the dependent component has recently
+ undergone (is undergoing) component evaluation and all
+ evaluation deliverables associated with the evaluation are
+ available. Therefore, there are no activities during
+ composition requesting the dependent component evaluation
+ activities to be re-verified. Also, it is verified that
+ the base component forms (one of) the test configurations
+ for the testing of the dependent component during the
+ dependent component evaluation, leaving to consider the base component in this
+ configuration.
+
+ The evaluation evidence from the evaluation of the dependent
+ component is required input into the composed TOE evaluation
+ activities. The only evaluation material from the evaluation
+ of the base component that is required as input into the
+ composed TOE evaluation activities:
+
+
+ Residual vulnerabilities in the base component, as
+ reported during the base component evaluation. This is
+ required for the
+ activities.
+
+ No other evaluation evidence from the base component
+ activities should be required for the composed TOE evaluation,
+ as the evaluation results from the component evaluation of the
+ base component should be reused. Additional information about
+ the base component may be required if the composed TOE TSF
+ includes more of the base component than was considered to be
+ TSF during component evaluation of the base component.
+
+ The component evaluation of the base and dependent components
+ are assumed to be complete by the time final verdicts are
+ assigned for the components.
+
+ The components only consider
+ resistance against an attacker with an attack potential up to
+ Enhanced-Basic. This is due to the level of design information
+ that can be provided of how the base component provides the
+ services on which the dependent component relies through
+ application of the
+ activities. Therefore, the confidence arising from composed TOE
+ evaluations using CAPs is limited to a level similar to that
+ obtained from EAL4 component TOE evaluations. Although
+ assurance in the components that comprise the composed TOE may
+ be higher than EAL4.
+
+
+
+ An ST will be submitted by the developer for the evaluation of
+ the composed (base component + dependent component) TOE. This
+ ST will identify the assurance package to be applied to the
+ composed TOE, providing assurance in the composed entity by
+ drawing upon the assurance gained in the component
+ evaluations.
+
+ The purpose of considering the composition of components
+ within an ST is to validate the compatibility of the
+ components from the point of view of both the environment and
+ the requirements, and also to assess that the composed TOE ST
+ is consistent with the component STs and the security policies
+ expressed within them. This includes determining that the
+ component STs and the security policies expressed within them
+ are compatible.
+
+ The composed TOE ST may refer out to the content of the
+ component STs, or the ST author may chose to reiterate the
+ material of the component STs within the composed TOE ST
+ providing a rationale of how the component STs are represented
+ in the composed TOE ST.
+
+ During the conduct of the
+ evaluation activities for a composed TOE ST the evaluator
+ determines that the component STs are accurately represented
+ in the composed TOE ST. This is achieved through determining
+ that the composed TOE ST demonstrably conforms to the
+ component TOE STs. Also, the evaluator will need to determine
+ that the dependencies of the dependent component on the
+ operational environment are adequately fulfilled in the
+ composed TOE.
+
+ The composed TOE description will describe the composed
+ solution. The logical and physical scope and boundary of the
+ composed solution will be described, and the logical
+ boundary(ies) between the components will also be
+ identified. The description will identify the security
+ functionality to be provided by each component.
+
+ The statement of SFRs for the composed TOE will identify which
+ component is to satisfy an SFR. If an SFR is met by both
+ components, then the statement will identify which component
+ meets the different aspects of the SFR. Similarly the composed
+ TOE Summary Specification will identify which component
+ provides the security functionality described.
+
+ The package of requirements
+ applied to the composed TOE ST should be consistent with the
+ package of requirements used in
+ the component evaluations.
+
+ Reuse of evaluation results from the evaluation of component
+ STs can be made in the instances that the composed TOE ST
+ directly refers to the component STs. e.g. if the composed TOE
+ ST refers to a component ST for part of its statement of SFRs,
+ the evaluator can understand that the requirement for the
+ completion of all assignment and selection operations (as
+ stated in .*.3C has been
+ satisfied in the component evaluations.
+
+
+
+ The TSF of the base component is often defined without
+ knowledge of the dependencies of the possible applications
+ with which it may by composed. The TSF of this base component
+ is defined to include all parts of the base component that
+ have to be relied upon for enforcement of the base component
+ SFRs. This will include all parts of the base component
+ required to implement the base component SFRs.
+
+ The TSFI of this base component represents the interfaces
+ provided by the TSF to the external entities defined in the
+ statement of SFRs to invoke a service of the TSF. This
+ includes interfaces to the human user and also interfaces to
+ external IT entities. However, the TSFI only includes those
+ interfaces to the TSF, and therefore is not necessarily an
+ exhaustive interface specification of all possible interfaces
+ available between an external entity and the base
+ component. The base component may present interfaces to
+ services that were not considered security-relevant, either
+ because of the inherent purpose of the service (e.g., adjust
+ type font) or because associated CC SFRs are not being claimed
+ in the base component's ST (e.g. the login interface when no
+ SFRs are claimed).
+
+ The functional interfaces provided by the base component are
+ in addition to the security interfaces (TSFIs), and are not
+ required to be considered during the base component
+ evaluation. These often include interfaces that are used by a
+ dependent component to invoke a service provided by the base
+ component.
+
+ The base component may include some indirect interfaces
+ through which TSFIs may be called, e.g. APIs that can be used
+ to invoke a service of the TSF, which were not considered
+ during the evaluation of the base component.
+
+
+ The dependent component, which relies on the base component,
+ is similarly defined: interfaces to external entities defined
+ in the SFRs of the component ST are categorised as TSFI and
+ are examined in .
+
+ Any call out from the dependent TSF to the environment in
+ support of an SFR will indicate that the dependent TSF
+ requires some service from the environment in order to satisfy
+ the enforcement of the stated dependent component SFRs. Such a
+ service is outside the dependent component boundary and the
+ base component is unlikely to be defined in the dependent ST
+ as an external entity. Hence, the calls for services made out
+ by the dependent TSF to its underlying platform (the base
+ component) will not be analysed as part of the activities. These dependencies on
+ the base component are expressed in the dependent component ST
+ as security objectives for the environment.
+
+ This abstraction of the dependent component and the interfaces
+ is shown in Figure
+ below.
+
+
+ When considering the composition of the base component and the
+ dependent component, if the dependent component's TSF requires
+ services from the base component to support the implementation
+ of the SFR, the interface to the service will need to be
+ defined. If that service is provided by the base component's
+ TSF, then that interface should be a TSFI of the base
+ component and will therefore already be defined within the
+ functional specification of the base component.
+
+ If, however, the service called by the dependent component's
+ TSF is not provided by the TSF of the base component (i.e., it
+ is implemented in the non-TSF portion of the base component or
+ possibly even in the non-TOE portion of the base component
+ (not illustrated in Figure ), there is unlikely to be a TSFI of the base
+ component relating to the service, unless the service is
+ mediated by the TSF of the base component. The interfaces to
+ these services from the dependent component to the operational
+ environment are considered in the family .
+
+ The non-TSF portion of the base component is drawn into the
+ TSF of the composed TOE due to the dependencies the dependent
+ component has on the base component to support the SFRs of the
+ dependent component. Therefore, in such cases, the TSF of the
+ composed TOE would be larger than simply the sum of the
+ components' TSFs.
+
+
+ It may be the case that the base component TSFI is being
+ called in a manner that was unforeseen in the base component
+ evaluation. Hence there would be a requirement for further
+ testing of the base component TSFI.
+
+ The possible interfaces are further described in the following
+ diagram (Figure ) and
+ supporting text.
+
+
+
+
+ Arrows going into 'dependent component-a'
+ (A and B) = where the component expects the environment to
+ respond to a service request (responding to calls out from
+ dependent component to the environment);
+
+ Arrows coming out of 'base component-b'
+ (C and D) = interfaces of services provided by the base
+ component to the environment;
+
+ Broken lines between components = types of communication
+ between pairs of interfaces;
+
+ The other (grey) arrows = interfaces that are described by
+ the given criteria.
+
+ The following is a simplification, but explains the
+ considerations that need to be made.
+
+ There are components a ('dependent component-a') and b ('base
+ component-b'): the arrows coming out of TSF-a
+ are services provided by TSF-a and are therefore TSFIs(a);
+ likewise, the arrows coming out of TSF-b
+ (``C'') are TSFIs(b). These are each detailed in their
+ respective functional specs. component-a is such that it
+ requires services from its environment: those needed by the
+ TSF(a) are labelled ``A''; the other (not related to TSF-a)
+ services are labelled ``B''.
+
+ When component-a and component-b are combined, there are four
+ possible combinations of {services needed by component-a} and
+ {services provided by component-b}, shown as broken lines
+ (types of communication between pairs of interfaces). Any set
+ of these might exist for a particular composition:
+
+
+ TSF-a needs those services that are provided by TSF-b ("A" is connected to "C"):
+ this is straightforward: the details about "C" are in the FSP for component-b.
+ In this instance the interfaces should all be defined in the functional specifications for
+ the component-b.
+
+
+ Non-TSF-a needs those services that are provided by TSF-b
+ (``B'' is connected to ``C''): this is straightforward
+ (again, the details about ``C'' are in the FSP for
+ component-b), but unimportant: security-wise.
+
+ Non-TSF-a needs those services that are provided by
+ non-TSF-b (``B'' is connected to ``D''): we have no
+ details about D, but there are no security implications
+ about the use of these interfaces, so they do not need to
+ be considered in the evaluation, although they are likely
+ to be an integration issue for the developer.
+
+ TSF-a needs those services that are provided by non-TSF-b
+ (``A'' is connected to ``D''): this would arise when
+ component-a and component-b have different senses of what
+ a ``security service'' is. Perhaps component-b is making
+ no claims about I&A (has no
+ SFRs in its ST), but component-a needs authentication
+ provided by its environment. There are no details about
+ the ``D'' interfaces available (they are not TSFI (b), so
+ they are not in component-b's FSP).
+
+ Note: if the kind of interaction described in case d above
+ exists, then the TSF of the composed TOE would be TSF-a + TSF-b
+ + Non-TSF-b. Otherwise, the TSF of the composed TOE would be
+ TSF-a + TSF-b.
+
+ Interfaces types 2 and 4 of Figure are not directly relevant to the evaluation of
+ the composed TOE. Interfaces 1 and 3 will be considered during
+ the application of different families:
+
+
+ (for component-b) will
+ describe the C interfaces.
+
+ will describe the A
+ interfaces.
+
+ will describe the C
+ interfaces for connection type 1 and the D interfaces for
+ connection type 3.
+
+ A typical example where composition may be applied is a
+ database management system (DBMS) that relies upon its
+ underlying operating system (OS). During the evaluation of
+ the DBMS component, there will be an assessment made of the
+ security properties of that DBMS (to whatever degree of rigour
+ is dictated by the assurance components used in the
+ evaluation): its TSF boundary will be identified, its
+ functional specification will be assessed to determine whether
+ it describes the interfaces to the security services provided
+ by the TSF, perhaps additional information about the TSF (its
+ design, architecture, internal structure) will be provided,
+ the TSF will be tested, aspects of its life-cycle and its
+ guidance documentation will be assessed, etc.
+
+ However, the DBMS evaluation will not call for any evidence
+ concerning the dependency the DBMS has on the OS. The ST of
+ the DBMS will most likely state assumptions about the OS in
+ its Assumptions subclause and state security objectives for the
+ OS in its Environment subclause. The DBMS ST may even
+ instantiate those objectives for the environment in terms of
+ SFRs for the OS. However, there will be no specification for
+ the OS that mirrors the detail in the functional
+ specification, architecture description, or other evidence as for the DBMS. will fulfil that need.
+
+ describes the interfaces of
+ the dependent TOE that make the calls to the base component
+ for the provision of services. These are the interfaces to
+ which the base component is to respond. The interface
+ descriptions are provided from the dependent component's
+ viewpoint.
+
+ describes the interfaces
+ provided by the base component, which respond to the dependent
+ component service requests. These interfaces are mapped to the
+ relevant dependent component interfaces that are identified in
+ the reliance information. (The completeness of this mapping,
+ whether the base component interfaces described represent all
+ dependent component interfaces, is not verified here, but in
+ ). At the higher levels of
+ the subsystems providing the
+ interfaces are described.
+
+ Any interfaces required by the dependent component that have
+ not been described for the base component are reported in the
+ rationale for . The rationale
+ also reports whether the interfaces of the base component on
+ which the dependent component relies were considered within
+ the base component evaluation. For any interfaces that were
+ not considered in the base component evaluation, a rationale
+ is provided of the impact of using the interface on the base
+ component TSF.
+
+
+
+
+ This annex contains ancillary material to further explain and
+ provide additional examples for the topics brought up in
+ families of the class.
+
+
+ A security architecture is a set of properties that the TSF
+ exhibits; these properties include self-protection, domain
+ separation, and non-bypassability. Having these properties
+ provides a basis of confidence that the TSF is providing its
+ security services. This annex provides additional material on
+ these properties, as well as discussion on contents of a
+ security architecture description.
+
+ The remainder of this subclause first explains these properties,
+ then discusses the kinds of information that are needed to
+ describe how the TSF exhibits those properties.
+
+ Self-protection refers to the ability of
+ the TSF to protect itself from manipulation from external
+ entities that may result in changes to the TSF. Without these
+ properties, the TSF might be disabled from performing its
+ security services.
+
+ It is oftentimes the case that a TOE uses services or
+ resources supplied by other IT entities in order to perform
+ its functions (e.g. an application that relies upon its
+ underlying operating system). In these cases, the TSF does
+ not protect itself entirely on its own, because it depends
+ on the other IT entities to protect the services it
+ uses.
+ Domain separation is a property whereby the TSF
+ creates separate security domains for each
+ untrusted active entity to operate on its resources, and then
+ keeps those domains separated from one another so that no entity
+ can run in the domain of any other. For example, an operating
+ system TOE supplies a domain (address space, per-process
+ environment variables) for each process associated with
+ untrusted entities.
+
+ For some TOEs such domains do not exist because all of the
+ actions of the untrusted entities are brokered by the TSF. A
+ packet-filter firewall is an example of such a TOE, where
+ there are no untrusted entity domains; there are only data
+ structures maintained by the TSF. The existence of domains,
+ then, is dependant upon 1) the type of TOE and 2) the SFRs
+ levied on the TOE. In the cases where the TOE does provide
+ domains for untrusted entities, this family requires that
+ those domains are isolated from one another such that
+ untrusted entities in one domain are prevented from
+ tampering (affecting without brokering by the TSF) from
+ another untrusted entity's domain.
+
+ Non-bypassability is a property that the
+ security functionality of the TSF (as specified by the SFRs)
+ is always invoked and cannot be circumvented when
+ appropriate for that specific mechanism. For example, if
+ access control to files is specified as a capability of the
+ TSF via an SFR, there must be no interfaces through which
+ files can be accessed without invoking the TSF's access
+ control mechanism (an interface through which a raw disk
+ access takes place might be an example of such an
+ interface).
+
+ As is the case with self-protection, the very nature of some
+ TOEs might depend upon their environments to play a role in
+ non-bypassability of the TSF. For example, a security
+ application TOE requires that it be invoked by the
+ underlying operating system. Similarly, a firewall depends
+ upon the fact that there are no direct connections between
+ the internal and external networks and that all traffic
+ between them must go through the firewall.
+
+
+ The security architecture description explains how the
+ properties described above are exhibited by the TSF. It
+ describes how domains are defined and how the TSF keeps them
+ separate. It describes what prevents untrusted processes
+ from getting to the TSF and modifying it. It describes what
+ ensures that all resources under the TSF's control are
+ adequately protected and that all actions related to the
+ SFRs are mediated by the TSF. It explains any role the
+ environment plays in any of these (e.g. presuming it gets
+ correctly invoked by its underlying environment, how are its
+ security functions invoked?).
+
+ The security architecture description presents the TSF's
+ properties of self-protection, domain separation, and
+ non-bypassability in terms of the decomposition descriptions.
+ The level of this description is commensurate with the TSF
+ description required by the ,
+ and requirements that are being claimed. For example, if
+ is the only TSF description
+ available, it would be difficult to provide any meaningful
+ security architecture description because none of the details of
+ any internal workings of the TSF would be available.
+
+ However, if the TOE design were also available, even at the most
+ basic level (), there would be
+ some information available concerning the subsystems that make
+ up the TSF, and there would be a description of how they work to
+ implement self-protection, domain separation, and
+ non-bypassability. For example, perhaps all user interaction
+ with the TOE is constrained through a process that acts on that
+ user's behalf, adopting all of the user's security attributes;
+ the security architecture description would describe how such a
+ process comes into being, how the process's behaviour is
+ constrained by the TSF (so it cannot corrupt the TSF), how all
+ actions of that process are mediated by the TSF (thereby
+ explaining why the TSF cannot be bypassed), etc.
+
+ If the available TOE design is more detailed (e.g. at the
+ modular level), or the implementation representation is also
+ available, then the security architecture description would be
+ correspondingly more detailed, explaining how the user's process
+ communicate with the TSF processes, how different requests are
+ processed by the TSF, what parameters are passed, what
+ programmatic protections (buffer overflow prevention, parameter
+ bounds checking, time of check/time of use checking, etc.) are
+ in place. Similarly, a TOE whose ST claimed the component would go into
+ implementation-specific detail.
+
+ The explanations provided in the security architecture
+ description are expected to be of sufficient detail that one
+ would be able to test their accuracy. That is, simple
+ assertions (e.g. "The TSF keeps domains separate'') provide
+ no useful information to convince the reader that the TSF
+ does indeed create and separate domains.
+
+ In cases where the TOE exhibits domain separation entirely on
+ its own, there would be a straightforward description of how
+ this is attained. The security architecture description would
+ explain the different kinds of domains that are defined by the
+ TSF, how they are defined (i.e. what resources are allocated
+ to each domain), how no resources are left unprotected, and
+ how the domains are kept separated so that active entities in
+ one domain cannot tamper with resources in another
+ domain.
+ For cases where the TOE depends upon other IT entities to play
+ a role in domain separation, that sharing of roles must be made
+ clear. For example, a TOE that is solely application software
+ relies upon the underlying operating system to correctly
+ instantiate the domains that the TOE defines; if the TOE
+ defines separate processing space, memory space, etc, for each
+ domain, it depends upon the underlying operating system to
+ operate correctly and benignly (e.g. allow the process to
+ execute only in the execution space that is requested by the
+ TOE software).
+ For example, mechanisms that implement domain separation
+ (e.g., memory management, protected processing modes provided
+ by the hardware, etc.) would be identified and described. Or,
+ the TSF might implement software protection constructs or
+ coding conventions that contribute to implementing separation
+ of software domains, perhaps by delineating user address space
+ from system address space.
+ The vulnerability analysis and testing (see ) activities will likely include attempts to defeat
+ the described TSF domain separation through the use of
+ monitoring or direct attack the TSF.
+
+
+ In cases where the TOE exhibits self-protection entirely
+ on its own, there would be a straightforward description
+ of how this self-protection is attained. Mechanisms that
+ provide domain separation to define a TSF domain that is
+ protected from other (user) domains would be identified
+ and described.
+
+ For cases where the TOE depends upon other IT entities to
+ play a role in protecting itself, that sharing of roles
+ must be made clear. For example, a TOE that is solely
+ application software relies upon the underlying operating
+ system to operate correctly and benignly; the application
+ cannot protect itself against a malicious operating system
+ that subverts it (for example, by overwriting its
+ executable code or TSF data).
+
+ The security architecture description also covers how user input
+ is handled by the TSF in such a way that the TSF does not
+ subject itself to being corrupted by that user input. For
+ example, the TSF might implement the notion of privilege and
+ protect itself by using privileged-mode routines to handle user
+ data. The TSF might make use of processor-based separation
+ mechanisms (e.g. privilege levels or rings) to separate TSF
+ code and data from user code and data. The TSF might implement
+ software protection constructs or coding conventions that
+ contribute to implementing separation of software, perhaps by
+ delineating user address space from system address space.
+
+ For TOEs that start up in a low-function mode (for
+ example, a single-user mode accessible only to installers
+ or administrators) and then transition to the evaluated
+ secure configuration (a mode whereby untrusted users are
+ able to login and use the services and resources of the
+ TOE), the security architecture description also includes
+ an explanation of how the TSF is protected against this
+ initialisation code that does not run in the evaluated
+ configuration. For such TOEs, the security architecture
+ description would explain what prevents those services
+ that should be available only during initialisation
+ (e.g. direct access to resources) from being accessible in
+ the evaluated configuration. It would also explain what
+ prevents initialisation code from running while the TOE is
+ in the evaluated configuration.
+
+ There must also be an explanation of how the trusted
+ initialisation code will maintain the integrity of the TSF
+ (and of its initialisation process) such that the
+ initialisation process is able to detect any modification
+ that would result in the TSF being spoofed into believe it
+ was in an initial secure state.
+
+ The vulnerability analysis and testing (see ) activities will likely include
+ attempts to defeat the described TSF self protection
+ through the use of tampering, direct attack, or monitoring
+ of the TSF.
+
+
+ The property of non-bypassability is concerned with
+ interfaces that permit the bypass of the enforcement
+ mechanisms. In most cases this is a consequence of the
+ implementation, where if a programmer is writing an
+ interface that accesses or manipulates an object, it is
+ that programmer's responsibility to use interfaces that
+ are part of the SFR enforcement mechanism for the object
+ and not to try to circumvent those interfaces. For the
+ description pertaining to non-bypassability, then, there
+ are two broad areas that have to be covered.
+
+ The first consists of those interfaces to the SFR-enforcement.
+ The property for these interfaces is that they contain no
+ operations or modes that allow them to be used to bypass the
+ TSF. It is likely that the evidence for and can be used in
+ large part to make this determination. Because non-bypassability
+ is the concern, if only certain operations available through
+ these TSFIs are documented (because they are SFR-enforcing) and
+ others are not, the developer should consider whether additional
+ information (to that presented in
+ and ) is necessary to make a
+ determination that the
+ SFR-supporting and SFR-non-interfering
+ operations of the TSFI do not afford an
+ untrusted entity the ability to bypass the policy being
+ enforced. If such information is necessary, it is included
+ in the security architecture description.
+
+ The second area of non-bypassability is concerned with
+ those interfaces whose interactions are not associated
+ with SFR-enforcement. Depending on the and components
+ claimed, some information about these interfaces may or
+ may not exist in the functional specification and TOE
+ design documentation. The information presented for such
+ interfaces (or groups of interfaces) should be sufficient
+ so that a reader can make a determination (at the level of
+ detail commensurate with the rest of the evidence supplied
+ in the class) that the
+ enforcement mechanisms cannot be bypassed.
+
+ The property that the security functionality cannot be
+ bypassed applies to all security functionality
+ equally. That is, the design description should cover
+ objects that are protected under the SFRs (e.g. _* components) and functionality
+ (e.g., audit) that is provided by the TSF. The description
+ should also identify the interfaces that are associated
+ with security functionality; this might make use of the
+ information in the functional specification. This
+ description should also describe any design constructs,
+ such as object managers, and their method of use. For
+ instance, if routines are to use a standard macro to
+ produce an audit record, this convention is a part of the
+ design that contributes to the non-bypassability of the
+ audit mechanism. It is important to note that
+ non-bypassability in this context is not an
+ attempt to answer the question ``could a part of the TSF
+ implementation, if malicious, bypass the security
+ functionality'', but rather to document how the
+ implementation does not bypass the security
+ functionality.
+
+ The vulnerability analysis and testing (see ) activities will likely include
+ attempts to defeat the described non-bypassability by
+ circumventing the TSF.
+
+
+
+
+ The purpose in specifying the TSFIs is to provide the
+ necessary information to conduct testing; without knowing the
+ possible means interact with the TSF, one cannot adequately
+ test the behaviour of the TSF.
+
+ There are two parts to specifying the TSFIs: identifying them
+ and describing them. Because of the diversity of possible
+ TOEs, and of different TSFs therein, there is no standard set
+ of interfaces that constitute ``TSFIs''. This annex provides
+ guidance on the factors that determine which interfaces are
+ TSFIs.
+
+
+ In order to identify the interfaces to the TSF, the parts of the
+ TOE that make up the TSF must first be identified. This
+ identification is actually a part of the analysis, but is also performed implicitly
+ (through identification and description of the TSFI) by the
+ developer in cases where is not
+ included in the assurance package. In this analysis, a portion
+ of the TOE must be considered to be in the TSF if it contributes
+ to the satisfaction of an SFR in the ST (in whole or in
+ part). This includes, for example, everything in the TOE that
+ contributes to TSF run-time initialisation, such as software
+ that runs prior to the TSF being able to protect itself because
+ enforcement of the SFRs has not yet begun (e.g., while booting
+ up). Also included in the TSF are all parts of the TOE that
+ contribute to the architectural principles of TSF
+ self-protection, domain separation, and non-bypassability (see
+ ).
+
+ Once the TSF has been defined, the TSFI are identified.
+ The TSFI consists of all means by which external entities (or
+ subjects in the TOE but outside of the TSF) supply data to the TSF,
+ receive data from the TSF and invoke services from the TSF.
+ These service invocations and responses are the means of crossing
+ the TSF boundary. While many of these are readily apparent, others
+ might not be as obvious. The question that should be asked when
+ determining the TSFIs is: ``How can a potential attacker interact
+ with the TSF in an attempt to subvert the SFRs?'' The following
+ discussions illustrate the application of the TSFI definition in
+ different contexts.
+
+
+ In TOEs such as smart cards, where the adversary has not
+ only logical access to the TOE, but also complete physical
+ access to the TOE, the TSF boundary is the physical
+ boundary. Therefore, the exposed electrical interfaces
+ are considered TSFI because their manipulation could
+ affect the behaviour of the TSF. As such, all these
+ interfaces (electrical contacts) need to be described:
+ various voltages that might be applied, etc.
+
+
+
+ The TSFIs of a TOE that performs protocol processing would
+ be those protocol layers to which a potential attacker has
+ direct access. This need not be the entire protocol stack,
+ but it might be.
+
+ For example, if the TOE were some sort of a network
+ appliance that allowed potential attackers to affect every
+ level of the protocol stack (i.e. to send arbitrary
+ signals, arbitrary voltages, arbitrary packets, arbitrary
+ datagrams, etc.), then the TSF boundary exists at each
+ layer of the stack. Therefore, the functional
+ specification would have to address every protocol at
+ every layer of the stack.
+
+ If, however, the TOE were a firewall that protects an
+ internal network from the Internet, a potential attacker
+ would have no means of directly manipulating the voltages
+ that enter the TOE; any extreme voltages would simply not
+ be passed though the Internet. That is, the attacker would
+ have access only to those protocols at the Internet layer
+ or above. The TSF boundary exists at each layer of the
+ stack. Therefore, the functional specification would have
+ to address only those protocols at or above the Internet
+ layer: it would describe each of the different
+ communication layers at which the firewall is exposed in
+ terms of what constitutes well-formed input for what might
+ appear on the line, and the result of both well-formed and
+ malformed inputs. For example, the description of the
+ Internet protocol layer would describe what constitutes a
+ well-formed IP packet and what happens when both
+ correctly-formed and malformed packets are
+ received. Likewise, the description of the TCP layer would
+ describe a successful TCP connection and what happens both
+ when successful connections are established and when
+ connections cannot be established or are inadvertently
+ dropped. Presuming the firewall's purpose is to filter
+ application-level commands (like FTP or telnet), the
+ description of the application layer would describe the
+ application-level commands that are recognised and
+ filtered by the firewall, as well as the results of
+ encountering unknown commands.
+
+ The descriptions of these layers would likely reference
+ published communication standards (telnet, FTP, TCP, etc.)
+ that are used, noting which user-defined options are
+ chosen.
+
+
+
+
+
+
+ ``Wrappers'' translate complex series of interactions into
+ simplified common services, such as when Operating Systems
+ create APIs for use by applications (as shown in Figure
+ ). Whether the TSFIs
+ would be the system calls or the APIs depends upon what is
+ available to the application: if the application can use
+ the system calls directly, then the system calls are the
+ TSFIs. If, however, there were something that prohibits
+ their direct use and requires all communication through
+ the APIs, then the APIs would be the TSFIs.
+
+ A Graphical User interface is similar: it translates
+ between machine-understandable commands and user-friendly
+ graphics. Similarly, the TSFIs would be the commands if
+ users have access to them, or the graphics (pull-down
+ menus, check-boxes, text fields) if the users are
+ constrained to using them.
+
+ It is worth noting that, in both of these examples, if the
+ user is prohibited from using the more primitive
+ interfaces (i.e. the system calls or the commands), the
+ description of this restriction and of its enforcement
+ would be included in the Security Architecture Description
+ (see ). Also, the wrapper would be
+ part of the TSF.
+
+
+
+ For a given TOE, not all of the interfaces may be
+ accessible. That is, the security
+ objectives for the operational environment (in the
+ Security Target) may prevent access to these interfaces or
+ limit access in such a way that they are practically
+ inaccessible. Such interfaces would not be considered
+ TSFIs. Some examples:
+
+ If the security objectives for the operational
+ environment for the stand-alone firewall state that
+ ``the firewall will be operational in a server room
+ environment to which only trusted and trained
+ personnel will have access, and which will be equipped
+ with an interruptible power supply (against power
+ failure)'', physical and power interfaces will not be
+ accessible, since trusted and trained personnel will
+ not attempt to dismantle the firewall and/or disable
+ its power supply. If the security
+ objectives for the operational environment for the
+ software firewall (application) state that ``the OS
+ and the hardware will provide a security domain for
+ the application free from tampering by other
+ programs'', the interfaces through which the firewall
+ can be accessed by other applications on the OS
+ (e.g. deleting or modifying the firewall executable,
+ direct reading or writing to the memory space of the
+ firewall) will not be accessible, since the
+ OS/hardware part of the operational environment makes
+ this interface inaccessible.If the
+ security objectives for the operational environment
+ for the software firewall additionally state that the
+ OS and hardware will faithfully execute the commands
+ of the TOE, and will not tamper with the TOE in any
+ manner, interfaces through which the firewall obtains
+ primitive functionality from the OS and hardware
+ (executing machine code instructions, OS APIs, such as
+ creating, reading, writing or deleting files,
+ graphical APIs etc.) will not be accessible, since the
+ OS/hardware are the only entities that can access that
+ interface, and they are completely
+ trusted. For all of these examples,
+ these inaccessible interfaces would not be
+ TSFIs.
+
+
+
+ Figure
+ illustrates a complex TOE: a database management system that
+ relies on hardware and software that is outside the TOE
+ boundary (referred to as the IT environment
+ in the rest of this discussion). To simplify this example,
+ the TOE is identical to the TSF. The
+ shaded boxes represent the TSF, while the unshaded boxes
+ represent IT entities in the environment. The TSF comprises
+ the database engine and management GUIs (represented by the
+ box labelled DB) and a kernel module that
+ runs as part of the OS that performs some security function
+ (represented by the box labelled PLG). The
+ TSF kernel module has entry points defined by the OS
+ specification that the OS will call to invoke some function
+ (this could be a device driver, or an authentication module,
+ etc.). The key is that this pluggable kernel module is
+ providing security services specified by functional
+ requirements in the ST.
+
+
+
+
+ The IT environment consists of the operating system itself
+ (represented by the box labelled OS), as
+ well as an external server (labelled SRV).
+ This external server, like the OS, provides a service that
+ the TSF depends on, and thus needs to be in the IT
+ environment. Interfaces in the figure are labelled
+ Ax for TSFI, and Bx for
+ other interfaces that would be documented in . Each of these groups of interfaces is now
+ discussed.
+
+ Interface group A1 represents the most obvious set of TSFI.
+ These are interfaces used by users to directly access the
+ database and its security functionality and
+ resources.
+
+ Interface group A2 represent the TSFI that the OS invokes to
+ obtain the functionality provided by the pluggable module.
+ These are contrasted with interface group B3, which
+ represent calls that the pluggable module makes to obtain
+ services from the IT environment.
+
+ Interface group A3 represent TSFI that pass through the IT
+ environment. In this case, the DBMS communicates over the
+ network using a proprietary application-level
+ protocol. While the IT environment is responsible for
+ providing various supporting protocols (e.g., Ethernet, IP,
+ TCP), the application layer protocol that is used to obtain
+ services from the DBMS is a TSFI and must be documented as
+ such. The dotted line indicates return values/services from
+ the TSF over the network connection.
+
+ The interfaces labelled Bx represent
+ interfaces to functionality in the IT Environment. These
+ interfaces are not TSFI and need only be discussed and
+ analysed when the TOE is being used in a composite
+ evaluation as part of the activities associated with the
+ class.
+
+
+
+ The Example firewall is used between an internal network and
+ an external network. It verifies the source address of data
+ received (to ensure that external data is not attempting to
+ masquerade as originating from the internal data); if it
+ detects any such attempts, it saves the offending attempt to
+ the audit log. The administrator connects to the firewall by
+ establishing a telnet connection to the firewall from the
+ internal network. Administrator actions consist of
+ authenticating, changing passwords, reviewing the audit log,
+ and setting or changing the addresses of the internal and
+ external networks.
+
+ The Example firewall presents the following interfaces to
+ the internal network:
+
+ IP datagrams
+ Administrator Commands and the
+ following interfaces to the external network:
+
+ IP datagrams
+ Interfaces Descriptions: IP
+ Datagrams
+ The datagrams are in the format specified by RFC 791.
+
+ Purpose - to transmit blocks of data (``datagrams'')
+ from source hosts to destination hosts identified by
+ fixed length addresses; also provides for fragmentation
+ and reassembly of long datagrams, if necessary, for
+ transmission through small-packet networks.
+ Method of Use - they arrive from the lower-level
+ (e.g. data link) protocol.
+ Parameters - the following fields of the IP datagram
+ header: source address, destination address,
+ don't-fragment flag.
+ Parameter description - [As defined by RFC 791,
+ subclause 3.1 (``Internet Header Format'')]
+ Actions - Transmits datagrams that are not
+ masquerading; fragments large datagrams if necessary;
+ reassembles fragments into datagrams.
+ Error messages - (none). No reliability guaranteed
+ (reliability to be provided by upper-level protocols)
+ Undeliverable datagrams (e.g. must be fragmented for
+ transmission, but don't-fragment flag is set)
+ dropped.
+ Interfaces Descriptions: Administrator
+ Commands
+ The administrator commands provide a means for the
+ administrator to interact with the firewall. These commands
+ and responses ride atop a telnet (RFC 854) connection
+ established from any host on the internal network. Available
+ commands are:
+
+ Passwd
+
+ Purpose - sets administrator password
+ Method of Use - Passwd
+ <password>
+ Parameters - password
+ Parameter description - value of new
+ password
+ Actions - changes password to new value
+ supplied. There are no restrictions.
+ Error messages - none.
+
+ Readaudit
+
+ Purpose - presents the audit log to the
+ administrator
+ Method of Use - Readaudit
+ Parameters - none
+ Parameter description - none
+ Actions - provides the text of the audit
+ log
+ Error messages - none.
+
+ Setintaddr
+
+ Purpose - sets the address of the internal
+ address.
+ Method of Use - Setintaddr
+ <address>
+ Parameters - address
+ Parameter description - first three fields of an
+ IP address (as defined in RFC 791). For example:
+ 123.123.123.
+ Actions - changes the internal value of the
+ variable defining the internal network, the value of
+ which is used to judge attempted masquerades.
+ Error messages - ``address in use'': indicates
+ the identified internal network is the same as the
+ external network.
+
+ Setextaddr
+
+ Purpose - sets the address of the external address
+ Method of Use - Setextaddr
+ <address>
+ Parameters - address
+ Parameter description - first three fields of an
+ IP address (as defined in RFC 791). For example:
+ 123.123.123.
+ Actions - changes the internal value of the
+ variable defining the external network.
+ Error messages - ``address in use'': indicates
+ the identified external network is the same as the
+ internal network.
+
+
+
+
+
+
+ The wide variety of TOEs makes it impossible to codify
+ anything more specific than ``well-structured'' or ``minimum
+ complexity''. Judgements on structure and complexity are
+ expected to be derived from the specific technologies used in
+ the TOE. For example, software is likely to be considered
+ well-structured if it exhibits the characteristics cited in
+ the software engineering disciplines.
+
+ This annex provides supplementary material on assessing the
+ structure and complexity of procedure-based software portions
+ of the TSF. This material is based on information readily
+ available in software engineering literature. For other kinds
+ of internals (e.g. hardware, non-procedural software such as
+ object-oriented code, etc.), corresponding literature on good
+ practises should be consulted.
+
+
+ The structure of procedural software is traditionally
+ assessed according to its
+ modularity. Software written with a modular
+ design aids in achieving understandability by clarifying
+ what dependencies a module has on other modules
+ (coupling) and by including in a module
+ only tasks that are strongly related to each other
+ (cohesion). The use of modular design
+ reduces the interdependence between elements of the TSF and
+ thus reduces the risk that a change or error in one module
+ will have effects throughout the TOE. Its use enhances
+ clarity of design and provides for increased assurance that
+ unexpected effects do not occur. Additional desirable
+ properties of modular decomposition are a reduction in the
+ amount of redundant or unneeded code.
+
+ Minimising the amount of functionality in the TSF allows the
+ evaluator as well as the developer to focus only on that
+ functionality which is necessary for SFR enforcement,
+ contributing further to understandability and further
+ lowering the likelihood of design or implementation
+ errors.
+
+ The incorporation of modular decomposition, layering and
+ minimisation into the design and implementation process must
+ be accompanied by sound software engineering
+ considerations. A practical, useful software system will
+ usually entail some undesirable coupling among modules, some
+ modules that include loosely-related functions, and some
+ subtlety or complexity in a module's design. These
+ deviations from the ideals of modular decomposition are
+ often deemed necessary to achieve some goal or constraint,
+ be it related to performance, compatibility, future planned
+ functionality, or some other factors, and may be acceptable,
+ based on the developer's justification for them. In applying
+ the requirements of this class, due consideration must be
+ given to sound software engineering principles; however, the
+ overall objective of achieving understandability must be
+ achieved.
+
+
+ Cohesion is the manner and degree to which the tasks
+ performed by a single software module are related to one
+ another; types of cohesion include coincidental,
+ communicational, functional, logical, sequential, and
+ temporal. These types of cohesion are characterised below,
+ listed in the order of decreasing desirability.
+
+ functional cohesion - a module
+ with functional cohesion performs activities related
+ to a single purpose. A functionally cohesive module
+ transforms a single type of input into a single type
+ of output, such as a stack manager or a queue
+ manager.
+ sequential cohesion - a module
+ with sequential cohesion contains functions each of
+ whose output is input for the following function in
+ the module. An example of a sequentially cohesive
+ module is one that contains the functions to write
+ audit records and to maintain a running count of the
+ accumulated number of audit violations of a specified
+ type.
+ communicational cohesion - a
+ module with communicational cohesion contains
+ functions that produce output for, or use output from,
+ other functions within the module. An example of a
+ communicationally cohesive module is an access check
+ module that includes mandatory, discretionary, and
+ capability checks.
+ temporal cohesion - a module
+ with temporal cohesion contains functions that need to
+ be executed at about the same time. Examples of
+ temporally cohesive modules include initialisation,
+ recovery, and shutdown modules.
+ logical (or
+ procedural) cohesion - a module with
+ logical cohesion performs similar activities on
+ different data structures. A module exhibits logical
+ cohesion if its functions perform related, but
+ different, operations on different inputs.
+ coincidental cohesion - a
+ module with coincidental cohesion performs unrelated,
+ or loosely related, activities.
+
+
+
+ Coupling is the manner and degree of interdependence
+ between software modules; types of coupling include call,
+ common and content coupling. These types of coupling are
+ characterised below, listed in the order of decreasing
+ desirability:
+
+ call: two modules are call coupled if they
+ communicate strictly through the use of their
+ documented function calls; examples of call coupling
+ are data, stamp, and control, which are defined below.
+
+ data: two modules are data
+ coupled if they communicate strictly through the
+ use of call parameters that represent single data
+ items.
+ stamp: two modules are stamp
+ coupled if they communicate through the use of
+ call parameters that comprise multiple fields or
+ that have meaningful internal structures.
+ control: two modules are
+ control coupled if one passes information that is
+ intended to influence the internal logic of the
+ other.
+
+ common: two modules are common
+ coupled if they share a common data area or a common
+ system resource. Global variables indicate that
+ modules using those global variables are common
+ coupled. Common coupling through global variables is
+ generally allowed, but only to a limited degree. For
+ example, variables that are placed into a global area,
+ but are used by only a single module, are
+ inappropriately placed, and should be removed. Other
+ factors that need to be considered in assessing the
+ suitability of global variables are:
+
+ The number of modules that modify a global
+ variable: In general, only a single module should
+ be allocated the responsibility for controlling
+ the contents of a global variable, but there may
+ be situations in which a second module may share
+ that responsibility; in such a case, sufficient
+ justification must be provided. It is unacceptable
+ for this responsibility to be shared by more than
+ two modules. (In making this assessment, care
+ should be given to determining the module actually
+ responsible for the contents of the variable; for
+ example, if a single routine is used to modify the
+ variable, but that routine simply performs the
+ modification requested by its caller, it is the
+ calling module that is responsible, and there may
+ be more than one such module). Further, as part
+ of the complexity determination, if two modules
+ are responsible for the contents of a global
+ variable, there should be clear indications of how
+ the modifications are coordinated between
+ them.
+ The number of modules that reference a global
+ variable: Although there is generally no limit on
+ the number of modules that reference a global
+ variable, cases in which many modules make such a
+ reference should be examined for validity and
+ necessity.
+
+ content: two modules are content
+ coupled if one can make direct reference to the
+ internals of the other (e.g. modifying code of, or
+ referencing labels internal to, the other module).
+ The result is that some or all of the content of one
+ module are effectively included in the other. Content
+ coupling can be thought of as using unadvertised
+ module interfaces; this is in contrast to call
+ coupling, which uses only advertised module
+ interfaces.
+
+
+
+
+ Complexity is the measure of the decision points and logical
+ paths of execution that code takes. Software engineering
+ literature cites complexity as a negative characteristic of
+ software because it impedes understanding of the logic and
+ flow of the code. Another impediment to the understanding of
+ code is the presence of code that is unnecessary, in that it
+ is unused or redundant.
+
+ The use of layering to separate levels of abstraction and
+ minimise circular dependencies further enables a better
+ understanding of the TSF, providing more assurance that the
+ TOE security functional requirements are accurately and
+ completely instantiated in the implementation.
+
+ Reducing complexity also includes reducing or eliminating
+ mutual dependencies, which pertains both to modules in a
+ single layer and to those in separate layers. Modules that
+ are mutually dependent may rely on one another to formulate
+ a single result, which could result in a deadlock condition,
+ or worse yet, a race condition (e.g., time of check vs. time
+ of use concern), where the ultimate conclusion could be
+ indeterminate and subject to the computing environment at
+ the given instant in time.
+
+ Design complexity minimisation is a key characteristic of a
+ reference validation mechanism, the purpose of which is to
+ arrive at a TSF that is easily understood so that it can be
+ completely analysed. (There are other important
+ characteristics of a reference validation mechanism, such as
+ TSF self-protection and non-bypassability; these other
+ characteristics are covered by requirements in the family.)
+
+
+
+
+ This Subclause provides additional guidance on the TDS family,
+ and its use of the terms ``subsystem'' and ``module''. This is
+ followed by a discussion of how, as more-detailed becomes
+ available, the requirement for the less-detailed is
+ reduced.
+
+ Figure
+ shows that, depending on the complexity of the TSF, the
+ design may be described in terms of subsystems
+ and modules (where subsystems are at a
+ higher level of abstraction than modules); or it may just be
+ described in terms of one level of abstraction (e.g.,
+ subsystems at lower assurance levels,
+ modules at higher levels). In cases where a
+ lower level of abstraction (modules) is presented,
+ requirements levied on higher-level abstractions
+ (subsystems) are essentially met by default. This concept is
+ further elaborated in the discussion on subsystems and
+ modules below.
+
+
+ The developer is expected to describe the design of the TOE
+ in terms of subsystems. The term
+ ``subsystem'' was chosen to be specifically vague so that it
+ could refer to units appropriate to the TOE (e.g.,
+ subsystems, modules). subsystems can even be uneven in
+ scope, as long as the requirements for description of
+ subsystems are met.
+
+ The first use of subsystems is to distinguish the TSF boundary;
+ that is, the portions of the TOE that comprise the TSF. In
+ general, a subsystem is part of the TSF if it has the capability
+ (whether by design or implementation) to affect the correct
+ operation of any of the SFRs. For example, for software that
+ depends on different hardware execution modes to provide domain
+ separation (see ) where
+ SFR-enforcing code is executed in one domain, then all
+ subsystems that execute in that domain would be considered part
+ of the TSF. Likewise, if a server outside that domain
+ implemented an SFR (e.g. enforced an access control policy over
+ objects it managed), then it too would be considered part of the
+ TSF.
+
+ The second use of subsystems is to provide a structure for
+ describing the TSF at a level of description that, while
+ describing how the TSF works, does not necessarily contain
+ low-level implementation detail found in module descriptions
+ (discussed later). subsystems are described at either a high
+ level (lacking an abundance of implementation detail) or a
+ detailed level (providing more insight into the
+ implementation). The level of description provided for a
+ subsystem is determined by the degree to which that
+ subsystem is responsible for implementing an SFR.
+
+ An SFR-enforcing subsystem is a subsystem
+ that provides mechanisms for enforcing an element of any SFR,
+ or directly supports a subsystem that is responsible
+ for enforcing an SFR. If a subsystem provides (implements)
+ an SFR-enforcing TSFI, then the subsystem is
+ SFR-enforcing.
+
+ Subsystems can also be identified as
+ SFR-supporting and
+ SFR-non-interfering. An SFR-supporting
+ subsystem is one that is depended on by an SFR-enforcing
+ subsystem in order to implement an SFR, but does not play as
+ direct a role as an SFR-enforcing subsystem. An
+ SFR-non-interfering subsystem is one that is not depended
+ upon, in either a supporting or enforcing role, to implement
+ an SFR.
+
+
+
+ A module is generally a relatively small architectural unit
+ that can be characterised in terms of the properties
+ discussed in . When both
+ (or above) requirements
+ and requirements are
+ present in a PP or ST, a ``module'' in terms of the requirements refers to the same
+ entity as a ``module'' for the requirements. Unlike subsystems, modules
+ describe the implementation in a level of detail that can
+ serve as a guide to reviewing the implementation
+ representation.
+
+ It is important to note that, depending on the TOE, modules
+ and subsystems may refer to the same abstraction. For and (which do not require description at the
+ module level) the subsystem description provides the lowest
+ level detail available about the TSF. For (which require module
+ descriptions) these descriptions provide the lowest level of
+ detail, while the subsystem descriptions (if they exist as
+ separate entities) merely serve to put to the module
+ descriptions in context. That is, it is not necessary to
+ provide detailed subsystem descriptions if module
+ descriptions exist. In TOEs that are sufficiently simple, a
+ separate ``subsystem description'' is not necessary; the
+ requirements can be met through documentation provided by
+ modules. For complex TOEs, the purpose of the subsystem
+ description (with respect to the TSF) is to provide the
+ reader context so they can focus their analysis
+ appropriately. This difference is illustrated in Figure
+ .
+
+ An SFR-enforcing module is a module that completely or partially implements
+ a security functional requirement (SFR) in the ST. Such modules may
+ implement an SFR-enforcing TSFI, but some functionality expressed in an SFR (for example,
+ audit and object re-use functionality) may not be directly tied to a single TSFI. As was
+ the case with subsystems, SFR-supporting modules are those modules that are depended upon by
+ an SFR-enforcing module, but are not responsible for directly implementing an SFR.
+ SFR-non-interfering modules are those modules that do not deal, directly or indirectly,
+ with the enforcement of SFRs.
+
+ It is important to note that the determination of what
+ ``directly implements'' means is somewhat subjective. In the
+ narrowest sense of the term, it could be interpreted to mean
+ the one or two lines of code that actually perform a
+ comparison, zeroing operation, etc. that implements a
+ requirement. A broader interpretation might be that it
+ includes the module that is invoked in response to a
+ SFR-enforcing TSFI, and all modules that may be invoked in
+ turn by that module (and so on until the completion of the
+ call). Neither of these interpretations is particularly
+ satisfying, since the narrowness of the first interpretation
+ may lead to important modules being incorrectly categorised
+ as SFR supporting, while the second leads to modules that
+ are actually not SFR-enforcing being classified as
+ such.
+
+ A description of a module should be such that one could create an implementation of the
+ module from the description, and the resulting implementation would be 1) identical to
+ the actual TSF implementation in terms of the interfaces presented, 2) identical in the
+ use of interfaces that are mentioned in the design, and 3) functionally equivalent to the
+ description of the purpose of the TSF module. For instance, RFC 793
+ provides a high-level description of the TCP protocol. It is necessarily implementation
+ independent. While it provides a wealth of detail, it is
+ not
+ a suitable design description because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC, and implementation choices
+ (for example, the use of global data vs. local data in various parts of the implementation)
+ may have an impact on the analysis that is performed. The design description of the TCP
+ module would list the interfaces presented by the implementation (rather than just those
+ defined in RFC 793), as well as an algorithm description of the processing associated with
+ the modules implementing TCP (assuming they were part of the TSF).
+
+ In the design, modules are described in detail in terms
+ of the function they provide (the purpose); the interfaces
+ they present (when required by the criteria); the return
+ values from such interfaces; the interfaces (presented by other modules)
+ they use (provided those interfaces are required to be also described);
+ and a description of how they provide their functionality using a
+ technique appropriate to the method used to implement the module.
+
+ The purpose of a module should be described indicating what
+ function the module is providing. It should be sufficient so
+ that the reader could get a general idea of what the
+ module's function is in the architecture.
+
+ The interfaces presented by a module are those interfaces used by
+ other modules to invoke the functionality provided. Interfaces include both
+ explicit interfaces (e.g., a calling sequence invoked by
+ other modules) as well as implicit interfaces (e.g., global
+ data manipulated by the module). Interfaces are described in terms of how
+ they are invoked, and any values that are returned. This description would
+ include a list of parameters, and descriptions of these parameters. If a parameter
+ were expected to take on a set of values (e.g., a ``flag'' parameter), the complete set
+ of values the parameter could take on that would have an effect on module processing
+ would be specified. Likewise, parameters representing data structures are described
+ such that each field of the data structure is identified and described.
+ Global data should be described to the extent required to understand their purpose.
+ The level of description required for a global data structure needs to be identical
+ to the one for module interfaces, where the input parameter and return values correspond
+ to the individual fields and their possible values in the data structure. Global data
+ structures may be described separate from the modules that manipulate or read them as
+ long as the design of the modules contain sufficient information about the global data
+ structures updated or the information extracted from global data structures.
+
+ Note that different programming languages may have
+ additional ``interfaces'' that would be non-obvious; an
+ example would be operator/function overloading in C++. This
+ ``implicit interface'' in the class description would also
+ be described as part of the module design. Note that
+ although a module could present only one interface, it is
+ more common that a module presents a small set of related
+ interfaces.
+
+ When it is required to describe the interfaces used by a module, it must be
+ clear from either the design description of the module or the purpose of the
+ module called, what service is expected from the module called. For example if
+ Module A is being described, and it uses Module B's bubble sort routine, the
+ description of the interaction between modules must allow to identify why
+ Module B's bubble sort routine is called and what this call contributes to the
+ implementation of the SFRs. The interface and purpose of Module B's bubble sort
+ routine must be described as part of the interfaces of Module B (provided the
+ level of ADV_TDS and the classification of Module B require a description its
+ interfaces) and so Module A just needs to identify what data it needs to have
+ sorted using this routine. An adequate description would be: "Module A invokes
+ Module B's interface double_bubble() to sort the usernames in
+ alphabetical order".
+ Note that if this sorting of the user names is not important for the enforcement of
+ any SFR (e. g. it is just done to speed up things and an algorithmically identical
+ implementation of Module A could also avoid to have the usernames sorted), the use of
+ Module B's bubble sort routine is not SFR-enforcing and it is suffcient to explain in
+ the description of Module A that the usernames are sorted in alphabetical order to
+ enhance performance. Module B may be classified as "SFR-supporting" only and the level
+ of ADV_TDS chosen indicates if the interfaces of SFR-supporting modules need to be
+ described or if its is sufficient to just describe the purpose of Module B.
+
+ As discussed previously, the algorithmic description of the
+ module should describe in an algorithmic fashion the
+ implementation of the module. This can be done in
+ pseudo-code, through flow charts, or (at ) informal text. It discusses
+ how the module inputs and called functions are used to
+ accomplish the module's function. It notes changes to global
+ data, system state, and return values produced by the
+ module. It is at the level of detail that an implementation
+ could be derived that would be very similar to the actual
+ implementation of the TOE.
+
+ It should be noted that source code does not meet the module
+ documentation requirements. Although the module design
+ describes the implementation, it is not the
+ implementation. The comments surrounding the source code
+ might be sufficient documentation if they provide an
+ explanation of the intent of the source code. In-line
+ comments that merely state what each line of code is doing
+ are useless because they provide no explanation of what the
+ module is meant to accomplish.
+
+ In the elements below, the labels (SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering) discussed for
+ subsystems and modules are used to describe the amount and
+ type of information that needs to be made available by the
+ developer. The elements have been structured so that there
+ is no expectation that the developer provide
+ only the information specified. That is, if
+ the developer's documentation of the TSF provides the
+ information in the requirements below, there is no
+ expectation that the developer update their documentation
+ and label subsystems and modules as SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering. The primary purpose
+ of this labelling is to allow developers with less mature
+ development methodologies (and associated artifacts, such as
+ detailed interface and design documentation) to provide the
+ necessary evidence without undue cost.
+
+
+
+ Because there is subjectivity in determining what is
+ SFR-enforcing vs. SFR-supporting (and in some cases, even
+ determining what is SFR-non-interfering) the following
+ paradigm has been adopted in this family. In early
+ components of the family, the developer makes a
+ determination about the classification of the subsystems
+ into SFR-enforcing, etc., supplying the appropriate
+ information, and there is little additional evidence for the
+ evaluator to examine to support this claim. As the level of
+ desired assurance increases, while the developer still makes
+ a classification determination, the evaluator obtains more
+ and more evidence that is used to confirm the developer's
+ classification.
+
+ In order to focus the evaluator's analysis on the SFR-related
+ portions of the TOE, especially at lower levels of assurance,
+ the components of the family are levelled such that initially
+ detailed information is required only for SFR-enforcing
+ architectural entities. As the level of assurance increases,
+ more information is required for SFR-supporting and (eventually)
+ SFR-non-interfering entities. It should be noted that even when
+ complete information is required, it is not required that all of
+ this information be analysed in the same level of detail. The
+ focus should be in all cases on whether the
+ necessary information has been provided and
+ analysed.
+
+ Table summarises the
+ information required at each of the family components for the
+ architectural entities to be described.
+
+
+
+
+
+ TSF subsystem
+ TSF Module
+
+
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+ SFR
+ Enforce
+ SFR
+ Support
+ SFR
+ NI
+
+
+
+
+
+ (informal
+ presentation)
+
+ structure, summary of SFR-Enf. behaviour, interactions
+
+ designation support
+ designation support means that
+ only documentation sufficient to support the
+ classification of the subsystem / module is
+ needed.
+
+ designation support
+
+
+
+
+
+
+ (informal
+ presentation)
+
+ structure, detailed description of SFR-Enf. behaviour,
+ summary of other behaviour, interactions
+
+
+ structure, summary of other behaviour, interactions
+
+ designation support, interactions
+
+
+
+
+
+
+
+ (informal
+ presentation)description,
+ interactionsdescription, interactions
+ description, interactions
+
+ purpose, SFR interfacesSFR interfaces means that the module description contains,
+ for each SFR-related interface, the returned values and the called interfaces
+ to other modules.
+ interaction, purpose
+ interaction, purpose
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, SFR interfaces
+
+
+ purpose, SFR interfaces
+
+ interaction, purpose
+
+
+
+
+ (semiformal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, all interfacesAll interfaces means that the module description contains,
+ for each interface, the returned values and the called interfaces to other
+ modules.
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+
+
+ (semiformal
+ presentation; additional formal
+ presentation)
+ description, interactions
+ description, interactions
+ description, interactions
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+ purpose, all interfaces
+
+
+
+
+ Description Detail Levelling
+
+
+
+
+
+ Formal methods provide a mathematical representation of the
+ TSF and its behaviour and are required by the , , and
+ components. There are two aspects of formal methods: the
+ specification language that is used for
+ formal expression, and the theorem prover
+ that mathematically proves the completeness and correctness of
+ the formal specification.
+
+ A formal specification is expressed within a formal system
+ based upon well-established mathematical concepts. These
+ mathematical concepts are used to define well-defined
+ semantics, syntax and rules of inference. A formal system is
+ an abstract system of identities and relations that can be
+ described by specifying a formal alphabet, a formal language
+ over that alphabet which is based on a formal syntax, and a
+ set of formal rules of inference for constructing derivations
+ of sentences in the formal language.
+
+ The evaluator should examine the identified formal systems to
+ make sure that:
+
+ The semantics, syntax and inference rules of the
+ formal system are defined or a definition is
+ referenced.
+ Each formal system is accompanied by explanatory text
+ that provides defined semantics so that:
+
+ the explanatory text provides defined meanings of
+ terms, abbreviations and acronyms that are used in a
+ context other than that accepted by normal
+ usage,
+ the use of a formal system and semiformal notation
+ use is accompanied by supporting explanatory text in
+ informal style appropriate for unambiguous
+ meaning,
+ the formal system is able to express rules and
+ characteristics of applicable SFPs,
+ security functionality and interfaces (providing
+ details of effects, exceptions and error messages) of
+ TSF, their subsystems or modules to be specified for
+ the assurance family for which the notations are
+ used.
+ the notation provides rules to determine the
+ meaning of syntactical valid constructs.
+
+ Each formal system uses a formal syntax that provides
+ rules to unambiguously recognise constructs.
+ Each formal system provides proof rules which
+
+ support logical reasoning of well-established
+ mathematical concepts,
+ help to prevent derivation of
+ contradictions
+
+ If the developer uses a formal system which is already accepted
+ by the evaluation authority the evaluator can rely on the level
+ of formality and strength of the system and focus on the
+ instantiation of the formal system to the TOE specifications and
+ correspondence proofs.
+
+ The formal style supports mathematical proofs of the security
+ properties based on the security features, the consistency of
+ refinements and the correspondence of the representations.
+ Formal tool support seems adequate whenever manual derivations
+ would otherwise become long winded and
+ incomprehensible. Formal tools are also apt to reduce the
+ error probability inherent in manual derivations.
+
+ Examples of formal systems:
+
+ The Z specification language is highly
+ expressive, and supports many different methods or styles
+ of formal specification. The use of Z has been
+ predominantly for model-oriented specification, using
+ schemas to formally specify
+ operations. See for more
+ information.
+ ACL2 is an open-source formal system
+ comprising a LISP-based specification language and a
+ theorem prover. See for
+ further information.
+ Isabelle is a popular generic theorem
+ proving environment that allows mathematical formulae to
+ be expressed in a formal language and provides tools for
+ proving those formulae within a logical calculus (see
+ e.g. for
+ additional information)
+ The B method is a formal system based
+ on the propositional calculus, the first order predicate
+ calculus with inference rules and set theory (see
+ e.g. for further
+ information).
+
+
+
+
+ The dependencies documented in the components of Clauses and - are the direct dependencies between the
+ assurance components.
+
+ The following dependency tables for assurance components show
+ their direct, indirect and optional dependencies. Each of the
+ components that is a dependency of some assurance component is
+ allocated a column. Each assurance component is allocated a
+ row. The value in the table cell indicate whether the column
+ label component is directly required (indicated by a cross
+ ``X'') or indirectly required (indicated by a dash ``-''), by
+ the row label component. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+ The purpose of this Clause is to document the philosophy that
+ underpins the CC approach to assurance. An understanding of this
+ Clause will permit the reader to understand the rationale behind
+ the CC Part 3 assurance requirements.
+
+
+ The CC philosophy is that the threats to security and
+ organisational security policy commitments should be clearly
+ articulated and the proposed security measures be demonstrably
+ sufficient for their intended purpose.
+
+ Furthermore, measures should be adopted that reduce the
+ likelihood of vulnerabilities, the ability to exercise
+ (i.e. intentionally exploit or unintentionally trigger) a
+ vulnerability, and the extent of the damage that could occur
+ from a vulnerability being exercised. Additionally, measures
+ should be adopted that facilitate the subsequent
+ identification of vulnerabilities and the elimination,
+ mitigation, and/or notification that a vulnerability has been
+ exploited or triggered.
+
+
+
+ The CC philosophy is to provide assurance based upon an
+ evaluation (active investigation) of the IT product that is to
+ be trusted. Evaluation has been the traditional means of
+ providing assurance and is the basis for prior evaluation
+ criteria documents. In aligning the existing approaches, the
+ CC adopts the same philosophy. The CC proposes measuring the
+ validity of the documentation and of the resulting IT product
+ by expert evaluators with increasing emphasis on scope, depth,
+ and rigour.
+
+ The CC does not exclude, nor does it comment upon, the
+ relative merits of other means of gaining assurance. Research
+ continues with respect to alternative ways of gaining
+ assurance. As mature alternative approaches emerge from these
+ research activities, they will be considered for inclusion in
+ the CC, which is so structured as to allow their future
+ introduction.
+
+
+ It is assumed that there are threat agents that will
+ actively seek to exploit opportunities to violate security
+ policies both for illicit gains and for well-intentioned,
+ but nonetheless insecure actions. Threat agents may also
+ accidentally trigger security vulnerabilities, causing harm
+ to the organisation. Due to the need to process sensitive
+ information and the lack of availability of sufficiently
+ trusted products, there is significant risk due to failures
+ of IT. It is, therefore, likely that IT security breaches
+ could lead to significant loss.
+
+ IT security breaches arise through the intentional
+ exploitation or the unintentional triggering of
+ vulnerabilities in the application of IT within business
+ concerns.
+
+ Steps should be taken to prevent vulnerabilities arising in
+ IT products. To the extent feasible, vulnerabilities should
+ be:
+
+
+ eliminated -- that is, active steps should be taken to
+ expose, and remove or neutralise, all exercisable
+ vulnerabilities;
+
+
+ minimised -- that is, active steps should be taken to
+ reduce, to an acceptable residual level, the potential
+ impact of any exercise of a vulnerability;
+
+
+ monitored -- that is, active steps should be taken to
+ ensure that any attempt to exercise a residual
+ vulnerability will be detected so that steps can be
+ taken to limit the damage.
+
+
+
+
+
+ Vulnerabilities can arise through failures in:
+
+
+ requirements -- that is, an IT product may possess all
+ the functions and features required of it and still
+ contain vulnerabilities that render it unsuitable or
+ ineffective with respect to security;
+
+
+ development -- that is, an IT product does not meet its
+ specifications and/or vulnerabilities have been
+ introduced as a result of poor development standards or
+ incorrect design choices;
+
+
+ operation -- that is, an IT product has been constructed
+ correctly to a correct specification but vulnerabilities
+ have been introduced as a result of inadequate controls
+ upon the operation.
+
+
+
+
+
+ Assurance is grounds for confidence that an IT product meets
+ its security objectives. Assurance can be derived from
+ reference to sources such as unsubstantiated assertions,
+ prior relevant experience, or specific experience. However,
+ the CC provides assurance through active
+ investigation. Active investigation is an evaluation of the
+ IT product in order to determine its security
+ properties.
+
+
+
+ Evaluation has been the traditional means of gaining
+ assurance, and is the basis of the CC approach. Evaluation
+ techniques can include, but are not limited to:
+
+
+ analysis and checking of process(es) and procedure(s);
+
+
+ checking that process(es) and procedure(s) are being
+ applied;
+
+
+ analysis of the correspondence between TOE design
+ representations;
+
+
+ analysis of the TOE design representation against the
+ requirements;
+
+
+ verification of proofs;
+
+
+ analysis of guidance documents;
+
+
+ analysis of functional tests developed and the results
+ provided;
+
+
+ independent functional testing;
+
+
+ analysis for vulnerabilities (including flaw
+ hypothesis);
+
+
+ penetration testing.
+
+
+
+
+
+
+ The CC philosophy asserts that greater assurance results from
+ the application of greater evaluation effort, and that the
+ goal is to apply the minimum effort required to provide the
+ necessary level of assurance. The increasing level of effort
+ is based upon:
+
+
+ scope -- that is, the effort is greater because a larger
+ portion of the IT product is included;
+
+
+ depth -- that is, the effort is greater because it is
+ deployed to a finer level of design and implementation
+ detail;
+
+
+ rigour -- that is, the effort is greater because it is
+ applied in a more structured, formal manner.
+
+
+
+
+
+
+ This annex provides an explanation of the criteria and examples of their application. This
+ annex does not define the criteria;
+ this definition can be found in CC Part 3 Section .
+
+ This annex consists of 2 major parts:
+
+
+ Guidance for completing an independent vulnerability
+ analysis. This is summarised in section , and described in more
+ detail in section
+ . These sections describe how an evaluator should approach
+ the construction of an independent Vulnerability Analysis.
+
+
+ How to characterise and use assumed Attack Potential of an
+ attacker. This is described in sections to . These sections provide an example of describe
+ how an attack potential can be characterised and should be
+ used, and provide examples.
+
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the existence and exploitability of flaws or
+ weaknesses in the TOE in the operational environment. This
+ determination is based upon analysis performed by the
+ evaluator, and is supported by evaluator testing.
+
+ At the lowest levels of the
+ evaluator simply performs a search of publicly available
+ information to identify any known weaknesses in the TOE, while
+ at the higher levels the evaluator performs a structured
+ analysis of the TOE evaluation evidence.
+
+ There are three main factors in performing a vulnerability
+ analysis, namely:
+
+ the identification of potential vulnerabilities;
+
+ assessment to determine whether the identified potential
+ vulnerabilities could allow an attacker with the relevant
+ attack potential to violate the SFRs.
+
+ penetration testing to determine whether the identified
+ potential vulnerabilities are exploitable in the operational
+ environment of the TOE.
+
+
+ The identification of vulnerabilities can be further
+ decomposed into the evidence to be searched and how hard to
+ search that evidence to identify potential vulnerabilities. In
+ a similar manner, the penetration testing can be further
+ decomposed into analysis of the potential vulnerability to
+ identify attack methods and the demonstration of the attack
+ methods.
+
+ These main factors are iterative in nature, i.e. penetration
+ testing of potential vulnerabilities may lead to the
+ identification of further potential vulnerabilities. Hence,
+ these are performed as a single vulnerability analysis
+ activity.
+
+
+
+ The evaluator vulnerability analysis is to determine that the
+ TOE is resistant to penetration attacks performed by an
+ attacker possessing a Basic (for and ),
+ Enhanced-Basic (for ),
+ Moderate (for ) or High (for
+ ) attack potential. The
+ evaluator first assesses the exploitability of all identified
+ potential vulnerabilities. This is accomplished by conducting
+ penetration testing. The evaluator should assume the role of
+ an attacker with a Basic (for
+ and ), Enhanced-Basic (for
+ ), Moderate (for ) or High (for ) attack potential when attempting to penetrate the
+ TOE.
+
+ The evaluator considers potential vulnerabilities encountered
+ by the evaluator during the conduct of other evaluation
+ activities. The evaluator penetration testing determining TOE
+ resistance to these potential vulnerabilities should be
+ performed assuming the role of an attacker with a Basic (for
+ and ), Enhanced-Basic (for ), Moderate (for )
+ or High (for ) attack
+ potential.
+
+ However, vulnerability analysis should not be performed as an
+ isolated activity. It is closely linked with and . The evaluator
+ performs these other evaluation activities with a focus on
+ identifying potential vulnerabilities or ``areas of
+ concern''. Therefore, evaluator familiarity with the generic
+ vulnerability guidance (provided in Section ) is required.
+
+
+ The following five categories provide discussion of generic
+ vulnerabilities.
+
+
+ Bypassing includes any means by which an attacker could
+ avoid security enforcement, by:
+
+
+ exploiting the capabilities of interfaces to the TOE,
+ or of utilities which can interact with the TOE;
+
+
+ inheriting privileges or other capabilities that
+ should otherwise be denied;
+
+
+ (where confidentiality is a concern) reading sensitive
+ data stored or copied to inadequately protected areas.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on exploiting the capabilities of
+ interfaces or utilities generally take advantage of
+ the absence of the required security enforcement on
+ those interfaces. For example, gaining access to
+ functionality that is implemented at a lower level
+ than that at which access control is
+ enforced. Relevant items include:
+
+
+ changing the predefined sequence of invocation of
+ TSFI;
+
+
+ invoking an additional TSFI;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using implementation detail introduced in less
+ abstract representations;
+
+
+ using the delay between time of access check and
+ time of use.
+
+
+
+
+ Changing the predefined sequence of invocation of
+ components should be considered where there is an
+ expected order in which interfaces to the TOE
+ (e.g. user commands) are called to invoke a TSFI
+ (e.g. opening a file for access and then reading data
+ from it). If a TSFI is invoked through one of the TOE
+ interfaces (e.g. an access control check), the
+ evaluator should consider whether it is possible to
+ bypass the control by performing the call at a later
+ point in the sequence or by missing it out altogether.
+
+
+ Executing an additional component (in the predefined
+ sequence) is a similar form of attack to the one
+ described above, but involves the calling of some
+ other TOE interface at some point in the sequence. It
+ can also involve attacks based on interception of
+ sensitive data passed over a network by use of network
+ traffic analysers (the additional component here being
+ the network traffic analyser).
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes using an unrelated TOE
+ interface to bypass the TSF by using it to achieve a
+ purpose that it was not designed or intended to
+ achieve. Covert channels are an example of this type
+ of attack (see for further discussion of covert
+ channels). The use of undocumented interfaces, which
+ may be insecure, also falls into this category. Such
+ interfaces may include undocumented support and help
+ facilities.
+
+
+ Using implementation detail introduced in lower
+ representations may allow an attacker to take
+ advantage of additional functions, resources or
+ attributes that are introduced to the TOE as a
+ consequence of the refinement process. Additional
+ functionality may include test harness code contained
+ in software modules and back-doors introduced during
+ the implementation process.
+
+
+ Using the delay between time of check and time of use
+ includes scenarios where an access control check is
+ made and access granted, and an attacker is
+ subsequently able to create conditions in which, had
+ they applied at the time the access check was made,
+ would have caused the check to fail. An example would
+ be a user creating a background process to read and
+ send highly sensitive data to the user's terminal, and
+ then logging out and logging back in again at a lower
+ sensitivity level. If the background process is not
+ terminated when the user logs off, the MAC checks
+ would have been effectively bypassed.
+
+
+ Attacks based on inheriting privileges are generally
+ based on illicitly acquiring the privileges or
+ capabilities of some privileged component, usually by
+ exiting from it in an uncontrolled or unexpected
+ manner. Relevant items include:
+
+
+ executing data not intended to be executable, or
+ making it executable;
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Executing data not intended to be executable, or
+ making it executable includes attacks involving
+ viruses (e.g. putting executable code or commands in a
+ file which are automatically executed when the file is
+ edited or accessed, thus inheriting any privileges the
+ owner of the file has).
+
+
+ Generating unexpected input for a component can have
+ unexpected effects which an attacker could take
+ advantage of. For example, if the TSF could be
+ bypassed if a user gains access to the underlying
+ operating system, it may be possible to gain such
+ access following the login sequence by exploring the
+ effect of hitting various control or escape sequences
+ whilst a password is being authenticated.
+
+
+ Invalidating assumptions and properties on which lower
+ level components rely includes attacks based on
+ breaking out of the constraints of an application to
+ gain access to an underlying operating system in order
+ to bypass the TSF of an application. In this case the
+ assumption being invalidated is that it is not
+ possible for a user of the application to gain such
+ access. A similar attack can be envisaged against an
+ application on an underlying database management
+ system: again the TSF could be bypassed if an attacker
+ can break out of the constraints of the application.
+
+
+ Attacks based on reading sensitive data stored in
+ inadequately protected areas (applicable where
+ confidentiality is a concern) include the following
+ issues which should be considered as possible means of
+ gaining access to sensitive data:
+
+
+ disk scavenging;
+
+
+ access to unprotected memory;
+
+
+ exploiting access to shared writable files or
+ other shared resources (e.g. swap files);
+
+
+ Activating error recovery to determine what access
+ users can obtain. For example, after a crash an
+ automatic file recovery system may employ a lost
+ and found directory for headerless files, which
+ are on disk without labels. If the TOE implements
+ mandatory access controls, it is important to
+ investigate at what security level this directory
+ is kept (e.g. at system high), and who has access
+ to this directory.
+
+
+
+
+
+ There are a number of different methods through which an
+ evaluator may identify a back-door, including two main
+ techniques. Firstly, by the evaluator inadvertently
+ identifying during testing an interface that can be
+ misused. Secondly, through testing each external
+ interface of the TSF in a debugging mode to identify any
+ modules that are not called as a part of testing the
+ documented interfaces and then inspecting the code that is
+ not called to consider whether it is a back-door.
+
+ For a software TOE where and or
+ higher components are included in the assurance package,
+ the evaluator may consider during their analysis of the
+ tools the libraries and packages that are linked by the
+ compiler at compilation stage to determine that back-doors
+ are not introduced at this stage.
+
+
+
+ Tampering includes any attack based on an attacker
+ attempting to influence the behaviour of the TSF
+ (i.e. corruption or de-activation), for example by:
+
+
+ accessing data on whose confidentiality or integrity
+ the TSF relies;
+
+
+ forcing the TOE to cope with unusual or unexpected
+ circumstances;
+
+
+ disabling or delaying security enforcement;
+
+
+ physical modification the TOE.
+
+
+
+ Each of the following should be considered (where
+ relevant) in the evaluator's independent vulnerability
+ analysis.
+
+
+ Attacks based on accessing data, whose confidentiality
+ or integrity are protected, include:
+
+
+ reading, writing or modifying internal data
+ directly or indirectly;
+
+
+ using a component in an unexpected context or for
+ an unexpected purpose;
+
+
+ using interfaces between components that are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Reading, writing or modifying internal data directly
+ or indirectly includes the following types of attack
+ which should be considered:
+
+
+ reading ``secrets'' stored internally, such as
+ user passwords;
+
+
+ spoofing internal data that security enforcing
+ mechanisms rely upon;
+
+
+ modifying environment variables (e.g. logical
+ names), or data in configuration files or
+ temporary files.
+
+
+
+ It may be possible to deceive a trusted process into
+ modifying a protected file that it wouldn't normally
+ access.
+
+
+ The evaluator should also consider the following
+ ``dangerous features'':
+
+
+ source code resident on the TOE along with a
+ compiler (for instance, it may be possible to
+ modify the login source code);
+
+
+ an interactive debugger and patch facility (for
+ instance, it may be possible to modify the
+ executable image);
+
+
+ the possibility of making changes at device
+ controller level, where file protection does not
+ exist;
+
+
+ diagnostic code which exists in the source code
+ and that may be optionally included;
+
+
+ developer's tools left in the TOE.
+
+
+
+
+ Using a component in an unexpected context or for an
+ unexpected purpose includes (for example), where the
+ TOE is an application built upon an operating system,
+ users exploiting knowledge of a word processor package
+ or other editor to modify their own command file
+ (e.g. to acquire greater privileges).
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction includes
+ attacks exploiting shared access to resources, where
+ modification of a resource by one component can
+ influence the behaviour of another (trusted)
+ component, e.g. at source code level, through the use
+ of global data or indirect mechanisms such as shared
+ memory or semaphores.
+
+
+ Attacks based on forcing the TOE to cope with unusual
+ or unexpected circumstances should always be
+ considered. Relevant items include:
+
+
+ generating unexpected input for a component;
+
+
+ invalidating assumptions and properties on which
+ lower-level components rely.
+
+
+
+
+ Generating unexpected input for a component includes
+ investigating the behaviour of the TOE when:
+
+
+ command input buffers overflow (possibly
+ ``crashing the stack'' or overwriting other
+ storage, which an attacker may be able to take
+ advantage of, or forcing a crash dump that may
+ contain sensitive information such as clear-text
+ passwords);
+
+
+ invalid commands or parameters are entered
+ (including supplying a read-only parameter to an
+ interface which expects to return data via that
+ parameter and supplying improperly formatted input
+ that should fail parsing such as SQL-injection,
+ format strings);
+
+
+ an end-of-file marker (e.g. CTRL-Z or CTRL-D) or
+ null character is inserted in an audit trail.
+
+
+
+
+ Invalidating assumptions and properties on which
+ lower-level components rely includes attacks taking
+ advantage of errors in the source code where the code
+ assumes (explicitly or implicitly) that security
+ relevant data is in a particular format or has a
+ particular range of values. In these cases the
+ evaluator should determine whether they can invalidate
+ such assumptions by causing the data to be in a
+ different format or to have different values, and if
+ so whether this could confer advantage to an attacker.
+
+
+ The correct behaviour of the TSF may be dependent on
+ assumptions that are invalidated under extreme
+ circumstances where resource limits are reached or
+ parameters reach their maximum value. The evaluator
+ should consider (where practical) the behaviour of the
+ TOE when these limits are reached, for example:
+
+
+ changing dates (e.g. examining how the TOE behaves
+ when a critical date threshold is passed);
+
+
+ filling disks;
+
+
+ exceeding the maximum number of users;
+
+
+ filling the audit log;
+
+
+ saturating security alarm queues at a console;
+
+
+ overloading various parts of a multi-user TOE
+ which relies heavily upon communications
+ components;
+
+
+ swamping a network, or individual hosts, with
+ traffic;
+
+
+ filling buffers or fields.
+
+
+
+
+ Attacks based on disabling or delaying security
+ enforcement include the following items:
+
+
+ using interrupts or scheduling functions to
+ disrupt sequencing;
+
+
+ disrupting concurrence;
+
+
+ using interfaces between components which are not
+ visible at a higher level of abstraction.
+
+
+
+
+ Using interrupts or scheduling functions to disrupt
+ sequencing includes investigating the behaviour of the
+ TOE when:
+
+
+ a command is interrupted (with CTRL-C, CTRL-Y,
+ etc.);
+
+
+ a second interrupt is issued before the first is
+ acknowledged.
+
+
+
+
+ The effects of terminating security critical processes
+ (e.g. an audit daemon) should be explored. Similarly,
+ it may be possible to delay the logging of audit
+ records or the issuing or receipt of alarms such that
+ it is of no use to an administrator (since the attack
+ may already have succeeded).
+
+
+ Disrupting concurrence includes investigating the
+ behaviour of the TOE when two or more subjects attempt
+ simultaneous access. It may be that the TOE can cope
+ with the interlocking required when two subjects
+ attempt simultaneous access, but that the behaviour
+ becomes less well defined in the presence of further
+ subjects. For example, a critical security process
+ could be put into a resource-wait state if two other
+ processes are accessing a resource which it requires.
+
+
+ Using interfaces between components which are not
+ visible at a higher level of abstraction may provide a
+ means of delaying a time-critical trusted process.
+
+
+ Physical attacks can be categorised into physical
+ probing, physical manipulation, physical modification,
+ and substitution.
+
+
+ Physical probing by penetrating the TOE targeting
+ internals of the TOE, e.g. reading at internal
+ communication interfaces, lines or memories.
+
+
+ Physical manipulation can be with the TOE
+ internals aiming at internal modifications of the
+ TOE (e.g. by using optical fault induction as an
+ interaction process), at the external interfaces
+ of the TOE (e.g. by power or clock glitches) and
+ at the TOE environment (e.g. by modifying
+ temperature).
+
+
+ Physical modification of TOE internal security
+ enforcing attributes to inherit privileges or
+ other capabilities that should be denied in
+ regular operation. Such modifications can be
+ caused, e.g., by optical fault induction. Attacks
+ based on physical modification may also yield a
+ modification of the TSF itself, e.g. by causing
+ faults at TOE internal program data transfers
+ before execution. Note, that such kind of
+ bypassing by modifying the TSF itself can
+ jeopardise every TSF unless there are other
+ measures (possibly environmental measures) that
+ prevent an attacker from gaining physical access
+ to the TOE.
+
+
+ Physical substitution to replace the TOE with
+ another IT entity, during delivery or operation of
+ the TOE. Substitution during delivery of the TOE
+ from the development environment to the user
+ should be prevented through application of secure
+ delivery procedures (such as those considered
+ under ). Substitution of the TOE during
+ operation may be considered through a combination
+ of user guidance and the operational environment,
+ such that the user is able to be confident that
+ they are interacting with the TOE.
+
+
+
+
+
+
+
+ Direct attack includes the identification of any
+ penetration tests necessary to test the strength of
+ permutational or probabilistic mechanism and other
+ mechanisms to ensure they withstand direct attack.
+
+ For example, it may be a flawed assumption that a
+ particular implementation of a pseudo-random number
+ generator will possess the required entropy necessary to
+ seed the security mechanism.
+
+ Where a probabilistic or permutational mechanism relies on
+ selection of security attribute value (e.g. selection of
+ password length) or entry of data by a human user
+ (e.g. choice of password), the assumptions made should
+ reflect the worst case.
+
+ Probabilistic or permutational mechanisms should be
+ identified during examination of evaluation evidence
+ required as input to this sub-activity (security target,
+ functional specification, TOE design and implementation
+ representation subset) and any other TOE (e.g. guidance)
+ documentation may identify additional probabilistic or
+ permutational mechanisms.
+
+ Where the design evidence or guidance includes assertions
+ or assumptions (e.g. about how many authentication
+ attempts are possible per minute), the evaluator should
+ independently confirm that these are correct. This may be
+ achieved through testing or through independent
+ analysis.
+
+ Direct attacks reliant upon a weakness in a cryptographic
+ algorithm should not be considered under , as this is outside the scope
+ of the CC. Correctness of the implementation of the
+ cryptographic algorithm is considered during the and
+ activities.
+
+
+
+ Information is an abstract view on relation between the
+ properties of entities, i.e. a signal contains information
+ for a system, if the TOE is able to react to this
+ signal. The TOE resources processes and stores information
+ represented by user data. Therefore:
+
+
+ information may flow with the user data between
+ subjects by internal TOE transfer or export from the TOE;
+
+
+ information may be generated and passed to other user
+ data;
+
+
+ information may be gained through monitoring the
+ operations on data representing the information.
+
+
+
+ The information represented by user data may be
+ characterised by security attributes like ``classification
+ level'' having values, for example unclassified,
+ confidential, secret, top secret, to control operations to
+ the data. This information and therefore the security
+ attributes may be changed by operations e.g. may describe decrease of the
+ level by ``sanitarisation'' or increase of level by
+ combination of data. This is one aspects of an information
+ flow analysis focused on controlled operations of
+ controlled subjects on controlled objects.
+
+ The other aspect is the analysis of illicit
+ information flow. This aspect is more
+ general than the direct access to objects containing user
+ data addressed by the
+ family. An unenforced
+ signalling channel carrying information under control of
+ the information flow control policy can also be caused by
+ monitoring of the processing of any object containing or
+ related to this information (e.g. side channels). An
+ enforced signalling channels
+ may be identified in terms of the subjects manipulating
+ resources and the subject or user that observe such
+ manipulation. Classically, covert channels have been
+ identified as timing or storage channels, according to the
+ resource being modified or modulated. As for other
+ monitoring attacks, the use of the TOE is in accordance
+ with the SFRs.
+
+ Covert channels are normally applicable in the case when
+ the TOE has unobservability AND multi-level separation
+ policy requirements. Covert channels may be routinely
+ spotted during vulnerability analysis and design
+ activities, and should therefore be tested. However,
+ generally such monitoring attacks are only identified
+ through specialised analysis techniques commonly referred
+ to as ``covert channel analysis''. These techniques have
+ been the subject of much research and there are many
+ papers published on this subject. Guidance for the
+ conduct of covert channel analysis should be sought from
+ the evaluation authority.
+
+ Unenforced information flow monitoring
+ attacks include passive analysis techniques aiming at
+ disclosure of sensitive internal data of the TOE by
+ operating the TOE in the way that corresponds to the
+ guidance documents.
+
+ Side Channel Analysis includes crypt analytical techniques
+ based on physical leakage of the TOE. Physical leakage can
+ occur by timing information, power consumption or power
+ emanation during computation of a TSF. Timing information
+ can be collected also by a remote-attacker (having network
+ access to the TOE), power based information channels
+ requires that the attacker is in the near-by environment
+ of the TOE.
+
+ Eavesdropping techniques include interception of all forms
+ of energy, e.g., electromagnetic or optical emanation of
+ computer displays, not necessarily in the near-field of
+ the TOE.
+
+ Monitoring also includes exploits of protocol flaws, e.g.,
+ an attack on SSL implementation.
+
+
+
+ Misuse may arise from:
+
+
+ incomplete guidance documentation;
+
+
+ unreasonable guidance;
+
+
+ unintended misconfiguration of the TOE;
+
+
+ forced exception behaviour of the TOE.
+
+
+
+ If the guidance documentation is incomplete the user may
+ not know how to operate the TOE in accordance with the
+ SFRs. The evaluator should apply familiarity with the TOE
+ gained from performing other evaluation activities to
+ determine that the guidance is complete. In particular,
+ the evaluator should consider the functional
+ specification. The TSF described in this document should
+ be described in the guidance as required to permit secure
+ administration and use through the TSFI available to human
+ users. In addition, the different modes of operation
+ should be considered to ensure that guidance is provided
+ for all modes of operation.
+
+ The evaluator may, as an aid, prepare an informal mapping
+ between the guidance and these documents. Any omissions in
+ this mapping may indicate incompleteness.
+
+ The guidance is considered to be unreasonable if it makes
+ demands on the TOE's usage or operational environment that
+ are inconsistent with the ST or unduly onerous to maintain
+ security.
+
+ A TOE may use a variety of ways to assist the consumer in
+ effectively using that TOE in accordance with the SFRs and
+ prevent unintentional misconfiguration. A TOE may employ
+ functionality (features) to alert the consumer when the
+ TOE is in a state that is inconsistent with the SFRs,
+ whilst other TOEs may be delivered with enhanced guidance
+ containing suggestions, hints, procedures, etc. on using
+ the existing security features most effectively; for
+ instance, guidance on using the audit feature as an aid
+ for detecting when the SFRs are being compromised; namely
+ insecure.
+
+ The evaluator considers the TOE's functionality, its
+ purpose and security objectives for the operational
+ environment to arrive at a conclusion of whether or not
+ there is reasonable expectation that use of the guidance
+ would permit transition into an insecure state to be
+ detected in a timely manner.
+
+ The potential for the TOE to enter into insecure states
+ may be determined using the evaluation deliverables, such
+ as the ST, the functional specification and any other
+ design representations provided as evidence for components
+ included in the assurance package for the TOE (e.g. the
+ TOE/TSF design specification if a component from is included).
+
+ Instances of forced exception behaviour of the TSF could
+ include, but are not limited to, the following:
+
+
+ behaviour of the TOE when start-up, close-down or error
+ recovery is activated;
+
+
+ behaviour of the TOE under extreme circumstances
+ (sometimes termed overload or asymptotic behaviour),
+ particularly where this could lead to the
+ de-activation or disabling of parts of the TSF;
+
+
+ any potential for unintentional misconfiguration or
+ insecure use arising from attacks noted in the section
+ on tampering above.
+
+
+
+
+
+
+ Potential vulnerabilities may be identified by the evaluator
+ during different activities. They may become apparent during
+ an evaluation activity or they may be identified as a result
+ of analysis of evidence to search for
+ vulnerabilities.
+
+
+ The encountered identification of vulnerabilities is where
+ potential vulnerabilities are identified by the evaluator
+ during the conduct of evaluation activities, i.e. the
+ evidence are not being analysed with the express aim of
+ identifying potential vulnerabilities.
+
+ The encountered method of identification is dependent on the
+ evaluator's experience and knowledge; which is monitored and
+ controlled by the evaluation authority. It is not reproducible
+ in approach, but will be documented to ensure repeatability of
+ the conclusions from the reported potential
+ vulnerabilities.
+
+ There are no formal analysis criteria required for this
+ method. Potential vulnerabilities are identified from the
+ evidence provided as a result of knowledge and
+ experience. However, this method of identification is not
+ constrained to any particular subset of evidence.
+
+ Evaluator is assumed to have knowledge of the TOE-type
+ technology and known security flaws as documented in the
+ public domain. The level of knowledge assumed is that
+ which can be gained from a security e-mail list relevant
+ to the TOE type, the regular bulletins (bug, vulnerability
+ and security flaw lists) published by those organisations
+ researching security issues in products and technologies
+ in widespread use. This knowledge is not expected to
+ extend to specific conference proceedings or detailed
+ theses produced by university research for or . However, to ensure the knowledge applied is
+ up to date, the evaluator may need to perform a search of
+ public domain material.
+
+ For to the search of publicly
+ available information is expected to include conference
+ proceeding and theses produced during research activities
+ by universities and other relevant organisations.
+
+ Examples of how these may arise (how the evaluator may
+ encounter potential vulnerabilities):
+
+
+ while the evaluator is examining some evidence, it
+ sparks a memory of a potential vulnerability
+ identified in a similar product type, that the
+ evaluator believes to also be present in the TOE under
+ evaluation;
+
+
+ while examining some evidence, the evaluator spots a
+ flaw in the specification of an interface, that
+ reflects a potential vulnerability.
+
+
+ This may include becoming aware of a potential
+ vulnerability in a TOE through reading about generic
+ vulnerabilities in a particular product type in an IT
+ security publication or on a security e-mail list to which
+ the evaluator is subscribed.
+
+ Attack methods can be developed directly from these
+ potential vulnerabilities. Therefore, the encountered
+ potential vulnerabilities are collated at the time of
+ producing penetration tests based on the evaluator's
+ vulnerability analysis. There is no explicit action for
+ the evaluator to encounter potential
+ vulnerabilities. Therefore, the evaluator is directed
+ through an implicit action specified in and .*.4E.
+
+ Current information regarding public domain
+ vulnerabilities and attacks may be provided to the
+ evaluator by, for example, an evaluation authority. This
+ information is to be taken into account by the evaluator
+ when collating encountered vulnerabilities and attack
+ methods when developing penetration tests.
+
+
+
+ The following types of analysis are presented in terms of
+ the evaluator actions.
+
+
+ The unstructured analysis to be performed by the
+ evaluator (for )
+ permits the evaluator to consider the generic
+ vulnerabilities (as discussed in ). The evaluator will also apply their
+ experience and knowledge of flaws in similar technology
+ types.
+
+
+
+ During the conduct of evaluation activities the
+ evaluator may also identify areas of concern. These are
+ specific portions of the TOE evidence that the evaluator
+ has some reservation about, although the evidence meets
+ the requirements for the activity with which the
+ evidence is associated. For example, a particular
+ interface specification looks particularly complex, and
+ therefore may be prone to error either in the
+ development of the TOE or in the operation of the
+ TOE. There is no potential vulnerability apparent at
+ this stage, further investigation is required. This is
+ beyond the bounds of encountered, as further
+ investigation is required.
+
+ Difference between potential vulnerability and area of
+ concern:
+
+
+ Potential vulnerability - The evaluator knows a
+ method of attack that can be used to exploit the
+ weakness or the evaluator knows of vulnerability
+ information that is relevant to the TOE.
+
+
+ Area of concern - The evaluator may be able to
+ discount concern as a potential vulnerability based
+ on information provided elsewhere. While reading
+ interface specification, the evaluator identifies
+ that due to the extreme (unnecessary) complexity of
+ an interface a potential vulnerability may lay
+ within that area, although it is not apparent
+ through this initial examination.
+
+
+ The focused approach to the identification of
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. This
+ approach to the identification of potential
+ vulnerabilities can be used during the independent
+ vulnerability analysis required by .
+
+ This analysis can be achieved through different
+ approaches, that will lead to commensurate levels of
+ confidence. None of the approaches have a rigid format
+ for the examination of evidence to be performed.
+
+ The approach taken is directed by the results of the
+ evaluator's assessment of the evidence to determine it
+ meets the requirements of the /
+ sub-activities. Therefore, the investigation of the
+ evidence for the existence of potential vulnerabilities
+ may be directed by any of the following:
+
+
+ areas of concern identified during examination of
+ the evidence during the conduct of evaluation
+ activities;
+
+
+ reliance on particular functionality to provide
+ separation, identified during the analysis of the
+ architectural design (as in ), requiring further analysis to
+ determine it cannot be bypassed;
+
+
+ representative examination of the evidence to
+ hypothesise potential vulnerabilities in the
+ TOE.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, the evaluator may not be able to
+ describe the steps in identifying potential
+ vulnerabilities before the outset of the
+ examination. The approach will evolve as a result of the
+ outcome of evaluation activities.
+
+ The areas of concern may arise from examination of any
+ of the evidence provided to satisfy the SARs specified
+ for the TOE evaluation. The information publicly
+ accessible is also considered.
+
+ The activities performed by the evaluator can be
+ repeated and the same conclusions, in terms of the level
+ of assurance in the TOE, can be reached although the
+ steps taken to achieve those conclusions may vary. As
+ the evaluator is documenting the form the analysis took,
+ the actual steps taken to achieve those conclusions are
+ also reproducible.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the
+ focused identification method). The method is specified
+ in terms of the information that will be considered and
+ how/why it will be considered. This approach to the
+ identification of potential vulnerabilities can be used
+ during the independent vulnerability analysis required
+ by and .
+
+ This analysis of the evidence is deliberate and
+ pre-planned in approach, considering all evidence
+ identified as an input into the analysis.
+
+ All evidence provided to satisfy the () assurance requirements specified in the
+ assurance package are used as input to the potential
+ vulnerability identification activity.
+
+ The ``methodical'' descriptor for this analysis has been
+ used in an attempt to capture the characterisation that
+ this identification of potential vulnerabilities is to
+ take an ordered and planned approach. A ``method'' or
+ ``system'' is to be applied in the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered; and the
+ hypothesis that is to be generated.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a security mechanism, such as domain
+ separation, hypothesising internal buffer overflows
+ leading to degradation of separation;
+
+
+ analysis to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine the SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the analysis that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be analysed to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ This identification method will provide a plan of attack
+ of the TOE, that would be performed by an evaluator
+ completing penetration testing of potential
+ vulnerabilities in the TOE. The rationale for the method
+ of identification would provide the evidence for the
+ coverage and depth of exploitation determination that
+ would be performed on the TOE.
+
+
+
+
+
+
+
+ Attack potential is used by a PP/ST author during the
+ development of the PP/ST, in consideration of the threat
+ environment and the selection of assurance components. This
+ may simply be a determination that the attack potential
+ possessed by the assumed attackers of the TOE is generically
+ characterised as Basic, Enhanced-Basic, Moderate or
+ High. Alternatively, the PP/ST may wish to specify
+ particular levels of individual factors assumed to be
+ possessed by attackers. (e.g. the attackers are assumed to
+ be experts in the TOE technology type, with access to
+ specialised equipment.)
+
+ The PP/ST author considers the threat profile developed during a
+ risk assessment (outside the scope of the CC, but used as an
+ input into the development of the PP/ST in terms of the Security
+ Problem Definition or in the case of low assurance STs, the
+ requirements statement). Consideration of this threat profile in
+ terms of one of the approaches discussed in the following
+ sections will permit the specification of the attack potential
+ the TOE is to resist.
+
+
+
+ Attack potential is especially considered by the evaluator
+ in two distinct ways during the ST evaluation and the
+ vulnerability assessment activities.
+
+ Attack potential is used by an evaluator during the conduct
+ of the vulnerability analysis sub-activity to determine
+ whether or not the TOE is resistant to attacks assuming a
+ specific attack potential of an attacker. If the evaluator
+ determines that a potential vulnerability is exploitable in
+ the TOE, they have to confirm that it is exploitable
+ considering all aspects of the intended environment,
+ including the attack potential assumed by an
+ attacker.
+
+ Therefore, using the information provided in the threat
+ statement of the Security Target, the evaluator determines
+ the minimum attack potential required by an attacker to
+ effect an attack, and arrives at some conclusion about the
+ TOE's resistance to attacks. Table demonstrates the relationship between this
+ analysis and attack potential.
+
+
+
+
+ Vulnerability Component
+ TOE resistant to attacker with
+ attack potential of:
+ Residual vulnerabilities only
+ exploitable by attacker with attack potential
+ of:
+
+
+
+
+ VAN.5
+ High
+ Beyond High
+
+
+ VAN.4
+ Moderate
+ High
+
+
+ VAN.3
+ Enhanced-Basic
+ Moderate
+
+
+ VAN.2
+ Basic
+ Enhanced-Basic
+
+
+ VAN.1
+ Basic
+ Enhanced-Basic
+
+
+
+ Vulnerability testing and attack potential
+
+
+ The ``beyond high'' entry in the residual vulnerabilities
+ column of the above table represents those potential
+ vulnerabilities that would require an attacker to have an
+ attack potential greater than that of ``high'' in order to
+ exploit the potential vulnerability. A vulnerability
+ classified as residual in this instance reflects the fact
+ that a known weakness exists in the TOE, but in the current
+ operational environment, with the assumed attack potential,
+ the weakness cannot be exploited.
+
+ At any level of attack potential a potential vulnerability
+ may be deemed ``infeasible'' due to a countermeasure in the
+ operational environment that prevents the vulnerability from
+ being exploited.
+
+ A vulnerability analysis applies to all TSFI, including ones
+ that access probabilistic or permutational mechanisms. No
+ assumptions are made regarding the correctness of the design
+ and implementation of the TSFI; nor are constraints placed
+ on the attack method or the attacker's interaction with the
+ TOE - if an attack is possible, then it is to be considered
+ during the vulnerability analysis. As shown in Table , successful evaluation
+ against a vulnerability assurance component reflects that
+ the TSF is designed and implemented to protect against the
+ required level of threat.
+
+ It is not necessary for an evaluator to perform an attack
+ potential calculation for each potential vulnerability. In
+ some cases it is apparent when developing the attack method
+ whether or not the attack potential required to develop and
+ run the attack method is commensurate with that assumed of
+ the attacker in the operational environment. For any
+ vulnerabilities for which an exploitation is determined, the
+ evaluator performs an attack potential calculation to
+ determine that the exploitation is appropriate to the level
+ of attack potential assumed for the attacker.
+
+ The approach described below is to be applied whenever it is
+ necessary to calculate attack potential, unless the evaluation
+ authority provides mandatory guidance that an alternative
+ approach is to be applied. The values given in Tables and
+ below are not mathematically proven. Therefore, the values given
+ in these example tables may need to be adjusted according to the
+ technology type and specific environments. The evaluator should
+ seek guidance from the evaluation authority.
+
+
+
+
+
+ Attack potential is a function of expertise, resources and
+ motivation. There are multiple methods of representing and
+ quantifying these factors. Also, there may be other factors
+ that are applicable for particular TOE types.
+
+
+ Motivation is an attack potential factor that can be used
+ to describe several aspects related to the attacker and
+ the assets the attacker desires. Firstly, motivation can
+ imply the likelihood of an attack - one can infer from a
+ threat described as highly motivated that an attack is
+ imminent, or that no attack is anticipated from an
+ un-motivated threat. However, except for the two extreme
+ levels of motivation, it is difficult to derive a
+ probability of an attack occurring from motivation.
+
+ Secondly, motivation can imply the value of the asset,
+ monetarily or otherwise, to either the attacker or the
+ asset holder. An asset of very high value is more likely
+ to motivate an attack compared to an asset of little
+ value. However, other than in a very general way, it is
+ difficult to relate asset value to motivation because the
+ value of an asset is subjective - it depends largely upon
+ the value an asset holder places on it.
+
+ Thirdly, motivation can imply the expertise and resources
+ with which an attacker is willing to effect an attack. One
+ can infer that a highly motivated attacker is likely to
+ acquire sufficient expertise and resources to defeat the
+ measures protecting an asset. Conversely, one can infer
+ that an attacker with significant expertise and resources
+ is not willing to effect an attack using them if the
+ attacker's motivation is low.
+
+ During the course of preparing for and conducting an
+ evaluation, all three aspects of motivation are at some
+ point considered. The first aspect, likelihood of attack,
+ is what may inspire a developer to pursue an
+ evaluation. If the developer believes that the attackers
+ are sufficiently motivated to mount an attack, then an
+ evaluation can provide assurance of the ability of the TOE
+ to thwart the attacker's efforts. Where the operational
+ environment is well defined, for example in a system
+ evaluation, the level of motivation for an attack may be
+ known, and will influence the selection of
+ countermeasures.
+
+ Considering the second aspect, an asset holder may believe
+ that the value of the assets (however measured) is
+ sufficient to motivate attack against them. Once an
+ evaluation is deemed necessary, the attacker's motivation
+ is considered to determine the methods of attack that may
+ be attempted, as well as the expertise and resources used
+ in those attacks. Once examined, the developer is able to
+ choose the appropriate assurance level, in particular the
+ requirement components,
+ commensurate with the attack potential for the
+ threats. During the course of the evaluation, and in
+ particular as a result of completing the vulnerability
+ assessment activity, the evaluator determines whether or
+ not the TOE, operating in its operational environment, is
+ sufficient to thwart attackers with the identified
+ expertise and resources.
+
+ It may be possible for a PP author to quantify the
+ motivation of an attacker, as the PP author has greater
+ knowledge of the operational environment in which the TOE
+ (conforming to the requirements of the PP) is to be
+ placed. Therefore, the motivation could form an explicit
+ part of the expression of the attack potential in the PP,
+ along with the necessary methods and measures to quantify
+ the motivation.
+
+
+
+
+ This section examines the factors that determine attack
+ potential, and provides some guidelines to help remove some
+ of the subjectivity from this aspect of the evaluation
+ process.
+
+
+ The determination of the attack potential for an attack
+ corresponds to the identification of the effort required to
+ create the attack, and to demonstrate that it can be
+ successfully applied to the TOE (including setting up or
+ building any necessary test equipment), thereby exploiting the
+ vulnerability in the TOE. The demonstration that the attack can
+ be successfully applied needs to consider any difficulties in
+ expanding a result shown in the laboratory to create a useful
+ attack. For example, where an experiment reveals some bits or
+ bytes of a confidential data item (such as a key), it is
+ necessary to consider how the remainder of the data item would
+ be obtained (in this example some bits might be measured
+ directly by further experiments, while others might be found by
+ a different technique such as exhaustive search). It may not be
+ necessary to carry out all of the experiments to identify the
+ full attack, provided it is clear that the attack actually
+ proves that access has been gained to a TOE asset, and that the
+ complete attack could realistically be carried out in
+ exploitation according to the
+ component targeted. In some cases the only way to prove that an
+ attack can realistically be carried out in exploitation
+ according to the component
+ targeted is to perform completely the attack and
+ then rate it based upon the resources actually required.
+ One of the outputs from the identification of a potential
+ vulnerability is assumed to be a script that gives a
+ step-by-step description of how to carry out the attack that can
+ be used in the exploitation of the vulnerability on another
+ instance of the TOE.
+
+ In many cases, the evaluators will estimate the parameters
+ for exploitation, rather than carry out the full
+ exploitation. The estimates and their rationale will be
+ documented in the ETR.
+
+
+
+ The following factors should be considered during analysis
+ of the attack potential required to exploit a
+ vulnerability:
+
+
+ Time taken to identify and exploit (
+ Elapsed Time);
+
+
+ Specialist technical expertise required (
+ Specialist Expertise);
+
+
+ Knowledge of the TOE design and operation (
+ Knowledge of the TOE);
+
+
+
+ Window of opportunity;
+
+
+
+ IT hardware/software or other
+ equipment required for
+ exploitation.
+
+
+
+ In many cases these factors are not independent, but may be
+ substituted for each other in varying degrees. For example,
+ expertise or hardware/software may be a substitute for time. A
+ discussion of these factors follows. (The levels of each factor
+ are discussed in increasing order of magnitude.) When it is the
+ case, the less ``expensive'' combination is considered in the
+ exploitation phase.
+ Elapsed time is the total amount
+ of time taken by an attacker to identify that a particular
+ potential vulnerability may exist in the TOE, to develop an
+ attack method and to sustain effort required to mount the attack
+ against the TOE. When considering this factor, the worst case
+ scenario is used to estimate the amount of time required. The
+ identified amount of time is as follows:
+ less than one day;between one day and one week;between one week and two weeks;between two weeks and one month;each additional month up to 6 months leads to an
+ increased value;more than 6 months.
+
+ Specialist expertise refers
+ to the level of generic knowledge of the underlying
+ principles, product type or attack methods (e.g. Internet
+ protocols, Unix operating systems, buffer overflows). The
+ identified levels are as follows:
+
+
+ Laymen are unknowledgeable compared to experts or
+ proficient persons, with no particular expertise;
+
+
+ Proficient persons are knowledgeable in that they are
+ familiar with the security behaviour of the product or
+ system type;
+
+
+ Experts are familiar with the underlying algorithms,
+ protocols, hardware, structures, security behaviour,
+ principles and concepts of security employed,
+ techniques and tools for the definition of new
+ attacks, cryptography, classical attacks for the
+ product type, attack methods, etc. implemented in the
+ product or system type.
+
+
+ The level ``Multiple Expert'' is introduced to allow for
+ a situation, where different fields of expertise are
+ required at an Expert level for distinct steps of an
+ attack.
+
+ It may occur that several types of expertise are
+ required. By default, the higher of the different
+ expertises factors is chosen. In very specific cases, the
+ ``multiple expert'' level could be used but it should be
+ noted that the expertise must concern fields that are
+ strictly different like for example HW manipulation and
+ cryptography.
+
+
+ Knowledge of the TOE refers to
+ specific expertise in relation to the TOE. This is
+ distinct from generic expertise, but not unrelated to
+ it. Identified levels are as follows:
+
+
+ Public information concerning the TOE (e.g. as gained
+ from the Internet);
+
+
+ Restricted information concerning the TOE
+ (e.g. knowledge that is controlled within the
+ developer organisation and shared with other
+ organisations under a non-disclosure agreement)
+
+
+ Sensitive information about the TOE (e.g. knowledge
+ that is shared between discreet teams within the
+ developer organisation, access to which is constrained
+ only to members of the specified teams);
+
+
+ Critical information about the TOE (e.g. knowledge
+ that is known by only a few individuals, access to
+ which is very tightly controlled on a strict need to
+ know basis and individual undertaking).
+
+
+
+ The knowledge of the TOE may graduate according to design
+ abstraction, although this can only be done on a TOE by
+ TOE basis. Some TOE designs may be public source (or
+ heavily based on public source) and therefore even the
+ design representation would be classified as public or at
+ most restricted, while the implementation representation
+ for other TOEs is very closely controlled as it would give
+ an attacker information that would aid an attack and is
+ therefore considered to be sensitive or even
+ critical.
+
+ It may occur that several types of knowledge are
+ required. In such cases, the higher of the different
+ knowledge factors is chosen.
+
+
+ Window of opportunity
+
+ (Opportunity) is also an important consideration, and has
+ a relationship to the Elapsed Time
+ factor. Identification or exploitation of a
+ vulnerability may require considerable amounts of access
+ to a TOE that may increase the likelihood of
+ detection. Some attack methods may require considerable
+ effort off-line, and only brief access to the TOE to
+ exploit. Access may also need to be continuous, or over a
+ number of sessions.
+
+ For some TOEs the Window of
+ opportunity may equate to the number of
+ samples of the TOE that the attacker can obtain. This is
+ particularly relevant where attempts to penetrate the
+ TOE and undermine the SFRs may result in the destruction
+ of the TOE preventing use of that TOE sample for further
+ testing, e.g. hardware devices. Often in these cases
+ distribution of the TOE is controlled and so the
+ attacker must apply effort to obtain further samples of
+ the TOE.
+
+ For the purposes of this discussion:
+
+
+ unnecessary/unlimited access means that the attack
+ doesn't need any kind of opportunity to be realised
+ because there is no risk of being detected during
+ access to the TOE and it is no problem to access the
+ number of TOE samples for the attack;
+
+ easy means that access is required for less than a day
+ and that the number of TOE samples required to perform
+ the attack is less than ten;
+
+ moderate means that access is required for less than a
+ month and that the number of TOE samples required to
+ perform the attack is less than one hundred;
+
+ difficult means that access is required for at least a
+ month or that the number of TOE samples required to
+ perform the attack is at least one hundred;
+
+ none means that the opportunity window is not
+ sufficient to perform the attack (the length for which
+ the asset to be exploited is available or is sensitive
+ is less than the opportunity length needed to perform
+ the attack - for example, if the asset key is changed
+ each week and the attack needs two weeks); another
+ case is, that a sufficient number of TOE samples
+ needed to perform the attack is not accessible to the
+ attacker - for example if the TOE is a hardware and
+ the probability to destroy the TOE during the attack
+ instead of being successful is very high and the
+ attacker has only access to one sample of the
+ TOE.
+
+ Consideration of this factor may result in determining
+ that it is not possible to complete the exploit, due to
+ requirements for time availability that are greater than
+ the opportunity time.
+
+
+ IT hardware/software or other equipment
+ refers to the equipment required to identify
+ or exploit a vulnerability.
+
+
+ Standard equipment is readily available to the
+ attacker, either for the identification of a
+ vulnerability or for an attack. This equipment may be
+ a part of the TOE itself (e.g. a debugger in an
+ operating system), or can be readily obtained
+ (e.g. Internet downloads, protocol analyser or simple
+ attack scripts).
+
+
+ Specialised equipment is not readily available to the attacker,
+ but could be acquired without undue effort. This could include
+ purchase of moderate amounts of equipment (e.g. power analysis
+ tools, use of hundreds of PCs linked across the Internet would
+ fall into this category), or development of more extensive
+ attack scripts or programs. If clearly different test benches
+ consisting of specialised equipment are required for distinct
+ steps of an attack this would be rated as bespoke.
+
+
+ Bespoke equipment is not readily available to the
+ public as it may need to be specially produced
+ (e.g. very sophisticated software), or because the
+ equipment is so specialised that its distribution is
+ controlled, possibly even restricted. Alternatively,
+ the equipment may be very expensive.
+
+ The level ``Multiple Bespoke'' is introduced to allow
+ for a situation, where different types of bespoke
+ equipment are required for distinct steps of an
+ attack.
+
+ Specialist expertise and Knowledge of the
+ TOE are concerned with the information
+ required for persons to be able to attack a TOE. There
+ is an implicit relationship between an attacker's
+ expertise (where the attacker may be one or more persons
+ with complementary areas of knowledge) and the ability
+ to effectively make use of equipment in an attack. The
+ weaker the attacker's expertise, the lower the potential
+ to use equipment (IT hardware/software or other
+ equipment). Likewise, the greater the expertise, the
+ greater the potential for equipment to be used in the
+ attack. Although implicit, this relationship between
+ expertise and the use of equipment does not always
+ apply, for instance, when environmental measures prevent
+ an expert attacker's use of equipment, or when, through
+ the efforts of others, attack tools requiring little
+ expertise to be effectively used are created and freely
+ distributed (e.g. via the Internet).
+
+
+
+ Table identifies the
+ factors discussed in the previous section and associates
+ numeric values with the total value of each factor.
+
+ Where a factor falls close to the boundary of a range the
+ evaluator should consider use of an intermediate value to those
+ in the table. For example, if twenty samples are required to
+ perform the attack then a value between one and four may be
+ selected for that factor, or if the design is based on a
+ publicly available design but the developer has made some
+ alterations then a value between zero and three should be
+ selected according to the evaluator's view of the impact of
+ those design changes. The table is intended as a guide.
+
+ The ``**'' specification in the table in considering
+ Window of Opportunity is not
+ to be seen as a natural progression from the timescales
+ specified in the preceding ranges associated with this
+ factor. This specification identifies that for a
+ particular reason the potential vulnerability cannot be
+ exploited in the TOE in its intended operational
+ environment. For example, access to the TOE may be
+ detected after a certain amount of time in a TOE with a
+ known environment (i.e. in the case of a system) where
+ regular patrols are completed, and the attacker could not
+ gain access to the TOE for the required two weeks
+ undetected. However, this would not be applicable to a TOE
+ connected to the network where remote access is possible,
+ or where the physical environment of the TOE is
+ unknown.
+
+
+
+
+
+ Factor
+
+
+ Value
+
+
+
+
+
+
+ Elapsed Time
+
+
+
+
+
+ <= one day
+
+ 0
+
+
+
+ <= one week
+
+ 1
+
+
+
+ <= two weeks
+
+ 2
+
+
+
+ <= one month
+
+ 4
+
+
+
+ <= two months
+
+ 7
+
+
+
+ <= three months
+
+ 10
+
+
+
+ <= four months
+
+ 13
+
+
+
+ <= five months
+
+ 15
+
+
+
+ <= six months
+
+ 17
+
+
+
+ > six months
+
+ 19
+
+
+
+ Expertise
+
+
+
+
+
+ Layman
+
+ 0
+
+
+
+ Proficient
+
+
+ 3*When several proficient persons are
+ required to complete the attack path, the
+ resulting level of expertise still remains
+ ``proficient'' (which leads to a 3
+ rating).
+
+
+
+ Expert
+
+ 6
+
+
+
+ Multiple experts
+
+ 8
+
+
+
+ Knowledge of TOE
+
+
+
+
+
+ Public
+
+ 0
+
+
+
+ Restricted
+
+ 3
+
+
+
+ Sensitive
+
+ 7
+
+
+
+ Critical
+
+ 11
+
+
+
+ Window of Opportunity
+
+
+
+
+
+ Unnecessary / unlimited access
+
+ 0
+
+
+
+ Easy
+
+ 1
+
+
+
+ Moderate
+
+ 4
+
+
+
+ Difficult
+
+ 10
+
+
+
+ None
+
+
+ **Indicates that the attack path is not
+ exploitable due to other measures in the
+ intended operational environment of the
+ TOE.
+
+
+
+
+ Equipment
+
+
+
+
+
+ Standard
+
+ 0
+
+
+
+ Specialised
+
+ 4If clearly different test benches
+ consisting of specialised equipment are required
+ for distinct steps of an attack, this should be
+ rated as bespoke.
+
+
+
+ Bespoke
+
+ 7
+
+
+
+ Multiple bespoke
+
+ 9
+
+
+
+
+ Calculation of attack potential
+
+
+ To determine the resistance of the TOE to the potential
+ vulnerabilities identified the following steps should be
+ applied:
+
+
+ Define the possible attack scenarios {AS1, AS2, ...,
+ ASn} for the TOE in the operational
+ environment.
+
+ For each attack scenario, perform a theoretical
+ analysis and calculate the relevant attack potential
+ using Table .
+
+ For each attack scenario, if necessary, perform
+ penetration tests in order to confirm or to disprove
+ the theoretical analysis.
+
+ Divide all attack scenarios {AS1, AS2, ..., ASn} into
+ two groups:
+
+
+ the attack scenarios having been successful
+ (i.e. those that have been used to successfully
+ undermine the SFRs), and
+
+ the attack scenarios that have been demonstrated
+ to be unsuccessful.
+
+
+
+ For each successful attack scenario, apply Table and determine, whether
+ there is a contradiction between the resistance of the
+ TOE and the chosen
+ assurance component, see the last column of Table .
+
+ Should one contradiction be found, the vulnerability
+ assessment will fail, e.g. the author of the ST chose
+ the component and an
+ attack scenario with an attack potential of 21 points
+ (high) has broken the security of the TOE. In this
+ case the TOE is resistant to attacker with attack
+ potential 'Moderate', this contradicts to , hence, the vulnerability
+ assessment fails.
+
+ The ``Values'' column of Table indicates the range of attack potential values
+ (calculated using Table ) of an
+ attack scenario that results in the SFRs being
+ undermined.
+
+
+ An approach such as this cannot take account of every
+ circumstance or factor, but should give a better
+ indication of the level of resistance to attack required
+ to achieve the standard ratings. Other factors, such as
+ the reliance on unlikely chance occurrences are not
+ included in the basic model, but can be used by an
+ evaluator as justification for a rating other than those
+ that the basic model might indicate.
+
+ It should be noted that whereas a number of
+ vulnerabilities rated individually may indicate high
+ resistance to attack, collectively the combination of
+ vulnerabilities may indicate that overall a lower rating
+ is applicable. The presence of one vulnerability may make
+ another easier to exploit.
+
+ If a PP/ST author wants to use the attack potential table for
+ the determination of the level of attack the TOE should
+ withstand (selection of Vulnerability analysis () component), he should proceed as
+ follows: For all different attack scenarios (i.e. for all
+ different types of attacker and/or different types of attack the
+ author has in mind) which must not violate the SFRs, several
+ passes through Table should be
+ made to determine the different values of attack potential
+ assumed for each such unsuccessful attack scenario. The PP/ST
+ author then chooses the highest value of them in order to
+ determine the level of the TOE resistance to be claimed from
+ Table : the TOE resistance must
+ be at least equal to this highest value determined. For
+ example, the highest value of attack potentials of all attack
+ scenarios, which must not undermine the TOE security policy,
+ determined in such a way is Moderate; hence, the TOE resistance
+ shall be at least Moderate (i.e. Moderate or High); therefore,
+ the PP/ST author can choose either (for Moderate) or
+ (for High) as the appropriate assurance component.
+
+
+
+
+
+
+
+ Mechanisms subject to direct attack are often vital for system
+ security and developers often strengthen these mechanisms. As
+ an example, a TOE might use a simple pass number
+ authentication mechanism that can be overcome by an attacker
+ who has the opportunity to repeatedly guess another user's
+ pass number. The system can strengthen this mechanism by
+ restricting pass numbers and their use in various ways. During
+ the course of the evaluation an analysis of this direct attack
+ could proceed as follows:
+
+ Information gleaned from the ST and design evidence reveals
+ that identification and authentication provides the basis upon
+ which to control access to network resources from widely
+ distributed terminals. Physical access to the terminals is not
+ controlled by any effective means. The duration of access to a
+ terminal is not controlled by any effective means. Authorised
+ users of the system choose their own pass numbers when
+ initially authorised to use the system, and thereafter upon
+ user request. The system places the following restrictions on
+ the pass numbers selected by the user:
+
+
+ the pass number must be at least four and no greater than
+ six digits long;
+
+
+ consecutive numerical sequences are disallowed (such as
+ 7,6,5,4,3);
+
+
+ repeating digits is disallowed (each digit must be
+ unique).
+
+
+
+ Guidance provided to the users at the time of pass number
+ selection is that pass numbers should be as random as possible
+ and should not be affiliated with the user in some way - a
+ date of birth, for instance.
+
+ The pass number space is calculated as follows:
+
+
+ Patterns of human usage are important considerations that
+ can influence the approach to searching a password
+ space. Assuming the worst case scenario and the user
+ chooses a number comprising only four digits, the number
+ of pass number permutations assuming that each digit must
+ be unique is:
+
+
+ The number of possible increasing sequences is seven, as
+ is the number of decreasing sequences. The pass number
+ space after disallowing sequences is:
+
+
+
+ Based on further information gleaned from the design evidence,
+ the pass number mechanism is designed with a terminal locking
+ feature. Upon the sixth failed authentication attempt the
+ terminal is locked for one hour. The failed authentication
+ count is reset after five minutes so that an attacker can at
+ best attempt five pass number entries every five minutes, or
+ 60 pass number entries every hour.
+
+ On average, an attacker would have to enter 2513 pass numbers,
+ over 2513 minutes, before entering the correct pass number. The
+ average successful attack would, as a result, occur in slightly
+ less than:
+
+ Using the approach to calculate the attack potential, described
+ in the previous section, identifies that it is possible that a
+ layman can defeat the mechanism within days (given easy access
+ to the TOE), with the use of standard equipment, and with no
+ knowledge of the TOE, giving a value of 1. Given the resulting
+ sum, 1, the attack potential required to effect a successful
+ attack is not rated, as it falls below that considered to be
+ Basic.
+
+
+
+
+ Table describes the
+ relationship between the composition assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Composed Assurance Packages (CAPs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance for
+ composed TOEs.
+
+ It is important to note that there are only a small number of
+ families and components from CC Part 3 included in the
+ CAPs. This is due to their nature of building upon evaluation
+ results of previously evaluated entities (base components and
+ dependent components), and is not to say that these do not
+ provide meaningful and desirable assurances.
+
+
+ CAPs are to be applied to composed TOEs, which are comprised
+ of components that have been (are going through) component TOE
+ evaluation (see ). The
+ individual components will have been certified to an EAL or
+ another assurance package specified in the ST. It is expected
+ that a basic level of assurance in a composed TOE will be
+ gained through application of EAL1, which can be achieved with
+ information about the components that is generally available
+ in the public domain. (EAL1 can be applied as specified
+ within to both component and composed TOEs.) CAPs provide an
+ alternative approach to obtaining higher levels of assurance
+ for a composed TOE than application of the EALs above
+ EAL1.
+
+ While a dependent component can be evaluated using a
+ previously evaluated and certified base component to satisfy
+ the IT platform requirements in the environment, this does not
+ provide any formal assurance of the interactions between the
+ components or the possible introduction of vulnerabilities
+ resulting from the composition. Composed assurance packages
+ consider these interactions and, at higher levels of
+ assurance, ensure that the interface between the components
+ has itself been the subject of testing. A vulnerability
+ analysis of the composed TOE is also performed to consider the
+ possible introduction of vulnerabilities as a result of
+ composing the components.
+
+ Table represents a summary
+ of the CAPs. The columns represent a hierarchically ordered
+ set of CAPs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, three hierarchically
+ ordered composed assurance packages are defined in the CC for
+ the rating of a composed TOE's assurance. They are
+ hierarchically ordered inasmuch as each CAP represents more
+ assurance than all lower CAPs. The increase in assurance from
+ CAP to CAP is accomplished by substitution of a hierarchically
+ higher assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements). These increases result in
+ greater analysis of the composition to identify the impact on
+ the evaluation results gained for the individual component
+ TOEs.
+
+ These CAPs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each CAP includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ The CAPs only consider resistance against an attacker with an
+ attack potential up to Enhanced-Basic. This is due to the level
+ of design information that can be provided through the , limiting some of the factors
+ associated with attack potential (knowledge of the composed TOE)
+ and subsequently affecting the rigour of vulnerability analysis
+ that can be performed by the evaluator. Therefore, the level of
+ assurance in the composed TOE is limited, although the assurance
+ in the individual components within the composed TOE may be much
+ higher.
+
+
+
+
+ The following Subclauses provide definitions of the CAPs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ Unlike the CC, where each element maintains the last digit of
+ its identifying symbol for all components within the family,
+ the CEM may introduce new work units when a CC evaluator
+ action element changes from sub-activity to sub-activity; as a
+ result, the last digit of the work unit's identifying symbol
+ may change although the work unit remains unchanged.
+
+ Any methodology-specific evaluation work required that is not
+ derived directly from CC requirements is termed
+ task or sub-task.
+
+
+
+ All work unit and sub-task verbs are preceded by the auxiliary
+ verb shall and by presenting both the verb
+ and the shall in
+
+ bold italic type face. The
+ auxiliary verb shall is used only when the
+ provided text is mandatory and therefore only within the work
+ units and sub-tasks. The work units and sub-tasks contain
+ mandatory activities that the evaluator must perform in order
+ to assign verdicts.
+
+ Guidance text accompanying work units and sub-tasks gives
+ further explanation on how to apply the CC words in an
+ evaluation. The verb usage is in accordance with ISO
+ definitions for these verbs. The auxiliary verb
+ should is used when the described method is
+ strongly preferred. All other auxiliary verbs, including
+ may, are used where the described method(s)
+ is allowed but is neither recommended nor strongly preferred;
+ it is merely explanation.
+
+ The verbs check, examine,
+ report and record are used
+ with a precise meaning within this part of the CEM and the
+ Clause should be
+ referenced for their definitions.
+
+
+
+ Material that has applicability to more than one sub-activity
+ is collected in one place. Guidance whose applicability is
+ widespread (across activities and EALs) has been collected
+ into . Guidance that
+ pertains to multiple sub-activities within a single activity
+ has been provided in the introduction to that activity. If
+ guidance pertains to only a single sub-activity, it is
+ presented within that sub-activity.
+
+
+
+ There are direct relationships between the CC structure
+ (i.e. class, family, component and element) and the structure
+ of the CEM. Figure illustrates the correspondence
+ between the CC constructs of class, family and evaluator
+ action elements and CEM activities, sub-activities and
+ actions. However, several CEM work units may result from the
+ requirements noted in CC developer action and content and
+ presentation elements.
+
+
+
+ For the purposes of this document, the following terms and
+ definitions apply.
+ Terms which are presented in bold-faced type are themselves
+ defined in this Subclause.
+ action
+
+ evaluator action element of the CC Part 3
+
+ These actions are either explicitly stated as evaluator
+ actions or implicitly derived from developer actions (implied
+ evaluator actions) within the CC Part 3 assurance components.
+
+ activity
+
+ application of an assurance class of the CC Part 3
+
+ check
+
+ generate a verdict by a simple comparison
+
+ Evaluator expertise is not required. The statement
+ that uses this verb describes what is mapped.
+
+ evaluation deliverable
+
+ any resource required from the sponsor or developer by the
+ evaluator or evaluation authority to perform one or more evaluation or
+ evaluation oversight activities
+
+ evaluation evidence
+ tangible evaluation deliverable
+ evaluation technical report
+
+ report that documents the overall verdict and its
+ justification, produced by the evaluator and submitted to an
+ evaluation authority
+ examine
+
+ generate a verdict by analysis using
+ evaluator expertise
+
+ The statement that uses this verb identifies what is analysed
+ and the properties for which it is analysed.
+
+ interpretation
+ clarification or amplification of a CC, CEM or
+ scheme requirement
+ methodology
+
+ system of principles, procedures and processes applied to IT
+ security evaluations
+
+ observation report
+
+ report written by the evaluator requesting a clarification
+ or identifying a problem during the evaluation
+
+ overall verdict
+ pass or fail statement issued by an
+ evaluator with respect to the result of an
+ evaluation
+
+ oversight verdict
+
+ statement issued by an evaluation authority confirming or
+ rejecting an overall verdict based on the
+ results of evaluation oversight activities
+
+ record
+
+ retain a written description of procedures, events,
+ observations, insights and results in sufficient detail to
+ enable the work performed during the evaluation to be
+ reconstructed at a later time
+
+ report
+
+ include evaluation results and supporting material in the
+ Evaluation Technical Report or an
+ Observation Report
+ scheme
+
+ set of rules, established by an evaluation authority,
+ defining the evaluation environment, including criteria and
+ methodology required to conduct IT security
+ evaluations
+
+ sub-activity
+
+ application of an assurance component of the CC Part 3
+
+ Assurance families are not explicitly addressed in the CEM
+ because evaluations are conducted on a single assurance
+ component from an assurance family.
+
+ tracing
+
+ simple directional relation between two sets of
+ entities, which shows which entities in the first set
+ correspond to which entities in the second
+
+ verdict
+ pass, fail or inconclusive statement issued
+ by an evaluator with respect to a CC evaluator action element,
+ assurance component, or class
+
+ Also see overall verdict.
+
+ work unit
+
+ most granular level of evaluation work
+
+ Each CEM action comprises one or more work units, which are
+ grouped within the CEM action by CC content and presentation
+ of evidence or developer action element. The work units are
+ presented in the CEM in the same order as the CC elements
+ from which they are derived. Work units are identified in
+ the left margin by a symbol such as . In this symbol, the
+ string
+ indicates the CC component (i.e. the CEM sub-activity), and
+ the final digit (2) indicates that this is
+ the second work unit in the
+ sub-activity.
+
+
+
+ The target audience for the Common Methodology for Information
+ Technology Security Evaluation (CEM) is primarily evaluators
+ applying the CC and certifiers confirming evaluator actions;
+ evaluation sponsors, developers, PP/ST authors and other parties
+ interested in IT security may be a secondary audience.
+
+ The CEM recognises that not all questions concerning IT security
+ evaluation will be answered herein and that further
+ interpretations will be needed. Individual schemes will
+ determine how to handle such interpretations, although these may
+ be subject to mutual recognition agreements. A list of
+ methodology-related activities that may be handled by individual
+ schemes can be found in .
+
+
+
+
+ Clause defines the
+ conventions used in the CEM.
+
+ Clause
+ describes general evaluation tasks with no verdicts associated
+ with them as they do not map to CC evaluator action
+ elements.
+
+ Clause addresses the work
+ necessary for reaching an evaluation result on a PP.
+
+ Clauses to define the evaluation activities, organised by
+ Assurance Classes.
+
+ covers the basic
+ evaluation techniques used to provide technical evidence of
+ evaluation results.
+
+ provides an explanation
+ of the Vulnerability Analysis criteria and examples of their
+ application.
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.
+
+ CC
+
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+
+
+
+
+ The Common Methodology for Information Technology Security
+ Evaluation (CEM) is a companion document to the Common Criteria
+ for Information Technology Security Evaluation (CC). The CEM
+ defines the minimum actions to be performed by an evaluator in
+ order to conduct a CC evaluation, using the criteria and
+ evaluation evidence defined in the CC.
+ The CEM does not define evaluator actions for certain high
+ assurance CC components, where there is as yet no generally
+ agreed guidance.
+
+
+
+ CEM
+
+ Common Methodology for Information Technology Security
+ Evaluation
+
+
+
+ ETR
+
+ Evaluation Technical Report
+
+
+
+ OR
+
+ Observation Report
+
+
+
+
+
+
+ Table describes the
+ relationship between the evaluation assurance levels and the
+ assurance classes, families and components.
+
+
+
+ The Evaluation Assurance Levels (EALs) provide an increasing
+ scale that balances the level of assurance obtained with the
+ cost and feasibility of acquiring that degree of assurance. The
+ CC approach identifies the separate concepts of assurance in a
+ TOE at the end of the evaluation, and of maintenance of that
+ assurance during the operational use of the TOE.
+
+ It is important to note that not all families and components
+ from CC Part 3 are included in the EALs. This is not to say that
+ these do not provide meaningful and desirable
+ assurances. Instead, it is expected that these families and
+ components will be considered for augmentation of an EAL in
+ those PPs and STs for which they provide utility.
+
+
+ Table represents a summary
+ of the EALs. The columns represent a hierarchically ordered
+ set of EALs, while the rows represent assurance families. Each
+ number in the resulting matrix identifies a specific assurance
+ component where applicable.
+
+ As outlined in the next Subclause, seven hierarchically
+ ordered evaluation assurance levels are defined in the CC for
+ the rating of a TOE's assurance. They are hierarchically
+ ordered inasmuch as each EAL represents more assurance than
+ all lower EALs. The increase in assurance from EAL to EAL is
+ accomplished by substitution of a hierarchically higher
+ assurance component from the same assurance family
+ (i.e. increasing rigour, scope, and/or depth) and from the
+ addition of assurance components from other assurance families
+ (i.e. adding new requirements).
+
+ These EALs consist of an appropriate combination of assurance
+ components as described in Clause of this CC Part 3. More
+ precisely, each EAL includes no more than one component of
+ each assurance family and all assurance dependencies of every
+ component are addressed.
+
+ While the EALs are defined in the CC, it is possible to
+ represent other combinations of assurance. Specifically, the
+ notion of ``augmentation'' allows the addition of assurance
+ components (from assurance families not already included in
+ the EAL) or the substitution of assurance components (with
+ another hierarchically higher assurance component in the same
+ assurance family) to an EAL. Of the assurance constructs
+ defined in the CC, only EALs may be augmented. The notion of
+ an ``EAL minus a constituent assurance component'' is not
+ recognised by the standard as a valid claim. Augmentation
+ carries with it the obligation on the part of the claimant to
+ justify the utility and added value of the added assurance
+ component to the EAL. An EAL may also be augmented with
+ extended assurance requirements.
+
+
+
+
+ The following Subclauses provide definitions of the EALs,
+ highlighting differences between the specific requirements and
+ the prose characterisations of those requirements using bold
+ type.
+
+
+
+
+
+ The objective of this clause is to cover general guidance
+ used to provide technical evidence of evaluation results. The
+ use of such general guidance helps in achieving objectivity,
+ repeatability and reproducibility of the work performed by the
+ evaluator.
+
+
+
+ This Subclause provides general guidance on sampling. Specific
+ and detailed information is given in those work units under
+ the specific evaluator action elements where sampling has to
+ be performed.
+
+ Sampling is a defined procedure of an evaluator whereby some
+ subset of a required set of evaluation evidence is examined
+ and assumed to be representative for the entire set. It allows
+ the evaluator to gain enough confidence in the correctness of
+ particular evaluation evidence without analysing the whole
+ evidence. The reason for sampling is to conserve resources
+ while maintaining an adequate level of assurance. Sampling of
+ the evidence can provide two possible outcomes:
+
+
+ The subset reveals no errors, allowing the evaluator to
+ have some confidence that the entire set is correct.
+
+
+ The subset reveals errors and therefore the validity of
+ the entire set is called into question. Even the
+ resolution of all errors that were found may be
+ insufficient to provide the evaluator the necessary
+ confidence and as a result the evaluator may have to
+ increase the size of the subset, or stop using sampling
+ for this particular evidence.
+
+
+
+ Sampling is a technique which can be used to reach a reliable
+ conclusion if a set of evidence is relatively homogeneous in
+ nature, e.g. if the evidence has been produced during a well
+ defined process.
+
+ Sampling in the cases identified in the CC, and in cases
+ specifically covered in CEM work items, is recognised as a
+ cost-effective approach to performing evaluator
+ actions. Sampling in other areas is permitted only in
+ exceptional cases, where performance of a particular activity
+ in its entirety would require effort disproportionate to the
+ other evaluation activities, and where this would not add
+ correspondingly to assurance. In such cases a rationale for
+ the use of sampling in that area will need to be made. Neither
+ the fact that the TOE is large and complex, nor that it has
+ many security functional requirements, is sufficient
+ justification, since evaluations of large, complex TOEs can be
+ expected to require more effort. Rather it is intended that
+ this exception be limited to cases such as that where the TOE
+ development approach yields large quantities of material for a
+ particular CC requirement that would normally all need to be
+ checked or examined, and where such an action would not be
+ expected to raise assurance correspondingly.
+
+ Sampling needs to be justified taking into account the
+ possible impact on the security objectives and threats of the
+ TOE. The impact depends on what might be missed as a result of
+ sampling. Consideration also needs to be given to the nature
+ of the evidence to be sampled, and the requirement not to
+ diminish or ignore any security functions.
+
+ It should be recognised that sampling of evidence directly
+ related to the implementation of the TOE (e.g. developer test
+ results) requires a different approach to sampling, then
+ sampling related to the determination of whether a process is
+ being followed. In many cases the evaluator is required to
+ determine that a process is being followed, and a sampling
+ strategy is recommended. The approach for sampling a
+ developer's test results will differ. This is because the
+ former case is concerned with ensuring that a process is in
+ place, and the latter deals with determining correct
+ implementation of the TOE. Typically, larger sample sizes
+ should be analysed in cases related to the correct
+ implementation of the TOE than would be necessary to ensure
+ that a process is in place.
+
+ In certain cases it may be appropriate for the evaluator to
+ give greater emphasis to the repetition of developer
+ testing. For example if the independent tests left for the
+ evaluator to perform would be only superficially different
+ from those included in an extensive developer test set
+ (possibly because the developer has performed more testing
+ than necessary to satisfy the
+ and criteria) then it would
+ be appropriate for the evaluator to give greater focus to the
+ repetition of developer tests. Note that this does not
+ necessarily imply a requirement for a high percentage sample
+ for repetition of developer tests; indeed, given an extensive
+ developer test set, the evaluator may be able to justify a low
+ percentage sample.
+
+ Where the developer has used an automated test suite to
+ perform functional testing, it will usually be easier for the
+ evaluator to re-run the entire test suite rather than repeat
+ only a sample of developer tests. However the evaluator does
+ have an obligation to check that the automatic testing does
+ not give misrepresentative results. The implication is thus
+ that this check must be performed for a sample of the
+ automatic test suite, with the principles for selecting some
+ tests in preference to others and ensuring a sufficient sample
+ size applying equally in this case.
+
+ The following principles should be followed whenever sampling
+ is performed:
+
+
+ Sampling should not be random, rather it should be chosen
+ such that it is representative of all of the evidence. The
+ sample size and composition must always be justified.
+
+
+ When sampling relates to the correct implementation of the
+ TOE, the sample should be representative of all aspects
+ relevant to the areas that are sampled. In particular, the
+ selection should cover a variety of components,
+ interfaces, developer and operational sites (if more than
+ one is involved) and hardware platform types (if more than
+ one is involved). The sample size should be commensurate
+ with the cost effectiveness of the evaluation and will
+ depend on a number of TOE dependent factors (e.g. the size
+ and complexity of the TOE, the amount of documentation).
+
+
+ Also, when sampling relates to specifically gaining
+ evidence that the developer testing is repeatable and
+ reproducible the sample used must be sufficient to
+ represent all distinct aspects of developer testing, such
+ as different test regimes. The sample used must be
+ sufficient to detect any systematic problem in the
+ developer's functional testing process. The evaluator
+ contribution resulting from the combination of repeating
+ developer tests and performing independent tests must be
+ sufficient to address the major points of concern for the
+ TOE.
+
+
+ Where sampling relates to gaining evidence that a process
+ (e.g. visitor control or design review) the evaluator
+ should sample sufficient information to gain reasonable
+ confidence that the procedure is being followed.
+
+
+ The sponsor and developer should not be informed in
+ advance of the exact composition of the sample, subject to
+ ensuring timely delivery of the sample and supporting
+ deliverable, e.g. test harnesses and equipment to the
+ evaluator in accordance with the evaluation schedule.
+
+
+ The choice of the sample should be free from bias to the
+ degree possible (one should not always choose the first or
+ last item). Ideally the sample selection should be done by
+ someone other than the evaluator.
+
+
+
+ Errors found in the sample can be categorised as being either
+ systematic or sporadic. If the error is systematic, the
+ problem should be corrected and a complete new sample
+ taken. If properly explained, sporadic errors might be solved
+ without the need for a new sample, although the explanation
+ should be confirmed. The evaluator should use judgement in
+ determining whether to increase the sample size or use a
+ different sample.
+
+
+
+ In general it is possible to perform the required evaluation
+ activities, sub-activities, and actions in any order or in
+ parallel. However, there are different kinds of dependencies
+ which have to be considered by the evaluator. This Subclause
+ provides general guidance on dependencies between different
+ activities, sub-activities, and actions.
+
+
+ For some cases the different assurance classes may recommend
+ or even require a sequence for the related activities. A
+ specific instance is the ST activity. The ST evaluation
+ activity is started prior to any TOE evaluation activities
+ since the ST provides the basis and context to perform
+ them. However, a final verdict on the ST evaluation may not
+ be possible until the TOE evaluation is complete, since
+ changes to the ST may result from activity findings during
+ the TOE evaluation.
+
+
+
+ Dependencies identified between components in CC Part 3 have
+ to be considered by the evaluator. Most dependencies are
+ one way, e.g. claims a
+ dependency on and . There are also instances of
+ mutual dependencies, where both components depend on each
+ other. An example of this is and .
+
+ A sub-activity can be assigned a pass verdict normally only
+ if all those sub-activities are successfully completed on
+ which it has a one-way dependency. For example, a pass
+ verdict on can normally
+ only be assigned if the sub-activities related to and are assigned a pass verdict too. In the case
+ of mutual dependency the ordering of these components is
+ down to the evaluator deciding which sub-activity to perform
+ first. Note this indicates that pass verdicts can normally
+ only be assigned once both sub-activities have been
+ successful.
+
+ So when determining whether a sub-activity will impact
+ another sub-activity, the evaluator should consider whether
+ this activity depends on potential evaluation results from
+ any dependent sub-activities. Indeed, it may be the case
+ that a dependent sub-activity will impact this sub-activity,
+ requiring previously completed evaluator actions to be
+ performed again.
+
+ A significant dependency effect occurs in the case of
+ evaluator-detected flaws. If a flaw is identified as a
+ result of conducting one sub-activity, the assignment of a
+ pass verdict to a dependent sub-activity may not be possible
+ until all flaws related to the sub-activity upon which it
+ depends are resolved.
+
+
+
+ It may be the case, that results which are generated by the
+ evaluator during one action are used for performing another
+ action. For example, actions for completeness and
+ consistency cannot be completed until the checks for content
+ and presentation have been completed. This means for example
+ that the evaluator is recommended to evaluate the PP/ST
+ rationale after evaluating the constituent parts of the
+ PP/ST.
+
+
+
+
+
+ The assurance class includes
+ requirements for
+
+
+ the application of configuration management, ensuring
+ that the integrity of the TOE is preserved;
+
+
+ measures, procedures, and standards concerned with
+ secure delivery of the TOE, ensuring that the security
+ protection offered by the TOE is not compromised during
+ the transfer to the user,
+
+
+ security measures, used to protect the development
+ environment.
+
+
+
+ A development site visit is a useful means whereby the
+ evaluator determines whether procedures are being followed
+ in a manner consistent with that described in the
+ documentation.
+
+ Reasons for visiting sites include:
+
+
+ to observe the use of the CM system as described in the
+ CM plan;
+
+
+ to observe the practical application of delivery
+ procedures as described in the delivery documentation;
+
+
+ to observe the application of security measures during
+ development and maintenance of the TOE as described in
+ the development security documentation.
+
+
+
+ Specific and detailed information is given in work units for
+ those activities where site visits are performed:
+
+
+ .n with n>=3
+ (especially work unit = = );
+
+
+ (especially work unit
+ );
+
+
+ (especially work unit
+ = ).
+
+
+
+
+
+ During an evaluation it is often necessary that the
+ evaluator will meet the developer more than once and it is a
+ question of good planning to combine the site visit with
+ another meeting to reduce costs. For example one might
+ combine the site visits for configuration management, for
+ the developer's security and for delivery. It may also be
+ necessary to perform more than one site visit to the same
+ site to allow the checking of all development phases. It
+ should be considered that development could occur at
+ multiple facilities within a single building, multiple
+ buildings at the same site, or at multiple sites.
+
+ The first site visit should be scheduled early during the
+ evaluation. In the case of an evaluation which starts during
+ the development phase of the TOE, this will allow corrective
+ actions to be taken, if necessary. In the case of an
+ evaluation which starts after the development of the TOE, an
+ early site visit could allow corrective measures to be put
+ in place if serious deficiencies in the applied procedures
+ emerge. This avoids unnecessary evaluation effort.
+
+ Interviews are also a useful means of determining whether the
+ written procedures reflect what is done. In conducting such
+ interviews, the evaluator aims to gain a deeper understanding of
+ the analysed procedures at the development site, how they are
+ used in practise and whether they are being applied as described
+ in the provided evaluation evidence. Such interviews complement
+ but do not replace the examination of evaluation
+ evidence.
+
+ As a first step preparing the site visits the evaluators
+ should perform the evaluator work units concerning the
+ assurance class excluding the
+ aspects describing the results of the site visit. Based on
+ the information provided by the relevant developer
+ documentation and the remaining open questions which were
+ not answered by the documentation the evaluators compile a
+ check list of the questions which are to be resolved by the
+ site visits.
+
+ The first version of the evaluation report concerning the
+ class and the check list serves
+ as input for the consultation with the evaluation authority
+ concerning the site visits.
+
+ The check list serve as a guide line for the site visits,
+ which questions are to be answered by inspection of the
+ relevant measures, their application and results, and by
+ interviews. Where appropriate, sampling is used for gaining
+ the required level of confidence (see Subclause ).
+
+ The results of the site visits are recorded and serve as
+ input for the final version of the evaluation report
+ concerning the assurance class .
+
+ Other approaches to gain confidence should be considered
+ that provide an equivalent level of assurance (e.g. to
+ analyse evaluation evidence). Any decision not to make a
+ visit should be determined in consultation with the
+ evaluation authority. Appropriate security criteria and a
+ methodology should be based on other standards of the
+ Information Security Management Systems area.
+
+
+
+ In the following some keywords are provided, which topics
+ should be checked during an audit.
+
+ Basic
+
+
+ Items of the configuration list, including TOE, source
+ code, run time libraries, design documentation,
+ development tools ().
+
+
+ Tracking of design documentation, source code, user
+ guidance to different versions of the TOE.
+
+
+ Integration of the configuration system in the design
+ and development process, test planning, test analysis
+ and quality management procedures.
+
+
+
+ Test analysis
+
+
+ Tracking of test plans and results to specific
+ configurations and versions of the TOE.
+
+
+
+ Access control to development systems
+
+
+ Policies for access control and logging.
+
+
+ Policies for project specific assignment and changing
+ of access rights.
+
+
+
+ Clearance
+
+
+ Policies for clearance of the TOE and user guidance to
+ the customer.
+
+
+ Policies for testing and approving of components and
+ the TOE before deployment.
+
+
+
+
+
+ Infrastructure
+
+
+ Security measures for physical access control to the
+ development site and rationale for the effectiveness
+ of these measures.
+
+
+
+ Organisational measures
+
+
+ Organisational structure of the company in respect of
+ the security of the development environment.
+
+
+ Organisational separation between development,
+ production, testing and quality assurance.
+
+
+
+ Personal measures
+
+
+ Measures for education of the personnel in respect of
+ development security.
+
+
+ Measures and legal agreements of non disclosure of
+ internal information.
+
+
+
+ Access control
+
+
+ Assignment of secured objects (for instance TOE,
+ source code, run time libraries, design documentation,
+ development tools, user guidance) and security
+ policies.
+
+
+ Policies and responsibilities concerning the access
+ control and the handling of authentication
+ information.
+
+
+ Policies for logging of any kind access to the
+ development site and protection of the logging data.
+
+
+
+ Input, processing and output of data
+
+
+ Security measures for protection of output and output
+ devices (printer, plotter and displays).
+
+
+ Securing of local networks and communication
+ connections.
+
+
+
+ Storage, transfer and destruction of documents and data
+ media.
+
+
+ Policies for handling of documents and data media.
+
+
+ Policies and responsibilities for destruction of
+ sorted out documents and logging of these events.
+
+
+
+ Data protection
+
+
+ Policies and responsibilities for data and information
+ protection (e.g. for performing backups).
+
+
+
+ Contingency plan
+
+
+ Practises in case of emergency and responsibilities.
+
+
+ Documentation of the contingency measures concerning
+ access control.
+
+
+ Information of the personnel about applicable
+ practises in extreme cases. protection (e.g. for
+ performing backups).
+
+
+
+
+
+
+ The examples of checklists for site visits consist in tables
+ for the preparation of an audit and for the presentation of
+ the results of an audit.
+
+ The checklist structure given in the following is
+ preliminary. Dependent on the concrete contents of the new
+ guideline, changes might become necessary.
+ The checklist is divided into three subclauses according
+ to the subjects indicated in the introduction (Subclause ).
+
+
+ Configuration management system.
+
+
+ Delivery procedures.
+
+
+ Security measures during development.
+
+
+ These subclauses correspond to the actual CC class , especially the families .n with n>=3, and .
+ The subclauses are subdivided further into rows
+ corresponding to the relevant work units of the CEM.
+
+ The columns of the checklist contain in turn
+
+
+ a consecutive number,
+
+
+ the referenced work unit,
+
+
+ the references to the corresponding developer
+ documentation,
+
+
+ the explicit reproduction of the developer measures,
+
+
+ special remarks and questions to be clarified on the
+ visit (beyond the standard evaluator task to verify the
+ application of the indicated measures),
+
+
+ the result of the examinations during the visit.
+
+
+ If it is decided to have separate checklists for
+ preparation and reporting of the audit, the result column is
+ omitted in the preparation list and the remarks and
+ questions column is omitted in the reporting list. The
+ remaining columns should be identical in both lists.
+
+
+ Example of a checklist at EAL 4 (extract)
+
+
+
+
+
+ A. Examination of the CM system ( and )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ A.1
+
+
+ ,
+
+
+
+ ``Configuration Management System'', ch. ...
+
+
+ The system automatically managing the source code
+ files is capable of administering user profiles and
+ graded access rights, and of checking identification
+ and authentication of users.
+
+
+ Does reading or updating of a source code file
+ require a user authentication?
+
+
+ If a user has not the right to access a confidential
+ document, it is not even displayed to him in the
+ file list.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ B. Examination of the Delivery Procedures ()
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ B.1
+
+
+ ,
+
+
+
+ ``Delivery of the TOE'', ch. ...
+
+
+ The software is transmitted PGP-signed and encrypted
+ to the customer.
+
+
+ ---
+
+
+ The evaluators have checked the process and found it
+ as described, additionally a checksum is
+ transmitted.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+ C. Examination of the organisational and
+ infrastructural developer security
+ (,
+ ,
+ )
+
+
+
+
+ No.
+
+
+ Work Unit
+
+
+ Developer Documentation
+
+
+ Measures
+
+
+ Questions and Remarks
+
+
+ Result
+
+
+
+
+
+
+ C.1
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Premises)
+
+
+ The premises are protected by security fencing.
+
+
+ Is the fencing sufficiently strong and high to
+ prevent an easy intrusion into the premises?
+
+
+ The evaluators considered the fencing to be
+ sufficiently strong and high.
+
+
+
+
+ C.2
+
+
+ ,
+
+
+
+ ``Security of the development environment'',
+ ch. ... (Building)
+
+
+ The building has the following access possibilities:
+ The main entrance which is surveyed by the reception
+ and is closed if the reception is not manned. And an
+ access in the goods reception which is secured by
+ two roller shutters.
+
+
+ Is the listing of the access possibilities complete?
+
+
+ Beyond the indicated access possibilities, there is
+ an emergency exit that cannot be opened from the
+ outside. The roller shutters mentioned before can be
+ operated only from inside.
+
+
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+ ...
+
+
+
+
+
+
+
+
+
+ This CEM describes the minimum technical work that evaluations
+ conducted under oversight (scheme) bodies must
+ perform. However, it also recognises (both explicitly and
+ implicitly) that there are activities or methods upon which
+ mutual recognition of evaluation results do not rely. For the
+ purposes of thoroughness and clarity, and to better delineate
+ where the CEM ends and an individual scheme's methodology
+ begins, the following matters are left up to the discretion of
+ the schemes. Schemes may choose to provide the following,
+ although they may choose to leave some unspecified. (Every
+ effort has been made to ensure this list is complete;
+ evaluators encountering a subject neither listed here nor
+ addressed in the CEM should consult with their evaluation
+ schemes to determine under whose auspices the subject
+ falls.)
+
+ The matters that schemes may choose to specify include:
+
+
+ what is required in ensuring that an evaluation was done
+ sufficiently - every scheme has a means of verifying the
+ technical competence, understanding of work and the work
+ of its evaluators, whether by requiring the evaluators to
+ present their findings to the oversight body, by requiring
+ the oversight body to redo the evaluator's work, or by
+ some other means that assures the scheme that all
+ evaluation bodies are adequate and comparable;
+
+
+ process for disposing of evaluation evidence upon
+ completion of an evaluation;
+
+
+ any requirements for confidentiality (on the part of the
+ evaluator and the non-disclosure of information obtained
+ during evaluation);
+
+
+ the course of action to be taken if a problem is
+ encountered during the evaluation (whether the evaluation
+ continues once the problem is remedied, or the evaluation
+ ends immediately and the remedied product must be
+ re-submitted for evaluation);
+
+
+ any specific (natural) language in which documentation
+ must be provided;
+
+
+ any recorded evidence that must be submitted in the ETR -
+ this CEM specifies the minimum to be reported in an ETR;
+ however, individual schemes may require additional
+ information to be included;
+
+
+ any additional reports (other than the ETR) required from
+ the evaluators -for example, testing reports;
+
+
+ any specific ORs that may be required by the scheme,
+ including the structure, recipients, etc. of any such ORs;
+
+
+ any specific content structure of any written report as a
+ result from an ST evaluation - a scheme may have a
+ specific format for all of its reports detailing results
+ of an evaluation, be it the evaluation of a TOE or of an
+ ST;
+
+
+ any additional PP/ST identification information required;
+
+
+ any activities to determine the suitability of
+ explicitly-stated requirements in an ST;
+
+
+ any requirements for provision of evaluator evidence to
+ support re-evaluation and re-use of evidence;
+
+
+ any specific handling of scheme identifiers, logos,
+ trademarks, etc.;
+
+
+ any specific guidance in dealing with cryptography;
+
+
+ handling and application of scheme, national and
+ international interpretations;
+
+
+ a list or characterisations of suitable alternative
+ approaches to testing where testing is infeasible;
+
+
+ the mechanism by which an evaluation authority can determine what
+ steps an evaluator took while testing;
+
+
+ preferred test approach (if any): at internal interface or
+ at external interface;
+
+
+ a list or characterisation of acceptable means of
+ conducting the evaluator's vulnerability analysis
+ (e.g. flaw hypothesis methodology);
+
+
+ information regarding any vulnerabilities and weaknesses
+ to be considered.
+
+
+
+
+
+
+
+ The following annexes through provide the application notes for the functional
+ classes defined in the main body of this part of the CC.
+
+
+ For the purposes of this document, the terms, definitions,
+ symbols and abbreviated terms given in CC Part 1 apply.
+
+
+ Security functional components, as defined in this CC Part 2, are
+ the basis for the security functional requirements expressed in a
+ Protection Profile (PP) or a Security Target (ST). These
+ requirements describe the desired security behaviour expected of a
+ Target of Evaluation (TOE) and are intended to meet the security
+ objectives as stated in a PP or an ST. These requirements describe
+ security properties that users can detect by direct interaction
+ (i.e. inputs, outputs) with the IT or by the IT response to
+ stimulus.
+
+ Security functional components express security requirements
+ intended to counter threats in the assumed operating environment
+ of the TOE and/or cover any identified organisational security
+ policies and assumptions.
+
+ The audience for this CC Part 2 includes consumers, developers,
+ and evaluators of secure IT products. CC Part 1
+ Chapter provides additional
+ information on the target audience of the CC, and on the use of
+ the CC by the groups that comprise the target audience. These
+ groups may use this part of the CC as follows:
+
+
+ Consumers, who use this CC Part 2 when selecting components to
+ express functional requirements to satisfy the security
+ objectives expressed in a PP or ST. CC Part 1 Section provides more detailed
+ information on the relationship between security objectives
+ and security requirements.
+
+
+ Developers, who respond to actual or perceived consumer
+ security requirements in constructing a TOE, may find a
+ standardised method to understand those requirements in this
+ part of the CC. They can also use the contents of this part of
+ the CC as a basis for further defining the TOE security
+ functionality and mechanisms that comply with those
+ requirements.
+
+
+ Evaluators, who use the functional requirements defined in
+ this part of the CC in verifying that the TOE functional
+ requirements expressed in the PP or ST satisfy the IT security
+ objectives and that all dependencies are accounted for and
+ shown to be satisfied. Evaluators also should use this part of
+ the CC to assist in determining whether a given TOE satisfies
+ stated requirements.
+
+
+
+
+
+ The CC and the associated security functional requirements
+ described herein are not meant to be a definitive answer to all
+ the problems of IT security. Rather, the CC offers a set of well
+ understood security functional requirements that can be used to
+ create trusted products reflecting the needs of the market. These
+ security functional requirements are presented as the current
+ state of the art in requirements specification and
+ evaluation.
+
+ This part of the CC does not presume to include all possible
+ security functional requirements but rather contains those that
+ are known and agreed to be of value by the CC Part 2 authors at
+ the time of release.
+
+ Since the understanding and needs of consumers may change, the
+ functional requirements in this part of the CC will need to be
+ maintained. It is envisioned that some PP/ST authors may have
+ security needs not (yet) covered by the functional requirement
+ components in CC Part 2. In those cases the PP/ST author may
+ choose to consider using functional requirements not taken from
+ the CC (referred to as extensibility), as explained in annexes
+ and
+ of
+ CC Part 1.
+
+
+
+ Clause
+ describes the paradigm used in the security functional
+ requirements of CC Part 2.
+
+ Clause
+ introduces the catalogue of CC Part 2 functional components
+ while clauses through describe the functional classes.
+
+ provides explanatory information for potential
+ users of the functional components including a complete cross
+ reference table of the functional component dependencies.
+
+ through provide the explanatory information for the
+ functional classes. This material must be seen as normative
+ instructions on how to apply relevant operations and select
+ appropriate audit or documentation information; the use of the
+ auxiliary verb should means that the instruction is strongly
+ preferred, but others may be justifiable. Where different
+ options are given, the choice is left to the PP/ST
+ author.
+
+ Those who author PPs or STs should refer to clause 2 of CC Part
+ 1 for relevant structures, rules, and guidance:
+
+
+ CC Part 1, clause
+ defines the terms used in the CC.
+
+
+ CC Part 1, annex defines the
+ structure for STs.
+
+
+ CC Part 1, annex defines the
+ structure for PPs.
+
+
+
+
+
+ The following referenced documents are indispensable for the
+ application of this document. For dated references, only the
+ edition cited applies. For undated references, the latest edition
+ of the referenced document (including any amendments) applies.CC
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 1: Introduction and general model.
+
+
+ This part of the CC defines the required structure and content
+ of security functional components for the purpose of security
+ evaluation. It includes a catalogue of functional components
+ that will meet the common security functionality requirements
+ of many IT products.
+
+
+ This chapter describes the paradigm used in the security
+ functional requirements of this part of the CC. Key concepts
+ discussed are highlighted in bold/italics. This section is not
+ intended to replace or supersede any of the terms found in CC Part
+ 1, chapter .
+
+ This part of the CC is a catalogue of security functional
+ components that can be specified for a Target of
+ Evaluation (TOE). A TOE is a set of software, firmware
+ and/or hardware possibly accompanied by user and administrator
+ guidance documentation. A TOE may contain resources such as
+ electronic storage media (e.g. main memory, disk space),
+ peripheral devices (e.g. printers), and computing capacity (e.g.
+ CPU time) that can be used for processing and storing
+ information and is the subject of an evaluation.
+
+ TOE evaluation is concerned primarily with ensuring that a defined
+ set of security functional requirements (SFRs) is
+ enforced over the TOE resources. The SFRs define the rules by
+ which the TOE governs access to and use of its resources, and thus
+ information and services controlled by the TOE.
+
+ The SFRs may define multiple Security Function Policies
+ (SFPs) to represent the rules that the TOE must enforce. Each such SFP
+ must specify its scope of control, by defining the subjects,
+ objects, resources or information, and operations to which it applies. All
+ SFPs are implemented by the TSF (see below), whose mechanisms enforce the
+ rules defined in the SFRs and provide necessary capabilities.
+
+ Those portions of a TOE that must be relied on for the correct
+ enforcement of the SFRs are collectively referred to as the
+ TOE Security Functionality (TSF). The TSF consists of
+ all hardware, software, and firmware of a TOE that is either
+ directly or indirectly relied upon for security enforcement.
+
+ The TOE may be a monolithic product containing hardware, firmware,
+ and software.
+
+ Alternatively a TOE may be a distributed product that consists
+ internally of multiple separated parts. Each of these parts of the
+ TOE provides a particular service for the TOE, and is connected to
+ the other parts of the TOE through an internal communication
+ channel. This channel can be as small as a processor bus,
+ or may encompass a network internal to the TOE.
+
+ When the TOE consists of multiple parts, each part of the TOE may
+ have its own part of the TSF which exchanges user and TSF data
+ over internal communication channels with other parts of the
+ TSF. This interaction is called internal TOE
+ transfer. In this case the separate parts of the TSF
+ abstractly form the composite TSF, which enforces the SFRs.
+
+ TOE interfaces may be localised to the particular TOE, or they may
+ allow interaction with other IT products over external
+ communication channels. These external interactions with
+ other IT products may take two forms:
+
+
+ The SFRs of the other ``trusted IT product'' and the SFRs of
+ the TOE have been administratively coordinated and the other
+ trusted IT product is assumed to enforce its SFRs correctly
+ (e. g. by being separately evaluated). Exchanges of
+ information in this situation are called inter-TSF
+ transfers, as they are between the TSFs of distinct
+ trusted products.
+
+
+ The other IT product may not be trusted, it may be called an
+ ``untrusted IT product''. Therefore its SFRs are either
+ unknown or their implementation is not viewed as
+ trustworthy. TSF mediated exchanges of information in this
+ situation are called transfers outside of the
+ TOE, as there is no TSF (or its policy characteristics
+ are unknown) on the other IT product.
+
+
+ The set of interfaces, whether interactive (man-machine
+ interface) or programmatic (application programming interface),
+ through which resources are accessed that are mediated by the TSF,
+ or information is obtained from the TSF, is referred to as the
+ TSF Interface (TSFI). The TSFI defines the boundaries
+ of the TOE functionality that provide for the enforcement of the
+ SFRs.
+
+ Users are outside of the TOE. However, in order to request that
+ services be performed by the TOE that are subject to rules
+ defined in the SFRs, users interact with the TOE through the
+ TSFIs. There are two types of users of interest to CC Part 2:
+ human users and external IT
+ entities. Human users may further be differentiated as
+ local human users, meaning they interact directly
+ with the TOE via TOE devices (e.g. workstations), or
+ remote human users, meaning they interact
+ indirectly with the TOE through another IT product.
+
+ A period of interaction between users and the TSF is referred to
+ as a user session. Establishment of user sessions can
+ be controlled based on a variety of considerations, for example:
+ user authentication, time of day, method of accessing the TOE, and
+ number of allowed concurrent sessions (per user or in total).
+
+ This part of the CC uses the term authorised to
+ signify a user who possesses the rights and/or privileges
+ necessary to perform an operation. The term authorised
+ user, therefore, indicates that it is allowable for a user
+ to perform a specific operation or a set of operations as defined
+ by the SFRs.
+
+ To express requirements that call for the separation of
+ administrator duties, the relevant security functional
+ components (from family )
+ explicitly state that administrative roles are
+ required. A role is a pre-defined set of rules establishing the
+ allowed interactions between a user operating in that role and
+ the TOE. A TOE may support the definition of any number of
+ roles. For example, roles related to the secure operation of a
+ TOE may include ``Audit Administrator'' and ``User Accounts
+ Administrator''.
+
+ TOEs contain resources that may be used for the
+ processing and storing of information. The primary goal of the TSF
+ is the complete and correct enforcement of the SFRs over the
+ resources and information that the TOE controls.
+
+ TOE resources can be structured and utilised in many different
+ ways. However, CC Part 2 makes a specific distinction that allows
+ for the specification of desired security properties. All entities
+ that can be created from resources can be characterised in one of
+ two ways. The entities may be active, meaning that they are the
+ cause of actions that occur internal to the TOE and cause
+ operations to be performed on information. Alternatively, the
+ entities may be passive, meaning that they are either the
+ container from which information originates or to which
+ information is stored.
+
+ Active entities in the TOE that perform operations on objects are
+ referred to as subjects. Several types of subjects
+ may exist within a TOE:
+
+
+ those acting on behalf of an authorised user (e.g. UNIX
+ processes);
+
+
+ those acting as a specific functional process that may in turn
+ act on behalf of multiple users (e.g. functions as might be
+ found in client/server architectures); or
+
+
+ those acting as part of the TOE itself (e.g. processes not
+ acting on behalf of a user).
+
+
+
+ CC Part 2 addresses the enforcement of the SFRs over types of
+ subjects as those listed above.
+
+ Passive entities in the TOE that contain or receive information
+ and upon which subjects perform operations are called
+ objects. In the case where a subject (an active
+ entity) is the target of an operation (e.g. interprocess
+ communication), a subject may also be acted on as an object.
+
+ Objects can contain information. This concept is
+ required to specify information flow control policies as addressed
+ in the FDP class.
+
+ Users, subjects, information, objects, sessions and resources
+ controlled by rules in the SFRs may possess certain
+ attributes that contain information that is used by
+ the TOE for its correct operation. Some attributes, such as file
+ names, may be intended to be informational or may be used to
+ identify individual resources while others, such as access control
+ information, may exist specifically for the enforcement of the
+ SFRs. These latter attributes are generally referred to as
+ ``security attributes''. The word attribute will be
+ used as a shorthand in some places of this part of the CC for the
+ word ``security attribute''. However, no matter what the intended
+ purpose of the attribute information, it may be necessary to have
+ controls on attributes as dictated by the SFRs.
+
+ Data in a TOE is categorised as either user data or TSF
+ data. Figure depicts this
+ relationship. User Data is information stored in TOE
+ resources that can be operated upon by users in accordance with
+ the SFRs and upon which the TSF places no special meaning. For
+ example, the content of an electronic mail message is user
+ data. TSF Data is information used by the TSF in making decisions
+ as required by the SFRs. TSF Data may be influenced
+ by users if allowed by the SFRs. Security attributes,
+ authentication data, TSF internal status variables used by the
+ rules defined in the SFRs or used for the protection of the TSF
+ and access control list entries are examples of TSF data.
+
+ There are several SFPs that apply to data protection such as
+ access control SFPs and information flow
+ control SFPs. The mechanisms that implement access control
+ SFPs base their policy decisions on attributes of the users,
+ resources, subjects, objects, sessions, TSF status data and
+ operations within the scope of control. These attributes are used
+ in the set of rules that govern operations that subjects may
+ perform on objects.
+
+ The mechanisms that implement information flow control SFPs base
+ their policy decisions on the attributes of the subjects and
+ information within the scope of control and the set of rules that
+ govern the operations by subjects on information. The attributes
+ of the information, which may be associated with the attributes of
+ the container or may be derived from the data in the container,
+ stay with the information as it is processed by the TSF.
+
+
+ Two specific types of TSF data addressed by CC Part 2 can be, but
+ are not necessarily, the same. These are authentication
+ data and secrets.
+
+ Authentication data is used to verify the claimed identity of a
+ user requesting services from a TOE. The most common form of
+ authentication data is the password, which depends on being kept
+ secret in order to be an effective security mechanism. However,
+ not all forms of authentication data need to be kept
+ secret. Biometric authentication devices (e.g. fingerprint
+ readers, retinal scanners) do not rely on the fact that the data
+ is kept secret, but rather that the data is something that only
+ one user possesses and that cannot be forged.
+
+ The term secrets, as used in CC Part 2, while applicable to
+ authentication data, is intended to also be applicable to other
+ types of data that must be kept secret in order to enforce a
+ specific SFP. For example, a trusted channel mechanism that
+ relies on cryptography to preserve the confidentiality of
+ information being transmitted via the channel can only be as
+ strong as the method used to keep the cryptographic keys secret
+ from unauthorised disclosure.
+
+ Therefore, some, but not all, authentication data needs to be kept
+ secret and some, but not all, secrets are used as authentication
+ data. Figure shows this relationship
+ between secrets and authentication data. In the Figure the types
+ of data typically encountered in the authentication data and the
+ secrets sections are indicated.
+
+
+
+
+
+ This clause provides an overview of the evaluation process
+ and defines the tasks an evaluator is intended to perform when
+ conducting an evaluation.
+
+ Each evaluation, whether of a PP or TOE (including ST),
+ follows the same process, and has four evaluator tasks in
+ common: the input task, the output task, the evaluation
+ sub-activities, and the demonstration of the technical
+ competence to the evaluation authority task.
+
+ The input task and the output tasks, which are related to
+ management of evaluation evidence and to report generation,
+ are entirely described in this clause. Each task has
+ associated sub-tasks that apply to, and are normative for all
+ CC evaluations (evaluation of a PP or a TOE).
+
+ The evaluation sub-activities are only introduced in this
+ clause, and fully described in the following clauses.
+
+ In contrast to the evaluation sub-activities, input and output
+ tasks have no verdicts associated with them as they do not map
+ to CC evaluator action elements; they are performed in order
+ to ensure conformance with the universal principles and to
+ comply with the CEM.
+
+ The demonstration of the technical competence to the
+ evaluation authority task may be fulfilled by the evaluation
+ authority analysis of the output tasks results, or may include
+ the demonstration by the evaluators of their understanding of
+ the inputs for the evaluation sub-activities. This task has no
+ associated evaluator verdict, but has an evaluator authority
+ verdict. The detailed criteria to pass this task are left to
+ the discretion of the evaluation authority, as noted in Annex
+ .
+
+
+
+
+ This subclause presents the general model of the methodology
+ and identifies:
+
+
+ roles and responsibilities of the parties involved in
+ the evaluation process;
+
+
+ the general evaluation model.
+
+
+
+
+
+ The general model defines the following roles: sponsor,
+ developer, evaluator and evaluation authority.
+
+ The sponsor is responsible for requesting and supporting an
+ evaluation. This means that the sponsor establishes the
+ different agreements for the evaluation (e.g. commissioning
+ the evaluation). Moreover, the sponsor is responsible for
+ ensuring that the evaluator is provided with the evaluation
+ evidence.
+
+ The developer produces the TOE and is responsible for
+ providing the evidence required for the evaluation
+ (e.g. training, design information), on behalf of the
+ sponsor.
+
+ The evaluator performs the evaluation tasks required in the
+ context of an evaluation: the evaluator receives the
+ evaluation evidence from the developer on behalf of the
+ sponsor or directly from the sponsor, performs the
+ evaluation sub-activities and provides the results of the
+ evaluation assessment to the evaluation authority.
+
+ The evaluation authority establishes and maintains the
+ scheme, monitors the evaluation conducted by the evaluator,
+ and issues certification/validation reports as well as
+ certificates based on the evaluation results provided by the
+ evaluator.
+
+
+
+ To prevent undue influence from improperly affecting an
+ evaluation, some separation of roles is required. This
+ implies that the roles described above are fulfilled by
+ different entities, except that the roles of developer and
+ sponsor may be satisfied by a single entity.
+
+ Moreover, some evaluations (e.g. EAL1 evaluation) may not
+ require the developer to be involved in the project. In this
+ case, it is the sponsor who provides the TOE to the
+ evaluator and who generates the evaluation evidence.
+
+
+
+ The evaluation process consists of the evaluator performing
+ the evaluation input task, the evaluation output task and
+ the evaluation sub-activities. Figure provides an overview of
+ the relationship between these tasks and
+ sub-activities.
+
+
+ The evaluation process may be preceded by a preparation
+ phase where initial contact is made between the sponsor and
+ the evaluator. The work that is performed and the
+ involvement of the different roles during this phase may
+ vary. It is typically during this step that the evaluator
+ performs a feasibility analysis to assess the likelihood of
+ a successful evaluation.
+
+
+
+ The evaluator assigns verdicts to the requirements of the CC
+ and not to those of the CEM. The most granular CC structure
+ to which a verdict is assigned is the evaluator action
+ element (explicit or implied). A verdict is assigned to an
+ applicable CC evaluator action element as a result of
+ performing the corresponding CEM action and its constituent
+ work units. Finally, an evaluation result is assigned, as
+ described in CC Part 1, Clause .
+
+
+ The CEM recognises three mutually exclusive verdict states:
+
+
+ Conditions for a pass verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST or TOE under evaluation are met. The
+ conditions for passing the element are defined as:
+
+
+ the constituent work units of the related CEM
+ action, and;
+
+
+ all evaluation evidence required for performing
+ these work units is coherent, that is it can be
+ fully and completely understood by the evaluator,
+ and
+
+
+ all evaluation evidence required for performing
+ these work units does not have any obvious internal
+ inconsistencies or inconsistencies with other
+ evaluation evidence. Note that obvious means here
+ that the evaluator discovers this inconsistency
+ while performing the work units: the evaluator
+ should not undertake a full consistency analysis
+ across the entire evaluation evidence every time a
+ work unit is performed.
+
+
+
+
+ Conditions for a fail verdict are
+ defined as an evaluator completion of the CC evaluator
+ action element and determination that the requirements
+ for the PP, ST, or TOE under evaluation are not met, or
+ that the evidence is incoherent, or an obvious
+ inconsistency in the evaluation evidence has been found;
+
+
+ All verdicts are initially inconclusive
+ and remain so until either a pass or
+ fail verdict is assigned.
+
+
+
+ The overall verdict is pass if and only if
+ all the constituent verdicts are also
+ pass. In the example illustrated in Figure
+ , if the verdict for one
+ evaluator action element is fail then the
+ verdicts for the corresponding assurance component,
+ assurance class, and overall verdict are also
+ fail.
+
+
+
+
+
+ The objective of this task is to ensure that the evaluator
+ has available the correct version of the evaluation evidence
+ necessary for the evaluation and that it is adequately
+ protected. Otherwise, the technical accuracy of the
+ evaluation cannot be assured, nor can it be assured that the
+ evaluation is being conducted in a way to provide repeatable
+ and reproducible results.
+
+
+
+ The responsibility to provide all the required evaluation
+ evidence lies with the sponsor. However, most of the
+ evaluation evidence is likely to be produced and supplied by
+ the developer, on behalf of the sponsor.
+
+ Since the assurance requirements apply to the entire TOE,
+ all evaluation evidence pertaining to all parts of the TOE
+ is to be made available to the evaluator. The scope and
+ required content of such evaluation evidence is independent
+ of the level of control that the developer has over each of
+ the parts of the TOE. For example, if design is required,
+ then the requirements will
+ apply to all subsystems that are part of the TSF. In
+ addition, assurance requirements that call for procedures to
+ be in place (for example,
+ and ) will also apply to the
+ entire TOE (including any part produced by another
+ developer).
+
+ It is recommended that the evaluator, in conjunction with
+ the sponsor, produce an index to required evaluation
+ evidence. This index may be a set of references to the
+ documentation. This index should contain enough information
+ (e.g. a brief summary of each document, or at least an
+ explicit title, indication of the subclauses of interest) to
+ help the evaluator to find easily the required
+ evidence.
+
+ It is the information contained in the evaluation evidence
+ that is required, not any particular document
+ structure. Evaluation evidence for a sub-activity may be
+ provided by separate documents, or a single document may
+ satisfy several of the input requirements of a
+ sub-activity.
+
+ The evaluator requires stable and formally-issued versions
+ of evaluation evidence. However, draft evaluation evidence
+ may be provided during an evaluation, for example, to help
+ an evaluator make an early, informal assessment, but is not
+ used as the basis for verdicts. It may be helpful for the
+ evaluator to see draft versions of particular appropriate
+ evaluation evidence, such as:
+
+
+ test documentation, to allow the evaluator to make an
+ early assessment of tests and test procedures;
+
+
+ design documents, to provide the evaluator with
+ background for understanding the TOE design;
+
+
+ source code or hardware drawings, to allow the evaluator
+ to assess the application of the developer's standards.
+
+
+
+ Draft evaluation evidence is more likely to be encountered
+ where the evaluation of a TOE is performed concurrently with
+ its development. However, it may also be encountered during
+ the evaluation of an already-developed TOE where the
+ developer has had to perform additional work to address a
+ problem identified by the evaluator (e.g. to correct an
+ error in design or implementation) or to provide evaluation
+ evidence of security that is not provided in the existing
+ documentation (e.g. in the case of a TOE not originally
+ developed to meet the requirements of the CC).
+
+
+
+
+ The evaluator shall perform configuration control of the
+ evaluation evidence.
+
+ The CC implies that the evaluator is able to identify and
+ locate each item of evaluation evidence after it has been
+ received and is able to determine whether a specific
+ version of a document is in the evaluator's
+ possession.
+
+ The evaluator shall protect the evaluation evidence from
+ alteration or loss while it is in the evaluator's
+ possession.
+
+
+
+ Schemes may wish to control the disposal of evaluation
+ evidence at the conclusion of an evaluation. The disposal
+ of the evaluation evidence should be achieved by one or
+ more of:
+
+
+ returning the evaluation evidence;
+
+
+ archiving the evaluation evidence;
+
+
+ destroying the evaluation evidence.
+
+
+
+
+
+ An evaluator may have access to sponsor and developer
+ commercially-sensitive information (e.g. TOE design
+ information, specialist tools), and may have access to
+ nationally-sensitive information during the course of an
+ evaluation. Schemes may wish to impose requirements for
+ the evaluator to maintain the confidentiality of the
+ evaluation evidence. The sponsor and evaluator may
+ mutually agree to additional requirements as long as these
+ are consistent with the scheme.
+
+ Confidentiality requirements affect many aspects of
+ evaluation work, including the receipt, handling, storage
+ and disposal of evaluation evidence.
+
+
+
+
+
+ The evaluation sub-activities vary depending whether it is a
+ PP or a TOE evaluation. Moreover, in the case of a TOE
+ evaluation, the sub-activities depend upon the selected
+ assurance requirements.
+
+
+
+
+ The objective of this Subclause is to describe the Observation
+ Report (OR) and the Evaluation Technical Report
+ (ETR). Schemes may require additional evaluator reports such
+ as reports on individual units of work, or may require
+ additional information to be contained in the OR and the
+ ETR. The CEM does not preclude the addition of information
+ into these reports as the CEM specifies only the minimum
+ information content.
+
+ Consistent reporting of evaluation results facilitates the
+ achievement of the universal principle of repeatability and
+ reproducibility of results. The consistency covers the type and
+ the amount of information reported in the ETR and OR. ETR and OR
+ consistency among different evaluations is the responsibility of
+ the evaluation authority.
+
+ The evaluator performs the two following sub-tasks in order
+ to achieve the CEM requirements for the information content
+ of reports:
+
+
+ write OR sub-task (if needed in the context of the
+ evaluation);
+
+
+ write ETR sub-task.
+
+
+
+
+
+ The evaluator delivers the ETR to the evaluation authority,
+ as well as any ORs as they become available. Requirements
+ for controls on handling the ETR and ORs are established by
+ the scheme which may include delivery to the sponsor or
+ developer. The ETR and ORs may include sensitive or
+ proprietary information and may need to be sanitised before
+ they are given to the sponsor.
+
+
+
+ In this version of the CEM, the requirements for the
+ provision of evaluator evidence to support re-evaluation and
+ re-use have not been explicitly stated. Where information
+ for re-evaluation or re-use is required by the sponsor, the
+ scheme under which the evaluation is being performed should
+ be consulted.
+
+
+
+ ORs provide the evaluator with a mechanism to request a
+ clarification (e.g. from the evaluation authority on the application of a
+ requirement) or to identify a problem with an aspect of the
+ evaluation.
+
+ In the case of a fail verdict, the evaluator shall provide
+ an OR to reflect the evaluation result. Otherwise, the
+ evaluator may use ORs as one way of expressing clarification
+ needs.
+
+ For each OR, the evaluator shall report the following:
+
+
+ the identifier of the PP or TOE evaluated;
+
+
+ the evaluation task/sub-activity during which the
+ observation was generated;
+
+
+ the observation;
+
+
+ the assessment of its severity (e.g. implies a fail
+ verdict, holds up progress on the evaluation, requires a
+ resolution prior to evaluation being completed);
+
+
+ the identification of the organisation responsible for
+ resolving the issue;
+
+
+ the recommended timetable for resolution;
+
+
+ the assessment of the impact on the evaluation of
+ failure to resolve the observation.
+
+
+
+ The intended audience of an OR and procedures for handling the
+ report depend on the nature of the report's content and on the
+ scheme. Schemes may distinguish different types of ORs or define
+ additional types, with associated differences in required
+ information and distribution (e.g. evaluation ORs to evaluation authorities
+ and sponsors).
+
+
+
+
+ The evaluator shall provide an ETR to present technical
+ justification of the verdicts.
+
+ The CEM defines the ETR's minimum content requirement;
+ however, schemes may specify additional content and
+ specific presentational and structural requirements. For
+ instance, schemes may require that certain introductory
+ material (e.g. disclaimers and copyright Clauses) be
+ reported in the ETR.
+
+ The reader of the ETR is assumed to be familiar with
+ general concepts of information security, the CC, the CEM,
+ evaluation approaches and IT.
+
+ The ETR supports the evaluation authority to confirm that
+ the evaluation was done to the required standard, but it
+ is anticipated that the documented results may not provide
+ all of the necessary information, so additional
+ information specifically requested by the scheme may be
+ necessary. This aspect is outside the scope of the
+ CEM.
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a PP evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report PP configuration control
+ identifiers.
+
+ PP configuration control identifiers (e.g. name, date and
+ version number) are required to identify what is being evaluated
+ in order for the evaluation authority to verify that the verdicts have been
+ assigned correctly by the evaluator.
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the PP developer is required to identify
+ the party responsible for producing the PP.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator references the evaluation criteria,
+ methodology and interpretations used to evaluate the
+ PP.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the handling of evaluation
+ results and assumptions made during the evaluation that
+ have an impact on the evaluation results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ The evaluator shall report a verdict and a supporting
+ rationale for each assurance component that constitutes
+ an activity, as a result of
+ performing the corresponding CEM action and its
+ constituent work units.
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, in particular the overall verdict as defined
+ in CC Part 1 Clause , and determined by application
+ of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be useful for
+ the evaluation authority. These recommendations may include shortcomings of
+ the PP discovered during the evaluation or mention of features
+ which are particularly useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+ This Subclause describes the minimum content of the ETR for
+ a TOE evaluation. The contents of the ETR are portrayed in
+ Figure ; this figure
+ may be used as a guide when constructing the structural
+ outline of the ETR document.
+
+
+
+ The evaluator shall report evaluation scheme
+ identifiers.
+
+ Evaluation scheme identifiers (e.g. logos) are the
+ information required to unambiguously identify the
+ scheme responsible for the evaluation oversight.
+
+ The evaluator shall report ETR configuration control
+ identifiers.
+
+ The ETR configuration control identifiers contain
+ information that identifies the ETR (e.g. name, date and
+ version number).
+
+ The evaluator shall report ST and TOE configuration
+ control identifiers.
+
+ ST and TOE configuration control identifiers identify
+ what is being evaluated in order for the evaluation authority to
+ verify that the verdicts have been assigned correctly by
+ the evaluator.
+
+ If the ST claims that the TOE conforms to the
+ requirements of one or more PPs, the ETR shall report
+ the reference of the corresponding PPs.
+
+ The PPs reference contains information that uniquely
+ identifies the PPs (e.g. title, date, and version
+ number).
+
+ The evaluator shall report the identity of the
+ developer.
+
+ The identity of the TOE developer is required to
+ identify the party responsible for producing the
+ TOE.
+
+ The evaluator shall report the identity of the
+ sponsor.
+
+ The identity of the sponsor is required to identify the
+ party responsible for providing evaluation evidence to
+ the evaluator.
+
+ The evaluator shall report the identity of the
+ evaluator.
+
+ The identity of the evaluator is required to identify
+ the party performing the evaluation and responsible for
+ the evaluation verdicts.
+
+
+
+ The evaluator shall report a high level description of
+ the TOE and its major components based on the evaluation
+ evidence described in the CC assurance family entitled
+ , where
+ applicable.
+
+ The intent of this Subclause is to characterise the degree
+ of architectural separation of the major components. If
+ there is no requirement
+ in the ST, this is not applicable and is considered to
+ be satisfied.
+
+
+
+ The evaluator shall report the evaluation methods,
+ techniques, tools and standards used.
+
+ The evaluator may reference the evaluation criteria,
+ methodology and interpretations used to evaluate the TOE
+ or the devices used to perform the tests.
+
+ The evaluator shall report any constraints on the
+ evaluation, constraints on the distribution of
+ evaluation results and assumptions made during the
+ evaluation that have an impact on the evaluation
+ results.
+
+ The evaluator may include information in relation to
+ legal or statutory aspects, organisation,
+ confidentiality, etc.
+
+
+
+ For each activity on which the TOE is evaluated, the
+ evaluator shall report:
+
+
+ the title of the activity considered;
+
+
+ a verdict and a supporting rationale for each
+ assurance component that constitutes this activity,
+ as a result of performing the corresponding CEM
+ action and its constituent work units.
+
+
+
+ The rationale justifies the verdict using the CC, the
+ CEM, any interpretations and the evaluation evidence
+ examined and shows how the evaluation evidence does or
+ does not meet each aspect of the criteria. It contains a
+ description of the work performed, the method used, and
+ any derivation of results. The rationale may provide
+ detail to the level of a CEM work unit.
+
+ The evaluator shall report all information specifically
+ required by a work unit.
+
+ For the and activities, work units that identify
+ information to be reported in the ETR have been
+ defined.
+
+
+
+ The evaluator shall report the conclusions of the
+ evaluation, which will relate to whether the TOE has
+ satisfied its associated ST, in particular the overall
+ verdict as defined in CC Part 1 Clause , and determined by
+ application of the verdict assignment described in .
+
+ The evaluator provides recommendations that may be useful for
+ the evaluation authority. These recommendations may include shortcomings of
+ the IT product discovered during the evaluation or mention of
+ features which are particularly useful.
+
+
+
+ The evaluator shall report for each item of evaluation
+ evidence the following information:
+
+
+ the issuing body (e.g. the developer, the sponsor);
+
+
+ the title;
+
+
+ the unique reference (e.g. issue date and version
+ number).
+
+
+
+
+
+ The evaluator shall report any acronyms or abbreviations
+ used in the ETR.
+
+ Glossary definitions already defined by the CC or CEM
+ need not be repeated in the ETR.
+
+
+
+ The evaluator shall report a complete list that uniquely
+ identifies the ORs raised during the evaluation and
+ their status.
+
+ For each OR, the list should contain its identifier as
+ well as its title or a brief summary of its
+ content.
+
+
+
+
+
+
+ The CC permits comparability between the results of independent
+ security evaluations. The CC does so by providing a common set
+ of requirements for the security functionality of IT products
+ and for assurance measures applied to these IT products during a
+ security evaluation. These IT products may be implemented in
+ hardware, firmware or software.
+ The evaluation process establishes a level of confidence that
+ the security functionality of these IT products and the
+ assurance measures applied to these IT products meet these
+ requirements. The evaluation results may help consumers to
+ determine whether these IT products fulfil their security needs.
+ The CC is useful as a guide for the development, evaluation
+ and/or procurement of IT products with security functionality.
+ The CC is intentionally flexible, enabling a range of evaluation
+ methods to be applied to a range of security properties of a
+ range of IT products. Therefore users of the standard are
+ cautioned to exercise care that this flexibility is not
+ misused. For example, using the CC in conjunction with
+ unsuitable evaluation methods, irrelevant security properties,
+ or inappropriate IT products, may result in meaningless
+ evaluation results.
+ Consequently, the fact that an IT product has been evaluated has
+ meaning only in the context of the security properties that were
+ evaluated and the evaluation methods that were used. Evaluation
+ authorities are advised to carefully check the products,
+ properties and methods to determine that an evaluation will
+ provide meaningful results. Additionally, purchasers of
+ evaluated products are advised to carefully consider this
+ context to determine whether the evaluated product is useful and
+ applicable to their specific situation and needs.
+ The CC addresses protection of assets from unauthorised
+ disclosure, modification, or loss of use. The categories of
+ protection relating to these three types of failure of security
+ are commonly called confidentiality, integrity, and
+ availability, respectively. The CC may also be applicable
+ to aspects of IT security outside of these three. The CC
+ is applicable to risks arising from human activities (malicious
+ or otherwise) and to risks arising from non-human
+ activities. Apart from IT security, the CC may be applied
+ in other areas of IT, but makes no claim of applicability in
+ these areas.
+ Certain topics, because they involve specialised techniques or
+ because they are somewhat peripheral to IT security, are
+ considered to be outside the scope of the CC. Some of these are
+ identified below.
+
+ The CC does not contain security evaluation criteria
+ pertaining to administrative security measures not related
+ directly to the IT security functionality. However, it is
+ recognised that significant security can often be achieved
+ through or supported by administrative measures such as
+ organisational, personnel, physical, and procedural
+ controls.
+
+ The evaluation of some technical physical aspects of IT
+ security such as electromagnetic emanation control is not
+ specifically covered, although many of the concepts
+ addressed will be applicable to that area.
+
+ The CC does not address the evaluation methodology
+ under which the criteria should be applied. This methodology
+ is given in the CEM.
+
+ The CC does not address the administrative and legal
+ framework under which the criteria may be applied by
+ evaluation authorities. However, it is expected that the CC
+ will be used for evaluation purposes in the context of such
+ a framework.
+
+ The procedures for use of evaluation results in
+ accreditation are outside the scope of the CC. Accreditation
+ is the administrative process whereby authority is granted
+ for the operation of an IT product (or collection thereof)
+ in its full operational environment including all of its
+ non-IT parts. The results of the evaluation process are an
+ input to the accreditation process. However, as other
+ techniques are more appropriate for the assessments of
+ non-IT related properties and their relationship to the IT
+ security parts, accreditors should make separate provisions
+ for those aspects.
+
+ The subject of criteria for the assessment of the inherent
+ qualities of cryptographic algorithms is not covered in the
+ CC. Should independent assessment of mathematical properties
+ of cryptography be required, the evaluation scheme under
+ which the CC is applied must make provision for such
+ assessments.
+
+ ISO terminology, such as "can", "informative", "may",
+ "normative", "shall" and "should" used throughout the document
+ are defined in the ISO/IEC Directives, Part 2. Note that the
+ term "should" has an additional meaning applicable when using
+ this standard. See the note below. The following definition is
+ given for the use of ``should'' in the CC.
+ should
+
+ within normative text, ``should'' indicates ``that among
+ several possibilities one is recommended as particularly
+ suitable, without mentioning or excluding others, or that a
+ certain course of action is preferred but not necessarily
+ required.'' (ISO/IEC Directives, Part 2).
+
+ The CC interprets ``not necessarily required'' to mean
+ that the choice of another possibility requires a justification
+ of why the preferred option was not chosen.
+
+ This part of the CC establishes the general concepts and
+ principles of IT security evaluation and specifies the general
+ model of evaluation given by various parts of the standard which
+ in its entirety is meant to be used as the basis for evaluation
+ of security properties of IT products.
+ Part one provides an overview of all parts of the CC
+ standard. It describes the various parts of the standard;
+ defines the terms and abbreviations to be used in all parts of
+ the standard; establishes the core concept of a Target of
+ Evaluation (TOE); the evaluation context and describes the
+ audience to which the evaluation criteria are addressed. An
+ introduction to the basic security concepts necessary for
+ evaluation of IT products is given.
+ It defines the various operations by which the functional and
+ assurance components given in CC Part 2 and CC Part 3 may be
+ tailored through the use of permitted operations.
+ The key concepts of protection profiles (PP), packages of
+ security requirements and the topic of conformance are specified
+ and the consequences of evaluation, evaluation results are
+ described. This part of the CC gives guidelines for the
+ specification of Security Targets (ST) and provides a
+ description of the organization of components throughout the
+ model. General information about the evaluation methodology are
+ given in the CEM and the scope of evaluation schemes is
+ provided.
+ The following referenced documents are indispensable for the
+ application of this CC part 1. For dated references, only the
+ edition cited applies. For undated references, the latest
+ edition of the referenced document (including any amendments)
+ applies.CC-2
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 2: Functional security components.
+ CC-3
+ Common Criteria for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_. Part 3: Assurance security components.
+ CEM
+ Common Methodology for Information Technology Security
+ Evaluation, Version _CCVERSION_, revision _CCREVISION_,
+ _CCDATE_.
+
+ For the purpose of the CC, the following terms and definitions
+ apply.
+ This Clause contains only
+ those terms which are used in a specialised way throughout the
+ CC. Some combinations of common terms used in the CC, while not
+ meriting inclusion in this Clause , are explained for clarity in the context
+ where they are used.
+ adverse actions
+
+ actions performed by a threat agent on an asset
+
+ assets
+
+ entities that the owner of the TOE presumably places value upon
+
+ assignment
+
+ the specification of an identified parameter in a component
+ (of the CC) or requirement
+
+ assurance
+
+ grounds for confidence that a TOE meets the SFRs
+
+ attack potential
+
+ measure of the effort to be expended in attacking a TOE,
+ expressed in terms of an attacker's expertise, resources and
+ motivation
+
+ augmentation
+
+ addition of one or more requirement(s) to a package
+
+ authentication data
+
+ information used to verify the claimed identity of a user
+
+ authorised user
+
+ TOE user who may, in accordance with the SFRs, perform an operation
+ Base Protection ProfileProtection Profile used as a basis to build a Protection Profile Configuration
+ class
+
+ set of CC families that share a common focus
+
+ coherent
+
+ logically ordered and having discernible meaning
+
+ For documentation, this addresses both the actual text and
+ the structure of the document, in terms of whether it is
+ understandable by its target audience.
+
+ complete
+
+ property where all necessary parts of an entity have been provided
+
+ In terms of documentation, this means that all relevant
+ information is covered in the documentation, at such a level
+ of detail that no further explanation is required at that
+ level of abstraction.
+
+ component
+
+ smallest selectable set of elements on which requirements
+ may be based
+
+ composed assurance package
+
+ assurance package consisting of requirements drawn from
+ CC Part 3 (predominately from the class), representing a point on the CC
+ predefined composition assurance scale
+
+ confirm
+
+ declare that something has been reviewed in detail with an
+ independent determination of sufficiency
+
+ The level of rigour required depends on the nature of the subject
+ matter. This term is only applied to evaluator actions.
+
+ connectivity
+
+ property of the TOE allowing interaction with IT entities
+ external to the TOE
+
+ This includes exchange of data by wire or by wireless means,
+ over any distance in any environment or configuration.
+
+ consistent
+
+ relationship between two or more entities such that there
+ are no apparent contradictions between these entities
+
+ counter, verb
+
+ meet an attack where the impact of a particular threat is
+ mitigated but not necessarily eradicated
+
+ demonstrable conformance
+
+ relation between an ST and a PP, where the ST provides a
+ solution which solves the generic security problem in the PP
+
+ The PP and the ST may contain entirely different statements
+ that discuss different entities, use different concepts
+ etc. Demonstrable conformance is also suitable for a TOE
+ type where several similar PPs already exist, thus allowing
+ the ST author to claim conformance to these PPs
+ simultaneously, thereby saving work.
+
+ demonstrate
+
+ provide a conclusion gained by an analysis which is less
+ rigorous than a ``proof''
+
+ dependency
+
+ relationship between components such that if a requirement
+ based on the depending component is included in a PP, ST or
+ package, a requirement based on the component that is
+ depended upon must normally also be included in the PP, ST
+ or package
+
+ describe
+
+ provide specific details of an entity
+
+ determine
+
+ affirm a particular conclusion based on independent analysis
+ with the objective of reaching a particular conclusion
+
+ The usage of this term implies a truly independent analysis,
+ usually in the absence of any previous analysis having been
+ performed. Compare with the terms ``confirm'' or
+ ``verify'' which imply that an analysis has already been
+ performed which needs to be reviewed
+
+ development environment
+
+ environment in which the TOE is developed
+
+ element
+
+ indivisible statement of a security need
+
+ ensure
+
+ guarantee a strong causal relationship between an action and
+ its consequences
+
+ When this term is preceded by the word ``help'' it indicates
+ that the consequence is not fully certain, on the basis of
+ that action alone.
+
+ evaluation
+
+ assessment of a PP, an ST or a TOE, against defined criteria
+
+ evaluation assurance level
+
+ set of assurance requirements drawn from CC Part 3,
+ representing a point on the CC predefined assurance scale,
+ that form an assurance package
+
+ evaluation authority
+
+ body that sets the standards and monitors the quality of
+ evaluations conducted by bodies within a specific community
+ and implements the CC for that community by means of an
+ evaluation scheme
+
+ evaluation scheme
+
+ administrative and regulatory framework under which the CC
+ is applied by an evaluation authority within a specific
+ community
+
+ exhaustive
+
+ characteristic of a methodical approach taken to perform an
+ analysis or activity according to an unambiguous plan
+
+ This term is used in the CC with respect to conducting an
+ analysis or other activity. It is related to ``systematic''
+ but is considerably stronger, in that it indicates not only
+ that a methodical approach has been taken to perform the
+ analysis or activity according to an unambiguous plan, but
+ that the plan that was followed is sufficient to ensure that
+ all possible avenues have been exercised.
+
+ explain
+
+ give argument accounting for the reason for taking a course
+ of action
+
+ This term differs from both ``describe'' and
+ ``demonstrate''. It is intended to answer the question
+ ``Why?'' without actually attempting to argue that the
+ course of action that was taken was necessarily optimal.
+
+ extension
+
+ addition to an ST or PP of functional requirements not
+ contained in CC Part 2 and/or assurance requirements not
+ contained in CC Part 3
+
+ external entity
+
+ human or IT entity possibly interacting with the TOE from
+ outside of the TOE boundary
+
+ family
+
+ set of components that share a similar goal but differ in
+ emphasis or rigour
+
+ formal
+
+ expressed in a restricted syntax language with defined
+ semantics based on well-established mathematical concepts
+
+ guidance documentation
+
+ documentation that describes the delivery, preparation,
+ operation, management and/or use of the TOE
+
+ identity
+
+ representation uniquely identifying entities (e.g. a user, a
+ process or a disk) within the context of the TOE
+
+ An example of such a representation is a string. For a human
+ user, the representation can be the full or abbreviated name
+ or a (still unique) pseudonym.
+
+ informal
+
+ expressed in natural language
+
+ inter TSF transfers
+
+ communicating data between the TOE and the security
+ functionality of other trusted IT products
+
+ internal communication channel
+
+ communication channel between separated parts of the TOE
+
+ internal TOE transfer
+
+ communicating data between separated parts of the TOE
+
+ internally consistent
+
+ no apparent contradictions exist between any aspects of an
+ entity
+
+ In terms of documentation, this means that there can be no
+ statements within the documentation that can be taken to
+ contradict each other.
+
+ iteration
+
+ use of the same component to express two or more distinct
+ requirements
+
+ justification
+
+ analysis leading to a conclusion
+
+ ``Justification'' is more rigorous than a
+ demonstration. This term requires significant rigour in
+ terms of very carefully and thoroughly explaining every step
+ of a logical argument.
+
+ object
+
+ passive entity in the TOE, that contains or receives
+ information, and upon which subjects perform operations
+
+ operation (on a component of the CC)
+
+ modification or repetition of a component
+
+ Allowed operations on components are assignment, iteration,
+ refinement and selection.
+
+ operation (on an object)
+
+ specific type of action performed by a subject on an object
+
+ operational environment
+
+ environment in which the TOE is operated
+
+ organisational security policy
+
+ set of security rules, procedures, or guidelines for an
+ organisation
+
+ A policy may pertain to a specific operational environment.
+
+ package
+
+ named set of either security functional or security
+ assurance requirements
+
+ An example of a package is ``EAL 3''.
+ Protection Profile ConfigurationProtection Profile composed of Base Protection Profiles and Protection Profile Module
+ Protection Profile evaluation
+
+ assessment of a PP against defined criteria
+
+ Protection Profile
+
+ implementation-independent statement of security needs for a
+ TOE type
+ Protection Profile Moduleimplementation-independent statement of security needs for a TOE type complementary to one or more Base Protection Profiles
+ prove
+
+ show correspondence by formal analysis in its mathematical
+ sense
+
+ It is completely rigorous in all ways. Typically, ``prove''
+ is used when there is a desire to show correspondence
+ between two TSF representations at a high level of rigour.
+
+ refinement
+
+ addition of details to a component
+
+ role
+
+ predefined set of rules establishing the allowed
+ interactions between a user and the TOE
+
+ secret
+
+ information that must be known only to authorised users
+ and/or the TSF in order to enforce a specific SFP
+
+ secure state
+
+ state in which the TSF data are consistent and the TSF
+ continues correct enforcement of the SFRs
+
+ security attribute
+
+ property of subjects, users (including external IT
+ products), objects, information, sessions and/or resources
+ that is used in defining the SFRs and whose values are used
+ in enforcing the SFRs
+
+ security function policy
+
+ set of rules describing specific security behaviour enforced
+ by the TSF and expressible as a set of SFRs
+
+ security objective
+
+ statement of an intent to counter identified threats and/or
+ satisfy identified organisation security policies and/or
+ assumptions
+
+ security problem
+
+ statement which in a formal manner defines the nature and
+ scope of the security that the TOE is intended to address
+
+ This statement consists of a combination of:
+
+ threats to be countered by the TOE and its operational environment,
+
+ the OSPs enforced by the TOE and its operational environment, and
+
+ the assumptions that are upheld for the operational environment of the TOE.
+
+ security requirement
+
+ requirement, stated in a standardised language, which is
+ meant to contribute to achieving the security objectives for
+ a TOE
+
+ Security Target
+
+ implementation-dependent statement of security needs for a
+ specific identified TOE
+
+ selection
+
+ specification of one or more items from a list in a component
+
+ semiformal
+
+ expressed in a restricted syntax language with defined semantics
+
+ specify
+
+ provide specific details about an entity in a rigorous and precise manner
+
+ strict conformance
+
+ hierarchical relationship between a PP and an ST where all
+ the requirements in the PP also exist in the ST
+
+ This relation can be roughly defined as ``the ST shall
+ contain all statements that are in the PP, but may contain
+ more''. Strict conformance is expected to be used for
+ stringent requirements that are to be adhered to in a single
+ manner.
+
+ ST evaluation
+
+ assessment of an ST against defined criteria
+
+ subject
+
+ active entity in the TOE that performs operations on objects
+
+ target of evaluation
+
+ set of software, firmware and/or hardware possibly
+ accompanied by guidance
+
+ threat agent
+
+ entity that can adversely act on assets
+
+ TOE evaluation
+
+ assessment of a TOE against defined criteria
+
+ TOE resource
+
+ anything useable or consumable in the TOE
+
+ TOE security functionality
+
+ combined functionality of all hardware, software, and
+ firmware of a TOE that must be relied upon for the correct
+ enforcement of the SFRs
+
+ trace, verb
+
+ perform an informal correspondence analysis between two
+ entities with only a minimal level of rigour
+
+ transfers outside of the TOE
+
+ TSF mediated communication of data to entities not under the
+ control of the TSF
+
+ translation
+
+ describes the process of describing security requirements in
+ a standardised language.
+
+ use of the term translation in this context is not literal
+ and does not imply that every SFR expressed in standardised
+ language can also be translated back to the security
+ objectives.
+
+ trusted channel
+
+ a means by which a TSF and another trusted IT product can
+ communicate with necessary confidence
+
+ trusted IT product
+
+ IT product, other than the TOE, which has its security
+ functional requirements administratively coordinated with
+ the TOE and which is assumed to enforce its security
+ functional requirements correctly
+
+ An example of a trusted IT product would be one that has
+ been separately evaluated.
+
+ trusted path
+
+ means by which a user and a TSF can communicate with the
+ necessary confidence
+
+ TSF data
+
+ data for the operation of the TOE upon which the enforcement
+ of the SFR relies
+
+ TSF interface
+
+ means by which external entities (or subjects in the TOE but
+ outside of the TSF) supply data to the TSF, receive data
+ from the TSF and invoke services from the TSF
+
+ user
+
+ see external entity
+
+ user data
+
+ data for the user, that does not affect the operation of the TSF
+
+ verify
+
+ rigorously review in detail with an independent
+ determination of sufficiency
+
+ Also see ``confirm''. This term has more rigorous
+ connotations. The term ``verify'' is used in the context
+ of evaluator actions where an independent effort is required
+ of the evaluator.
+
+ The following terms are used in the requirements for software
+ internal structuring. Some of these are derived from the
+ IEEE Std 610.12-1990,
+ Standard glossary of software engineering terminology,
+ Institute of Electrical and Electronics Engineers.
+ administrator
+
+ entity that has a level of trust with respect to all
+ policies implemented by the TSF
+
+ Not all PPs or STs assume the same level of trust for
+ administrators. Typically administrators are assumed to
+ adhere at all times to the policies in the ST of the
+ TOE. Some of these policies may be related to the
+ functionality of the TOE, others may be related to the
+ operational environment.
+
+ call tree
+
+ identifies the modules in a system in diagrammatic form
+ showing which modules call one another
+
+ Adapted from
+ cohesion
+
+ module strength
+
+ manner and degree to which the tasks performed by a single
+ software module are related to one another
+
+ Types of cohesion include coincidental, communicational,
+ functional, logical, sequential, and temporal. These types
+ of cohesion are described by the relevant term entry.
+
+ coincidental cohesion
+
+ module with the characteristic of performing unrelated, or
+ loosely related, activities
+
+ See ``cohesion''.
+
+ communicational cohesion
+
+ module containing functions that produce output for, or use
+ output from, other functions within the module
+
+ See ``cohesion''.
+ An example of a communicationally cohesive module is an
+ access check module that includes mandatory,
+ discretionary, and capability checks.
+ complexity
+
+ measure of how difficult software is to understand, and thus
+ to analyse, test, and maintain
+
+ Reducing complexity is the ultimate goal for using modular
+ decomposition, layering and minimisation. Controlling
+ coupling and cohesion contributes significantly to this
+ goal.
+ A good deal of effort in the software engineering field
+ has been expended in attempting to develop metrics to
+ measure the complexity of source code. Most of these
+ metrics use easily computed properties of the source code,
+ such as the number of operators and operands, the
+ complexity of the control flow graph (cyclomatic
+ complexity), the number of lines of source code, the ratio
+ of comments to executable code, and similar
+ measures. Coding standards have been found to be a useful
+ tool in generating code that is more readily understood.
+ The family calls for a complexity
+ analysis in all components. It is expected that the
+ developer will provide support for the claims that there
+ has been a sufficient reduction in complexity. This
+ support could include the developer's programming
+ standards, and an indication that all modules meet the
+ standard (or that there are some exceptions that are
+ justified by software engineering arguments). It could
+ include the results of tools used to measure some of the
+ properties of the source code, or it could include other
+ support that the developer finds appropriate.
+ coupling
+
+ manner and degree of interdependence between software modules
+
+ Types of coupling include call, common and content
+ coupling. These are characterised below:
+
+ call coupling
+
+ relationship between two modules
+
+ Examples of call coupling are data, stamp, and control:
+
+ call coupling (data)
+
+ relationship between two modules communicating strictly
+ through the use of call parameters that represent single
+ data items.
+
+ See ``call coupling''
+
+ call coupling (stamp)
+
+ relationship between two modules through the use of call
+ parameters that comprise multiple fields or that have
+ meaningful internal structures.
+
+ See ``call coupling''
+
+ call coupling (control)
+
+ relationship between two modules if one passes information
+ that is intended to influence the internal logic of the
+ other.
+
+ See ``call coupling''
+
+ common coupling
+
+ relationship between two modules sharing a common data area
+ or other common system resource
+
+ Global variables indicate that modules using those global
+ variables are common coupled. Common coupling through global
+ variables is generally allowed, but only to a limited
+ degree.
+ For example, variables that are placed into a global area,
+ but are used by only a single module, are inappropriately
+ placed, and should be removed. Other factors that need to
+ be considered in assessing the suitability of global
+ variables are:
+
+ The number of modules that modify a global variable:
+ In general, only a single module should be allocated
+ the responsibility for controlling the contents of a
+ global variable, but there may be situations in which
+ a second module may share that responsibility; in such
+ a case, sufficient justification must be provided. It
+ is unacceptable for this responsibility to be shared
+ by more than two modules. (In making this assessment,
+ care should be given to determining the module
+ actually responsible for the contents of the variable;
+ for example, if a single routine is used to modify the
+ variable, but that routine simply performs the
+ modification requested by its caller, it is the
+ calling module that is responsible, and there may be
+ more than one such module). Further, as part of the
+ complexity determination, if two modules are
+ responsible for the contents of a global variable,
+ there should be clear indications of how the
+ modifications are coordinated between them.
+
+ The number of modules that reference a global
+ variable: Although there is generally no limit on the
+ number of modules that reference a global variable,
+ cases in which many modules make such a reference
+ should be examined for validity and necessity.
+
+ content coupling
+
+ relationship between two modules where one makes direct
+ reference to the internals of the other
+
+ Examples include modifying code of, or referencing labels
+ internal to, the other module. The result is that some or
+ all of the content of one module are effectively included in
+ the other. Content coupling can be thought of as using
+ unadvertised module interfaces; this is in contrast to call
+ coupling, which uses only advertised module interfaces.
+
+ domain separation
+
+ security architecture property whereby the TSF defines
+ separate security domains for each user and for the TSF and
+ ensures that no user process can affect the contents of a
+ security domain of another user or of the TSF
+
+ functional cohesion
+
+ functional property of a module which performs activities
+ related to a single purpose
+
+ A functionally cohesive module transforms a single type of
+ input into a single type of output, such as a stack manager or
+ a queue manager. See also ``cohesion''.
+
+ interaction
+
+ general communication-based activity between entities
+
+ interface
+
+ means of interaction with a component or module
+
+ layering
+
+ design technique where separate groups of modules (the
+ layers) are hierarchically organised to have separate
+ responsibilities such that one layer depends only on layers
+ below it in the hierarchy for services, and provides its
+ services only to the layers above it
+
+ Strict layering adds the constraint that each layer receives
+ services only from the layer immediately beneath it, and
+ provides services only to the layer immediately above it.
+
+ logical cohesion
+
+ procedural cohesion
+
+ characteristics of a module performing similar activities on
+ different data structures
+
+ A module exhibits logical cohesion if its functions perform
+ related, but different, operations on different inputs. See
+ also ``cohesion''.
+
+ modular decomposition
+
+ process of breaking a system into components to facilitate
+ design, development and evaluation
+
+ non-bypassability (of the TSF)
+
+ security architecture property whereby all SFR-related
+ actions are mediated by the TSF
+
+ procedural cohesion
+
+ See ``logical cohesion''
+
+ security domains
+
+ environments provided by the TSF for the use by untrusted entities in such a way that these environments are isolated and protected from each other
+
+ sequential cohesion
+
+ module containing functions each of whose output is input
+ for the following function in the module
+
+ An example of a sequentially cohesive module is one that
+ contains the functions to write audit records and to
+ maintain a running count of the accumulated number of audit
+ violations of a specified type.
+
+ software engineering
+
+ application of a systematic, disciplined, quantifiable
+ approach to the development and maintenance of software;
+ that is, the application of engineering to software
+
+ As with engineering practices in general, some amount of
+ judgement must be used in applying engineering
+ principles. Many factors affect choices, not just the
+ application of measures of modular decomposition, layering,
+ and minimisation. For example, a developer may design a
+ system with future applications in mind that will not be
+ implemented initially. The developer may choose to include
+ some logic to handle these future applications without fully
+ implementing them; further, the developer may include some
+ calls to as-yet unimplemented modules, leaving call
+ stubs. The developer's justification for such deviations
+ from well-structured programs will have to be assessed using
+ judgement, as well as the application of good software
+ engineering discipline.
+
+ temporal cohesion
+
+ characteristics of a module containing functions that need
+ to be executed at about the same time
+
+ Adapted from . Examples of temporally
+ cohesive modules include initialisation, recovery, and
+ shutdown modules.
+
+ TSF self-protection
+
+ security architecture property whereby the TSF cannot be
+ corrupted by non-TSF code or entities
+
+ installation
+
+ procedure performed by a human user embedding the TOE in its
+ operational environment and putting it into an operational
+ state
+
+ This operation is performed normally only once, after
+ receipt and acceptance of the TOE. The TOE is expected to be
+ progressed to a configuration allowed by the ST. If similar
+ processes have to be performed by the developer they are
+ denoted as ``generation'' throughout . If
+ the TOE requires an initial start-up that does not need to
+ be repeated regularly, this process would be classified as
+ installation.
+
+ operation
+
+ usage phase of the TOE including ``normal usage'',
+ administration and maintenance of the TOE after delivery and
+ preparation
+
+ preparation
+
+ activity in the life-cycle phase of a product, comprising
+ the customer's acceptance of the delivered TOE and its
+ installation which may include such things as booting,
+ initialisation, start-up and progressing the TOE to a state
+ ready for operation
+
+ acceptance criteria
+
+ criteria to be applied when performing the acceptance
+ procedures (e.g. successful document review, or successful
+ testing in the case of software, firmware or hardware)
+
+ acceptance procedures
+
+ procedures followed in order to accept newly created or
+ modified configuration items as part of the TOE, or to move
+ them to the next step of the life-cycle
+
+ These procedures identify the roles or individuals
+ responsible for the acceptance and the criteria to be
+ applied in order to decide on the acceptance.
+ There are several types of acceptance situations some of
+ which may overlap:
+
+ acceptance of an item into the configuration
+ management system for the first time, in particular
+ inclusion of software, firmware and hardware
+ components from other manufacturers into the TOE
+ (``integration'');
+
+ progression of configuration items to the next
+ life-cycle phase at each stage of the construction of
+ the TOE (e.g. module, subsystem, quality control of
+ the finished TOE);
+
+ subsequent to transports of configuration items (for
+ example parts of the TOE or preliminary products)
+ between different development sites;
+
+ subsequent to the delivery of the TOE to the consumer.
+
+ configuration management
+
+ discipline applying technical and administrative direction
+ and surveillance to: identify and document the functional
+ and physical characteristics of a configuration item,
+ control changes to those characteristics, record and report
+ change processing and implementation status, and verify
+ compliance with specified requirements.
+
+ CM documentation
+
+ all CM documentation including CM output, CM list
+ (configuration list), CM system records, CM plan and CM
+ usage documentation
+
+ configuration management evidence
+
+ everything that may be used to establish confidence in the
+ correct operation of the CM system
+
+ For example, CM output, rationales provided by the
+ developer, observations, experiments or interviews made by
+ the evaluator during a site visit.
+
+ configuration item
+
+ object managed by the CM system during the TOE development
+
+ These may be either parts of the TOE or objects related to
+ the development of the TOE like evaluation documents or
+ development tools. CM items may be stored in the CM system
+ directly (for example files) or by reference (for example
+ hardware parts) together with their version.
+
+ configuration list
+
+ configuration management output document listing all
+ configuration items for a specific product together with the
+ exact version of each configuration management item relevant
+ for a specific version of the complete product
+
+ This list allows distinguishing the items belonging to the
+ evaluated version of the product from other versions of
+ these items belonging to other versions of the product. The
+ final configuration management list is a specific document
+ for a specific version of a specific product. (Of course the
+ list can be an electronic document inside of a configuration
+ management tool. In that case it can be seen as a specific
+ view into the system or a part of the system rather than an
+ output of the system. However, for the practical use in an
+ evaluation the configuration list will probably be delivered
+ as a part of the evaluation documentation.) The
+ configuration list defines the items that are under the
+ configuration management requirements of .
+
+ configuration management output
+
+ results, related to configuration management, produced or
+ enforced by the configuration management system
+
+ These configuration management related results could occur
+ as documents (for example filled paper forms, configuration
+ management system records, logging data, hard-copies and
+ electronic output data) as well as actions (for example
+ manual measures to fulfil configuration management
+ instructions). Examples of such configuration management
+ outputs are configuration lists, configuration management
+ plans and/or behaviours during the product life-cycle.
+
+ configuration management plan
+
+ description of how the configuration management system is
+ used for the TOE
+
+ The objective of issuing a configuration management plan is
+ that staff members can see clearly what they have to
+ do. From the point of view of the overall configuration
+ management system this can be seen as an output document
+ (because it may be produced as part of the application of
+ the configuration management system). From the point of view
+ of the concrete project it is a usage document because
+ members of the project team use it in order to understand
+ the steps that they have to perform during the project. The
+ configuration management plan defines the usage of the
+ system for the specific product; the same system may be used
+ to a different extent for other products. That means the
+ configuration management plan defines and describes the
+ output of the configuration management system of a company
+ which is used during the TOE development.
+
+ configuration management system
+
+ set of procedures and tools (including their documentation)
+ used by a developer to develop and maintain configurations
+ of his products during their life-cycles
+
+ Configuration management systems may have varying degrees of
+ rigour and function. At higher levels, configuration
+ management systems may be automated, with flaw remediation,
+ change controls, and other tracking mechanisms.
+
+ configuration management system records
+
+ output produced during the operation of the configuration
+ management system documenting important configuration
+ management activities
+
+ Examples of configuration management system records are
+ configuration management item change control forms or
+ configuration management item access approval forms.
+
+ configuration management tools
+
+ manually operated or automated tools realising or supporting
+ a configuration management system
+
+ For example tools for the version management of the parts of
+ the TOE.
+
+ configuration management usage documentation
+
+ part of the configuration management system, which
+ describes, how the configuration management system is
+ defined and applied by using for example handbooks,
+ regulations and/or documentation of tools and procedures
+
+ delivery
+
+ transmission of the finished TOE from the production
+ environment into the hands of the customer
+
+ This product life-cycle phase may include packaging and
+ storage at the development site, but does not include
+ transportations of the unfinished TOE or parts of the TOE
+ between different developers or different development
+ sites.
+
+ developer
+
+ organisation responsible for the development of the TOE
+
+ development
+
+ product life-cycle phase which is concerned with generating
+ the implementation representation of the TOE
+
+ Throughout the requirements, development
+ and related terms (developer, develop) are meant in the more
+ general sense to comprise development and production.
+
+ development tools
+
+ tools (including test software, if applicable) supporting
+ the development and production of the TOE
+
+ For example for a software TOE, development tools are
+ usually programming languages, compilers, linkers and
+ generating tools.
+
+ implementation representation
+
+ least abstract representation of the TSF, specifically the
+ one that is used to create the TSF itself without further
+ design refinement
+
+ Source code that is then compiled or a hardware drawing that
+ is used to build the actual hardware are examples of parts
+ of an implementation representation.
+
+ life-cycle
+
+ sequence of stages of existence of an object (for example a
+ product or a system) in time
+
+ life-cycle definition
+
+ definition of the life-cycle model
+
+ life cycle model
+
+ description of the stages and their relations to each other
+ that are used in the management of the life-cycle of a
+ certain object, how the sequence of stages looks like and
+ which high level characteristics the stages have
+
+ production
+
+ production life-cycle phase follows the development phase
+ and consists of transforming the implementation
+ representation into the implementation of the TOE, i.e. into
+ a state acceptable for delivery to the customer
+
+ This phase may comprise manufacturing, integration,
+ generation, internal transports, storage, and labelling of
+ the TOE.
+
+ covert channel
+
+ enforced, illicit signalling channel that allows a user to
+ surreptitiously contravene the multi-level separation policy
+ and unobservability requirements of the TOE
+
+ encountered potential vulnerabilities
+
+ potential weakness in the TOE identified by the evaluator
+ while performing evaluation activities that could be used to
+ violate the SFRs
+
+ exploitable vulnerability
+
+ weakness in the TOE that can be used to violate the SFRs in
+ the operational environment for the TOE
+
+ monitoring attacks
+
+ generic category of attack methods that includes passive
+ analysis techniques aiming at disclosure of sensitive
+ internal data of the TOE by operating the TOE in the way
+ that corresponds to the guidance documents
+
+ potential vulnerability
+
+ suspected, but not confirmed, weakness
+
+ Suspicion is by virtue of a postulated attack path to
+ violate the SFRs.
+
+ residual vulnerability
+
+ weakness that cannot be exploited in the operational
+ environment for the TOE, but that could be used to violate
+ the SFRs by an attacker with greater attack potential than
+ is anticipated in the operational environment for the TOE
+
+ vulnerability
+
+ weakness in the TOE that can be used to violate the SFRs in
+ some environment
+
+ base component
+
+ entity in a composed TOE, which has itself been the subject
+ of an evaluation, providing services and resources to a
+ dependent component
+
+ compatible (components)
+
+ property of a component able to provide the services
+ required by the other component, through the corresponding
+ interfaces of each component, in consistent operational
+ environments
+
+ component TOE
+
+ successfully evaluated TOE that is part of another composed
+ TOE
+
+ composed TOE
+
+ TOE comprised solely of two or more components that have
+ been successfully evaluated
+
+ dependent component
+
+ entity in a composed TOE, which is itself the subject of an
+ evaluation, relying on the provision on services by a base
+ component
+
+ functional interface
+
+ external interface providing a user with access to
+ functionality of the TOE which is not directly involved in
+ enforcing security functional requirements
+
+ In a composed TOE these are the interfaces provided by the
+ base component that are required by the dependent component
+ to support the operation of the composed TOE.
+
+ The following abbreviations are used in one or more parts of the
+ CC:API
+ Application Programming Interface
+ CAP
+ Composed Assurance Package
+ CC
+ Common Criteria
+ CCRAArrangement on the
+ Recognition of Common Criteria Certificates in the field of IT
+ Security
+ CM
+ Configuration Management
+ DAC
+ Discretionary Access Control
+ EAL
+ Evaluation Assurance Level
+ GHz
+ Gigahertz
+ GUI
+ Graphical User Interface
+ IC
+ Integrated Circuit
+ IOCTL
+ Input Output Control
+ IP
+ Internet Protocol
+ IT
+ Information Technology
+ MB
+ Mega Byte
+ OS
+ Operating System
+ OSP
+ Organisational Security Policy
+ PC
+ Personal Computer
+ PCI
+ Peripheral Component Interconnect
+ PKI
+ Public Key Infrastructure
+ PP
+ Protection Profile
+ RAM
+ Random Access Memory
+ RPC
+ Remote Procedure Call
+ SAR
+ Security Assurance Requirement
+ SFR
+ Security Functional Requirement
+ SFP
+ Security Function Policy
+ SPD
+ Security Problem Definition
+ ST
+ Security Target
+ TCP
+ Transmission Control Protocol
+ TOE
+ Target of Evaluation
+ TSF
+ TOE Security Functionality
+ TSFI
+ TSF Interface
+ VPN
+ Virtual Private Network
+
+ This Clause introduces the main concepts of the CC. It
+ identifies the concept ``TOE'', the target audience of the CC,
+ and the approach taken to present the material in the remainder
+ of the CC.
+ The CC is flexible in what to evaluate and is therefore not
+ tied to the boundaries of IT products as commonly
+ understood. Therefore in the context of evaluation, the CC
+ uses the term ``TOE'' (Target of Evaluation).
+ A TOE is defined as a set of software, firmware and/or
+ hardware possibly accompanied by guidance.
+ While there are cases where a TOE consists of an IT product,
+ this need not be the case. The TOE may be an IT product, a
+ part of an IT product, a set of IT products, a unique
+ technology that may never be made into a product, or a
+ combination of these.
+ As far as the CC is concerned, the precise relation
+ between the TOE and any IT products is only important in one
+ aspect: the evaluation of a TOE containing only part of an IT
+ product should not be misrepresented as the evaluation of the
+ entire IT product.
+ Examples of TOEs include:
+
+ A software application;
+
+ An operating system;
+
+ A software application in combination with an operating
+ system;
+
+ A software application in combination with an operating
+ system and a workstation;
+
+ An operating system in combination with a workstation;
+
+ A smart card integrated circuit;
+
+ The cryptographic co-processor of a smart card integrated
+ circuit;
+
+ A Local Area Network including all terminals, servers,
+ network equipment and software;
+
+ A database application excluding the remote client
+ software normally associated with that database
+ application.
+
+ In the CC, a TOE can occur in several
+ representations, such as (for a software TOE):
+
+ a list of files in a configuration management system;
+
+ a single master copy, that has just been compiled;
+
+ a box containing a CD-ROM and a manual, ready to be shipped to a customer;
+
+ an installed and operational version.
+
+ All of these are considered to be a TOE: and wherever the
+ term ``TOE'' is used in the remainder of the CC, the
+ context determines the representation that is meant.
+ In general, IT products can be configured in many ways:
+ installed in different ways, with different options enabled
+ or disabled. As, during a CC evaluation, it will be
+ determined whether a TOE meets certain requirements, this
+ flexibility in configuration may lead to problems, as all
+ possible configurations of the TOE must meet the
+ requirements. For these reasons, it is often the case that
+ the guidance part of the TOE strongly constrains the
+ possible configurations of the TOE. That is: the guidance of
+ the TOE may be different from the general guidance of the IT
+ product.
+ An example is an operating system IT product. This product
+ can be configured in many ways (e.g. types of users, number
+ of users, types of external connections allowed/disallowed,
+ options enabled/disabled etc.).
+ If the same IT product is to be a TOE, and is evaluated
+ against a reasonable set of requirements, the configuration
+ should be much more tightly controlled, as many options
+ (e.g. allow all types of external connections or the system
+ administrator does not need to be authenticated) will lead
+ to a TOE not meeting the requirements.
+ For this reason, there would normally be a difference
+ between the guidance of the IT product (allowing many
+ configurations) and the guidance of the TOE (allowing only
+ one or only configurations that do not differ in
+ security-relevant ways).
+ Note that if the guidance of the TOE still allows more than
+ one configuration, these configurations are collectively
+ called ``the TOE'' and each such configuration must meet the
+ requirements levied on the TOE.
+ There are three groups with a general interest in evaluation
+ of the security properties of TOEs: consumers, developers and
+ evaluators. The criteria presented in this CC part 1 have been
+ structured to support the needs of all three groups. They are
+ all considered to be the principal users of the CC. The
+ three groups can benefit from the criteria as explained in the
+ following paragraphs.
+ The CC is written to ensure that evaluation fulfils
+ the needs of the consumers as this is the fundamental
+ purpose and justification for the evaluation process.
+ Consumers can use the results of evaluations to help decide
+ whether a TOE fulfils their security needs. These security
+ needs are typically identified as a result of both risk
+ analysis and policy direction. Consumers can also use the
+ evaluation results to compare different TOEs.
+ The CC gives consumers, especially in consumer groups
+ and communities of interest, an implementation-independent
+ structure, termed the Protection Profile (PP), in which to
+ express their security requirements in an unambiguous
+ manner.
+ The CC is intended to support developers in preparing
+ for and assisting in the evaluation of their TOEs and in
+ identifying security requirements to be satisfied by those
+ TOEs. These requirements are contained in an
+ implementation-dependent construct termed the Security
+ Target (ST). This ST may be based on one or more PPs to show
+ that the ST conforms to the security requirements from
+ consumers as laid down in those PPs.
+ The CC can then be used to determine the
+ responsibilities and actions to provide evidence that is
+ necessary to support the evaluation of the TOE against these
+ requirements. It also defines the content and presentation
+ of that evidence.
+ The CC contains criteria to be used by evaluators
+ when forming judgements about the conformance of TOEs to
+ their security requirements. The CC describes the set
+ of general actions the evaluator is to carry out. Note that
+ the CC does not specify procedures to be followed in
+ carrying out those actions. More information on these
+ procedures may be found in Subclause .
+ While the CC is oriented towards specification and
+ evaluation of the IT security properties of TOEs, it may
+ also be useful as reference material to all parties with an
+ interest in or responsibility for IT security. Some of the
+ additional interest groups that can benefit from information
+ contained in the CC are:
+
+ system custodians and system security officers
+ responsible for determining and meeting organisational
+ IT security policies and requirements;
+
+ auditors, both internal and external, responsible for
+ assessing the adequacy of the security of an IT solution
+ (which may consist of or contain a TOE);
+
+ security architects and designers responsible for the
+ specification of security properties of IT products;
+
+ accreditors responsible for accepting an IT solution for
+ use within a particular environment;
+
+ sponsors of evaluation responsible for requesting and
+ supporting an evaluation; and
+
+ evaluation authorities responsible for the management
+ and oversight of IT security evaluation programmes.
+
+ The CC is presented as a set of distinct but related
+ parts as identified below. Terms used in the description of
+ the parts are explained in Clause .
+ Part 1, Introduction and general model is the
+ introduction to the CC. It defines the general concepts
+ and principles of IT security evaluation and presents a
+ general model of evaluation.
+ Part 2, Security functional components
+ establishes a set of functional components that serve as
+ standard templates upon which to base functional
+ requirements for TOEs. CC Part 2 catalogues the set of
+ functional components and organises them in families and
+ classes.
+ Part 3, Security assurance components
+ establishes a set of assurance components that serve as
+ standard templates upon which to base assurance
+ requirements for TOEs. CC Part 3 catalogues the set of
+ assurance components and organises them into families and
+ classes. CC Part 3 also defines evaluation criteria for
+ PPs and STs and presents seven pre-defined assurance
+ packages which are called the Evaluation Assurance Levels
+ (EALs).
+
+ In support of the three parts of the CC listed above,
+ other documents have been published, the CEM provides
+ the methodology for IT security evaluation using the CC
+ as a basis. It is anticipated that other documents will be
+ published, including technical rationale material and guidance
+ documents.
+ The following table presents, for the three key target
+ audience groupings, how the parts of the CC will be of
+ interest.
+ Consumers
+
+ Developers
+
+ Evaluators
+
+ Part 1
+
+ Use for background information and
+ are obliged to use for reference purposes. Guidance
+ structure for PPs.
+
+ Use for background information and reference
+ purposes. Are obliged to use for the development of
+ security specifications for TOEs.
+
+ Are obliged to use for reference purposes and for
+ guidance in the structure for PPs and STs.
+
+ Part 2
+
+ Use for guidance and reference when formulating
+ statements of requirements for a TOE.
+
+ Are obliged to use for reference when interpreting
+ statements of functional requirements and formulating
+ functional specifications for TOEs.
+
+ Are obliged to use for reference when interpreting
+ statements of functional requirements.
+
+ Part 3
+
+ Use for guidance when determining required levels of
+ assurance.
+
+ Use for reference when interpreting statements of
+ assurance requirements and determining assurance
+ approaches of TOEs.
+
+ Use for reference when interpreting statements of
+ assurance requirements.
+ Road map to the Common Criteria
+ In order to achieve greater comparability between evaluation
+ results, evaluations should be performed within the framework
+ of an authoritative evaluation scheme that sets the standards,
+ monitors the quality of the evaluations and administers the
+ regulations to which the evaluation facilities and evaluators
+ must conform.
+ The CC does not state requirements for the regulatory
+ framework. However, consistency between the regulatory
+ frameworks of different evaluation authorities will be
+ necessary to achieve the goal of mutual recognition of the
+ results of such evaluations.
+ A second way of achieving greater comparability between
+ evaluation results is using a common methodology to achieve
+ these results. For the CC, this methodology is given in
+ the CEM.
+ Use of a common evaluation methodology contributes to the
+ repeatability and objectivity of the results but is not by
+ itself sufficient. Many of the evaluation criteria require the
+ application of expert judgement and background knowledge for
+ which consistency is more difficult to achieve. In order to
+ enhance the consistency of the evaluation findings, the final
+ evaluation results may be submitted to a certification
+ process.
+ The certification process is the independent inspection of the
+ results of the evaluation leading to the production of the
+ final certificate or approval, which is normally publicly
+ available. The certification process is a means of gaining
+ greater consistency in the application of IT security
+ criteria.
+ The evaluation schemes and certification processes are the
+ responsibility of the evaluation authorities that run such
+ schemes and processes and are outside the scope of the CC.
+ This clause presents the general concepts used throughout the
+ CC, including the context in which the concepts are to be used
+ and the CC approach for applying the concepts. CC Part 2 and CC
+ Part 3, which are obliged to be consulted by users of the CC
+ Part 1, expand on the use of these concepts and assume that the
+ approach described is used. Further, for users of the CC who
+ intend to perform evaluation activities the CEM is
+ applicable. This clause assumes some knowledge of IT security
+ and does not propose to act as a tutorial in this area.
+ The CC discusses security using a set of security
+ concepts and terminology. An understanding of these concepts and
+ the terminology is a prerequisite to the effective use of
+ the CC. However, the concepts themselves are quite
+ general and are not intended to restrict the class of IT
+ security problems to which the CC is applicable.
+ Security is concerned with the protection of assets. Assets
+ are entities that someone places value upon. Examples of
+ assets include:
+ contents of a file or a server;the authenticity of votes cast in an election;the availability of an electronic commerce
+ process;the ability to use an expensive printer;access to a classified facility.
+ but given that value is highly subjective, almost anything can
+ be an asset.
+ The environment(s) in which these assets are located is called
+ the operational environment. Examples of (aspects of)
+ operational environments are:
+
+ the computer room of a bank;
+
+ a computer network connected to the Internet;
+
+ a LAN;
+
+ a general office environment.
+
+ Many assets are in the form of information that is stored,
+ processed and transmitted by IT products to meet requirements
+ laid down by owners of the information. Information owners may
+ require that availability, dissemination and modification of
+ any such information are strictly controlled and that the
+ assets are protected from threats by countermeasures. Figure
+ illustrates these
+ high level concepts and relationships.
+ Safeguarding assets of interest is the responsibility of
+ owners who place value on those assets. Actual or presumed
+ threat agents may also place value on the assets and seek to
+ abuse assets in a manner contrary to the interests of the
+ owner. Examples of threat agents include hackers, malicious
+ users, non-malicious users (who sometimes make errors),
+ computer processes and accidents.
+ The owners of the assets will perceive such threats as
+ potential for impairment of the assets such that the value of
+ the assets to the owners would be reduced. Security-specific
+ impairment commonly includes, but is not limited to: loss of
+ asset confidentiality, loss of asset integrity and loss of
+ asset availability.
+ These threats therefore give rise to risks to the assets,
+ based on the likelihood of a threat being realised and the
+ impact on the assets when that threat is
+ realised. Subsequently countermeasures are imposed to reduce
+ the risks to assets. These countermeasures may consist of IT
+ countermeasures (such as firewalls and smart cards) and non-IT
+ countermeasures (such as guards and procedures). See also
+ ISO/IEC 27001 and ISO/IEC 27002 for a more general discussion
+ on security countermeasures (controls).
+ Owners of assets may be (held) responsible for those assets
+ and therefore should be able to defend the decision to accept
+ the risks of exposing the assets to the threats.
+ Two important elements in defending this decision are being
+ able to demonstrate that:
+
+ the countermeasures are sufficient: if the countermeasures do what
+ they claim to do, the threats to the assets are countered;
+
+ the countermeasures are correct: the countermeasures do
+ what they claim to do.
+
+ Many owners of assets lack the knowledge, expertise or
+ resources necessary to judge sufficiency and correctness of
+ the countermeasures, and they may not wish to rely solely on
+ the assertions of the developers of the countermeasures. These
+ consumers may therefore choose to increase their confidence in
+ the sufficiency and correctness of some or all of their
+ countermeasures by ordering an evaluation of these
+ countermeasures.
+ In an evaluation, sufficiency of the countermeasures is
+ analysed through a construct called the Security Target. In
+ this Subclause a simplified view on this construct is
+ provided: a more detailed and complete description may be
+ found in .
+ The Security Target begins with describing the assets and
+ the threats to those assets. The Security Target then
+ describes the countermeasures (in the form of Security
+ Objectives) and demonstrates that these countermeasures are
+ sufficient to counter these threats: if the countermeasures
+ do what they claim to do, the threats are countered.
+ The Security Target then divides these countermeasures in
+ two groups:
+
+ the security objectives for the TOE: these describe the
+ countermeasure(s) for which correctness will be
+ determined in the evaluation;
+
+ the security objectives for the Operational Environment:
+ these describe the countermeasures for which correctness
+ will not be determined in the evaluation.
+
+ The reasons for this division are:
+
+ The CC is only suitable for assessing the
+ correctness of IT countermeasures. Therefore the non-IT
+ countermeasures (e.g. human security guards, procedures)
+ are always in the Operational Environment.
+
+ Assessing correctness of countermeasures costs time and
+ money, possibly making it infeasible to assess the
+ correctness of all IT countermeasures.
+
+ The correctness of some IT countermeasures may already
+ have been assessed in another evaluation. It is
+ therefore not cost-effective to assess this correctness
+ again.
+
+ For the TOE (the IT countermeasures whose correctness will
+ be assessed during the evaluation), the Security Target
+ requires a further detailing of the security objectives for
+ the TOE in Security Functional Requirements (SFRs). These
+ SFRs are formulated in a standardised language (described in
+ CC Part 2) to ensure exactness and facilitate comparability.
+ In summary, the Security Target demonstrates that:
+
+ The SFRs meet the security objectives for the TOE;
+
+ The security objectives for the TOE and the security
+ objectives for the operational environment counter the
+ threats;
+
+ And therefore, the SFRs and the security objectives for
+ the operational environment counter the threats.
+
+ From this it follows that a correct TOE (meeting the SFRs)
+ in combination with a correct operational environment
+ (meeting the security objectives for the operational
+ environment) will counter the threats. In the next two
+ subclauses correctness of the TOE and correctness of the
+ operational environment are discussed separately.
+ A TOE may be incorrectly designed and implemented, and may
+ therefore contain errors that lead to vulnerabilities. By
+ exploiting these vulnerabilities, attackers may still damage
+ and/or abuse the assets.
+ These vulnerabilities may arise from accidental errors made
+ during development, poor design, intentional addition of
+ malicious code, poor testing etc.
+ To determine correctness of the TOE, various activities can
+ be performed such as:
+
+ testing the TOE;
+
+ examining various design representations of the TOE;
+
+ examining the physical security of the development
+ environment of the TOE.
+
+ The Security Target provides a structured description of
+ these activities to determine correctness in the form of
+ Security Assurance Requirements (SARs). These SARs are
+ formulated in a standardised language (described in CC Part
+ 3) to ensure exactness and facilitate comparability.
+ If the SARs are met, there exists assurance in the
+ correctness of the TOE and the TOE is therefore less likely
+ to contain vulnerabilities that can be exploited by
+ attackers. The amount of assurance that exists in the
+ correctness of the TOE is determined by the SARs themselves:
+ a few ``weak'' SARs will lead to a little assurance, a lot
+ of ``strong'' SARs will lead to a lot of assurance.
+ The operational environment may also be incorrectly designed
+ and implemented, and may therefore contain errors that lead
+ to vulnerabilities. By exploiting these vulnerabilities,
+ attackers may still damage and/or abuse the assets.
+ However, in the CC, no assurance is obtained
+ regarding the correctness of the operational
+ environment. Or, in other words, the operational environment
+ is not evaluated (see the next Subclause).
+ As far as the evaluation is concerned, the operational
+ environment is assumed to be a 100% correct instantiation of
+ the security objectives for the operational environment.
+ This does not preclude a consumer of the TOE from using
+ other methods to determine the correctness of his
+ operational environment, such as:
+
+ If, for an OS TOE, the security objectives for the
+ operational environment state ``The operational
+ environment shall ensure that entities from an untrusted
+ network (e.g. the Internet) can only access the TOE by
+ ftp'', the consumer could select an evaluated firewall,
+ and configure it to only allow ftp access to the TOE;
+
+ If the security objectives for the operational
+ environment state ``The operational environment shall
+ ensure that all administrative personnel will not behave
+ maliciously'', the consumer could adapt his contracts
+ with administrative personnel to include punitive
+ sanctions for malicious behaviour, but this
+ determination is not part of a CC evaluation.
+
+ The CC recognises two types of evaluation: an ST/TOE
+ evaluation, which is described below, and an evaluation of
+ PPs, which is defined in CC Part 3. In many places,
+ the CC uses the term evaluation (without qualifiers) to
+ refer to an ST/TOE evaluation.
+ In the CC an ST/TOE evaluation proceeds in two steps:
+
+ An ST evaluation: where the sufficiency of the TOE and the
+ operational environment are determined;
+
+ A TOE evaluation: where the correctness of the TOE is
+ determined. As said earlier, the TOE evaluation does not
+ assess correctness of the operational environment.
+
+ The ST evaluation is carried out by applying the Security
+ Target evaluation criteria (which are defined in CC Part 3) to
+ the Security Target. The precise method to apply the criteria is determined by the evaluation
+ methodology that is used.
+ The TOE evaluation is more complex. The principal inputs to a
+ TOE evaluation are: the evaluation evidence, which includes
+ the TOE and ST, but will usually also include input from the
+ development environment, such as design documents or developer
+ test results.
+ The TOE evaluation consists of applying the SARs (from the
+ Security Target) to the evaluation evidence. The precise
+ method to apply a specific SAR is determined by the evaluation
+ methodology that is used.
+ How the results of applying the SARs are documented, and what
+ reports need to be generated and in what detail, is determined
+ by both the evaluation methodology that is used and the
+ evaluation scheme under which the evaluation is carried out.
+ The result of the TOE evaluation process is either:
+
+ A statement that not all SARs have been met and that
+ therefore there is not the specified level of assurance
+ that the TOE meets the SFRs as stated in the ST;
+
+ A statement that all SARs have been met, and that
+ therefore there is the specified level of assurance that
+ the TOE meets the SFRs as stated in the ST.
+
+ The TOE evaluation may be carried out after TOE development
+ has finished, or in parallel with TOE development.
+ The method of stating ST/TOE evaluation results is described
+ in Clause . These results also
+ identify the PP(s) and package(s) to which the TOE claims
+ conformance, and these constructs are described in the next
+ Clause.
+ The CC functional and assurance components may be used exactly
+ as defined in CC Part 2 and CC Part 3, or they may be tailored
+ through the use of permitted operations. When using
+ operations, the PP/ST author should be careful that the
+ dependency needs of other requirements that depend on this
+ requirement are satisfied. The permitted operations are
+ selected from the following set:
+
+ Iteration: allows a component to be used more than once
+ with varying operations;
+
+ Assignment: allows the specification of parameters;
+
+ Selection: allows the specification of one or more items
+ from a list; and
+
+ Refinement: allows the addition of details.
+
+ The assignment and selection operations are permitted only
+ where specifically indicated in a component. Iteration and
+ refinement are permitted for all components. The operations
+ are described in more detail below.
+ The CC Part 2 Annexes provide the guidance on the valid
+ completion of selections and assignments. This guidance
+ provides normative instructions on how to complete operations,
+ and those instructions shall be followed unless the PP/ST
+ author justifies the deviation:
+
+ ``None'' is only available as a choice for the completion
+ of a selection if explicitly provided.
+
+ The lists provided for the completion of selections must
+ be non-empty. If a ``None'' option is chosen, no
+ additional selection options may be chosen. If ``None''
+ is not given as an option in a selection, it is
+ permissible to combine the choices in a selection with
+ ``and''s and ``or''s, unless the selection explicitly
+ states ``choose one of''.
+ Selection operations may be combined by iteration where
+ needed. In this case, the applicability of the option
+ chosen for each iteration should not overlap the subject
+ of the other iterated selection, since they are intended
+ to be exclusive.
+ For the completion of assignments, the CC Part 2 Annexes
+ shall be consulted in order to determine when ``None''
+ would be a valid completion.
+
+ The iteration operation may be performed on every
+ component. The PP/ST author performs an iteration operation
+ by including multiple requirements based on the same
+ component. Each iteration of a component shall be different
+ from all other iterations of that component, which is
+ realised by completing assignments and selections in a
+ different way, or by applying refinements to it in a
+ different way.
+ Different iterations should be uniquely identified to allow
+ clear rationales and tracings to and from these
+ requirements.
+ It is important to note that sometimes an iteration
+ operation can be used with components where could also be
+ possible to perform an assignment operation with a range or
+ list of values instead of iterate them. In that case the
+ author can select the most appropriate alternative,
+ considering if there is a necessity of providing a whole
+ rationale for the range of values or if it is necessary to
+ have a separate one for each of them. The author should also
+ keep in mind if individual traces are required for those
+ values.
+ An assignment operation occurs where a given component
+ contains an element with a parameter that may be set by the
+ PP/ST author. The parameter may be an unrestricted variable,
+ or a rule that narrows the variable to a specific range of
+ values.
+ Whenever an element in a PP contains an assignment, a PP
+ author shall do one of four things:
+
+ leave the assignment uncompleted. The PP author could
+ include ``When the
+ defined number of unsuccessful authentication attempts
+ has been met or surpassed, the TSF shall
+ [assignment: list of actions].'' in the PP.
+
+ complete the assignment. As an example, the PP author
+ could include ``When
+ the defined number of unsuccessful authentication
+ attempts has been met or surpassed, the TSF shall
+ prevent that external entity from binding to any
+ subject in the future.'' in the PP.
+
+ narrow the assignment, to further limit the range of
+ values that is allowed. As an example, the PP author
+ could include ``The
+ TSF shall detect when [assignment: positive
+ integer between 4 and 9] unsuccessful authentication
+ attempts occur ...'' in the PP.
+
+ transform the assignment to a selection, thereby
+ narrowing the assignment. As an example, the PP author
+ could include ``When
+ the defined number of unsuccessful authentication
+ attempts has been met or surpassed, the TSF shall
+ [selection: prevent that user from binding to any
+ subject in the future, notify the
+ administrator].'' in the PP.
+
+ Whenever an element in an ST contains an assignment, an ST
+ author shall complete that assignment, as indicated in b)
+ above. Options a), c) and d) are not allowed for STs.
+ The values chosen in options b), c) and d) shall conform to
+ the indicated type required by the assignment.
+ When an assignment is to be completed with a set
+ (e.g. subjects), one may list a set of subjects, but also
+ some description of the set from which the elements of the
+ set can be derived such as:
+
+ all subjects
+
+ all subjects of type X
+
+ all subjects except subject a
+
+ as long as it is clear which subjects are meant.
+
+ The selection operation occurs where a given component
+ contains an element where a choice from several items has to
+ be made by the PP/ST author.
+ Whenever an element in a PP contains a selection, the PP
+ author may do one of three things:
+
+ leave the selection uncompleted.
+
+ complete the selection by choosing one or more items.
+
+ restrict the selection by removing some of the choices,
+ but leaving two or more.
+
+ Whenever an element in an ST contains a selection, an ST
+ author shall complete that selection, as indicated in b)
+ above. Options a) and c) are not allowed for STs.
+ The item or items chosen in b) and c) shall be taken from
+ the items provided in the selection.
+ The refinement operation can be performed on every
+ requirement. The PP/ST author performs a refinement by
+ altering that requirement. The first rule for a refinement
+ is that a TOE meeting the refined requirement also meets the
+ unrefined requirement in the context of the PP/ST (i.e. a
+ refined requirement must be ``stricter'' than the original
+ requirement). If a refinement does not meet this rule, the
+ resulting refined requirement is considered to be an
+ extended requirement and shall be treated as such.
+ The first rule for a refinement is that a TOE meeting the
+ refined requirement also meets the unrefined requirement in
+ the context of the PP/ST (i.e. a refined requirement must be
+ ``stricter'' than the original requirement)
+ The only exception to this rule is that a PP/ST author is
+ allowed to refine a SFR to apply to some but not all
+ subjects, objects, operations, security attributes and/or
+ external entities.
+ However, this exception does not apply to refining SFRs that
+ are taken from PPs that compliance is being claimed to;
+ these SFRs may not be refined to apply to fewer subjects,
+ objects, operations, security attributes and/or external
+ entities than the SFR in the PP.
+ The second rule for a refinement is that the refinement
+ shall be related to the original component.
+ A special case of refinement is an editorial refinement,
+ where a small change is made in a requirement,
+ i.e. rephrasing a sentence due to adherence to proper
+ English grammar, or to make it more understandable to the
+ reader. This change is not allowed to modify the meaning of
+ the requirement in any way.
+ Dependencies may exist between components. Dependencies arise
+ when a component is not self sufficient and relies upon the
+ presence of another component to provide security
+ functionality or assurance.
+ The functional components in CC Part 2 typically have
+ dependencies on other functional components as do some of the
+ assurance components in CC Part 3 which may have dependencies
+ on other CC Part 3 components. CC Part 2 dependencies on CC
+ Part 3 components may also be defined. However, this does not
+ preclude extended functional components having dependencies on
+ assurance components or vice versa.
+ Component dependency descriptions are determined by consulting
+ the CC Part 2 and CC Part 3 component definitions. In order to
+ ensure completeness of the TOE security requirements,
+ dependencies should be satisfied when requirements based on
+ components with dependencies are incorporated into PPs and
+ STs. Dependencies should also be considered when constructing
+ packages.
+ In other words: if component A has a dependency on component
+ B, this means that whenever a PP/ST contains a security
+ requirement based on component A, the PP/ST shall also contain
+ one of :
+
+ a security requirement based on component B, or
+
+ a security requirement based on a component that is
+ hierarchically higher than B, or
+
+ a justification why the PP/ST does not contain a security
+ requirement based on component B.
+
+ In cases a) and b), when a security requirement is included
+ because of a dependency, it may be necessary to complete
+ operations (assignment, iteration, refinement, selection) on
+ that security requirement in a particular manner to make sure
+ that it actually satisfies the dependency.
+ In case c), the justification that a security requirement is
+ not included should address either:
+
+ why the dependency is not necessary or useful, or
+
+ that the dependency has been addressed by the operational
+ environment of the TOE, in which case the justification
+ should describe how the security objectives for the
+ operational environment address this dependency, or
+
+ that the dependency has been addressed by the other SFRs
+ in some other manner (extended SFRs, combinations of SFRs
+ etc.)
+
+ In the CC it is mandatory to base requirements on
+ components from CC Part 2 or CC Part 3 with two
+ exceptions:
+
+ there are security objectives for the TOE that can not be
+ translated to Part 2 SFRs, or there are third party
+ requirements (e.g., laws, standards) that can not be
+ translated to Part 3 SARs (e.g. regarding evaluation of
+ cryptography);
+
+ a security objective can be translated, but only with
+ great difficulty and/or complexity based on components in
+ CC Part 2 and/or CC Part 3.
+
+ In both cases the PP/ST author is required to define his own
+ components. These newly defined components are called extended
+ components. A precisely defined extended component is needed
+ to provide context and meaning to the extended SFRs and SARs
+ based on that component.
+ After the new components have been defined correctly, the
+ PP/ST author can then base one or more SFRs or SARs on these
+ newly defined extended components and use them in the same way
+ as the other SFRs and SARs. From this point on, there is no
+ further distinction between SARs and SFRs based on the CC and
+ SARs and SFRs based on extended components. Refer to CC Part 3
+ and for further
+ requirements on extended components.
+ To allow consumer groups and communities of interest to
+ express their security needs, and to facilitate writing STs,
+ this part of the CC provides two special constructs: packages
+ and Protection Profiles (PPs). In the following two subclauses
+ these constructs are described in more detail, followed by a
+ subclause on how these constructs can be used.
+ A package is a named set of security requirements. A package
+ is either
+
+ a functional package, containing only SFRs, or
+
+ an assurance package, containing only SARs.
+
+ Mixed packages containing both SFRs and SARs are not allowed.
+ A package can be defined by any party and is intended to be
+ re-usable. To this goal it should contain requirements that
+ are useful and effective in combination. Packages can be used
+ in the construction of larger packages, PPs and STs. At
+ present there are no criteria for the evaluation of packages,
+ therefore any set of SFRs or SARs can be a package.
+ Examples of assurance packages are the evaluation assurance
+ levels (EALs) that are defined in CC Part 3. At the time
+ of writing there are no functional packages for this version
+ of the CC.
+ Whereas an ST always describes a specific TOE (e.g. the
+ MinuteGap v18.5 Firewall), a PP is intended to describe a TOE
+ type (e.g. firewalls). The same PP may therefore be used as a
+ template for many different STs to be used in different
+ evaluations. A detailed description of PPs is given in .
+ In general an ST describes requirements for a TOE and is
+ written by the developer of that TOE, while a PP describes
+ the general requirements for a TOE type, and is therefore
+ typically written by:
+
+ A user community seeking to come to a consensus on the
+ requirements for a given TOE type;
+
+ A developer of a TOE, or a group of developers of
+ similar TOEs wishing to establish a minimum baseline for
+ that type of TOE;
+
+ A government or large corporation specifying its
+ requirements as part of its acquisition process.
+
+ The PP determines the allowed type of conformance of the ST
+ to the PP. That is, the PP states (in the PP conformance
+ statement, see subclause )
+ what the allowed types of conformance for the ST are:
+
+ if the PP states that strict conformance is required,
+ the ST shall conform to the PP in a strict manner;
+
+ if the PP states that demonstrable conformance is
+ required, the ST shall conform to the PP in a strict or
+ demonstrable manner.
+
+ Restating this in other words, an ST is only allowed to
+ conform in a PP in a demonstrable manner, if the PP
+ explicitly allows this.
+ If an ST claims conformance to multiple PPs, it shall
+ conform (as described above) to each PP in the manner
+ ordained by that PP. This may mean that the ST conforms
+ strictly to some PPs and demonstrably to other PPs.
+ Note that either the ST conforms to the PP in question or it
+ does not. The CC does not recognise ``partial''
+ conformance. It is therefore the responsibility of the PP
+ author to ensure the PP is not overly onerous, prohibiting
+ PP/ST authors in claiming conformance to the PP.
+ An ST is equivalent or more restrictive than a PP if:
+
+ all TOEs that meet the ST also meet the PP, and
+
+ all operational environments that meet the PP also meet
+ the ST.
+
+ or, informally, the ST shall levy the same or more,
+ restrictions on the TOE and the same or less restrictions on
+ the operational environment of the TOE.
+ This general statement can be made more specific for various
+ subclauses of the ST:
+ Security problem definition: The
+ conformance rationale in the ST shall demonstrate that
+ the security problem definition in the ST is equivalent
+ (or more restrictive) than the security problem
+ definition in the PP. This means that:
+
+ all TOEs that would meet the security problem
+ definition in the ST also meet the security problem
+ definition in the PP;
+
+ all operational environments that would meet the
+ security problem definition in the PP would also
+ meet the security problem definition in the ST.
+ Security objectives: The conformance
+ rationale in the ST shall demonstrate that the security
+ objectives in the ST is equivalent (or more restrictive)
+ than the security objectives in the PP. This means that:
+
+ all TOEs that would meet the security objectives for
+ the TOE in the ST also meet the security objectives
+ for the TOE in the PP;
+
+ all operational environments that would meet the
+ security objectives for the operational environment
+ in the PP would also meet the security objectives
+ for the operational environment in the ST.
+
+ If strict conformance for protection profiles is specified
+ then the following requirements apply:
+ Security problem definition:
+
+ The ST shall contain the security problem definition of the PP and may specify additional
+ threats and OSPs; it shall contain all assumptions as defined in the PP, with two
+ possible exceptions as explained in the next two bullets;
+ an assumption (or a part of an assumption) specified in the PP may be omitted from the ST, if
+ all security objectives for the operational environment defined in the PP addressing this
+ assumption (or this part of an assumption) are replaced by security objectives for the TOE in
+ the ST;
+ a new assumption may be added in the ST to the set of assumptions defined in the PP, if this
+ new assumption does not mitigate a threat (or part of a threat) meant to be addressed by
+ security objectives for the TOE in the PP and if this assumption doesn't fulfil an OSP (or a
+ part of an OSP) meant to be addressed by security objectives for the TOE in the PP; Security objectives: The ST:
+
+ shall contain all security objectives for the TOE of the PP but may specify additional security
+ objectives for the TOE;
+ shall contain all security objectives for the operational environment as defined in the
+ PP with two exceptions as explained in the next two bullet points;
+ may specify that certain objectives for the operational environment in the PP are security
+ objectives for the TOE in the ST. This is called re-assigning a security objective. If a security
+ objective is re-assigned to the TOE the security objectives justification has to make clear which
+ assumption or part of the assumption may not be necessary any more;
+ may specify additional objectives for the operational environment, if these new objectives do not
+ mitigate a threat (or part of a threat) meant to be addressed by security objectives of the TOE in
+ the PP and if these new objectives do not fulfil an OSP (or a part of an OSP) meant to be
+ addressed by security objectives of the TOE in the PPSecurity requirements: The ST shall contain
+ all SFRs and SARs in the PP, but may claim additional or
+ hierarchically stronger SFRs and SARs. The completion of
+ operations in the ST must be consistent with that in the
+ PP; either the same completion will be used in the ST as
+ that in the PP or one that makes the requirement more
+ restrictive (the rules of refinement apply).
+
+ If demonstrable conformance for protection profiles is
+ specified then the following requirements apply:
+
+ the ST shall contain a rationale on why the ST is
+ considered to be ``equivalent or more restrictive'' than
+ the PP.
+
+ Demonstrable conformance allows a PP author to describe
+ a common security problem to be solved and provide
+ generic guidelines to the requirements necessary for its
+ resolution, in the knowledge that there is likely to be
+ more than one way of specifying a resolution.
+
+ PP evaluation is optional. Evaluation is performed by applying
+ the criteria to them as listed in
+ CC Part 3. The goal of such an evaluation is to demonstrate
+ that the PP is complete, consistent, and technically sound and
+ suitable for use as a template on which to build another PP or
+ an ST.
+ Basing a PP/ST on an evaluated PP has two advantages:
+
+ There is much less risk that there are errors, ambiguities
+ or gaps in the PP. If any problems with a PP (that would
+ have been caught by evaluating that PP) are found during
+ the writing or evaluation of the new ST, significant time
+ may elapse before the PP is corrected.
+
+ Evaluation of the new PP/ST may often re-use evaluation
+ results of the evaluated PP, resulting in less effort
+ for evaluating the new PP/ST.
+
+ If an ST claims to be conformant to one or more packages
+ and/or Protection Profiles, the evaluation of that ST will
+ (among other properties of that ST) demonstrate that the ST
+ actually conforms to these packages and/or PPs that they claim
+ conformance to. Details of this determination of conformance
+ can be found in .
+ This allows the following process:
+
+ An organisation seeking to acquire a particular type of
+ IT security product develops their security needs into a
+ PP, then has this evaluated and publishes it;
+
+ A developer takes this PP, writes an ST that claims
+ conformance to the PP and has this ST evaluated;
+
+ The developer then builds a TOE (or uses an existing
+ one) and has this evaluated against the ST.
+
+ The result is that the developer can prove that his TOE is
+ conformant to the security needs of the organisation: the
+ organisation can therefore acquire that TOE. A similar line of
+ reasoning applies to packages.
+ The CC also allows PPs to conform to other PPs, allowing
+ chains of PPs to be constructed, each based on the previous
+ one(s).
+ For instance, one could take a PP for an Integrated Circuit
+ and a PP for a Smart Card OS, and use these to construct a
+ Smart Card PP (IC and OS) that claims conformance to the
+ other two. One could then write a PP on Smart Cards for
+ Public Transport based on the Smart Card PP and a PP on
+ Applet Loading. Finally, a developer could then construct an
+ ST based on this Smart Cards for Public Transport PP.
+ To allow the definition of modular Protection Profiles that address optional TOE's security features,
+ this chapter introduces two constructs: PP-Modules and PP-Configurations, as well as the way they can be used to evaluate compliant products.
+ A PP-Module is a consistent set of elements (threats, assumptions, organisational policies, objectives and security requirements) with a unique reference.
+ Unlike Protection Profiles, PP-Modules address optional security features of a given type of TOE that cannot be required uniformly for all products of this kind.
+ Each PP-Module refers to at least one Base Protection Profile (or Base-PP)
+ that provides the definition of the TOE type and the mandatory requirements to fulfill.
+ The PP-Module specifies the modified TOE type, complements these requirements and has to
+ be used with the Base-PPs: a PP-Module may introduce new elements to the Base-PPs and
+ may also refine or interpret some of the elements of the Base-PPs.
+ If the PP-Module refers to several Base Protection Profiles, this set of Base-PPs have to
+ be used simultaneously for the evaluation and usage of the PP-Module.
+ The PP-Module can also refer to alternative sets of Base-PPs, in the case the PP-Module could comply with alternative Base-PPs depending of the usage.
+ The evaluation of a PP-Module alone is meaningless. A PP-Module has to be evaluated as part of a PP-Configuration, at least with its
+ mandatory Base-PPs.
+ A PP-Configuration results from the combination of at least one PP-Module with its
+ Base-PPs, without any additional content: a PP-Configuration is much like a Protection
+ Profile that would include all the elements from the Base-PPs and the PP-Modules.
+ A PP-Configuration can select more PPs than the Base-PPs of the PP-Modules, but at
+ least all of the Base-PPs of the referred PP-Modules must be included in the
+ PP-Configuration.
+ If the PP-Module defines alternative sets of Base-PPs, only one of these sets must be used in the PP-Configuration.
+ A PP-Configuration holds a unique reference and identifies all the PP components: selected Base-PPs and selected PP-Modules.
+ A PP-Configuration can only combine certified Base-PPs to PP-Modules.
+ Evaluation rules for PP-Configurations are similar to the ones for standard PPs. These rules are described in Class ACE, in CC Part 3.
+ PP-Modules are used to build specific PP-Configurations on top of one or more Base-PPs.
+ PP-Modules are used in Security Targets only as part of well-identified PP-Configurations.
+ PP-Configurations are used like Protection Profiles. A Security Target can claim
+ conformity to a PP-Configuration provided this PP-Configuration has been evaluated.
+ Henceforth, the evaluation of the ST can rely on the results of the PP-Configuration
+ evaluation results as usual.
+ Note that the evaluation of a PP-Configuration can arise in two situations, with no impact on the evaluation methodology:
+ Independently of any product evaluation, or
+ As the first step of the evaluation of a Security Target that claims conformity with the PP-Configuration.
+ Otherwise the conformance claim is meaningless and the ST evaluation would fail in this aspect.
+
+ In practice, a ST that claims conformance with a non-certified PP-Configuration can still be evaluated with a
+ conformance claim against the Base-PP of the PP-Configuration; the elements of the ST that meet the PP-Modules
+ of the PP-Configuration would be evaluated as standard additions to the Base-PP, proper to the TOE.
+ This clause presents the expected results from PP and ST/TOE
+ evaluations performed according to the CEM.
+ PP evaluations lead to catalogues of evaluated PPs.
+ An ST evaluation leads to intermediate results that are used
+ in the frame of a TOE evaluation.
+ ST/TOE evaluations lead to catalogues of evaluated TOEs. In
+ many cases these catalogues will refer to the IT products that
+ the TOEs are derived from rather than the specific
+ TOE. Therefore, the existence of an IT product in a catalogue
+ should not be construed as meaning that the whole IT product
+ has been evaluated; instead the actual extent of the ST/TOE
+ evaluation is defined by the ST. Refer to the bibliography for
+ examples of such catalogues.
+ STs may be based on packages, evaluated PPs or non-evaluated
+ PPs - however this is not mandatory, as STs do not have to be
+ based on anything at all.
+ Evaluation should lead to objective and repeatable results
+ that can be cited as evidence, even if there is no absolute
+ objective scale for representing the results of a security
+ evaluation. The existence of a set of evaluation criteria is a
+ necessary pre-condition for evaluation to lead to a meaningful
+ result and provides a technical basis for mutual recognition
+ of evaluation results between evaluation authorities.
+ An evaluation result represents the findings of a specific
+ type of investigation of the security properties of a
+ TOE. Such a result does not automatically guarantee fitness
+ for use in any particular application environment. The
+ decision to accept a TOE for use in a specific application
+ environment is based on consideration of many security issues
+ including the evaluation findings.
+ CC Part 3 contains the evaluation criteria that an evaluator
+ is obliged to consult in order to state whether a PP is
+ complete, consistent, and technically sound and hence suitable
+ for use in developing an ST.
+ The results of the evaluation shall also include a
+ ``Conformance Claim'' (see Subclause )).
+ This chapter presents the expected results from PP-Configuration evaluation and ST/TOE evaluations according to the Class ACE (Protection Profile Configuration Evaluation) presented in CEM class .
+ The evaluated PP-Configurations integrate the catalogue of evaluated PPs, linked to the Base-PPs of the PP-Configurations.
+ STs may be based on packages, evaluated PPs or non-evaluated PPs, evaluated PP-Configurations or non-evaluated PP-Configurations, or built-in independently.
+ CC Part 3 contains the evaluation criteria that an evaluator is obliged to follow in order to state whether a PP-Configuration is complete, consistent, and technically sound and hence suitable for use in developing an ST.
+ The results of the evaluation shall also include a "Conformance Claim" (see Subclause ).
+ CC Part 3 contains the evaluation criteria that an evaluator
+ is obliged to consult in order to determine whether
+ sufficient assurance exists that the TOE satisfies the SFRs
+ in the ST. Evaluation of the TOE shall therefore result in a
+ pass/fail statement for the ST. If both the ST and the TOE
+ evaluation have resulted in a pass statement, the underlying
+ product is eligible for inclusion in a registry. The results
+ of evaluation shall also include a ``Conformance Claim'' as
+ defined in the next subclause.
+ It may be the case that the evaluation results are
+ subsequently used in a certification process, but this
+ certification process is outside the scope of the CC.
+ The conformance claim indicates the source of the collection
+ of requirements that is met by a PP or ST that passes its
+ evaluation. This conformance claim contains a CC conformance
+ claim that:
+
+ describes the version of the CC to which the PP
+ or ST claims conformance.
+
+ describes the conformance to CC Part 2 (security
+ functional requirements) as either:
+ CC Part 2 conformant - A PP or ST
+ is CC Part 2 conformant if all SFRs in that PP
+ or ST are based only upon functional components in
+ CC Part 2, or
+ CC Part 2 extended - A PP or ST
+ is CC Part 2 extended if at least one SFR in
+ that PP or ST is not based upon functional
+ components in CC Part 2.
+
+ describes the conformance to CC Part 3 (security
+ assurance requirements) as either:
+ CC Part 3 conformant - A PP or ST
+ is CC Part 3 conformant if all SARs in that PP
+ or ST are based only upon assurance components in
+ CC Part 3, or
+ CC Part 3 extended - A PP or ST
+ is CC Part 3 extended if at least one SAR in
+ that PP or ST is not based upon assurance components
+ in CC Part 3.
+
+ Additionally, the conformance claim may include a statement
+ made with respect to packages, in which case it consists of
+ one of the following:
+ Package name Conformant - A PP or ST is
+ conformant to a pre-defined package (e.g. EAL) if:
+
+ the SFRs of that PP or ST are identical to the SFRs
+ in the package, or
+
+ the SARs of that PP or ST are identical to the SARs
+ in the package.
+ Package name Augmented - A PP or ST is
+ an augmentation of a predefined package if:
+
+ the SFRs of that PP or ST contain all SFRs in the
+ package, but have at least one additional SFR or one
+ SFR that is hierarchically higher than an SFR in the
+ package.
+
+ the SARs of that PP or ST contain all SARs in the
+ package, but have at least one additional SAR or one
+ SAR that is hierarchically higher than an SAR in the
+ package.
+
+ Note that when a TOE is successfully evaluated to a given
+ ST, any conformance claims of the ST also hold for the
+ TOE. A TOE can therefore also be e.g. CC Part 2 conformant.
+ Finally, the conformance claim may also include two
+ statements with respect to Protection Profiles:
+ PP Conformant - A PP or TOE meets
+ specific PP(s), which are listed as part of the
+ conformance result.
+ Conformance Statement (Only for PPs) -
+ This statement describes the manner in which PPs or STs
+ must conform to this PP: strict or demonstrable. For
+ more information on this Conformance Statement, see
+ .
+
+ Besides the standard CC conformance claim regarding the version of the CC, the CC Part 2 and Part 3, the SFR and SAR packages, and the standard PP claim,
+
+ a PP-Configuration has to provide a conformance statement applicable to the conformant STs, either strict or demonstrable, that meet the conformance statements of the Base-PP(s),
+
+ a ST may claim conformity with one or more PP-Configurations.
+
+ Once an ST and a TOE have been evaluated, asset owners can
+ have the assurance (as defined in the ST) that the TOE,
+ together with the operational environment, counters the
+ threats. The evaluation results may be used by the asset
+ owner in deciding whether to accept the risk of exposing the
+ assets to the threats.
+ However, the asset owner should carefully check whether:
+
+ the Security Problem Definition in the ST matches the
+ security problem of the asset owner;
+
+ the Operational Environment of the asset owner conforms
+ (or can be made to conform) to the security objectives
+ for the Operational Environment described in the ST.
+
+ If either of these is not the case, the TOE may not be
+ suitable for the purposes of the asset owner.
+ Additionally, once an evaluated TOE is in operation, it is
+ still possible that previously unknown errors or
+ vulnerabilities in the TOE may surface. In that case, the
+ developer may correct the TOE (to repair the
+ vulnerabilities) or change the ST to exclude the
+ vulnerabilities from the scope of the evaluation. In either
+ case, the old evaluation results may no longer be valid.
+ If it is deemed necessary that confidence is regained,
+ re-evaluation is needed. The CC may be used for this
+ re-evaluation, but detailed procedures for re-evaluation are
+ outside the scope of this part of the CC.
+ The goal of this annex is to explain the Security Target (ST)
+ concept. This annex does not define the criteria; this definition can be found in CC Part
+ 3 and is supported by the documents given in the bibliography.
+ This annex consists of four major parts:
+ What an ST must contain. This is
+ summarised in Subclause , and described in more detail
+ in Subclauses - . These subclauses describe the
+ mandatory contents of the ST, the interrelationships
+ between these contents, and provide examples.
+ How an ST should be used. This is
+ summarised in Subclause , and described in more detail in
+ subclause . These
+ subclauses describe how an ST should be used, and some of
+ the questions that can be answered with an ST.
+ Low Assurance STs. Low Assurance STs are
+ STs with reduced content. They are described in detail in
+ subclause .
+ Claiming compliance with
+ standards. Subclause describes how an ST writer can claim that
+ the TOE meets a particular standard.
+
+ Figure portrays the mandatory
+ contents of an ST that are given in CC Part 3. Figure may also be used as a structural outline
+ of the ST, though alternative structures are allowed. For
+ instance, if the security requirements rationale is
+ particularly bulky, it could be included in an appendix of the
+ ST instead of in the security requirements subclause. The
+ separate subclauses of an ST and the contents of those
+ subclauses are briefly summarised below and explained in much
+ more detail in subclauses to . An ST normally contains:
+ an ST introduction containing three
+ narrative descriptions of the TOE on different levels of
+ abstraction;
+ a conformance claim, showing whether the
+ ST claims conformance to any PPs and/or packages, and if
+ so, to which PPs and/or packages;
+ a security problem definition, showing
+ threats, OSPs and assumptions;
+ security objectives, showing how the
+ solution to the security problem is divided between
+ security objectives for the TOE and security objectives
+ for the operational environment of the TOE;
+ extended components definition
+ (optional), where new components (i.e. those not included
+ in CC Part 2 or CC Part 3) may be defined. These new
+ components are needed to define extended functional and
+ extended assurance requirements;
+ security requirements, where a
+ translation of the security objectives for the TOE into a
+ standardised language is provided. This standardised
+ language is in the form of SFRs. Additionally this
+ subclause defines the SARs;
+ a TOE summary specification, showing how
+ the SFRs are implemented in the TOE.
+
+ There also exists low assurance STs which have reduced
+ contents; these are described in detail in subclause . All other parts of this Annex assume an ST
+ with full contents.
+ A typical ST fulfils two roles:
+
+ Before and during the evaluation, the ST specifies
+ ``what is to be evaluated''. In this role, the ST serves
+ as a basis for agreement between the developer and the
+ evaluator on the exact security properties of the TOE
+ and the exact scope of the evaluation. Technical
+ correctness and completeness are major issues for this
+ role. Subclause describes how
+ the ST should be used in this role.
+
+ After the evaluation, the ST specifies ``what was
+ evaluated''. In this role, the ST serves as a basis for
+ agreement between the developer or re-seller of the TOE
+ and the potential consumer of the TOE. The ST describes
+ the exact security properties of the TOE in an abstract
+ manner, and the potential consumer can rely on this
+ description because the TOE has been evaluated to meet
+ the ST. Ease of use and understandability are major
+ issues for this role. Subclause describes how the ST should be used
+ in this role.
+
+ Two roles (among many) that an ST should not fulfil are:
+ a detailed specification: An ST is
+ designed to be a security specification on a relatively
+ high level of abstraction. An ST should, in general, not
+ contain detailed protocol specifications, detailed
+ descriptions of algorithms and/or mechanisms, long
+ description of detailed operations etc.
+ a complete specification: An ST is
+ designed to be a security specification and not a
+ general specification. Unless security-relevant,
+ properties such as interoperability, physical size and
+ weight, required voltage etc. should not be part of an
+ ST. This means that in general an ST may be a part of a
+ complete specification, but not a complete specification
+ itself.
+
+ The ST introduction describes the TOE in a narrative way on
+ three levels of abstraction:
+
+ the ST reference and the TOE reference, which provide
+ identification material for the ST and the TOE that the ST
+ refers to;
+
+ the TOE overview, which briefly describes the TOE;
+
+ the TOE description, which describes the TOE in more
+ detail.
+
+ An ST contains a clear ST reference that identifies that
+ particular ST. A typical ST reference consists of title,
+ version, authors and publication date. An example of an ST
+ reference is ``MauveRAM Database ST, version 1.3, MauveCorp
+ Specification Team, 11 October 2002''.
+ An ST also contains a TOE reference that identifies the TOE
+ that claims conformance to the ST. A typical TOE reference
+ consists of developer name, TOE name and TOE version
+ number. An example of a TOE reference is ``MauveCorp
+ MauveRAM Database v2.11''. As a single TOE may be evaluated
+ multiple times, for instance by different consumers of that
+ TOE, and therefore have multiple STs, this reference is not
+ necessarily unique.
+ If the TOE is constructed from one or more well-known
+ products, it is allowed to reflect this in the TOE
+ reference, by referring to the product name(s). However,
+ this should not be used to mislead consumers: situations
+ where major parts or security functionalities were not
+ considered in the evaluation, yet the TOE reference does not
+ reflect this are not allowed.
+ The ST reference and the TOE reference facilitate indexing
+ and referencing the ST and TOE and their inclusion in
+ summaries of lists of evaluated TOEs/Products.
+ The TOE overview is aimed at potential consumers of a TOE
+ who are looking through lists of evaluated TOEs/Products to
+ find TOEs that may meet their security needs, and are
+ supported by their hardware, software and firmware. The
+ typical length of a TOE overview is several paragraphs.
+ To this end, the TOE overview briefly describes the usage of
+ the TOE and its major security features, identifies the TOE
+ type and identifies any major non-TOE
+ hardware/software/firmware required by the TOE.
+ The description of the usage and major security features
+ of the TOE is intended to give a very general idea of what
+ the TOE is capable of in terms of security, and what it
+ can be used for in a security context. This subclause
+ should be written for (potential) TOE consumers,
+ describing TOE usage and major security features in terms
+ of business operations, using language that TOE consumers
+ understand.
+ An example of this is ``The MauveCorp MauveRAM Database
+ v2.11 is a multi-user database intended to be used in a
+ networked environment. It allows 1024 users to be active
+ simultaneously. It allows password/token and biometric
+ authentication, protects against accidental data
+ corruption, and can roll-back ten thousand
+ transactions. Its audit features are highly configurable,
+ so as to allow detailed audit to be performed for some
+ users and transactions, while protecting the privacy of
+ other users and transactions.''
+ The TOE overview identifies the general type of TOE, such
+ as: firewall, VPN-firewall, smart card, crypto-modem,
+ intranet, web server, database, web server and database,
+ LAN, LAN with web server and database, etc.
+ It may be the case that the TOE is not of a readily
+ available type, in which case ``none'' would be
+ acceptable.
+ In some cases, a TOE type can mislead consumers. Examples include:
+
+ certain functionality can be expected of the TOE
+ because of its TOE type, but the TOE does not have
+ this functionality. Examples include:
+
+ an ATM-card type TOE, which does not support any
+ identification/authentication functionality;
+
+ a firewall type TOE, which does not support
+ protocols that are almost universally used;
+
+ a PKI-type TOE, which has no certificate
+ revocation functionality.
+
+ the TOE can be expected to operate in certain
+ operational environments because of its TOE type, but
+ it cannot do so. Examples include:
+
+ a PC-operating system type TOE, which is unable to
+ function securely unless the PC has no network
+ connection, floppy drive, and CD/DVD-player;
+
+ a firewall, which is unable to function securely
+ unless all users that can connect through that
+ firewall are benign.
+
+ While some TOEs do not rely upon other IT, many TOEs
+ (notably software TOEs) rely on additional, non-TOE,
+ hardware, software and/or firmware. In the latter case,
+ the TOE overview is required to identify such non-TOE
+ hardware,software and/or firmware . A complete and fully
+ detailed identification of the additional hardware,
+ software and/or firmware is not necessary, but the
+ identification should be complete and detailed enough for
+ potential consumers to determine the major
+ hardware,software and/or firmware needed to use the TOE.
+ Example hardware/software/firmware identifications are:
+
+ a standard PC with a 1GHz or faster processor and
+ 512MB or more RAM, running version 3.0 Update 6b, c,
+ or 7, or version 4.0 of the Yaiza operating system;
+
+ a standard PC with a 1GHz or faster version processor
+ and 512MB or more RAM, running version 3.0 Update 6d
+ of the Yaiza operating system and the WonderMagic 1.0
+ Graphics card with the 1.0 WM Driver Set;
+
+ a standard PC with version 3.0 of the Yaiza OS (or
+ higher);
+
+ a CleverCard SB2067 integrated circuit;
+
+ a CleverCard SB2067 integrated circuit running v2.0 of
+ the QuickOS smart card operating system;
+
+ the December 2002 installation of the LAN of the
+ Director-General's Office of the Department of
+ Traffic.
+
+ A TOE description is a narrative description of the TOE,
+ likely to run to several pages. The TOE description should
+ provide evaluators and potential consumers with a general
+ understanding of the security capabilities of the TOE, in
+ more detail than was provided in the TOE overview. The TOE
+ description may also be used to describe the wider
+ application context into which the TOE will fit.
+ The TOE description discusses the physical scope of the TOE:
+ a list of all hardware, firmware, software and guidance
+ parts that constitute the TOE. This list should be described
+ at a level of detail that is sufficient to give the reader a
+ general understanding of those parts.
+ The TOE description should also discuss the logical scope of
+ the TOE: the logical security features offered by the TOE at
+ a level of detail that is sufficient to give the reader a
+ general understanding of those features. This description is
+ expected to be in more detail than the major security
+ features described in the TOE overview.
+ An important property of the physical and logical scopes is
+ that they describe the TOE in such a way that there remains
+ no doubt on whether a certain part or feature is in the TOE
+ or whether this part or feature is outside the TOE. This is
+ especially important when the TOE is intertwined with and
+ cannot be easily separated from non-TOE entities.
+ Examples where the TOE is intertwined with non-TOE entities
+ are:
+
+ the TOE is a cryptographic co-processor of a smart card
+ IC, instead of the entire IC;
+
+ the TOE is a smart card IC, except for the cryptographic
+ processor;
+
+ the TOE is the Network Address Translation part of the
+ MinuteGap Firewall v18.5.
+
+ This subclause of an ST describes how the ST conforms with:
+
+ Part 2 and Part 3 of this International Standard;
+
+ Protection Profiles (if any);
+
+ Packages (if any).
+
+ The description of how the ST conforms to the CC consists of
+ two items: the version of the CC that is used and whether the
+ ST contains extended security requirements or not (see
+ Subclause ).
+ The description of conformance of the ST to Protection
+ Profiles means that the ST lists the packages that conformance
+ is being claimed to. For an explanation of this, see Subclause
+ .
+ The description of conformance of the ST to packages means
+ that the ST lists the packages that conformance is being
+ claimed to. For an explanation of this, see Subclause .
+ A Security Target can use PP-Configurations in the same way as standard Protection Profiles. That is, the Conformance claim of a ST can contain a PP claim that identifies the PP-Configurations the ST is conformant with.
+ The security problem definition defines the security problem
+ that is to be addressed. The security problem definition is,
+ as far as the CC is concerned, axiomatic. That is,
+ the process of deriving the security problem definition
+ falls outside the scope of the CC.
+ However, it should be noted that the usefulness of the
+ results of an evaluation strongly depends on the ST, and the
+ usefulness of the ST strongly depends on the quality of the
+ security problem definition. It is therefore often
+ worthwhile to spend significant resources and use
+ well-defined processes and analyses to derive a good
+ security problem definition.
+ Note that according to CC Part 3 it is not mandatory
+ to have statements in all subclauses, an ST with threats
+ does not need to have OSPs and vice versa. Also, any ST may
+ omit assumptions.
+ Also note that where the TOE is physically distributed, it
+ may be better to discuss the relevant threats, OSPs and
+ assumptions separately for distinct domains of the TOE
+ operational environment.
+ This subclause of the security problem definition shows
+ the threats that are to be countered by the TOE, its
+ operational environment, or a combination of the two.
+ A threat consists of an adverse action performed by a
+ threat agent on an asset.
+ Adverse actions are actions performed by a threat agent on
+ an asset. These actions influence one or more properties
+ of an asset from which that asset derives its value.
+ Threat agents may be described as individual entities, but
+ in some cases it may be better to describe them as types
+ of entities, groups of entities etc.
+ Examples of threat agents are hackers, users, computer
+ processes, and accidents. Threat agents may be further
+ described by aspects such as expertise, resources,
+ opportunity and motivation.
+ Examples of threats are:
+
+ a hacker (with substantial expertise, standard
+ equipment, and being paid to do so) remotely copying
+ confidential files from a company network;
+
+ a worm seriously degrading the performance of a
+ wide-area network;
+
+ a system administrator violating user privacy;
+
+ someone on the Internet listening in on confidential
+ electronic communication.
+
+ This subclause of the security problem definition shows
+ the OSPs that are to be enforced by the TOE, its
+ operational environment, or a combination of the two.
+ OSPs are security rules, procedures, or guidelines imposed
+ (or presumed to be imposed) now and/or in the future by an
+ actual or hypothetical organisation in the operational
+ environment. OSPs may be laid down by an organisation
+ controlling the operational environment of the TOE, or
+ they may be laid down by legislative or regulatory
+ bodies. OSPs can apply to the TOE and/or the operational
+ environment of the TOE.
+ Examples of OSPs are:
+
+ All products that are used by the Government must
+ conform to the National Standard for password
+ generation and encryption;
+
+ Only users with System Administrator privilege and
+ clearance of Department Secret shall be allowed to
+ manage the Department Fileserver.
+
+ This subclause of the security problem definition shows
+ the assumptions that are made on the operational
+ environment in order to be able to provide security
+ functionality. If the TOE is placed in an operational
+ environment that does not meet these assumptions, the TOE
+ may not be able to provide all of its security
+ functionality anymore. Assumptions can be on physical,
+ personnel and connectivity of the operational environment.
+ Examples of assumptions are:
+
+ Assumptions on physical aspects of the operational environment:
+
+ It is assumed that the TOE will be placed in a
+ room that is designed to minimise electromagnetic
+ emanations;
+
+ It is assumed that the administrator consoles of
+ the TOE will be placed in a restricted access
+ area.
+
+ Assumptions on personnel aspects of the operational
+ environment:
+
+ It is assumed that users of the TOE will be
+ trained sufficiently in order to operate the TOE;
+
+ It is assumed that users of the TOE are approved
+ for information that is classified as National
+ Secret;
+
+ It is assumed that users of the TOE will not write
+ down their passwords.
+
+ Assumptions on connectivity aspects of the operational
+ environment:
+
+ It is assumed that a PC workstation with at least
+ 10GB of disk space is available to run the TOE on;
+
+ It is assumed that the TOE is the only non-OS
+ application running on this workstation;
+
+ It is assumed that the TOE will not be connected
+ to an untrusted network.
+
+ Note that during the evaluation these assumptions are
+ considered to be true: they are not tested in any way. For
+ these reasons, assumptions can only be made on the
+ operational environment. Assumptions can never be made on
+ the behaviour of the TOE because an evaluation consists of
+ evaluating assertions made about the TOE and not by
+ assuming that assertions on the TOE are true.
+ The security objectives are a concise and abstract statement
+ of the intended solution to the problem defined by the
+ security problem definition. The role of the security
+ objectives is threefold:
+
+ provide a high-level, natural language solution of the
+ problem;
+
+ divide this solution into two part wise solutions, that
+ reflect that different entities each have to address a
+ part of the problem;
+
+ demonstrate that these part wise solutions form a
+ complete solution to the problem.
+
+ The security objectives consist of a set of short and
+ clear statements without overly much detail that together
+ form a high-level solution to the security problem. The
+ level of abstraction of the security objectives aims at
+ being clear and understandable to knowledgeable potential
+ consumers of the TOE. The security objectives are in
+ natural language.
+ In an ST the high-level security solution, as described by
+ the security objectives, is divided into two part wise
+ solutions. These part wise solutions are called the
+ security objectives for the TOE and the security
+ objectives for the operational environment. This reflects
+ that these part wise solutions are to be provided by two
+ different entities: the TOE, and the operational
+ environment.
+ The TOE provides security functionality to solve a
+ certain part of the problem defined by the security
+ problem definition. This part wise solution is called
+ the security objectives for the TOE and consists of a
+ set of objectives that the TOE should achieve in order
+ to solve its part of the problem.
+ Examples of security objectives for the TOE are:
+
+ The TOE shall keep confidential the content of all
+ files transmitted between it and a Server;
+
+ The TOE shall identify and authenticate all users
+ before allowing them access to the Transmission
+ Service provided by the TOE;
+
+ The TOE shall restrict user access to data according
+ to the Data Access policy described in Annex 3 of
+ the ST.
+
+ If the TOE is physically distributed, it may be better
+ to subdivide the ST subclause containing the security
+ objectives for the TOE into several sub-subclauses to
+ reflect this.
+ The operational environment of the TOE implements
+ technical and procedural measures to assist the TOE in
+ correctly providing its security functionality (which is
+ defined by the security objectives for the TOE). This
+ part wise solution is called the security objectives for
+ the operational environment and consists of a set of
+ statements describing the goals that the operational
+ environment should achieve.
+ Examples of security objectives for the operational
+ environment are:
+
+ The operational environment shall provide a
+ workstation with the OS Inux version 3.01b to
+ execute the TOE on;
+
+ The operational environment shall ensure that all
+ human TOE users receive appropriate training before
+ allowing them to work with the TOE;
+
+ The operational environment of the TOE shall
+ restrict physical access to the TOE to
+ administrative personnel and maintenance personnel
+ accompanied by administrative personnel;
+
+ The operational environment shall ensure the
+ confidentiality of the audit logs generated by the
+ TOE before sending them to the central Audit Server.
+
+ If the operational environment of the TOE consists of
+ multiple sites, each with different properties, it may
+ be better to subdivide the ST subclause containing the
+ security objectives for the operational environment into
+ several sub-subclauses to reflect this.
+ The ST also contains a security objectives rationale
+ containing two subclauses:
+
+ a tracing that shows which security objectives
+ address which threats, OSPs and assumptions;
+
+ a set of justifications that shows that all threats,
+ OSPs, and assumptions are effectively addressed by
+ the security objectives.
+
+ The tracing shows how the security objectives trace
+ back to the threats, OSPs and assumptions as described
+ in the security problem definition.
+ No spurious objectives: Each
+ security objective traces to at least one threat,
+ OSP or assumption.
+ Complete with respect to the security
+ problem definition: Each threat, OSP and
+ assumption has at least one security objective
+ tracing to it.
+ Correct tracing: Since
+ assumptions are always made by the TOE on the
+ operational environment, security objectives for
+ the TOE do not trace back to assumptions. The
+ tracings allowed by CC Part 3 are depicted in
+ Figure .
+
+ Multiple security objectives may trace to the same
+ threat, indicating that the combination of those
+ security objectives counters that threat. A similar
+ argument holds for OSPs and assumptions.
+ The security objectives rationale also demonstrates
+ that the tracing is effective: All the given threats,
+ OSPs and assumption are addressed (i.e. countered,
+ enforced and upheld respectively) if all security
+ objectives tracing to a particular threat, OSP or
+ assumption are achieved.
+ This demonstration analyses the effect of achieving
+ the relevant security objectives on countering the
+ threats, enforcing the OSPs and upholding the
+ assumptions and leads to the conclusion that this is
+ indeed the case.
+ In some cases, where parts of the security problem
+ definition very closely resemble some security
+ objectives, the demonstration can be very simple. An
+ example is: a threat ``T17: Threat agent X reads the
+ Confidential Information in transit between A and B'',
+ a security objective for the TOE: ``OT12: The TOE
+ shall ensure that all information transmitted between
+ A and B is kept confidential'', and a demonstration
+ ``T17 is directly countered by OT12''.
+ Countering a threat does not necessarily mean removing
+ that threat, it can also mean sufficiently diminishing
+ that threat or sufficiently mitigating that threat.
+ Examples of removing a threat are:
+
+ removing the ability to execute the adverse action
+ from the threat agent;
+
+ moving, changing or protecting the asset in such a
+ way that the adverse action is no longer
+ applicable to it;
+
+ removing the threat agent (e.g. removing machines
+ from a network that frequently crash that
+ network).
+
+ Examples of diminishing a threat are:
+
+ restricting the ability of a threat agent to
+ perform adverse actions;
+
+ restricting the opportunity to execute an adverse
+ action of a threat agent;
+
+ reducing the likelihood of an executed adverse
+ action being successful;
+
+ reducing the motivation to execute an adverse
+ action of a threat agent by deterrence;
+
+ requiring greater expertise or greater resources
+ from the threat agent.
+
+ Examples of mitigating the effects of a threat are:
+
+ making frequent back-ups of the asset;
+
+ obtaining spare copies of an asset;
+
+ insuring an asset;
+
+ ensuring that successful adverse actions are
+ always timely detected, so that appropriate action
+ can be taken.
+
+ Based on the security objectives and the security
+ objectives rationale, the following conclusion can be
+ drawn: if all security objectives are achieved then the
+ security problem as defined in is
+ solved: all threats are countered, all OSPs are
+ enforced, and all assumptions are upheld.
+ In many cases the security requirements (see the next
+ subclause) in an ST are based on components in CC Part 2
+ or CC Part 3. However, in some cases, there may be
+ requirements in an ST that are not based on components in
+ CC Part 2 or CC Part 3. In this case, new components
+ (extended components) must be defined, and this definition
+ should be done in the Extended Components Definition. For
+ more information on this, see Annex .
+ Note that this subclause is intended to contain only the
+ extended components and not the extended requirements
+ (requirements based on extended components). The extended
+ requirements should be included in the security
+ requirements (see the next subclause) and are for all
+ purposes the same as requirements based on components in
+ CC Part 2 or CC Part 3.
+ The security requirements consist of two groups of
+ requirements:
+ the security functional requirements
+ (SFRs): a translation of the security objectives for the
+ TOE into a standardised language;
+ the security assurance requirements
+ (SARs): a description of how assurance is to be gained
+ that the TOE meets the SFRs.
+
+ These two groups are discussed in the following two subclauses:
+ The SFRs are a translation of the security objectives for
+ the TOE. They are usually at a more detailed level of
+ abstraction, but they have to be a complete translation
+ (the security objectives must be completely addressed) and
+ be independent of any specific technical solution
+ (implementation). The CC requires this translation into a
+ standardised language for several reasons:
+
+ to provide an exact description of what is to be
+ evaluated. As security objectives for the TOE are
+ usually formulated in natural language, translation
+ into a standardised language enforces a more exact
+ description of the functionality of the TOE.
+
+ to allow comparison between two STs. As different ST
+ authors may use different terminology in describing
+ their security objectives, the standardised language
+ enforces using the same terminology and concepts. This
+ allows easy comparison.
+
+ There is no translation required in the CC for the
+ security objectives for the operational environment,
+ because the operational environment is not evaluated and
+ does therefore not require a description aimed at its
+ evaluation. See the bibliography for items relevant to the
+ security assessment of operational systems.
+ It may be the case that parts of the operational
+ environment are evaluated in another evaluation, but this
+ is out of scope for the current evaluation. For example:
+ an OS TOE may require a firewall to be present in its
+ operational environment. Another evaluation may
+ subsequently evaluate the firewall, but this evaluation
+ has nothing to do with the evaluation of the OS TOE.
+ The CC supports this translation in three ways:
+
+ by providing a predefined precise ``language''
+ designed to describe exactly what is to be
+ evaluated. This language is defined as a set of
+ components defined in CC Part 2. The use of this
+ language as a well-defined translation of the
+ security objectives for the TOE to SFRs is
+ mandatory, though some exceptions exist (see
+ Subclause ).
+
+ by providing operations: mechanisms that allow the
+ ST writer to modify the SFRs to provide a more
+ accurate translation of the security objectives for
+ the TOE. This part of the CC defines the four
+ allowed operations: assignment, selection,
+ iteration, and refinement. These are described
+ further in Subclause .
+
+ by providing dependencies: a mechanism that supports
+ a more complete translation to SFRs. In the CC Part
+ 2 language, an SFR can have a dependency on other
+ SFRs. This signifies that if an ST uses that SFR, it
+ generally needs to use those other SFRs as
+ well. This makes it much harder for the ST writer to
+ overlook including necessary SFRs and thereby
+ improves the completeness of the ST. Dependencies
+ are described further in Subclause .
+
+ The ST also contains a security requirements rationale,
+ consisting of two subclauses about SFRs:
+
+ a tracing that shows which SFRs address which
+ security objectives for the TOE;
+
+ a set of justifications that shows that all security
+ objectives for the TOE are effectively addressed by
+ the SFRs.
+
+ The tracing shows how the SFRs trace back to the
+ security objectives for the TOE as follows:
+ No spurious SFRs: Each SFR traces
+ back to at least one security objective.
+ Complete with respect to the security
+ objectives for the TOE: Each security
+ objective for the TOE has at least one SFR tracing
+ to it.
+
+ Multiple SFRs may trace to the same security objective
+ for the TOE, indicating that the combination of those
+ security requirements meets that security objective
+ for the TOE.
+ The security requirements rationale demonstrates that
+ the tracing is effective: if all SFRs tracing to a
+ particular security objective for the TOE are
+ satisfied, that security objective for the TOE is
+ achieved.
+ This demonstration should analyse the effects of
+ satisfying the relevant SFRs on achieving the security
+ objective for the TOE and lead to the conclusion that
+ this is indeed the case.
+ In cases where SFRs very closely resemble security
+ objectives for the TOE, the demonstration can be very
+ simple.
+ The SARs are a description of how the TOE is to be
+ evaluated. This description uses a standardised language
+ for two reasons:
+
+ to provide an exact description of how the TOE is to
+ be evaluated. Using a standardised language assists in
+ creating an exact description and avoids ambiguity.
+
+ to allow comparison between two STs. As different ST
+ authors may use different terminology in describing
+ the evaluation, the standardised language enforces
+ using the same terminology and concepts. This allows
+ easy comparison.
+
+ This standardised language is defined as a set of
+ components defined in CC Part 3. The use of this
+ language is mandatory, though some exceptions
+ exist. The CC enhances this language in two ways:
+
+ by providing operations: mechanisms that allow the ST
+ writer to modify the SARs. The CC has four operations:
+ assignment, selection, iteration, and
+ refinement. These are described further in Subclause
+ .
+
+ by providing dependencies: a mechanism that supports a
+ more complete translation to SARs. In CC Part 3
+ language, an SAR can have a dependency on other
+ SARs. This signifies that if an ST uses that SAR, it
+ generally needs to use those other SARs as well. This
+ makes it much harder for the ST writer to overlook
+ including necessary SARs and thereby improves the
+ completeness of STs. Dependencies are described
+ further in Subclause .
+
+ The ST also contains a security requirements rationale
+ that explains why this particular set of SARs was deemed
+ appropriate. There are no specific requirements for this
+ explanation. The goal for this explanation is to allow the
+ readers of the ST to understand the reasons why this
+ particular set was chosen.
+ An example of an inconsistency is if the security problem
+ description mentions threats where the threat agent is
+ very capable, and a low (or no) is
+ included in the SARs.
+ In the security problem definition of the ST, the security
+ problem is defined as consisting of threats, OSPs and
+ assumptions. In the security objectives subclause of the
+ ST, the solution is provided in the form of two
+ sub-solutions:
+
+ security objectives for the TOE;
+
+ security objectives for the operational environment.
+
+ Additionally, a security objectives rationale is provided
+ showing that if all security objectives are achieved, the
+ security problem is solved: all threats are countered, all
+ OSPs are enforced, and all assumptions are upheld.
+ In the security requirements subclause of the ST, the
+ security objectives for the TOE are translated to SFRs and
+ a security requirements rationale is provided showing that
+ if all SFRs are satisfied, all security objectives for the
+ TOE are achieved.
+ Additionally, a set of SARs is provided to show how the
+ TOE is evaluated, together with an explanation for
+ selecting these SARs.
+ All of the above can be combined into the statement: If
+ all SFRs and SARs are satisfied and all security
+ objectives for the operational environment are achieved,
+ then there exists assurance that the security problem as
+ defined in is solved: all
+ threats are countered, all OSPs are enforced, and all
+ assumptions are upheld. This is illustrated in Figure
+ .
+ The amount of assurance obtained is defined by the SARs,
+ and whether this amount of assurance is sufficient is
+ defined by the explanation for choosing these SARs.
+ The objective for the TOE summary specification is to provide
+ potential consumers of the TOE with a description of how the
+ TOE satisfies all the SFRs. The TOE summary specification
+ should provide the general technical mechanisms that the TOE
+ uses for this purpose. The level of detail of this description
+ should be enough to enable potential consumers to understand
+ the general form and implementation of the TOE.
+ For instance if the TOE is an Internet PC and the SFRs contain
+ to specify authentication,
+ the TOE summary specification should indicate how this
+ authentication is done: password, token, iris scanning
+ etc. More information, like applicable standards that the TOE
+ uses to meet SFRs, or more detailed descriptions may also be
+ provided.
+ After the evaluation, the ST specifies ``what was
+ evaluated''. In this role, the ST serves as a basis for
+ agreement between the developer or re-seller of the TOE and
+ the potential consumer of the TOE. The ST can therefore answer
+ the following questions (and more):
+ How can I find the ST/TOE that I need given the
+ multitude of existing STs/TOEs? This question is
+ addressed by the TOE overview, which gives a brief
+ (several paragraphs) summary of the TOE;
+ Does this TOE fit in with my existing
+ IT-infrastructure? This question is addressed by
+ the TOE overview, which identifies the major
+ hardware/firmware/software elements needed to run the TOE;
+ Does this TOE fit in with my existing operational
+ environment? This question is addressed by the
+ security objectives for the operational environment, which
+ identifies all constraints the TOE places on the
+ operational environment in order to function;
+ What does the TOE do (interested reader)?
+ This question is addressed by the TOE overview, which
+ gives a brief (several paragraphs) summary of the TOE;
+ What does the TOE do (potential
+ consumer)? This question is addressed by the TOE
+ description, which gives a less brief (several pages)
+ summary of the TOE;
+ What does the TOE do (technical)? This
+ question is addressed by the TOE summary specification
+ which provides a high-level description of the mechanisms
+ the TOE uses;
+ What does the TOE do (expert)? This
+ question is addressed by the SFRs which provide an
+ abstract highly technical description, and the TOE summary
+ specification which provide additional detail;
+ Does the TOE address the problem as defined by my
+ government/organisation? If your
+ government/organisation has defined packages and/or PPs to
+ define this solution, then the answer can be found in the
+ Conformance Claims subclause of the ST, which lists all
+ packages and PPs that the ST conforms to
+ Does the TOE address my security problem
+ (expert)? What are the threats countered by the
+ TOE? What organisational security policies does it
+ enforce? What assumptions does it make about the
+ operational environment? These questions are addressed by
+ the security problem definition;
+ How much trust can I place in the TOE?
+ This can be found in the SARs in the security requirements
+ subclause, which provide the assurance level that was used
+ to evaluate the TOE, and hence the trust that the
+ evaluation provides in the correctness of the TOE.
+
+ Writing an ST is not a trivial task, and may, especially in
+ low assurance evaluations, be a major part of the total effort
+ expended by the developer and the evaluator in the whole of
+ the evaluation. For this reason, it is also possible to write
+ a low assurance ST.
+ The CC allows the use of a low assurance ST for an EAL 1
+ evaluation, but not for EAL 2 and up. A low-assurance ST may
+ only claim conformance to a low-assurance PP (see ). A regular ST
+ (i.e., one with full contents) may claim conformance with a
+ low assurance PP.
+ A low assurance ST has a significantly reduced content
+ compared to a regular ST:
+
+ there is no need to describe the security problem definition;
+
+ there is no need to describe the security objectives for
+ the TOE. The security objectives for the operational
+ environment must still be described;
+
+ there is no need to describe the security objectives
+ rationale as there is no security problem definition in
+ the ST;
+
+ the security requirements rationale only needs to justify
+ (any) dependencies not being satisfied as there are no
+ security objectives for the TOE in the ST.
+
+ All that remains are:
+
+ the references to TOE and ST;
+
+ a conformance claim;
+
+ the various narrative descriptions;
+
+ the TOE overview;
+
+ the TOE description;
+
+ the TOE summary specification.
+
+ security objectives for the operational environment;
+
+ the SFRs and the SARs (including the extended components
+ definition) and the security requirements rationale (only
+ if the dependencies are not satisfied).
+
+ The reduced content of a low assurance ST is shown in Figure
+ .
+ In some cases, an ST writer may wish to refer to an external
+ standard, such as a particular cryptographic standard or
+ protocol. The CC allows three ways of doing this:
+
+ As an organisational security policy (or part of it).
+
+ If, for example, there exists a government standard
+ defining how passwords have to be chosen, this may be
+ stated as an organisational security policy in an
+ ST. This may lead to an objective for the environment
+ (e. g. if users of the TOE need to choose passwords
+ accordingly), or it may lead to security objectives for
+ the TOE and then to appropriate SFRs (likely of the
+ class), if the TOE generates
+ passwords. In both cases the rationale of the developer
+ needs to make plausible that the security objectives for
+ the TOE and the SFRs are suitable to fulfil the OSP. The
+ evaluator will examine if this is in fact plausible (and
+ may decide to look into the standard for this), if the
+ OSP is implemented by SFRs, as explained below.
+ As a technical standard (for example a cryptographic
+ standard) used in a refinement of an SFR.
+
+ In this case conformance to the standard is part of the
+ fulfilment of the SFR by the TOE and is treated as if
+ the full text of the standard is part of the
+ SFR. Conformance is subsequently determined like any
+ other conformance to SFRs: during and
+ it is analysed, by design analysis and
+ tests, that the SFR is completely and fully implemented
+ in the TOE. If reference to only a certain part of a
+ standard is desired, that part should be unambiguously
+ stated in the SFR refinement.
+ As a technical standard (for example a cryptographic
+ standard) mentioned in the TOE summary specification.
+
+ The TOE summary specification is only considered as an
+ explanation of how the SFRs are realised, and is not
+ strictly used as a strict implementation requirement
+ like the SFRs or the documents delivered for . So the evaluator may detect an inconsistency
+ if the TSS references a technical standard and this is
+ not reflected in documentation, but
+ there is no routine activity to test fulfilment of the
+ standard.
+ The goal of this Annex is to explain the Protection Profile
+ (PP) concept. This Annex does not define the criteria; this definition can be found in
+ CC Part 3 and is supported by the documents given in the
+ bibliography.
+ As PPs and STs have a significant overlap, this Annex focuses
+ on the differences between PPs and STs. The material that is
+ identical between STs and PPs is described in .
+ This annex consists of four major parts:
+ What a PP must contain. This is
+ summarised in Subclause , and described in more detail
+ in Subclauses -. These clauses describe the
+ mandatory contents of the PP, the interrelationships
+ between these contents, and provide examples.
+ How a PP should be used. This is
+ summarised in Subclause .
+ Low Assurance PPs. Low Assurance PPs are
+ PPs with reduced content. They are described in detail in
+ Subclause .
+ Claiming compliance with
+ standards. Subclause describes how a PP writer can claim that
+ the TOE is to meet a particular standard.
+
+ Figure portrays the
+ mandatory content for a PP that is given in
+ CC Part 3. Figure may
+ also be used as a structural outline of the PP, though
+ alternative structures are allowed. For instance, if the
+ security requirements rationale is particularly bulky, it
+ could be included in an appendix of the PP instead of in the
+ security requirements subclause. The separate subclauses of a
+ PP and the contents of those subclauses are briefly summarised
+ below and explained in much more detail in Subclauses - . A
+ PP contains:
+
+ a PP introduction containing a narrative
+ description of the TOE type;
+
+ a conformance claim, showing whether the
+ PP claims conformance to any PPs and/or packages, and if
+ so, to which PPs and/or packages;
+
+ a security problem definition, showing
+ threats, OSPs and assumptions;
+ security objectives, showing how the
+ solution to the security problem is divided between
+ security objectives for the TOE and security objectives
+ for the operational environment of the TOE;
+ extended components definition, where new
+ components (i.e. those not included in CC Part 2 or
+ CC Part 3) may be defined. These new components are
+ needed to define extended functional and extended
+ assurance requirements;
+ security requirements, where a
+ translation of the security objectives for the TOE into a
+ standardised language is provided. This standardised
+ language is in the form of SFRs. Additionally this
+ subclause defines the SARs;
+
+ There also exist low assurance PPs, which have reduced
+ contents; these are described in detail in Subclause . With this exception, all other
+ parts of this Annex assume a PP with full contents.
+ A PP is typically a statement of need where a user
+ community, a regulatory entity, or a group of developers
+ define a common set of security needs. A PP gives consumers
+ a means of referring to this set, and facilitates future
+ evaluation against these needs.
+ A PP is therefore typically used as:
+
+ part of a requirement specification for a specific
+ consumer or group of consumers, who will only consider
+ buying a specific type of IT if it meets the PP;
+
+ part of a regulation from a specific regulatory entity,
+ who will only allow a specific type of IT to be used if
+ it meets the PP;
+
+ a baseline defined by a group of IT developers, who then
+ agree that all IT that they produce of this type will
+ meet this baseline.
+
+ though this does not preclude other uses.
+ Three roles (among many) that a PP should not fulfil are:
+ a detailed specification: A PP is
+ designed to be a security specification on a relatively
+ high level of abstraction. A PP should, in general, not
+ contain detailed protocol specifications, detailed
+ descriptions of algorithms and/or mechanisms, long
+ description of detailed operations etc.
+ a complete specification: A PP is
+ designed to be a security specification and not a general
+ specification. Unless security-relevant, properties such
+ as interoperability, physical size and weight, required
+ voltage etc. should not be part of a PP. This means that
+ in general a PP is a part of a complete specification, but
+ not a complete specification itself.
+ a specification of a single product:
+ Unlike an ST, a PP is designed to describe a certain type
+ of IT, and not a single product. When only a single
+ product is described, it is better to use an ST for this
+ purpose.
+
+ The PP introduction describes the TOE in a narrative way on
+ two levels of abstraction:
+
+ the PP reference, which provides identification material
+ for the PP;
+
+ the TOE overview, which briefly describes the TOE.
+
+ A PP contains a clear PP reference that identifies that
+ particular PP. A typical PP reference consists of title,
+ version, authors and publication date. An example of a PP
+ reference is ``Atlantean Navy CablePhone Encryptor PP,
+ version 2b, Atlantean Navy Procurement Office, April 7,
+ 2003''. The reference must be unique so that it is possible
+ to tell different PPs and different versions of the same PP
+ apart.
+ The PP reference facilitates indexing and referencing the PP
+ and its inclusion in lists of PPs.
+ The TOE overview is aimed at potential consumers of a TOE
+ who are looking through lists of evaluated products to find
+ TOEs that may meet their security needs, and are supported
+ by their hardware, software and firmware.
+ The TOE overview is also aimed at developers who may use the
+ PP in designing TOEs or in adapting existing products.
+ The typical length of a TOE overview is several paragraphs.
+ To this end, the TOE overview briefly describes the usage of
+ the TOE and its major security features, identifies the TOE
+ type and identifies any major non-TOE
+ hardware/software/firmware available to the TOE.
+ The description of the usage and major security features
+ of the TOE is intended to give a very general idea of what
+ the TOE should be capable of, and what it can be used
+ for. This subclause should be written for (potential) TOE
+ consumers, describing TOE usage and major security
+ features in terms of business operations, using language
+ that TOE consumers understand.
+ An example of this is ``The Atlantean Navy CablePhone
+ Encryptor is an encryption device that should allow
+ confidential communication between ships across the
+ Atlantean Navy CablePhone system. To this end it should
+ allow at least 32 different users and support at least 100
+ Mbps encryption speed. It should allow both bilateral
+ communication between ships and broadcast across the
+ entire network.''
+ The TOE overview identifies the general type of TOE, such
+ as: firewall, VPN-firewall, smart card, crypto-modem,
+ intranet, web server, database, web server and database,
+ LAN, LAN with web server and database, etc.
+ While some TOEs do not rely upon other IT, many TOEs
+ (notably software TOEs) rely on additional, non-TOE,
+ hardware, software and/or firmware. In the latter case,
+ the TOE overview is required to identify the non-TOE
+ hardware/software/firmware.
+ As a Protection Profile is not written for a specific
+ product, in many cases only a general idea can be given of
+ the available hardware/software/firmware. In some other
+ cases, e.g. a requirements specification for a specific
+ consumer where the platform is already known, (much) more
+ specific information may be provided.
+ Examples of hardware/software/firmware identifications
+ are:
+
+ None. (for a completely stand-alone TOE);
+
+ The Yaiza 3.0 Operating System running on a general
+ PC;
+
+ a CleverCard SB2067 integrated circuit;
+
+ a CleverCard SB2067 IC running v2.0 of the QuickOS
+ smart card operating system;
+
+ the December 2002 installation of the LAN of the
+ Director-General's Office of the Department of
+ Traffic.
+
+ This subclause of a PP describes how the PP conforms with
+ other PPs and with packages. It is identical to the
+ conformance claims subclause for an ST (see Subclause ), with one exception:
+ the conformance statement.
+ The conformance statement in the PP states how STs and/or
+ other PPs must conform to that PP. The PP author selects
+ whether ``strict'' or ``demonstrable'' conformance is
+ required. See
+ for more details on this.
+ This subclause is identical to the security problem definition
+ subclause of an ST as explained in Subclause .
+ This subclause is identical to the security objectives subclause
+ of an ST as explained in Subclause .
+ This subclause is identical to the extended components subclause
+ of an ST as explained in Subclause .
+ This subclause is identical to the security requirements
+ subclause of an ST as explained in Subclause . Note however that the rules for completing
+ operations in a PP are slightly different from the rules for
+ completing operations in an ST. This is explained in more
+ detail in Subclause .
+ A PP has no TOE summary specification.
+ A low assurance PP has the same relationship to a regular PP
+ (i.e., one with full contents), as a low assurance ST has to a
+ regular ST. This means that a low-assurance PP consists of
+
+ a PP introduction, consisting of a PP reference and a TOE
+ overview;
+
+ a conformance claim;
+
+ security objectives for the operational environment;
+
+ the SFRs and the SARs (including the extended components
+ definition) and the security requirements rationale (only
+ if the dependencies are not satisfied).
+
+ A low-assurance PP may only claim conformance to a
+ low-assurance PP (see ). A
+ regular PP may claim conformance with a low assurance PP.
+ The reduced content of a low assurance PP is shown in Figure
+ .
+ This subclause is identical to the subclause on standards for
+ STs as described in Subclause , with one exception: as a PP has no TOE
+ summary specification, the third option is not valid for PPs.
+ The PP author is reminded that referring to a standard in SFRs
+ may impose a significant burden on a developer developing a
+ TOE to meet that PP (depending on the size and complexity of
+ the standard and the assurance level required), and that it
+ may be more suitable to require alternative (non-CC related)
+ ways to assess conformance to that standard.
+ Once evaluated, a PP-Configuration can be refined and used in the same way as a standard Protection Profile. This chapter explains how to combine the content of the Base-PP(s) and PP-Module(s) of a PP-Configuration so as to interpret it as a standard PP.
+ The TOE type of a PP to interpret in the same way as the PP-Configuration would be constituted of the TOE type of the Base-PP(s) with the additions introduced in the PP-Module(s) TOE types. The evaluation of the PP-Configuration ensures that it forms a consistent TOE type.
+ The Conformance claims of a PP to interpret in the same way as the PP-Configuration would contain:
+
+ The conformance to the PP(s) whose conformance is claimed in the Base-PP(s).
+
+ The conformance to SAR packages (including predefined EAL) from the Base-PPs. The issue of ANDed Base-PPs with different EALs has to be dealt with like in an ST conformant to all those PPs (meaning that the ST has to claim the level of the minimum EAL of all the Base-PPs).
+
+ The conformance statement (strict or demonstrable) from the Base-PPs. The issue of ANDed Base-PPs with different conformance statements has to be dealt with like in an ST conformant to all those PPs.
+
+ The SPD of a PP to interpret in the same way as the PP-Configuration would contain the union of the elements from the Base-PP(s) and PP-Module(s) of the PP-Configuration.
+ The security objectives of a PP to interpret in the same way as the PP-Configuration would contain the union of the security objectives from the Base-PP(s) and PP-Module(s) of the PP-Configuration.
+ The extended functional components of a PP to interpret in the same way as the PP-Configuration would contain all extended functional components from the Base-PP(s) and PP-Module(s) of the PP-Configuration.
+ The set of SFRs of a PP to interpret in the same way as the PP-Configuration would contain:
+
+ all the SFRs from the PP-Module(s) of the PP-Configuration.
+
+ all the SFRs from the Base-PP(s) except those which are refined in the PP-Module(s).
+
+ The consistency analysis performed on PP-Configuration during evaluation shall ensure this set is valid.
+ Figure shows the mandatory content of a PP-Module.
+ The content of the PP-Module is summarized below and explained in detail in sections from to . A PP-Module contains:
+
+ an Introduction that identifies the PP-Module, identifies the Base-PP(s) and states the correspondence rationale, and provides a description of the TOE within its environment that meets the descriptions underlying the Base-PPs,
+
+ a Consistency rationale that states the correspondence between the Module and its Base-PP(s),
+
+ a Conformance claim regarding the CC, with inherited EAL and conformance statement,
+
+ a Security problem definition with threats, assumptions and organisational security policies,
+
+ a Security objectives section presenting the solution to the security problem in terms of objectives for the TOE and its operational environment,
+
+ an optional Extended functional components definition where new functional components not included in CC Part 2 are introduced,
+
+ a Security functional requirements section with a standardized statement of the TOE security objectives.
+
+ A PP-Module is a security statement of a group of users or developers, regulators, administration, or any other entity that meets specific consumer needs. A PP-Module complements one or more Base-PPs and allows consumers to refer to this statement, facilitates the evaluation against it and the comparison of conformant evaluated TOEs.
+ The PP-Module introduction provides a clear and unambiguous reference that allows identifying the PP-Module. A typical reference is made of the title of the PP-Module, its version, their authors and the publication date.
+ The PP-Module reference will be used to index the document in Protection Profiles databases.
+ The PP-Module introduction identifies the Base Protection Profile(s) the Module relies on. The identification consists of a list of PP references.
+ The PP-Module may require to be used with a set of Base-PPs simultaneously, say {PP1,..., PPn}; the identification list states:
+ The PP-Module may allow the use with alternative sets of Base-PPs, say {S1,..., Sk}; the identification list states:
+ The general form of the Base-PP identification is then
+ Note that a PP-Module that states a list with an "OR" can be replaced by as many PP-Modules as elements in the list. That is, the list with an "OR" is a means to avoid managing similar PP-Modules for different usages, which does not introduce any complexity to the security specification itself.
+ The TOE overview of the PP-Module may complete the TOE overviews of the Base-PPs, provided the supplements do not contradict the Base-PPs:
+
+ The TOE type of the PP-Module can be the same of the Base-PPs or introduce specificities that meet the purpose of the PP-Module.
+
+ The PP-Module can introduce additional usage and major security features to those stated in the Base-PPs.
+
+ The PP-Module can specify particular non-TOE hardware, software and/or firmware compliant with the statement in the Base-PPs.
+
+ The possibility of supplementing the TOE overview of one or more Base-PPs in a PP-Module has the same meaning as the supplements of a ST regarding the TOE overview of a PP or the supplements of a PP that is conformant to another PP.
+ The statement of the TOE overview in a PP-Module is necessary whenever the TOE overview of the Base-PPs present different characteristics that need to be consolidated.
+ The PP-Module may provide as many specific TOE overviews as alternative sets of Base-PPs.
+ The PP-Module has to provide a consistency rationale with respect to its Base-PPs.
+ If the PP-Module specifies alternative sets of Base-PPs, the PP-Module must provide as many conformance claims as the number of alternative set of Base-PPs.
+ If the PP-Module specifies alternative sets of Base-PPs, the PP-Module must provide as many consistency rationales as the number of alternative set of Base-PPs.
+ The consistency analysis must be performed on the TOE type, the SPD, the objectives and the security functional requirements. At the end, the goal is to demonstrate that a TOE can meet the TOE type descriptions provided in the Base-PP(s) and in the PP-Module and that can satisfy all the Base-PPs and the PP-Module security functional requirements.
+ The consistency rationale must demonstrate that the unions of the SPD, the objectives and the security functional requirements from the Base-PPs and from the PP-Module do not lead to a contradiction.
+ The consistency rationale may use correspondence tables between SPD/objectives/SFRs in the PP-Module and SPD/objectives/SFRs in the Base-PPs together with textual justifications whenever needed.
+ Note that the consistency at the SFR level implies the consistency of the union of objectives and the union of SPDs provided that the PP-Module does not change the assumptions and objectives for the environment of the Base-PP(s).
+ This section describes how the PP-Module conforms to:
+
+ Part 2 of the Common Criteria: CC version and extended security requirements,
+
+ SFR packages.
+
+ A PP-Module cannot claim conformance to any PP, PP-Module or PP-Configuration.
+ A PP-Module inherits the conformity to SAR packages (including predefined EAL) from the Base-PPs. The issue of ANDed Base-PPs with different EALs has to be dealt with like in an ST conformant to all those PPs.
+ A PP-Module inherits the conformance statement (strict or demonstrable) from the Base-PPs. The issue of ANDed Base-PPs with different conformance statements has to be dealt with like in an ST conformant to all those PPs.
+ This section defines the security problem addressed by the PP-Module. It can contain assumptions, threats and organisational security policies.
+ A PP-Module defines the security problem in relationship with the security problem of the Base-PPs and the definition of the TOE and its environment provided in the PP-Module's Introduction.
+ Each element of the SPD may either come from a Base-PP or be entirely new. Let E be an element of the SPD of a PP-Module, one of the following cases holds:
+
+ E belongs to an identified Base-PP; the PP-Module may only contain a reference to the element in the Base-PP,
+
+ E results from the refinement of an element of a Base-PP,
+
+ E is a new element introduced by the PP-Module, related to additional features of the TOE or its environment.
+
+ Note that the interpreted / refined elements can be dealt with as new elements without any impact on the meaning of the SPD.
+ Note that as for STs, a PP-Module can introduce assumptions provided they cover aspects that are outside the scope of the Base-PPs.
+ This section defines the security objectives for the TOE and for the TOE's operational environment
+ A PP-Module defines the security objectives in relationship with its security problem and with the security objectives of the Base-PPs.
+ Each security objective may either come from a Base-PP or be entirely new. Let O be an objective of a PP-Module, one of the following cases holds:
+
+ O belongs to an identified Base-PP; the PP-Module may only contain a reference to the objective in the Base-PP
+
+ O results from the refinement of an objective of the same kind (for the TOE or for the TOE operational environment) of a Base-PP,
+
+ O is a new objective introduced by the PP-Module.
+
+ Note that the refined objectives can be dealt with as new objectives without any impact on the meaning of the whole set of objectives.
+ As for STs, a PP-Module can introduce new objectives for the TOE operational environment only provided they address aspects that are outside the scope of the Base-PPs.
+ In the opposite, if this is the purpose of the PP-Module, some security objectives for the environment of the Base-PPs could become security objectives for the TOE in the PP-Module.
+ This section also defines the rationale between the SPD and the security objectives of the PP-Module, which consists of a mapping that traces the SPD of the PP-Module to their security objectives as well as a justification demonstrating that the tracing is effective, as specified in section . Moreover, the mapping has to show not only that all the assumptions, threats and organisational security policies are covered but also that there is no useless security objective.
+ It may happen that some security objectives of the PP-Module cover also elements of the SPD of the Base-PPs that do not belong to the SPD of the PP-Module itself. This information is not required, but can be provided in application notes.
+ This section is identical to the standard PP and ST extended components section specified in section , applied to functional components only.
+ This section defines the security functional requirements for the TOE in relationship with the set of TOE security objectives in the PP-Module and with the security functional requirements of the Base-PPs.
+ Each security functional requirement may either come from a Base-PP or be entirely new. Let R be a security functional requirement of a PP-Module, one of the following cases holds:
+
+ R belongs to an identified Base-PP; the PP-Module may only contain a reference to the requirement in the Base-PP,
+
+ R results from the refinement of a SFR of a Base-PPs,
+
+ R is a new requirement introduced by the PP-Module.
+
+ Note that the refined requirements can be dealt with as new ones without any impact on the meaning of the whole set of requirements.
+ This section also defines the rationale between the SFRs and the TOE security objectives of the PP-Module, which consists of a mapping that traces the TOE objectives of the PP-Module to one or more SFRs and a justification demonstrating that the tracing is effective, as specified in section . Moreover, the mapping must fulfill the conditions specified in section and has to show not only that all the objectives for the TOE are covered but also that there is no useless security functional requirement.
+ It may happen that some SFRs of the PP-Module cover also TOE security objectives of the Base-PPs that do not belong to the PP-Module itself. This information is not required, but can be provided in application notes.
+ In order to limit the amount of information contained in the PP-Module, the editor may apply the following rules.
+ Let E, O and R belong to the SPD, the security objectives and the security functional requirements of a Protection Profile Q, respectively, with E mapped to O and O mapped to R.
+ Let P be a PP-Module with Q amongst its Base-PPs. P has to satisfy the following condition:
+ E, O, R and the mappings between them may belong to P only if at least one of these elements is linked to a new element in P, that is
+
+ Either there is a new element E' in the SPD of P such that E' is mapped to O, or
+
+ There is a new objective O' in P such that E is mapped to O' or O' is mapped to R, or
+
+ There is a new requirement R' in P such that O is mapped to R'.
+
+ That is, a PP-Module would not contain portions of Base-PPs unless they are required to fulfill new needs. Here, refined elements are considered new.
+ The content of the PP-Configuration is summarized below and explained in detail in Annexes , , and . A PP-Configuration contains:
+
+ a Reference that identifies the PP-Configuration,
+
+ a Components statement that identifies the Base-PPs and the PP-Modules composing the PP-Configuration,
+
+ a Conformance statement, that specifies whether the conformance to this PP-Configuration has to be strict or demonstrable,
+
+ a SAR statement, specifying the EAL, SAR package or list of the selected assurance components applicable to the PP-Configuration.
+
+ PP-Configurations are security statements that cover specific needs of groups of users, consumers, organisations, etc. Any PP-Configuration can be used exactly as a standard Protection Profile, as explained in Subclause .
+ The PP-Configuration reference provides a clear and unambiguous identification, usually made of a title, version number, sponsor and the publication date.
+ The PP-Configuration reference will be used to index the document in Protection Profiles databases.
+ The Components statement identifies the Base-PPs and the PP-Modules that compose the PP-Configuration.
+ The Components statement must include at least all Base-PPs referenced in the PP-Modules. If the PP-Module specifies alternative sets of Base-PPs, only one of these sets must be referred to in the PP-Configuration.
+ The Conformance statement specifies whether the conformance to this PP-Configuration has to be strict or demonstrable.
+ Any ST that claims conformance to the PP-Configuration shall conform to the kind of conformance claimed in the PP-Configuration.
+ The SAR statement specifies the set of SAR (potentially predefined EAL) applicable to any product evaluation with a ST that claims conformance to this PP-Configuration.
+ The assurance components for PP-Configuration evaluation, defined in Chapter 11: Class ACE of CC Part 3, are the following: ACE_INT.1, ACE_CCL.1, ACE_SPD.1, ACE_ECD.1, ACE_OBJ.1, ACE_REQ.1, ACE_MCO.1 and ACE_CCO.1.
+ As described in this CC part 1, Protection Profiles and
+ Security Targets contain pre-defined security requirements, as
+ well as providing PP and ST authors the ability to extend the
+ component lists in some circumstances.
+ The four types of operations are given in section . Examples of the various
+ operations are described below:
+ As described in section
+ the iteration operation may be performed on every
+ component. The PP/ST author performs an iteration operation
+ by including multiple requirements based on the same
+ component. Each iteration of a component is different from
+ all other iterations of that component, which is realised by
+ completing assignments and selections in a different way, or
+ by applying refinements to it in a different way. Different
+ iterations should be uniquely identified to allow clear
+ rationales and tracings to and from these requirements.
+ A typical example of an iteration is
+ being iterated twice in order to require the implementation
+ of two different cryptographic algorithms. An example of
+ each iteration being uniquely identified is:
+
+ Cryptographic operation (RSA and DSA signatures)
+ (FCS_COP.1(1))
+
+ Cryptographic operation (TLS/SSL: symmetric operations)
+ (FCS_COP.1(2))
+
+ As described in subclause
+ an assignment operation occurs where a given component
+ contains an element with a parameter that may be set by the
+ PP/ST author. The parameter may be an unrestricted variable,
+ or a rule that narrows the variable to a specific range of
+ values.
+ An example of an element with an assignment is: ``When the defined number of
+ unsuccessful authentication attempts has been met or
+ surpassed, the TSF shall [assignment: list of
+ actions].''
+ As described in subclause
+ the selection operation occurs where a given component
+ contains an element where a choice from several items has to
+ be made by the PP/ST author.
+ An example of an element with a selection is: ``The TSF shall run a suite of
+ self tests [selection: during initial start-up, periodically
+ during normal operation, at the request of the authorised
+ user, at the conditions [assignment: conditions under which
+ self test should occur]] to demonstrate the correct
+ operation of ...''
+ As described in subclause
+ the refinement operation can be performed on every
+ requirement. The PP/ST author performs a refinement by
+ altering that requirement.
+ An example of a valid refinement is ``The TSF shall require each user to be
+ successfully authenticated before allowing any other
+ TSF-mediated actions on behalf of that user.'' being refined
+ to ``The TSF shall require each user to be successfully
+ authenticated by username/password before
+ allowing any other TSF-mediated actions on behalf of that
+ user.''
+ The first rule for a refinement is that a TOE meeting the
+ refined requirement also meets the unrefined requirement in
+ the context of the PP/ST (i.e. a refined requirement must be
+ ``stricter'' than the original requirement)
+ The only exception to this rule is that a PP/ST author is
+ allowed to refine a SFR to apply to some but not all
+ subjects, objects, operations, security attributes and/or
+ external entities.
+ An example of a such an exception is ``The TSF shall require each user to be
+ successfully authenticated before allowing any other
+ TSF-mediated actions on behalf of that user.'' being refined
+ to ``The TSF shall require each user originating from
+ the internet to be successfully authenticated before
+ allowing any other TSF-mediated actions on behalf of that
+ user.''
+ The second rule for a refinement given is that the
+ refinement shall be related to the original component. For
+ example, refining an audit component with an extra element
+ on prevention of electromagnetic radiation is not allowed.
+ A special case of refinement is an editorial refinement,
+ where a small change is made in a requirement,
+ i.e. rephrasing a sentence due to adherence to proper
+ English grammar, or to make it more understandable to the
+ reader. This change is not allowed to modify the meaning of
+ the requirement in any way. Examples of editorial
+ refinements include:
+
+ the SFR ``The TSF shall
+ continue to preserve a secure state when the following
+ failures occur: breakdown of one CPU''
+ could be refined to
+ ``The TSF shall continue to preserve a secure state when
+ the following failure occurs: breakdown of one
+ CPU'' or even
+ ``The TSF shall continue to preserve a secure state when
+ one CPU breaks down''.
+
+ The CC has organised the components in CC Part 2 and CC Part 3
+ into hierarchical structures:
+ Classes, consisting ofFamilies, consisting ofComponents, consisting ofElements.
+ This organisation into a hierarchy of class - family -
+ component - element is provided to assist consumers,
+ developers and evaluators in locating specific components.
+ The CC presents functional and assurance components in
+ the same general hierarchical style and use the same
+ organisation and terminology for each.
+ An example of a class is the class that is
+ focused at identification of users, authentication of users
+ and binding of users and subjects.
+ An example of a family is the family
+ which is part of the class. This family
+ concentrates on the authentication of users.
+ An example of a component is which
+ concentrates on unforgeable authentication.
+ An example of an element is which
+ concentrates on the prevention of use of copied
+ authentication data.
+ Whenever a PP/ST author defines an extended component,
+ this has to be done in a similar manner to the existing CC
+ components: clear, unambiguous and evaluatable (it is
+ possible to systematically demonstrate whether a
+ requirement based on that component holds for a
+ TOE). Extended components must use similar labelling,
+ manner of expression, and level of detail as the existing
+ CC components.
+ The PP/ST author also has to make to sure that all
+ applicable dependencies of an extended component are
+ included in the definition of that extended
+ component. Examples of possible dependencies are:
+
+ if an extended component refers to auditing,
+ dependencies to components of the
+ class may have to be included;
+
+ if an extended component modifies or accesses data,
+ dependencies to components of the
+ family may have to be included;
+
+ if an extended component uses a particular design
+ description a dependency to the appropriate family (e.g. Functional Specification) may
+ have to be included.
+
+ In the case of an extended functional component, the PP/ST
+ author also has to include any applicable audit and
+ associated operations information in the definition of
+ that component, similar to existing CC Part 2
+ components. In the case of an extended assurance
+ component, the PP/ST author also has to provide suitable
+ evaluation methodology for the component, similar to the
+ methodology provided in the CEM.
+ Extended components may be placed in existing families, in
+ which case the PP/ST writer has to show how these families
+ change. If they do not fit into an existing family, they
+ shall be placed in a new family. New families have to be
+ defined similarly to the CC.
+ New families may be placed in existing classes in which
+ case the PP/ST writer has to show how these classes
+ change. If they do not fit into an existing class, they
+ shall be placed in a new class. New classes have to be
+ defined similarly to the CC.
+ A PP is intended to be used as a ``template'' for an ST. That
+ is: the PP describes a set of user needs, while an ST that
+ conforms to that PP describes a TOE that satisfies those
+ needs.
+ Note that it is also possible for a PP to be used as a
+ template for another PP. That is PPs can claim conformance to
+ other PPs. This case is completely similar to that of an ST
+ vs. a PP. For clarity this Annex describes only the ST/PP
+ case, but it holds also for the PP/PP case.
+ The CC does not allow any form of partial conformance, so if a
+ PP is claimed, the PP or ST must fully conform to the
+ referenced PP or PPs. There are however two types of
+ conformance (``strict'' and demonstrable'') and the type of
+ conformance allowed is determined by the PP. That is, the PP
+ states (in the PP conformance statement, see subclause ) what the allowed types of conformance for the ST
+ are. This distinction between strict and demonstrable
+ conformance is applicable to each PP to which an ST may claim
+ conformance on an individual basis. This may mean that the ST
+ conforms strictly to some PPs and demonstrably to other
+ PPs. An ST is only allowed to conform to a PP in a
+ demonstrable manner, if the PP explicitly allows this, whereas
+ an ST can always conform with strict conformance to any PP.
+ Restating this in other words, an ST is only allowed to
+ conform to a PP in a demonstrable manner, if the PP explicitly
+ allows this.
+ Conformance to a PP means that the PP or ST (and if an ST is
+ of an evaluated product, the product as well) meets all
+ requirements of that PP.
+ Published PPs will normally require demonstrable
+ conformance. This means that STs claiming conformance with the
+ PP must offer a solution to the generic security problem
+ described in the PP, but can do so in any way that is
+ equivalent or more restrictive to that described in the
+ PP. ``Equivalent but more restrictive'' is defined at length
+ within the CC, but in principle it means that the PP
+ and ST may contain entirely different statements that discuss
+ different entities, use different concepts etc., provided that
+ overall the ST levies the same or more restrictions on the
+ TOE, and the same or less restrictions on the operational
+ environment of the TOE.
+ Strict conformance is oriented to the PP-author who requires
+ evidence that the requirements in the PP are met, that the ST
+ is an instantiation of the PP, though the ST could be broader
+ than the PP. In essence, the ST specifies that the TOE does at
+ least the same as in the PP, while the operational environment
+ does at most the same as in the PP.
+ A typical example of the use of strict conformance is in
+ selection based purchasing where a product's security
+ requirements are expected to exactly match those specified in
+ the PP.
+ An ST instantiating strict conformance to a PP can still
+ introduce additional restrictions to those given in the PP.
+ Demonstrable conformance is orientated to the PP-author who
+ requires evidence that the ST is a suitable solution to the
+ generic security problem described in the PP.
+ Where there is a clear subset-superset type relation between
+ PP and ST in the case of strict conformance, the relation is
+ less clear-cut in the case of demonstrable conformance. STs
+ claiming conformance with the PP must offer a solution to the
+ generic security problem described in the PP. but can do so in
+ any way that is equivalent or more restrictive to that
+ described in the PP.
+ This bibliography contains references to further material and
+ standards that the reader of the CC may find useful. For
+ undated references the reader is recommended to refer to the
+ latest edition of the referenced document.ISO/IEC 15292Information technology -- Security techniques --
+ Protection Profile registration proceduresISO/IEC 15443Information technology -- Security techniques
+ -- A framework for IT security assurance - all partsISO/IEC 15446Information technology -- Security techniques
+ -- Guide for the production of Protection Profiles and Security
+ TargetsISO/IEC 19790Information technology -- Security techniques
+ -- Security requirements for cryptographic modulesISO/IEC 19791Information technology -- Security techniques
+ -- Security assessment of operational systemsISO/IEC 27001Information technology -- Security techniques
+ -- Information security management systems -- RequirementsISO/IEC 27002Information technology -- Security techniques
+ -- Code of practice for information security managementIEEE Std 610.12-1990
+ Institute of Electrical and Electronics Engineers, Standard
+ Glossary of Software Engineering Terminology
+ CC portal
+ Common Criteria portal, February 2009. CCRA, www.commoncriteriaportal.org
+
+
+
+ Table describes the
+ relationship between PPs and the families and components of the
+ class.
+
+
+
+
+
+
+
+
+
+
+ The following Subclauses describe the constructs used in
+ representing the assurance classes, families, and
+ components.
+
+ Figure
+ illustrates the SARs defined in this CC Part 3. Note that the
+ most abstract collection of SARs is referred to as a
+ class. Each class contains assurance families, which then
+ contain assurance components, which in turn contain assurance
+ elements. Classes and families are used to provide a taxonomy
+ for classifying SARs, while components are used to specify
+ SARs in a PP/ST.
+
+
+ Figure
+ illustrates the assurance class structure.
+
+
+ Each assurance class is assigned a unique name. The name
+ indicates the topics covered by the assurance
+ class.
+
+ A unique short form of the assurance class name is also
+ provided. This is the primary means for referencing the
+ assurance class. The convention adopted is an ``A''
+ followed by two letters related to the class name.
+
+
+
+ Each assurance class has an introductory Subclause that
+ describes the composition of the class and contains
+ supportive text covering the intent of the class.
+
+
+
+ Each assurance class contains at least one assurance
+ family. The structure of the assurance families is
+ described in the following Subclause.
+
+
+
+
+
+ Figure
+ illustrates the assurance family structure.
+
+
+ Every assurance family is assigned a unique name. The name
+ provides descriptive information about the topics covered
+ by the assurance family. Each assurance family is placed
+ within the assurance class that contains other families
+ with the same intent.
+
+ A unique short form of the assurance family name is also
+ provided. This is the primary means used to reference the
+ assurance family. The convention adopted is that the short
+ form of the class name is used, followed by an underscore,
+ and then three letters related to the family name.
+
+
+
+ The objectives Subclause of the assurance family presents
+ the intent of the assurance family.
+
+ This Subclause describes the objectives, particularly
+ those related to the CC assurance paradigm, that the
+ family is intended to address. The description for the
+ assurance family is kept at a general level. Any specific
+ details required for objectives are incorporated in the
+ particular assurance component.
+
+
+
+ Each assurance family contains one or more assurance
+ components. This Subclause of the assurance family
+ describes the components available and explains the
+ distinctions between them. Its main purpose is to
+ differentiate between the assurance components once it has
+ been determined that the assurance family is a necessary
+ or useful part of the SARs for a PP/ST.
+
+ Assurance families containing more than one component are
+ levelled and rationale is provided as to how the
+ components are levelled. This rationale is in terms of
+ scope, depth, and/or rigour.
+
+
+
+ The application notes Subclause of the assurance family,
+ if present, contains additional information for the
+ assurance family. This information should be of particular
+ interest to users of the assurance family (e.g. PP and ST
+ authors, designers of TOEs, evaluators). The presentation
+ is informal and covers, for example, warnings about
+ limitations of use and areas where specific attention may
+ be required.
+
+
+
+ Each assurance family has at least one assurance
+ component. The structure of the assurance components is
+ provided in the following Subclause.
+
+
+
+
+ Figure illustrates the
+ assurance component structure.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding convention. Those parts of the
+ requirements that are new, enhanced or modified beyond the
+ requirements of the previous component within a hierarchy
+ are bolded.
+
+
+ The component identification Subclause provides
+ descriptive information necessary to identify, categorise,
+ register, and reference a component.
+
+ Every assurance component is assigned a unique name. The
+ name provides descriptive information about the topics
+ covered by the assurance component. Each assurance
+ component is placed within the assurance family that
+ shares its security objective.
+
+ A unique short form of the assurance component name is
+ also provided. This is the primary means used to reference
+ the assurance component. The convention used is that the
+ short form of the family name is used, followed by a
+ period, and then a numeric character. The numeric
+ characters for the components within each family are
+ assigned sequentially, starting from 1.
+
+
+
+ The objectives Subclause of the assurance component, if
+ present, contains specific objectives for the particular
+ assurance component. For those assurance components that
+ have this Subclause, it presents the specific intent of
+ the component and a more detailed explanation of the
+ objectives.
+
+
+
+ The application notes Subclause of an assurance component,
+ if present, contains additional information to facilitate
+ the use of the component.
+
+
+
+ Dependencies among assurance components arise when a
+ component is not self-sufficient, and relies upon the
+ presence of another component.
+
+ Each assurance component provides a complete list of
+ dependencies to other assurance components. Some
+ components may list ``No dependencies'', to indicate that
+ no dependencies have been identified. The components
+ depended upon may have dependencies on other
+ components.
+
+ The dependency list identifies the minimum set of
+ assurance components which are relied upon. Components
+ which are hierarchical to a component in the dependency
+ list may also be used to satisfy the dependency.
+
+ In specific situations the indicated dependencies might
+ not be applicable. The PP/ST author, by providing
+ rationale for why a given dependency is not applicable,
+ may elect not to satisfy that dependency.
+
+
+
+ A set of assurance elements is provided for each assurance
+ component. An assurance element is a security requirement
+ which, if further divided, would not yield a meaningful
+ evaluation result. It is the smallest security requirement
+ recognised in the CC.
+
+ Each assurance element is identified as belonging to one
+ of the three sets of assurance elements:
+
+
+ Developer action elements: the activities that shall
+ be performed by the developer. This set of actions is
+ further qualified by evidential material referenced in
+ the following set of elements. Requirements for
+ developer actions are identified by appending the
+ letter ``D'' to the element number.
+
+
+ Content and presentation of evidence elements: the
+ evidence required, what the evidence shall
+ demonstrate, and what information the evidence shall
+ convey. Requirements for content and presentation of
+ evidence are identified by appending the letter ``C''
+ to the element number.
+
+
+ Evaluator action elements: the activities that shall
+ be performed by the evaluator. This set of actions
+ explicitly includes confirmation that the requirements
+ prescribed in the content and presentation of evidence
+ elements have been met. It also includes explicit
+ actions and analysis that shall be performed in
+ addition to that already performed by the
+ developer. Implicit evaluator actions are also to be
+ performed as a result of developer action elements
+ which are not covered by content and presentation of
+ evidence requirements. Requirements for evaluator
+ actions are identified by appending the letter ``E''
+ to the element number.
+
+
+
+ The developer actions and content and presentation of
+ evidence define the assurance requirements that are used
+ to represent a developer's responsibilities in
+ demonstrating assurance in the TOE meeting the SFRs of a
+ PP or ST.
+
+ The evaluator actions define the evaluator's
+ responsibilities in the two aspects of evaluation. The
+ first aspect is validation of the PP/ST, in accordance
+ with the classes and in Clauses and . The second
+ aspect is verification of the TOE's conformance with its
+ SFRs and SARs. By demonstrating that the PP/ST is valid
+ and that the requirements are met by the TOE, the
+ evaluator can provide a basis for confidence that the TOE
+ in its operational environment solves the defined security
+ problem.
+
+ The developer action elements, content and presentation of
+ evidence elements, and explicit evaluator action elements,
+ identify the evaluator effort that shall be expended in
+ verifying the security claims made in the ST of the
+ TOE.
+
+
+
+
+ Each element represents a requirement to be met. These
+ statements of requirements are intended to be clear,
+ concise, and unambiguous. Therefore, there are no compound
+ sentences: each separable requirement is stated as an
+ individual element.
+
+
+
+ This CC Part 3 contains classes of families and components
+ that are grouped on the basis of related assurance. At the
+ start of each class is a diagram that indicates the families
+ in the class and the components in each family.
+
+
+ In Figure ,
+ above, the class as shown contains a single family. The
+ family contains three components that are linearly
+ hierarchical (i.e. component 2 requires more than component
+ 1, in terms of specific actions, specific evidence, or
+ rigour of the actions or evidence). The assurance families
+ in this CC Part 3 are all linearly hierarchical, although
+ linearity is not a mandatory criterion for assurance
+ families that may be added in the future.
+
+
+
+
+ Figure illustrates
+ the EALs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in an EAL by reference to the actual
+ components defined in the CC.
+
+
+
+ Each EAL is assigned a unique name. The name provides
+ descriptive information about the intent of the EAL.
+
+ A unique short form of the EAL name is also provided. This
+ is the primary means used to reference the EAL.
+
+
+
+ The objectives Subclause of the EAL presents the intent of
+ the EAL.
+
+
+ The application notes Subclause of the EAL, if present,
+ contains information of particular interest to users of the
+ EAL (e.g. PP and ST authors, designers of TOEs targeting
+ this EAL, evaluators). The presentation is informal and
+ covers, for example, warnings about limitations of use and
+ areas where specific attention may be required.
+ A set of assurance components have been chosen for each
+ EAL.
+ A higher level of assurance than that provided by a given
+ EAL can be achieved by:
+
+ including additional assurance components from other
+ assurance families; or
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ assurance levels defined in the CC. While assurance
+ components further decompose into assurance elements,
+ assurance elements cannot be individually referenced by
+ assurance levels. Note that the arrow in the figure
+ represents a reference from an EAL to an assurance component
+ within the class where it is defined.
+
+
+
+
+
+ The structure of the CAPs is similar to that of the EALs. The
+ main difference between these two types of package is the type
+ of TOE they apply to; the EALs applying to component TOEs and
+ the CAPs applying to composed TOEs.
+
+ Figure illustrates
+ the CAPs and associated structure defined in this CC Part
+ 3. Note that while the figure shows the contents of the
+ assurance components, it is intended that this information
+ would be included in a CAP by reference to the actual
+ components defined in the CC.
+
+
+
+ Each CAP is assigned a unique name. The name provides
+ descriptive information about the intent of the CAP.
+
+ A unique short form of the CAP name is also provided. This
+ is the primary means used to reference the CAP.
+
+
+
+ The objectives Subclause of the CAP presents the intent of
+ the CAP.
+
+
+ The application notes Subclause of the CAP, if present,
+ contains information of particular interest to users of the
+ CAP (e.g. PP and ST authors, integrators of composed TOEs
+ targeting this CAP, evaluators). The presentation is
+ informal and covers, for example, warnings about limitations
+ of use and areas where specific attention may be
+ required.
+ A set of assurance components have been chosen for each
+ CAP.
+ Some dependencies identify the activities performed during
+ the evaluation of the dependent component on which the
+ composed TOE activity relies. Where it is not explicitly
+ identified that the dependency is on a dependent component
+ activity, the dependency is to another evaluation activity
+ of the composed TOE.
+ A higher level of assurance than that provided by a given
+ CAP can be achieved by:
+
+ including additional assurance components from other
+ assurance families; or
+
+ replacing an assurance component with a higher level
+ assurance component from the same assurance family.
+
+ The components included in the CAP
+ assurance packages should not be used as augmentations for
+ component TOE evaluations, as this would provide no
+ meaningful assurance for the component.
+
+
+ Figure
+ illustrates the relationship between the SARs and the
+ composed assurance packages defined in the CC. While
+ assurance components further decompose into assurance
+ elements, assurance elements cannot be individually
+ referenced by assurance packages. Note that the arrow in the
+ figure represents a reference from a CAP to an assurance
+ component within the class where it is defined.
+
+
+
+
+
+
+
+
+ This clause defines the content and presentation of the
+ functional requirements of the CC, and provides guidance on
+ the organisation of the requirements for new components to be
+ included in an ST. The functional requirements are expressed
+ in classes, families, and components.
+
+
+
+ Figure illustrates the
+ functional class structure in diagrammatic form. Each
+ functional class includes a class name, class introduction,
+ and one or more functional families.
+
+
+
+
+
+ The class name subclause provides information necessary to
+ identify and categorise a functional class. Every
+ functional class has a unique name. The categorical
+ information consists of a short name of three
+ characters. The short name of the class is used in the
+ specification of the short names of the families of that
+ class.
+
+
+
+ The class introduction expresses the common intent or
+ approach of those families to satisfy security
+ objectives. The definition of functional classes does not
+ reflect any formal taxonomy in the specification of the
+ requirements.
+
+ The class introduction provides a figure describing the
+ families in this class and the hierarchy of the components
+ in each family, as explained in subclause .
+
+
+
+
+
+ Figure
+ illustrates the functional family structure in diagrammatic
+ form.
+
+
+
+
+
+ The family name subclause provides categorical and
+ descriptive information necessary to identify and
+ categorise a functional family. Every functional family
+ has a unique name. The categorical information consists of
+ a short name of seven characters, with the first three
+ identical to the short name of the class followed by an
+ underscore and the short name of the family as follows
+ XXX_YYY. The unique short form of the family name provides
+ the principal reference name for the components.
+
+
+
+ The family behaviour is the narrative description of the
+ functional family stating its security objective and a
+ general description of the functional requirements. These
+ are described in greater detail below:
+
+
+ The security objectives of the family
+ address a security problem that may be solved with the
+ help of a TOE that incorporates a component of this
+ family;
+
+
+ The description of the functional
+ requirements summarises all the requirements
+ that are included in the component(s). The description
+ is aimed at authors of PPs, STs and functional
+ packages who wish to assess whether the family is
+ relevant to their specific requirements.
+
+
+
+
+
+ Functional families contain one or more components, any
+ one of which can be selected for inclusion in PPs, STs and
+ functional packages. The goal of this section is to
+ provide information to users in selecting an appropriate
+ functional component once the family has been identified
+ as being a necessary or useful part of their security
+ requirements.
+
+ This section of the functional family description
+ describes the components available, and their
+ rationale. The exact details of the components are
+ contained within each component.
+
+ The relationships between components within a functional
+ family may or may not be hierarchical. A component is
+ hierarchical to another if it offers more security.
+
+ As explained in the descriptions of the
+ families provide a graphical overview of the hierarchy of
+ the components in a family.
+
+
+
+
+ The management clauses contain information for
+ the PP/ST authors to consider as management activities for a
+ given component. The clauses reference components of the
+ management class (FMT), and provide guidance regarding potential
+ management activities that may be applied via operations to
+ those components.
+
+ A PP/ST author may select the indicated management components or
+ may include other management requirements not listed to detail
+ management activities. As such the information should be
+ considered informative.
+
+
+
+
+ The audit requirements contain auditable
+ events for the PP/ST authors to select, if requirements
+ from the class , are included in the
+ PP/ST. These requirements include security relevant events
+ in terms of the various levels of detail supported by the
+ components of the family. For example,
+ an audit note might include actions that are in terms of:
+ Minimal - successful use of the security mechanism; Basic
+ - any use of the security mechanism as well as relevant
+ information regarding the security attributes involved;
+ Detailed - any configuration changes made to the
+ mechanism, including the actual configuration values
+ before and after the change.
+
+ It should be observed that the categorisation of auditable
+ events is hierarchical. For example, when Basic Audit
+ Generation is desired, all auditable events identified as
+ being both Minimal and Basic should be included in the
+ PP/ST through the use of the appropriate assignment
+ operation, except when the higher level event simply
+ provides more detail than the lower level event. When
+ Detailed Audit Generation is desired, all identified
+ auditable events (Minimal, Basic and Detailed) should be
+ included in the PP/ST.
+
+ In the class the rules governing the audit
+ are explained in more detail.
+
+
+
+
+
+ Figure illustrates the
+ functional component structure.
+
+
+
+
+
+ The component identification subclause provides
+ descriptive information necessary to identify, categorise,
+ register and cross-reference a component. The following is
+ provided as part of every functional component:
+
+ A unique name. The name reflects the
+ purpose of the component.
+
+ A short name. A unique short form of the
+ functional component name. This short name serves as the
+ principal reference name for the categorisation,
+ registration and cross-referencing of the component. This
+ short name reflects the class and family to which the
+ component belongs and the component number within the
+ family.
+
+ A hierarchical-to list. A list of other
+ components that this component is hierarchical to and for
+ which this component can be used to satisfy dependencies
+ to the listed components.
+
+
+
+
+ A set of elements is provided for each component. Each
+ element is individually defined and is self-contained.
+
+ A functional element is a security functional requirement
+ that if further divided would not yield a meaningful
+ evaluation result. It is the smallest security functional
+ requirement identified and recognised in the CC.
+
+ When building packages, PPs and/or STs, it is not
+ permitted to select only one or more elements from a
+ component. The complete set of elements of a component
+ must be selected for inclusion in a PP, ST or package.
+
+ A unique short form of the functional element name is
+ provided. For example the requirement name FDP_IFF.4.2
+ reads as follows: F - functional requirement, DP - class
+ ``User data protection'', _IFF -
+ family ``Information flow control
+ functions'', .4 - 4th component named
+ ``Partial elimination of illicit information
+ flows'', .2 - 2nd element of the component.
+
+
+
+
+ Dependencies among functional components arise when a
+ component is not self sufficient and relies upon the
+ functionality of, or interaction with, another component
+ for its own proper functioning.
+
+ Each functional component provides a complete list of
+ dependencies to other functional and assurance
+ components. Some components may list ``No
+ dependencies''. The components depended upon may in
+ turn have dependencies on other components. The list
+ provided in the components will be the direct
+ dependencies. That is only references to the functional
+ requirements that are required for this requirement to
+ perform its job properly. The indirect dependencies, that
+ is the dependencies that result from the depended upon
+ components can be found in
+ of this part of the CC. It is noted that in some cases the
+ dependency is optional in that a number of functional
+ requirements are provided, where each one of them would be
+ sufficient to satisfy the dependency (see for example
+ ).
+
+ The dependency list identifies the minimum functional or
+ assurance components needed to satisfy the security
+ requirements associated with an identified
+ component. Components that are hierarchical to the
+ identified component may also be used to satisfy the
+ dependency.
+
+ The dependencies indicated in CC Part 2 are
+ normative. They must be satisfied within a PP/ST. In
+ specific situations the indicated dependencies might not
+ be applicable. The PP/ST author, by providing the
+ rationale why it is not applicable, may leave the depended
+ upon component out of the package, PP or ST.
+
+
+
+
+
+
+
+
+ The grouping of the components in this part of the CC does not
+ reflect any formal taxonomy.
+
+ This part of the CC contains classes of families and
+ components, which are rough groupings on the basis of related
+ function or purpose, presented in alphabetic order. At the
+ start of each class is an informative diagram that indicates
+ the taxonomy of each class, indicating the families in each
+ class and the components in each family. The diagram is a
+ useful indicator of the hierarchical relationship that may
+ exist between components.
+
+ In the description of the functional components, a section
+ identifies the dependencies between the component and any
+ other components.
+
+ In each class a figure describing the family hierarchy similar
+ to Figure , is provided. In Figure
+ the first family, Family 1,
+ contains three hierarchical components, where component 2 and
+ component 3 can both be used to satisfy dependencies on
+ component 1. Component 3 is hierarchical to component 2 and
+ can also be used to satisfy dependencies on component 2.
+
+
+
+
+ In Family 2 there are three components not all of which are
+ hierarchical. Components 1 and 2 are hierarchical to no other
+ components. Component 3 is hierarchical to component 2, and
+ can be used to satisfy dependencies on component 2, but not to
+ satisfy dependencies on component 1.
+
+ In Family 3, components 2, 3, and 4 are hierarchical to
+ component 1. Components 2 and 3 are both hierarchical to
+ component 1, but non-comparable. Component 4 is hierarchical
+ to both component 2 and component 3.
+
+ These diagrams are meant to complement the text of the
+ families and make identification of the relationships
+ easier. They do not replace the ``Hierarchical
+ to:'' note in each component that is the mandatory
+ claim of hierarchy for each component.
+
+
+ The relationship between components within a family is
+ highlighted using a bolding
+ convention. This bolding convention calls for the bolding of
+ all new requirements. For hierarchical components,
+ requirements are bolded when they are
+ enhanced or modified beyond the requirements of the previous
+ component. In addition, any new or enhanced permitted
+ operations beyond the previous component are also
+ highlighted using bold type.
+
+
+
+
+
+ This annex contains additional guidance for the families and
+ components defined in the elements of this CC Part 2, which
+ may be required by users, developers or evaluators to use the
+ components. To facilitate finding the appropriate information,
+ the presentation of the classes, families and components in
+ this annex is similar to the presentation within the elements.
+
+
+
+ This clause defines the content and presentation of the notes
+ related to functional requirements of the CC.
+
+
+
+ Figure below
+ illustrates the functional class structure in this annex.
+
+
+
+
+
+ This is the unique name of the class defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The class introduction in this annex provides information
+ about the use of the families and components of the
+ class. This information is completed with the informative
+ diagram that describes the organisation of each class with
+ the families in each class and the hierarchical
+ relationship between components in each family.
+
+
+
+
+
+ Figure illustrates
+ the functional family structure for application notes in
+ diagrammatic form.
+
+
+
+
+
+ This is the unique name of the family defined within the
+ normative elements of this part of the CC.
+
+
+
+
+ The user notes contain additional information that is of
+ interest to potential users of the family, that is PP, ST
+ and functional package authors, and developers of TOEs
+ incorporating the functional components. The presentation
+ is informative, and might cover warnings about limitations
+ of use and areas where specific attention might be
+ required when using the components.
+
+
+
+
+ The evaluator notes contain any information that is of
+ interest to developers and evaluators of TOEs that claim
+ compliance with a component of the family. The
+ presentation is informative and can cover a variety of
+ areas where specific attention might be needed when
+ evaluating the TOE. This can include clarifications of
+ meaning and specification of the way to interpret
+ requirements, as well as caveats and warnings of specific
+ interest to evaluators.
+
+ These User Notes and Evaluator Notes sections are not
+ mandatory and appear only if appropriate.
+
+
+
+
+
+ Figure illustrates
+ the functional component structure for the application
+ notes.
+
+
+
+
+
+ This is the unique name of the component defined within
+ the normative elements of this part of the CC.
+
+
+
+
+ Any specific information related to the component can be
+ found in this section.
+
+
+ The rationale contains the specifics
+ of the rationale that refine the general statements on
+ rationale for the specific level, and should only be
+ used if level specific amplification is required.
+
+
+ The application notes contain
+ additional refinement in terms of narrative
+ qualification as it pertains to a specific
+ component. This refinement can pertain to user notes,
+ and/or evaluator notes as described in Subclause . This refinement can be
+ used to explain the nature of the dependencies
+ (e.g. shared information, or shared operation).
+
+
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+ This portion of each component contains advice relating to
+ the permitted operations of the component.
+
+ This section is not mandatory and appears only if
+ appropriate.
+
+
+
+
+
+ The following dependency tables for functional components
+ show their direct, indirect and optional dependencies. Each
+ of the components that is a dependency of some functional
+ component is allocated a column. Each functional component is
+ allocated a row. The value in the table cell indicate whether
+ the column label component is directly required (indicated by
+ a cross ``X''), indirectly required (indicated by a
+ dash ``-''), or optionally required (indicated by a
+ ``o'') by the row label component. An example of a
+ component with optional dependencies is , which requires either
+ or to be present. So if is present, is not
+ necessary and vice versa. If no character is presented, the
+ component is not dependent upon another component.
+
+
+
+
+
+ Security auditing involves recognising, recording, storing,
+ and analysing information related to security relevant
+ activities (i.e. activities controlled by the TSF). The
+ resulting audit records can be examined to determine which
+ security relevant activities took place and whom (which user)
+ is responsible for them.
+
+
+
+
+ CC audit families allow PP/ST authors the ability to define
+ requirements for monitoring user activities and, in some
+ cases, detecting real, possible, or imminent violations of
+ the enforcement of the SFRs. The TOE's security audit functions are
+ defined to help monitor security-relevant events, and act as a
+ deterrent against security violations. The requirements of the
+ audit families refer to functions that include audit data
+ protection, record format, and event selection, as well as
+ analysis tools, violation alarms, and real-time analysis. The
+ audit trail should be presented in human-readable format
+ either directly (e.g. storing the audit trail in
+ human-readable format) or indirectly (e.g. using audit
+ reduction tools), or both.
+
+ While developing the security audit requirements, the PP/ST
+ author should take note of the inter-relationships among the
+ audit families and components. The potential exists to specify
+ a set of audit requirements that comply with the
+ family/component dependencies lists, while at the same time
+ resulting in a deficient audit function (e.g. an audit
+ function that requires all security relevant events to be
+ audited but without the selectivity to control them on any
+ reasonable basis such as individual user or object).
+
+
+ The implementation of audit requirements for networks and
+ other large systems may differ significantly from those
+ needed for stand-alone systems. Larger, more complex and
+ active systems require more thought concerning which audit
+ data to collect and how this should be managed, due to
+ lowered feasibility of interpreting (or even storing) what
+ gets collected. The traditional notion of a time-ordered list
+ or ``trail'' of audited events may not
+ be applicable in a global asynchronous network with
+ arbitrarily many events occurring at once.
+
+ Also, different hosts and servers on a distributed TOE may
+ have differing naming policies and values. Symbolic names
+ presentation for audit review may require a net-wide
+ convention to avoid redundancies and ``name
+ clashes.''
+
+ A multi-object audit repository, portions of which are
+ accessible by a potentially wide variety of authorised
+ users, may be required if audit repositories are to serve a
+ useful function in distributed systems.
+
+ Finally, misuse of authority by authorised users should be
+ addressed by systematically avoiding local storage of audit
+ data pertaining to administrator actions.
+
+
+
+
+
+
+ This family defines the response to be taken in case of
+ detected events indicative of a potential security
+ violation.
+
+
+
+ The Security audit automatic response family describes
+ requirements for the handling of audit events. The
+ requirement could include requirements for alarms or TSF
+ action (automatic response). For example, the TSF could
+ include the generation of real time alarms, termination of
+ the offending process, disabling of a service, or
+ disconnection or invalidation of a user account.
+
+ An audit event is defined to be an ``potential
+ security violation'' if so indicated by the
+ components.
+
+
+
+
+
+
+
+
+ An action should be taken for follow up action in the
+ event of an alarm. This action can be to inform the
+ authorised user, to present the authorised user with a set
+ of possible containment actions, or to take corrective
+ actions. The timing of the actions should be carefully
+ considered by the PP/ST author.
+
+
+
+ At , the TSF shall take actions in
+ case a potential security violation is detected.
+
+
+ the management (addition, removal, or modification) of
+ actions.
+
+
+ Actions taken due to potential security violations.
+
+
+ The TSF shall take
+
+
+ list of actions
+
+
+
+ the PP/ST author should specify the actions to be taken
+ in case of a potential security violation. An example of
+ such a list is: ``inform the authorised user, disable
+ the subject that created the potential security
+ violation.'' It can also specify that the action to be
+ taken can be specified by an authorised user.
+
+
+ upon detection of a potential security violation.
+
+
+
+
+
+
+
+ This family defines requirements for recording the
+ occurrence of security relevant events that take place under
+ TSF control. This family identifies the level of auditing,
+ enumerates the types of events that shall be auditable by
+ the TSF, and identifies the minimum set of audit-related
+ information that should be provided within various audit
+ record types.
+
+
+
+ The Security audit data generation family includes
+ requirements to specify the audit events that should be
+ generated by the TSF for security-relevant events.
+
+ This family is presented in a manner that avoids a dependency
+ on all components requiring audit support. Each component has
+ an audit section developed in which the events to be audited
+ for that functional area are listed. When the PP/ST author
+ assembles the PP/ST, the items in the audit area are used to
+ complete the variable in this component. Thus, the
+ specification of what could be audited for a functional area
+ is localised in that functional area.
+
+ The list of auditable events is entirely dependent on the
+ other functional families within the PP/ST. Each family
+ definition should therefore include a list of its
+ family-specific auditable events. Each auditable event in the
+ list of auditable events specified in the functional family
+ should correspond to one of the levels of audit event
+ generation specified in this family (i.e. minimal, basic,
+ detailed). This provides the PP/ST author with information
+ necessary to ensure that all appropriate auditable events are
+ specified in the PP/ST. The following example shows how
+ auditable events are to be specified in appropriate functional
+ families:
+
+ ``The following actions should be auditable if is included in the PP/ST:
+
+
+ Minimal: Successful use of the user security attribute
+ administration functions;
+
+
+ Basic: All attempted uses of the user security attribute
+ administration functions;
+
+
+ Basic: Identification of which user security attributes
+ have been modified;
+
+
+ Detailed: With the exception of specific sensitive
+ attribute data items (e.g. passwords, cryptographic
+ keys), the new values of the attributes should be
+ captured.''
+
+
+
+ For each functional component that is chosen, the auditable
+ events that are indicated in that component, at and below the
+ level indicated in should be
+ auditable. If, for example, in the previous example ``Basic''
+ would be selected in , the
+ auditable events mentioned in a), b) and c) should be
+ auditable.
+
+ Observe that the categorisation of auditable events is
+ hierarchical. For example, when Basic Audit Generation is
+ desired, all auditable events identified as being either
+ Minimal or Basic, should also be included in the PP/ST
+ through the use of the appropriate assignment operation,
+ except when the higher level event simply provides more
+ detail than the lower level event. When Detailed Audit
+ Generation is desired, all identified auditable events
+ (Minimal, Basic, and Detailed) should be included in the
+ PP/ST.
+
+ A PP/ST author may decide to include other auditable events
+ beyond those required for a given audit level. For example,
+ the PP/ST may claim only minimal audit capabilities while
+ including most of the basic capabilities because the few
+ excluded capabilities conflict with other PP/ST constraints
+ (e.g. because they require the collection of unavailable
+ data).
+
+ The functionality that creates the auditable event should be
+ specified in the PP or ST as a functional requirement.
+
+ The following are examples of the types of the events that
+ should be defined as auditable within each PP/ST functional
+ component:
+
+
+ Introduction of objects within the control of the TSF into a
+ subject's address space;
+
+
+ Deletion of objects;
+
+
+ Distribution or revocation of access rights or
+ capabilities;
+
+
+ Changes to subject or object security attributes;
+
+
+ Policy checks performed by the TSF as a result of a
+ request by a subject;
+
+
+ The use of access rights to bypass a policy check;
+
+
+ Use of Identification and Authentication functions;
+
+
+ Actions taken by an operator, and/or authorised user
+ (e.g. suppression of a TSF protection mechanism as
+ human-readable labels);
+
+
+ Import/export of data from/to removable media
+ (e.g. printed output, tapes, diskettes).
+
+
+
+
+
+
+
+
+
+
+ This component defines requirements to identify the
+ auditable events for which audit records should be
+ generated, and the information to be provided in the audit
+ records.
+
+ by itself might be used
+ when the SFRs do not require that individual user identities
+ be associated with audit events. This could be appropriate
+ when the PP/ST also contains privacy requirements. If the
+ user identity must be incorporated could be used in addition.
+
+ If the subject is a user, the user identity may be recorded as
+ the subject identity. The identity of the user may not yet been
+ verified if has not been
+ applied. Therefore in the instance of an invalid login the
+ claimed user identity should be recorded. It should be
+ considered to indicate when a recorded identity has not been
+ authenticated.
+
+
+
+ There is a dependency on . If correctness of time is not an issue for
+ this TOE, elimination of this dependency could be
+ justified.
+
+
+
+ defines the level of auditable
+ events, and specifies the list of data that shall be
+ recorded in each record.
+
+
+ The TSF shall be able to generate an audit record of the
+ following auditable events:
+
+
+ Start-up and shutdown of the audit functions;
+
+
+ All auditable events for the
+
+ minimum
+ basic
+ detailed
+ not specified
+
+
+ the PP/ST author should select the level of
+ auditable events called out in the audit section of
+ other functional components included in the
+ PP/ST. This level is one of the following:
+ ``minimum'', ``basic'', ``detailed'' or ``not
+ specified''.
+
+
+ level of audit; and
+
+
+
+
+ other specifically defined auditable events
+
+
+
+ the PP/ST author should assign a list of other
+ specifically defined auditable events to be included
+ in the list of auditable events. The assignment may
+ comprise none, or events that could be auditable
+ events of a functional requirement that are of a
+ higher audit level than requested in , as well as the
+ events generated through the use of a specified
+ Application Programming Interface (API).
+
+ .
+
+
+
+
+ The TSF shall record within each audit record at least the
+ following information:
+
+
+ Date and time of the event, type of event, subject identity (if
+ applicable), and the outcome (success or failure) of the event;
+ and
+
+
+ For each audit event type, based on the auditable event
+ definitions of the functional components included in the
+ PP/ST,
+
+
+ other audit relevant information
+
+
+
+ the PP/ST author should assign, for each auditable
+ events included in the PP/ST, either a list of other
+ audit relevant information to be included in audit
+ events records or none.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ This component addresses the requirement of accountability
+ of auditable events at the level of individual user
+ identity. This component should be used in addition to
+ .
+
+ There is a potential conflict between the audit and privacy
+ requirements. For audit purposes it may be desirable to know
+ who performed an action. The user may want to keep his/her
+ actions to himself/herself and not be identified by other
+ persons (e.g. a site with job offers). Or it might be
+ required in the Organisational Security Policy that the
+ identity of the users must be protected. In those cases the
+ objectives for audit and privacy might contradict each
+ other. Therefore if this requirement is selected and privacy
+ is important, inclusion of the component user pseudonimity
+ might be considered. Requirements on determining the real
+ user name based on its pseudonym are specified in the
+ privacy class.
+
+ If the identity of the user has not yet been verified through
+ authentication, in the instance of an invalid login the claimed
+ user identity should be recorded. It should be considered to
+ indicate when a recorded identity has not been authenticated.
+
+
+
+ At , the TSF shall associate
+ auditable events to individual user identities.
+
+
+ For audit events resulting from actions of identified users, the
+ TSF shall be able to associate each auditable event with the
+ identity of the user that caused the event.
+
+
+
+
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible or
+ real security violations. This analysis may work in support of
+ intrusion detection, or automatic response to a potential
+ security violation.
+
+ The actions to be taken based on the detection can be
+ specified using the family as
+ desired.
+
+
+
+ This family defines requirements for automated means that
+ analyse system activity and audit data looking for possible
+ or real security violations. This analysis may work in
+ support of intrusion detection, or automatic response to a
+ potential security violation.
+
+ The action to be performed by the TSF on detection of a
+ potential violation is defined in components.
+
+ For real-time analysis, audit data could be transformed into a
+ useful format for automated treatment, but into a different
+ useful format for delivery to authorised users for
+ review.
+
+
+
+
+
+
+
+
+ This component is used to specify the set of auditable
+ events whose occurrence or accumulated occurrence held to
+ indicate a potential violation of the enforcement of the
+ SFRs, and any rules to be used to perform the violation
+ analysis.
+
+
+
+ In , basic threshold
+ detection on the basis of a fixed rule set is
+ required.
+
+
+ maintenance of the rules by (adding, modifying, deletion)
+ of rules from the set of rules.
+
+
+ Enabling and disabling of any of the analysis mechanisms;
+
+
+ Automated responses performed by the tool.
+
+
+ The TSF shall be able to apply a set of rules in monitoring
+ the audited events and based upon these rules indicate a
+ potential violation of the enforcement of the SFRs.
+
+
+ The TSF shall enforce the following rules for monitoring
+ audited events:
+
+
+ Accumulation or combination of
+
+
+ subset of defined auditable events
+
+
+
+ the PP/ST author should identify the subset of
+ defined auditable events whose occurrence or
+ accumulated occurrence need to be detected as an
+ indication of a potential violation of the
+ enforcement of the SFRs.
+
+
+ known to indicate a potential security violation;
+
+
+
+
+ any other rules
+
+
+
+ the PP/ST author should specify any other rules that
+ the TSF should use in its analysis of the audit
+ trail. Those rules could include specific
+ requirements to express the needs for the events to
+ occur in a certain period of time (e.g. period of
+ the day, duration). If there are no additional
+ rules that the TSF should use in the analysis of the
+ audit trail, this assignment can be completed with
+ ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+ A profile is a structure that
+ characterises the behaviour of users and/or subjects; it
+ represents how the users/subjects interact with the TSF in
+ a variety of ways. Patterns of usage are established with
+ respect to the various types of activity the
+ users/subjects engage in (e.g. patterns in exceptions
+ raised, patterns in resource utilisation (when, which,
+ how), patterns in actions performed). The ways in which
+ the various types of activity are recorded in the profile
+ (e.g. resource measures, event counters, timers) are
+ referred to as profile metrics.
+
+ Each profile represents the expected patterns of usage
+ performed by members of the profile target
+ group. This pattern may be based on past use
+ (historical patterns) or on normal use for users of
+ similar target groups (expected behaviour). A profile
+ target group refers to one or more users who interact with
+ the TSF. The activity of each member of the profile group
+ is used by the analysis tool in establishing the usage
+ patterns represented in the profile. The following are
+ some examples of profile target groups:
+
+
+ Single user account: one profile per
+ user;
+
+
+ Group ID or Group Account: one profile
+ for all users who possess the same group ID or operate
+ using the same group account;
+
+
+ Operating Role: one profile for all users
+ sharing a given operating role;
+
+
+ System: one profile for all users of a
+ system.
+
+
+
+ Each member of a profile target group is assigned an
+ individual suspicion rating that
+ represents how closely that member's new
+ activity corresponds to the established patterns of usage
+ represented in the group profile.
+
+ The sophistication of the anomaly detection tool will
+ largely be determined by the number of target profile
+ groups required by the PP/ST and the complexity of the
+ required profile metrics.
+
+
+ The PP/ST author should enumerate specifically what activity
+ should be monitored and/or analysed by the TSF. The PP/ST
+ author should also identify specifically what information
+ pertaining to the activity is necessary to construct the
+ usage profiles.
+
+ requires that the TSF
+ maintain profiles of system usage. The word maintain implies
+ that the anomaly detector is actively updating the usage
+ profile based on new activity performed by the profile
+ target members. It is important here that the metrics for
+ representing user activity are defined by the PP/ST
+ author. For example, there may be a thousand different
+ actions an individual may be capable of performing, but the
+ anomaly detector may choose to monitor a subset of that
+ activity. Anomalous activity gets integrated into the
+ profile just like non-anomalous activity (assuming the tool
+ is monitoring those actions). Things that may have appeared
+ anomalous four months ago, might over time become the norm
+ (and vice-versa) as the user's work duties change. The TSF
+ wouldn't be able to capture this notion if it filtered out
+ anomalous activity from the profile updating
+ algorithms.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ suspicion rating.
+
+ The PP/ST author should define how to interpret suspicion
+ ratings and the conditions under which anomalous activity is
+ indicated to the
+ mechanism.
+
+
+
+ In , the TSF maintains
+ individual profiles of system usage, where a profile
+ represents the historical patterns of usage performed by
+ members of the profile target group. A profile target group
+ refers to a group of one or more individuals (e.g. a single
+ user, users who share a group ID or group account, users who
+ operate under an assigned role, users of an entire system or
+ network node) who interact with the TSF. Each member of a
+ profile target group is assigned an individual suspicion
+ rating that represents how well that member's current
+ activity corresponds to the established patterns of usage
+ represented in the profile. This analysis can be performed
+ at runtime or during a post-collection batch-mode
+ analysis.
+
+
+ maintenance (deletion, modification, addition) of the
+ group of users in the profile target group.
+
+
+
+ The TSF shall be able to maintain profiles of system usage,
+ where an individual profile represents the historical
+ patterns of usage performed by the member(s) of
+
+
+ the profile target group
+
+
+
+ the PP/ST author should specify the profile target
+ group. A single PP/ST may include multiple profile
+ target groups.
+
+ .
+
+
+ The TSF shall be able to maintain a suspicion rating
+ associated with each user whose activity is recorded in a
+ profile, where the suspicion rating represents the degree to
+ which the user's current activity is found
+ inconsistent with the established patterns of usage
+ represented in the profile.
+
+
+ The TSF shall be able to indicate a possible violation of
+ the enforcement of the SFRs when a user's suspicion rating exceeds
+ the following threshold conditions
+
+
+ conditions under which anomalous activity is reported by
+ the TSF
+
+
+
+ the PP/ST author should specify conditions under which
+ anomalous activity is reported by the TSF. Conditions
+ may include the suspicion rating reaching a certain
+ value, or be based on the type of anomalous activity
+ observed.
+
+ .
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant that they are always worthy of
+ independent review. Example of such events include the
+ deletion of a key TSF security data file (e.g. the
+ password file) or activity such as a remote user
+ attempting to gain administrative privilege. These events
+ are referred to as signature events in that their
+ occurrence in isolation from the rest of the system
+ activity are indicative of intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data).
+
+ The elements of do not
+ require that the TSF implementing the immediate attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able
+ to detect the occurrence of signature events that represent
+ a significant threat to enforcement of the SFRs. This search
+ for signature events may occur in real-time or during a
+ post-collection batch-mode analysis.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of system
+ events whose occurrence, in isolation from all other
+ system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by
+ themselves indicate a clear violation to the enforcement
+ of the SFRs, or whose occurrence is so significant that
+ they warrant actions.
+
+
+ that may indicate a violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events
+ against the record of system activity discernible from an
+ examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when a system event is found to match
+ a signature event that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+
+
+
+
+
+ In practice, it is at best rare when an analysis tool can
+ detect with certainty when a security violation is
+ imminent. However, there do exist some system events that
+ are so significant they are always worthy of independent
+ review. Example of such events include the deletion of a key
+ TSF security data file (e.g. the password file) or activity
+ such as a remote user attempting to gain administrative
+ privilege. These events are referred to as signature events
+ in that their occurrence in isolation from the rest of the
+ system activity are indicative of intrusive activity. Event
+ sequences are an ordered set of signature events that might
+ indicate intrusive activity.
+
+ The complexity of a given tool will depend greatly on the
+ assignments defined by the PP/ST author in identifying the
+ base set of signature events and event sequences.
+
+ The PP/ST author should enumerate specifically what events
+ should be monitored by the TSF in order to perform the
+ analysis. The PP/ST author should identify specifically
+ what information pertaining to the event is necessary to
+ determine if the event maps to a signature event.
+
+ Administrative notification should be provided such that
+ the authorised user understands the significance of the
+ event and the appropriate possible responses.
+
+ An effort was made in the specification of these
+ requirements to avoid a dependency on audit data as the
+ sole input for monitoring system activity. This was done
+ in recognition of the existence of previously developed
+ intrusion detection tools that do not perform their
+ analyses of system activity solely through the use of
+ audit data (examples of other input data include network
+ datagrams, resource/accounting data, or combinations of
+ various system data). Levelling, therefore, requires the
+ PP/ST author to specify the type of input data used to
+ monitor system activity.
+
+ The elements of do not
+ require that the TSF implementing the complex attack
+ heuristics be the same TSF whose activity is being
+ monitored. Thus, one can develop an intrusion detection
+ component that operates independently of the system whose
+ system activity is being analysed.
+
+
+
+ In , the TSF shall be able to
+ represent and detect multi-step intrusion scenarios. The
+ TSF is able to compare system events (possibly performed
+ by multiple individuals) against event sequences known to
+ represent entire intrusion scenarios. The TSF shall be
+ able to indicate when a signature event or event sequence
+ is found that indicates a potential violation of the
+ enforcement of the SFRs.
+
+
+ maintenance (deletion, modification, addition) of the subset
+ of system events;
+
+
+ maintenance (deletion, modification, addition) of the set of
+ sequence of system events.
+
+
+
+ The TSF shall be able to maintain an internal representation
+ of the following event sequences of known intrusion
+ scenarios
+
+
+ list of sequences of system events whose occurrence are
+ representative of known penetration scenarios
+
+
+
+ the PP/ST author should identify a base set of list of
+ sequences of system events whose occurrence are
+ representative of known penetration scenarios. These
+ event sequences represent known penetration
+ scenarios. Each event represented in the sequence should
+ map to a monitored system event, such that as the system
+ events are performed, they are bound (mapped) to the
+ known penetration event sequences.
+
+
+ and the following signature events
+
+
+ a subset of system events
+
+
+
+ the PP/ST author should identify a base subset of
+ system events whose occurrence, in isolation from all
+ other system activity, may indicate a violation of the
+ enforcement of the SFRs. These include events that by themselves indicate
+ a clear violation to the SFRs, or whose occurrence is
+ so significant they warrant action.
+
+
+ that may indicate a potential
+ violation of the enforcement of the SFRs.
+
+
+ The TSF shall be able to compare the signature events and
+ event sequences against the record of system activity
+ discernible from an examination of
+
+
+ the information to be used to determine system activity
+
+
+
+ the PP/ST author should specify the information used to
+ determine system activity. This information is the input
+ data used by the analysis tool to determine the system
+ activity that has occurred on the TOE. This data may
+ include audit data, combinations of audit data with
+ other system data, or may consist of data other than the
+ audit data. The PP/ST author should define precisely
+ what system events and event attributes are being
+ monitored within the input data.
+
+ .
+
+
+ The TSF shall be able to indicate a potential violation of the
+ enforcement of the SFRs when system activity is found to match
+ a signature event or event sequence that indicates a potential
+ violation of the enforcement of the SFRs.
+
+
+
+
+
+
+
+ This family defines the requirements for audit tools that
+ should be available to authorised users to assist in the
+ review of audit data.
+
+
+
+ The Security audit review family defines requirements
+ related to review of the audit information.
+
+ These functions should allow pre-storage or post-storage
+ audit selection that includes, for example, the ability to
+ selectively review:
+
+
+ the actions of one or more users (e.g. identification,
+ authentication, TOE entry, and access control actions);
+
+
+ the actions performed on a specific object or TOE
+ resource;
+
+
+ all of a specified set of audited exceptions;
+ or
+
+
+ actions associated with a specific SFR attribute.
+
+
+
+ The distinction between audit reviews is based on
+ functionality. Audit review (only) encompasses the ability to
+ view audit data. Selectable review is more sophisticated, and
+ requires the ability to select subsets of audit data based on a
+ single criterion or multiple criteria with logical (i.e. and/or)
+ relations, and order the audit data before it is
+ reviewed.
+
+
+
+
+
+
+
+
+ This component will provide authorised users the
+ capability to obtain and interpret the information. In
+ case of human users this information needs to be in a
+ human understandable presentation. In case of external IT
+ entities the information needs to be unambiguously
+ represented in an electronic fashion.
+
+
+
+ This component is used to specify that users and/or
+ authorised users can read the audit records. These audit
+ records will be provided in a manner appropriate to the
+ user. There are different types of users (human users,
+ machine users) that might have different needs.
+
+ The content of the audit records that can be viewed can be
+ specified.
+
+
+
+ , provides the capability to read
+ information from the audit records.
+
+
+ maintenance (deletion, modification, addition) of the group
+ of users with read access right to the audit records.
+
+
+ Reading of information from the audit records.
+
+
+ The TSF shall provide
+
+
+ authorised users
+
+
+
+ the PP/ST author should specify the authorised users
+ that can use this capability. If appropriate the PP/ST
+ author may include security roles (see ).
+
+
+ with the capability to read
+
+
+ list of audit information
+
+
+
+ the PP/ST author should specify the type of information
+ the specified user is permitted to obtain from the audit
+ records. Examples are ``all'', ``subject identity'',
+ ``all information belonging to audit records referencing
+ this user''. When employing the SFR, FAU_SAR.1, it is not
+ necessary to repeat, in full detail, the list of audit
+ information first specified in FAU_GEN.1. Use of terms
+ such as ``all'' or ``all audit information'' assist in
+ eliminating ambiguity and the further need for
+ comparative analysis between the two security
+ requirements.
+
+
+ from the audit records.
+
+
+ The TSF shall provide the audit records in a manner suitable
+ for the user to interpret the information.
+
+
+
+
+
+
+
+
+
+ This component specifies that any users not identified in
+ will not be able to read
+ the audit records.
+
+
+
+ , requires that there are
+ no other users except those that have been identified in
+ that can read the
+ information.
+
+
+ Unsuccessful attempts to read information from the audit
+ records.
+
+
+ The TSF shall prohibit all users read access to the audit
+ records, except those users that have been granted explicit
+ read-access.
+
+
+
+
+
+
+
+
+
+ This component is used to specify that it should be
+ possible to perform selection of the audit data to be
+ reviewed. If based on multiple criteria, those criteria
+ should be related together with logical
+ (i.e. ``and'' or
+ ``or'') relations, and the tools
+ should provide the ability to manipulate audit data
+ (e.g. sort, filter).
+
+
+
+ , requires audit review
+ tools to select the audit data to be reviewed based on
+ criteria.
+
+
+ the parameters used for the viewing.
+
+
+ The TSF shall provide the ability to apply
+
+ methods of selection and/or ordering
+
+ the PP/ST author should specify whether capabilities to
+ select and/or order audit data is required from the
+ TSF.
+ of audit data based on
+
+ criteria with logical relations
+
+ the PP/ST author should assign the criteria, possibly
+ with logical relations, to be used to select the audit
+ data for review. The logical relations are intended to
+ specify whether the operation can be on an individual
+ attribute or a collection of attributes. An example of
+ this assignment could be: ``application, user account
+ and/or location''. In this case the operation could be
+ specified using any combination of the three attributes:
+ application, user account and location..
+
+
+
+
+
+
+
+ This family defines requirements to select the set of events to
+ be audited during TOE operation from the set of all auditable
+ events.
+
+
+
+ The Security audit event selection family provides
+ requirements related to the capabilities of identifying which
+ of the possible auditable events are to be audited. The
+ auditable events are defined in the family, but those events should be defined as
+ being selectable in this component to be audited.
+
+ This family ensures that it is possible to keep the audit
+ trail from becoming so large that it becomes useless, by
+ defining the appropriate granularity of the selected
+ security audit events.
+
+
+
+
+
+
+
+
+
+ This component defines the selection criteria used, and the
+ resulting audited subsets of the set of all auditable events,
+ based on user attributes, subject attributes, object attributes,
+ or event types.
+
+ The existence of individual user identities is not assumed
+ for this component. This allows for TOEs such as routers
+ that may not support the notion of users.
+
+ For a distributed environment, the host identity could be
+ used as a selection criteria for events to be audited.
+
+ The management function
+ will handle the rights of authorised users to query or
+ modify the selections.
+
+
+ , requires the ability to
+ select the set of events to be audited from the set of all
+ auditable events, identified in , based upon attributes to be specified by the
+ PP/ST author.
+
+
+ maintenance of the rights to view/modify the audit events.
+
+
+ All modifications to the audit configuration that occur
+ while the audit collection functions are operating.
+
+
+ The TSF shall be able to select the set of events to be audited from
+ the set of all auditable events based on the following
+ attributes:
+ object identityuser identitysubject identityhost identityevent type
+ the PP/ST author should select whether the
+ security attributes upon which audit selectivity
+ is based, is related to object identity, user
+ identity, subject identity, host identity, or event type.
+ list of additional attributes that audit selectivity is based upon
+
+ the PP/ST author should specify any additional
+ attributes upon which audit selectivity is based. If
+ there are no additional rules upon which audit
+ selectivity is based, this assignment can be
+ completed with ``none''.
+
+
+
+
+
+
+ This family defines the requirements for the TSF to be able
+ to create and maintain a secure audit trail. Stored audit
+ records refers to those records within the audit trail, and
+ not the audit records that have been retrieved (to temporary
+ storage) through selection.
+
+
+
+ The Security audit event storage family describes
+ requirements for storing audit data for later use, including
+ requirements controlling the loss of audit information due
+ to TOE failure, attack and/or exhaustion of storage
+ space.
+
+
+
+
+
+
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+ The TSF will protect the stored audit records in the audit trail from unauthorised
+ deletion and modification. It is noted that in some TOEs the
+ auditor (role) might not be authorised to delete the audit
+ records for a certain period of time.
+
+
+
+ At , requirements are
+ placed on the audit trail. It will be protected from
+ unauthorised deletion and/or modification.
+
+
+ The TSF shall protect the stored audit records in the audit
+ trail from unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+
+
+
+
+
+
+
+
+ This component allows the PP/ST author to specify to which
+ metrics the audit trail should conform.
+
+ In a distributed environment, as the location of the audit
+ trail is in the TSF, but not necessarily co-located with
+ the function generating the audit data, the PP/ST author
+ could request authentication of the originator of the
+ audit record, or non-repudiation of the origin of the
+ record prior storing this record in the audit trail.
+
+
+
+ , specifies the guarantees
+ that the TSF maintains over the audit data given the
+ occurrence of an undesired condition.
+
+
+ maintenance of the parameters that control the audit storage
+ capability.
+
+
+ The TSF shall protect the stored audit records in the audit trail from
+ unauthorised deletion.
+
+
+ The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF
+ shall prevent or only be able to detect modifications of the
+ stored audit records in the audit trail. Only one of these
+ options may be
+ chosen. unauthorised
+ modifications to the stored audit records in the audit trail.
+
+
+ The TSF shall ensure that
+
+
+ metric for saving audit records
+
+
+
+ the PP/ST author should specify the metric that the TSF
+ must ensure with respect to the stored audit
+ records. This metric limits the data loss by enumerating
+ the number of records that must be kept, or the time
+ that records are guaranteed to be maintained. An example
+ of the metric could be ``100,000'' indicating that
+ 100,000 audit records can be stored.
+
+
+ stored audit records will be maintained when the
+ following conditions occur:
+
+ audit storage exhaustion
+ failure
+ attack
+
+
+ the PP/ST author should specify the condition under which the
+ TSF shall still be able to maintain a defined amount of audit
+ data. This condition can be any of the following: audit
+ storage exhaustion, failure, attack.
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that actions will be taken when
+ the audit trail exceeds certain pre-defined limits.
+
+
+
+ , specifies actions to be taken if a
+ threshold on the audit trail is exceeded.
+
+
+ maintenance of the threshold;
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of imminent audit storage failure.
+
+
+ Actions taken due to exceeding of a threshold.
+
+
+ The TSF shall
+
+
+ actions to be taken in case
+ of possible audit storage failure
+
+
+
+ the PP/ST author should indicate the pre-defined
+ limit. If the management functions indicate that this
+ number might be changed by the authorised user, this
+ value is the default value. The PP/ST author might
+ choose to let the authorised user define this
+ limit. In that case the assignment can be for example
+ ``an authorised user set limit''.
+
+
+ if the audit trail exceeds
+
+
+ pre-defined limit
+
+
+
+ the PP/ST author should specify actions that should be
+ taken in case of imminent audit storage failure
+ indicated by exceeding the threshold. Actions might
+ include informing an authorised user.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies the behaviour of the TOE if the audit
+ trail is full: either audit records are ignored, or the TOE is
+ frozen such that no audited events can take place. The
+ requirement also states that no matter how the requirement is
+ instantiated, the authorised user with specific rights to this
+ effect, can continue to generate audited events (actions). The
+ reason is that otherwise the authorised user could not even
+ reset the TOE. Consideration should be given to the choice of
+ the action to be taken by the TSF in the case of audit storage
+ exhaustion, as ignoring events, which provides better
+ availability of the TOE, will also permit actions to be
+ performed without being recorded and without the user being
+ accountable.
+
+
+
+ , specifies actions in case the
+ audit trail is full.
+
+
+ maintenance (deletion, modification, addition) of actions to
+ be taken in case of audit storage failure.
+
+
+ Actions taken due to the audit storage failure.
+
+
+ The TSF shall
+ ``ignore audited
+ events''``prevent audited events,
+ except those taken by the authorised user with special
+ rights''
+ ``overwrite the oldest stored audit
+ records''
+
+ the PP/ST author should select whether the TSF shall ignore
+ audited actions, or whether it should prevent audited
+ actions from happening, or whether the oldest audit records
+ should be overwritten when the TSF can no longer store audit
+ records. Only one of these options may be chosen.
+ and
+
+ other actions to be taken in case of audit storage
+ failure
+
+ the PP/ST author should specify other actions that should be
+ taken in case of audit storage failure, such as informing the
+ authorised user. If there is no other action to be taken in
+ case of audit storage failure, this assignment can be
+ completed with ``none''.
+ if the audit trail is full.
+
+
+
+
+
+
+
+ This class provides two families specifically concerned with
+ assuring the identity of a party participating in a data
+ exchange. These families are related to assuring the identity
+ of the originator of transmitted information (proof of origin)
+ and assuring the identity of the recipient of transmitted
+ information (proof of receipt). These families ensure that an
+ originator cannot deny having sent the message, nor can the
+ recipient deny having received it.
+
+
+
+ This class describes requirements specifically of interest for
+ TOEs that are used for the transport of information. Families
+ within this class deal with non-repudiation.
+
+ In this class the concept of ``information'' is
+ used. This information should be interpreted as the object
+ being communicated, and could contain an electronic mail
+ message, a file, or a set of predefined attribute types.
+
+ In the literature, the terms ``proof of receipt''
+ and ``proof of origin'' are commonly used
+ terms. However it is recognised that the term
+ ``proof'' might be interpreted in a legal sense to
+ imply a form of mathematical rationale. The components in this
+ class interpret the de-facto use of the word
+ ``proof'' in the context of ``evidence''
+ that the TSF demonstrates the non-repudiated transport of
+ types of information.
+
+
+
+
+
+ Non-repudiation of origin ensures that the originator of
+ information cannot successfully deny having sent the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that receives information
+ during a data exchange is provided with evidence of the
+ origin of the information. This evidence can then be
+ verified by either this subject or other subjects.
+
+
+
+ Non-repudiation of origin defines requirements to provide
+ evidence to users/subjects about the identity of the
+ originator of some information. The originator cannot
+ successfully deny having sent the information because
+ evidence of origin (e.g. digital signature) provides
+ evidence of the binding between the originator and the
+ information sent. The recipient or a third party can verify
+ the evidence of origin. This evidence should not be
+ forgeable.
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of origin might
+ fail. Therefore a PP/ST author should consider including
+ integrity requirements such as in the
+ PP/ST.
+
+ In non-repudiation there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of origin (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of origin, for
+ example, a recipient or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was transmitted. For example, requests for
+ proposals must be transmitted before a certain date in order
+ to be considered. In such instances, these requirements can
+ be customised to provide a timestamp indication (time of
+ origin).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with the capability to request evidence of the
+ origin of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and recipients of evidence.
+
+
+ The identity of the user who requested that evidence of
+ origin would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall be able to generate evidence of origin for
+ transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection, should specify the third
+ parties that can request evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of origin.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+ list of information fields
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of origin for transmitted information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of origin
+ for transmitted
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of origin
+ function, for example, electronic mail messages.
+
+
+ at all times.
+
+
+ The TSF shall be able to relate the
+
+
+ list of attributes
+
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, originator identity, time of origin, and
+ location of origin.
+
+
+ of the originator of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields within the information over which
+ the attributes provide evidence of origin, such as the
+ body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ origin of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of origin. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can verify the evidence of origin.
+
+
+ given
+
+
+ limitations on the evidence of origin
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ Non-repudiation of receipt ensures that the recipient of
+ information cannot successfully deny receiving the
+ information. This family requires that the TSF provide a
+ method to ensure that a subject that transmits information
+ during a data exchange is provided with evidence of receipt
+ of the information. This evidence can then be verified by
+ either this subject or other subjects.
+
+
+
+ Non-repudiation of receipt defines requirements to provide
+ evidence to other users/subjects that the information was
+ received by the recipient. The recipient cannot successfully
+ deny having received the information because evidence of
+ receipt (e.g. digital signature) provides evidence of the
+ binding between the recipient attributes and the
+ information. The originator or a third party can verify the
+ evidence of receipt. This evidence should not be forgeable.
+
+ It should be noted that the provision of evidence that the
+ information was received does not necessarily imply that the
+ information was read or comprehended, but only delivered
+
+ If the information or the associated attributes are altered
+ in any way, validation of the evidence of receipt with
+ respect to the original information might fail. Therefore a
+ PP/ST author should consider including integrity
+ requirements such as in the PP/ST.
+
+ In non-repudiation, there are several different roles
+ involved, each of which could be combined in one or more
+ subjects. The first role is a subject that requests evidence
+ of receipt (only in ). The second role
+ is the recipient and/or other subjects to which the evidence
+ is provided, (e.g. a notary). The third role is a subject
+ that requests verification of the evidence of receipt, for
+ example, an originator or a third party such as an arbiter.
+
+ The PP/ST author must specify the conditions that must be
+ met to be able to verify the validity of the evidence. An
+ example of a condition which could be specified is where the
+ verification of evidence must occur within 24 hours. These
+ conditions, therefore, allow the tailoring of the
+ non-repudiation to legal requirements, such as being able to
+ provide evidence for several years.
+
+ In most cases, the identity of the recipient will be the
+ identity of the user who received the transmission. In some
+ instances, the PP/ST author does not want the user identity
+ to be exported. In that case, the PP/ST author must consider
+ whether it is appropriate to include this class, or whether
+ the identity of the transport service provider or the
+ identity of the host should be used.
+
+ In addition to (or instead of) the user identity, a PP/ST
+ author might be more concerned about the time the
+ information was received. For example, when an offer expires
+ at a certain date, orders must be received before a certain
+ date in order to be considered. In such instances, these
+ requirements can be customised to provide a timestamp
+ indication (time of receipt).
+
+
+
+
+
+
+
+
+ , requires the TSF to provide
+ subjects with a capability to request evidence of the
+ receipt of information.
+
+
+ The management of changes to information types, fields,
+ originator attributes and third parties recipients of
+ evidence.
+
+
+ The identity of the user who requested that evidence of
+ receipt would be generated.
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+ The TSF shall be able to generate
+ evidence of receipt for received
+
+
+ list of information types
+
+
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example, electronic mail messages.
+
+
+ at the request of the
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can request
+ evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subject who
+ can request evidence of receipt.
+
+ .
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ , requires that the TSF always
+ generate evidence of receipt for received information.
+
+
+
+ The invocation of the non-repudiation service.
+
+
+ Identification of the information, the destination, and a
+ copy of the evidence provided.
+
+
+ The identity of the user who requested a verification of the
+ evidence.
+
+
+
+ The TSF shall enforce the generation of evidence of receipt
+ for received
+
+ list of information types
+
+ the PP/ST author should fill in the types of
+ information subject to the evidence of receipt
+ function, for example electronic mail messages. at all times.
+
+
+ The TSF shall be able to relate the
+
+ list of attributes
+
+
+ the PP/ST author should fill in the list of the
+ attributes that shall be linked to the information;
+ for example, recipient identity, time of receipt, and
+ location of receipt.
+
+
+ of the recipient of the information, and the
+
+
+ list of information fields
+
+
+
+ the PP/ST author should fill in the list of
+ information fields with the fields within the
+ information over which the attributes provide evidence
+ of receipt, such as the body of a message.
+
+
+ of the information to which the evidence applies.
+
+
+ The TSF shall provide a capability to verify the evidence of
+ receipt of information to
+
+
+ originator
+
+
+ recipient
+
+
+
+
+ list of third parties
+
+
+
+ the PP/ST author, dependent on the selection,
+ should specify the third parties that can verify
+ the evidence of receipt. A third party could be an
+ arbiter, judge or legal body.
+
+
+
+
+
+ the PP/ST author should specify the user/subjects who
+ can verify the evidence of receipt.
+
+
+ given
+
+
+ limitations on the evidence of receipt
+
+
+
+ the PP/ST author should fill in the list of
+ limitations under which the evidence can be
+ verified. For example the evidence can only be
+ verified within a 24 hour time interval. An assignment
+ of ``immediate'' or
+ ``indefinite'' is acceptable.
+
+ .
+
+
+
+
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+
+
+ The TSF may employ cryptographic functionality to help satisfy
+ several high-level security objectives. These include (but are
+ not limited to): identification and authentication,
+ non-repudiation, trusted path, trusted channel and data
+ separation. This class is used when the TOE implements
+ cryptographic functions, the implementation of which could be
+ in hardware, firmware and/or software.
+
+ The class is composed of two families: and . The family addresses the management aspects of
+ cryptographic keys, while the family is
+ concerned with the operational use of those cryptographic
+ keys.
+
+ For each cryptographic key generation method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key distribution method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key access method implemented by the
+ TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic key destruction method implemented by
+ the TOE, if any, the PP/ST author should select the component.
+
+ For each cryptographic operation (such as digital signature,
+ data encryption, key agreement, secure hash, etc.) performed
+ by the TOE, if any, the PP/ST author should select the component.
+
+ Cryptographic functionality may be used to meet objectives
+ specified in class , and in families , , ,
+ , , , to meet a variety of objectives. In the cases
+ where cryptographic functionality is used to meet objectives
+ for other classes, the individual functional components
+ specify the objectives that cryptographic functionality must
+ satisfy. The objectives in class should be
+ used when cryptographic functionality of the TOE is sought by
+ consumers.
+
+
+
+
+
+ Cryptographic keys must be managed throughout their life
+ cycle. This family is intended to support that lifecycle and
+ consequently defines requirements for the following
+ activities: cryptographic key generation, cryptographic key
+ distribution, cryptographic key access and cryptographic key
+ destruction. This family should be included whenever there
+ are functional requirements for the management of
+ cryptographic keys.
+
+
+
+ Cryptographic keys must be managed throughout their
+ lifetime. The typical events in the lifecycle of a
+ cryptographic key include (but are not limited to):
+ generation, distribution, entry, storage, access
+ (e.g. backup, escrow, archive, recovery) and destruction.
+
+ The inclusion of other stages is dependent on the key management
+ strategy being implemented, as the TOE need not be involved in
+ all of the key life-cycle (e.g. the TOE may only generate and
+ distribute cryptographic keys).
+
+ This family is intended to support the cryptographic key
+ lifecycle and consequently defines requirements for the
+ following activities: cryptographic key generation,
+ cryptographic key distribution, cryptographic key access and
+ cryptographic key destruction. This family should be
+ included whenever there are functional requirements for the
+ management of cryptographic keys.
+
+ If Security Audit Data Generation is
+ included in the PP/ST then, in the context of the events
+ being audited:
+
+
+ The object attributes may include the assigned user
+ for the cryptographic key, the user role, the
+ cryptographic operation that the cryptographic key is
+ to be used for, the cryptographic key identifier and
+ the cryptographic key validity period.
+
+
+ The object value may include the values of cryptographic
+ key(s) and parameters excluding any sensitive
+ information (such as secret or private cryptographic
+ keys).
+
+
+
+ Typically, random numbers are used to generate cryptographic
+ keys. If this is the case, then
+ should be used instead of the component .
+ In cases where random number generation is required for purposes other
+ than for the generation of cryptographic keys, the component
+ should be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic key sizes and
+ method used to generate cryptographic keys to be
+ specified, this can be in accordance with an assigned
+ standard. It should be used to specify the cryptographic
+ key sizes and the method (e.g. algorithm) used to generate
+ the cryptographic keys. Only one instance of the component
+ is needed for the same method and multiple key sizes. The
+ key size could be common or different for the various
+ entities, and could be either the input to or the output
+ from the method.
+
+
+
+ , requires cryptographic keys to be
+ generated in accordance with a specified algorithm and key
+ sizes which can be based on an assigned standard.
+
+
+
+ Success and failure of the activity.
+
+
+ The object attribute(s), and object value(s) excluding any
+ sensitive information (e.g. secret or private keys).
+
+
+ The TSF shall generate cryptographic keys in accordance with
+ a specified cryptographic key generation algorithm
+
+
+ cryptographic key generation algorithm
+
+
+
+ the PP/ST author should specify the cryptographic key
+ generation algorithm to be used.
+
+
+ and specified cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to generate
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to distribute
+ cryptographic keys to be specified, this can be in
+ accordance with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ distributed in accordance with a specified distribution
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall distribute cryptographic keys in accordance
+ with a specified cryptographic key distribution method
+
+
+ cryptographic key distribution method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ distribution method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to distribute
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to access
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires access to cryptographic
+ keys to be performed in accordance with a specified access
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall perform
+
+
+ type of cryptographic key access
+
+
+
+ the PP/ST author should specify the type of
+ cryptographic key access being used. Examples of types
+ of cryptographic key access include (but are not
+ limited to) cryptographic key backup, cryptographic
+ key archival, cryptographic key escrow and
+ cryptographic key recovery.
+
+
+ in accordance with a specified cryptographic key access
+ method
+
+
+ cryptographic key access method
+
+
+
+ the PP/ST author should specify the cryptographic key
+ access method to be used.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to access cryptographic
+ keys. The assigned standard may comprise none, one or
+ more actual standards publications, for example, from
+ international, national, industry or organisational
+ standards.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the method used to destroy
+ cryptographic keys be specified, this can be in accordance
+ with an assigned standard.
+
+
+
+ , requires cryptographic keys to be
+ destroyed in accordance with a specified destruction
+ method which can be based on an assigned standard.
+
+
+
+
+
+ The TSF shall destroy cryptographic keys in accordance with
+ a specified cryptographic key destruction method
+
+
+ cryptographic key destruction method
+
+
+
+ the PP/ST author should specify the key destruction
+ method to be used to destroy cryptographic keys.
+
+
+ that meets the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents the method used to destroy
+ cryptographic keys. The assigned standard may comprise
+ none, one or more actual standards publications, for
+ example, from international, national, industry or
+ organisational standards.
+
+ .
+
+
+
+
+
+
+
+ In order for a cryptographic operation to function
+ correctly, the operation must be performed in accordance
+ with a specified algorithm and with a cryptographic key of a
+ specified size. This family should be included whenever
+ there are requirements for cryptographic operations to be
+ performed.
+
+ Typical cryptographic operations include data encryption
+ and/or decryption, digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or verification of checksum, secure hash
+ (message digest), cryptographic key encryption and/or
+ decryption, and cryptographic key agreement.
+
+
+
+ A cryptographic operation may have cryptographic mode(s) of
+ operation associated with it. If this is the case, then the
+ cryptographic mode(s) must be specified. Examples of
+ cryptographic modes of operation are cipher block chaining,
+ output feedback mode, electronic code book mode, and cipher
+ feedback mode.
+
+ Cryptographic operations may be used to support one or more
+ TOE security services. The component
+ may need to be iterated more than once depending on:
+
+
+ the user application for which the security service is
+ being used.
+
+
+ the use of different cryptographic algorithms and/or
+ cryptographic key sizes.
+
+
+ the type or sensitivity of the data being operated on.
+
+
+
+ If Security audit data generation is
+ included in the PP/ST then, in the context of the
+ cryptographic operation events being audited:
+
+
+ The types of cryptographic operation may include digital
+ signature generation and/or verification, cryptographic
+ checksum generation for integrity and/or for
+ verification of checksum, secure hash (message digest)
+ computation, data encryption and/or decryption,
+ cryptographic key encryption and/or decryption,
+ cryptographic key agreement and random number
+ generation.
+
+
+ The subject attributes may include subject role(s) and
+ user(s) associated with the subject.
+
+
+ The object attributes may include the assigned user for
+ the cryptographic key, user role, cryptographic
+ operation the cryptographic key is to be used for,
+ cryptographic key identifier, and the cryptographic key
+ validity period.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component requires the cryptographic algorithm and
+ key size used to perform specified cryptographic
+ operation(s) which can be based on an assigned standard.
+
+
+
+ , requires a cryptographic operation
+ to be performed in accordance with a specified algorithm
+ and with a cryptographic key of specified sizes. The
+ specified algorithm and cryptographic key sizes can be
+ based on an assigned standard.
+
+
+ Success and failure, and the type of cryptographic
+ operation.
+
+
+ Any applicable cryptographic mode(s) of operation, subject
+ attributes and object attributes.
+
+
+ The TSF shall perform
+
+
+ list of cryptographic operations
+
+
+
+ the PP/ST author should specify the cryptographic
+ operations being performed. Typical cryptographic
+ operations include digital signature generation and/or
+ verification, cryptographic checksum generation for
+ integrity and/or for verification of checksum, secure
+ hash (message digest) computation, data encryption
+ and/or decryption, cryptographic key encryption and/or
+ decryption, cryptographic key agreement and random
+ number generation. The cryptographic operation may be
+ performed on user data or TSF data.
+
+
+ in accordance with a specified cryptographic algorithm
+
+
+ cryptographic algorithm
+
+
+
+ the PP/ST author should specify the cryptographic
+ algorithm to be used. Typical cryptographic algorithms
+ include, but are not limited to, DES, RSA and IDEA.
+
+
+ and cryptographic key sizes
+
+
+ cryptographic key sizes
+
+
+
+ the PP/ST author should specify the cryptographic key
+ sizes to be used. The key sizes specified should be
+ appropriate for the algorithm and its intended use.
+
+
+ that meet the following:
+
+
+ list of standards
+
+
+
+ the PP/ST author should specify the assigned standard
+ that documents how the identified cryptographic
+ operation(s) are performed. The assigned standard may
+ comprise none, one or more actual standards
+ publications, for example, from international,
+ national, industry or organisational standards.
+
+ .
+
+
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. is split
+ into four groups of families (listed below) that address user
+ data within a TOE, during import, export, and storage as well
+ as security attributes directly related to user data.
+
+ The families in this class are organised into four groups:
+
+
+ User data protection security function policies:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families permit the PP/ST author to
+ name the user data protection security function policies
+ and define the scope of control of the policy, necessary
+ to address the security objectives. The names of these
+ policies are meant to be used throughout the remainder
+ of the functional components that have an operation that
+ calls for an assignment or selection of an "access
+ control SFP" or an "information flow control
+ SFP". The rules that define the functionality of
+ the named access control and information flow control
+ SFPs will be defined in the and
+ families (respectively).
+
+
+ Forms of user data protection:
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ;
+
+
+ ; and
+
+
+ .
+
+
+
+
+ Off-line storage, import and export:
+
+
+ ;
+
+
+ ;
+
+
+ .
+
+
+
+ Components in these families address the trustworthy
+ transfer into or out of the TOE.
+
+
+ Inter-TSF communication:
+
+
+ ; and
+
+
+ .
+
+
+
+ Components in these families address communication
+ between the TSF of the TOE and another trusted IT
+ product.
+
+
+
+
+
+ This class contains families specifying requirements related
+ to protecting user data. This class differs from FIA and FPT
+ in that specifies components to
+ protect user data, FIA specifies components to protect
+ attributes associated with the user, and FPT specifies
+ components to protect TSF information.
+
+ The class does not contain explicit requirements for
+ traditional Mandatory Access Controls (MAC) or traditional
+ Discretionary Access Controls (DAC); however, such
+ requirements may be constructed using components from this
+ class.
+
+ does not explicitly deal with
+ confidentiality, integrity, or availability, as all three are
+ most often intertwined in the policy and mechanisms. However,
+ the TOE security policy must adequately cover these three
+ objectives in the PP/ST.
+
+ A final aspect of this class is that it specifies access
+ control in terms of ``operations''. An operation
+ is defined as a specific type of access on a specific
+ object. It depends on the level of abstraction of the PP/ST
+ author whether these operations are described as
+ ``read'' and/or ``write''
+ operations, or as more complex operations such as
+ ``update the database''.
+
+ The access control policies are policies that control access
+ to the information container. The attributes represent
+ attributes of the container. Once the information is out of
+ the container, the accessor is free to modify that
+ information, including writing the information into a
+ different container with different attributes. By contrast, an
+ information flow policies controls access to the information,
+ independent of the container. The attributes of the
+ information, which may be associated with the attributes of
+ the container (or may not, as in the case of a multi-level
+ database) stay with the information as it moves. The accessor
+ does not have the ability, in the absence of an explicit
+ authorisation, to change the attributes of the information.
+
+ This class is not meant to be a complete taxonomy of IT access
+ policies, as others can be imagined. Those policies included
+ here are simply those for which current experience with actual
+ systems provides a basis for specifying requirements. There
+ may be other forms of intent that are not captured in the
+ definitions here.
+
+ For example, one could imagine a goal of having user-imposed
+ (and user-defined) controls on information flow (e.g. an
+ automated implementation of the NO FOREIGN handling
+ caveat). Such concepts could be handled as refinements of, or
+ extensions to the components.
+
+ Finally, it is important when looking at the components in
+ to remember that these components are
+ requirements for functions that may be implemented by a
+ mechanism that also serves or could serve another purpose. For
+ example, it is possible to build an access control policy
+ () that uses labels () as the basis of the access control
+ mechanism.
+
+ A set of SFRs may encompass many security function
+ policies (SFPs), each to be identified by the two policy
+ oriented components , and . These policies will typically take
+ confidentiality, integrity, and availability aspects into
+ consideration as required, to satisfy the TOE
+ requirements. Care should be taken to ensure that all objects
+ are covered by at least one SFP and that there are no
+ conflicts arising from implementing the multiple SFPs.
+
+ When building a PP/ST using components from the class, the following information provides guidance
+ on where to look and what to select from the class.
+
+ The requirements in the class are defined in
+ terms of a set of SFRs that will
+ implement a SFP. Since a TOE may implement multiple SFPs
+ simultaneously, the PP/ST author must specify the name for
+ each SFP, so it can be referenced in other families. This name
+ will then be used in each component selected to indicate that
+ it is being used as part of the definition of requirements for
+ that SFP. This allows the author to easily indicate the
+ scope for operations such as objects covered, operations
+ covered, authorised users, etc.
+
+ Each instantiation of a component can apply to only one
+ SFP. Therefore if an SFP is specified in a component then
+ this SFP will apply to all the elements in this
+ component. The components may be instantiated multiple times
+ within a PP/ST to account for different policies if so
+ desired.
+
+ The key to selecting components from this family is to have a
+ well defined set of TOE security objectives to enable proper
+ selection of the components from the two policy components;
+ and . In and respectively, all access control
+ policies and all information flow control policies are
+ named. Furthermore the scope of control of these components in
+ terms of the subjects, objects and operations covered by this
+ security functionality. The names of these policies are meant
+ to be used throughout the remainder of the functional
+ components that have an operation that calls for an assignment
+ or selection of an ``access control SFP'' or an ``information
+ flow control SFP''. The rules that define the functionality
+ of the named access control and information flow control SFPs
+ will be defined in the and
+ families
+ (respectively).
+
+ The following steps are guidance on how this class is applied
+ in the construction of a PP/ST:
+
+
+ Identify the policies to be enforced from the , and families. These
+ families define scope of control for the policy,
+ granularity of control and may identify some rules to go
+ with the policy.
+
+
+ Identify the components and perform any applicable operations
+ in the policy components. The assignment operations may be
+ performed generally (such as with a statement ``All
+ files'') or specifically (``The files
+ ``A'', ``B'', etc.) depending upon
+ the level of detail known.
+
+
+ Identify any applicable function components from the and families to address
+ the named policy families from and
+ . Perform the operations to make the
+ components define the rules to be enforced by the named
+ policies. This should make the components fit the
+ requirements of the selected function envisioned or to be
+ built.
+
+
+ Identify who will have the ability to control and change
+ security attributes under the function, such as only a
+ security administrator, only the owner of the object,
+ etc. Select the appropriate components from
+ and perform the operations. Refinements may be useful here
+ to identify missing features, such as that some or all
+ changes must be done via trusted path.
+
+
+ Identify any appropriate components from the for initial values for new objects and subjects.
+
+
+ Identify any applicable rollback components from the family.
+
+
+ Identify any applicable residual information protection
+ requirements from the family.
+
+
+ Identify any applicable import or export components, and how
+ security attributes should be handled during import and
+ export, from the and families.
+
+
+ Identify any applicable internal TOE communication
+ components from the family.
+
+
+ Identify any requirements for integrity protection of stored
+ information from the .
+
+
+ Identify any applicable inter-TSF communication components
+ from the or
+ families.
+
+
+
+
+
+
+
+ This family identifies the access control SFPs (by name) and
+ defines the scope of control of the policies that form the
+ identified access control portion of the SFRs related to the
+ SFP. This scope of control is characterised by three sets: the
+ subjects under control of the policy, the objects under control
+ of the policy, and the operations among controlled subjects and
+ controlled objects that are covered by the policy. The criteria
+ allows multiple policies to exist, each having a unique name.
+ This is accomplished by iterating components from this family
+ once for each named access control policy. The rules that
+ define the functionality of an access control SFP will be
+ defined by other families such as and . The names
+ of the access control SFPs identified here in are meant to be used throughout the remainder of
+ the functional components that have an operation that calls for
+ an assignment or selection of an ``access control SFP.''
+
+
+
+ This family is based upon the concept of arbitrary controls
+ on the interaction of subjects and objects. The scope and
+ purpose of the controls is based upon the attributes of the
+ accessor (subject), the attributes of the container being
+ accessed (object), the actions (operations) and any
+ associated access control rules.
+
+ The components in this family are capable of identifying the
+ access control SFPs (by name) to be enforced by the traditional
+ Discretionary Access Control (DAC) mechanisms. It further
+ defines the subjects, objects and operations that are covered by
+ identified access control SFPs. The rules that define the
+ functionality of an access control SFP will be defined by other
+ families, such as and . The names of the access control SFPs
+ defined in are meant to be used
+ throughout the remainder of the functional components that have
+ an operation that calls for an assignment or selection of an
+ ``access control SFP.''
+
+ The access control SFP covers a set of triplets: subject,
+ object, and operations. Therefore a subject can be covered
+ by multiple access control SFPs but only with respect to a
+ different operation or a different object. Of course the
+ same applies to objects and operations.
+
+ A critical aspect of an access control function that
+ enforces an access control SFP is the ability for users to
+ modify the attributes involved in access control
+ decisions. The family does not address
+ these aspects. Some of these requirements are left
+ undefined, but can be added as refinements, while others are
+ covered elsewhere in other families and classes such as
+ .
+
+ There are no audit requirements in as
+ this family specifies access control SFP requirements. Audit
+ requirements will be found in families specifying functions
+ to satisfy the access control SFPs identified in this
+ family.
+
+ This family provides a PP/ST author the capability to
+ specify several policies, for example, a fixed access
+ control SFP to be applied to one scope of control, and a
+ flexible access control SFP to be defined for a different
+ scope of control. To specify more than one access control
+ policy, the components from this family can be iterated
+ multiple times in a PP/ST to different subsets of operations
+ and objects. This will accommodate TOEs that contain
+ multiple policies, each addressing a particular set of
+ operations and objects. In other words, the PP/ST author
+ should specify the required information in the ACC component
+ for each of the access control SFPs that the TSF will
+ enforce. For example, a TOE incorporating three access
+ control SFPs, each covering only a subset of the objects,
+ subjects, and operations within the TOE, will contain one
+ component for each of the three
+ access control SFPs, necessitating a total of three components.
+
+
+
+
+
+
+
+
+ The terms object and subject refer to generic elements in
+ the TOE. For a policy to be implementable, the entities
+ must be clearly identified. For a PP, the objects and
+ operations might be expressed as types such as: named
+ objects, data repositories, observe accesses, etc. For a
+ specific TOE these generic terms (subject, object) must be
+ refined, e.g. files, registers, ports, daemons, open
+ calls, etc.
+
+ This component specifies that the policy cover some
+ well-defined set of operations on some subset of the
+ objects. It places no constraints on any operations
+ outside the set - including operations on objects for
+ which other operations are controlled.
+
+
+
+ , requires that each identified
+ access control SFP be in place for a subset of the
+ possible operations on a subset of the objects in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects, objects, and operations among subjects
+ and objects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ objects, and operations among subjects and objects
+ covered by the SFP.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations on
+ objects, that are included in the SFP, are covered by an
+ access control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ objects and subjects is covered by an access control SFP.
+
+
+
+ , requires that each identified
+ access control SFP cover all operations on subjects and
+ objects covered by that SFP. It further requires that all
+ objects and operations protected by the TSF are covered by at
+ least one identified access control SFP.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ access control SFP to be enforced by the TSF.
+
+
+ on
+
+
+ list of subjects and objects
+
+
+
+ the PP/ST author should specify the list of subjects
+ and objects covered by the SFP. All operations among
+ those subjects and objects will be covered by the SFP.
+
+
+ and all operations among subjects and objects covered by the
+ SFP.
+
+
+ The TSF shall ensure that all operations between any subject
+ controlled by the TSF and any object controlled by the TSF are covered by an
+ access control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in . specifies the scope of control of the
+ policy.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement an access control policy named in which also specifies the scope of
+ control of the policy.
+
+ This family provides a PP/ST author the capability to
+ describe the rules for access control. This results in a
+ TOE where the access to objects will not change. An
+ example of such an object is ``Message of the Day'', which
+ is readable by all, and changeable only by the authorised
+ administrator. This family also provides the PP/ST author
+ with the ability to describe rules that provide for
+ exceptions to the general access control rules. Such
+ exceptions would either explicitly allow or deny
+ authorisation to access an object.
+
+ There are no explicit components to specify other possible
+ functions such as two-person control, sequence rules for
+ operations, or exclusion controls. However, these
+ mechanisms, as well as traditional DAC mechanisms, can be
+ represented with the existing components, by careful
+ drafting of the access control rules.
+
+ A variety of acceptable access control functionality may be
+ specified in this family such as:
+
+
+ Access control lists (ACLs)
+
+
+ Time-based access control specifications
+
+
+ Origin-based access control specifications
+
+
+ Owner-controlled access control attributes
+
+
+
+
+
+
+
+
+
+
+ This component provides requirements for a mechanism that
+ mediates access control based on security attributes
+ associated with subjects and objects. Each object and
+ subject has a set of associated attributes, such as
+ location, time of creation, access rights (e.g., Access
+ Control Lists (ACLs)). This component allows the PP/ST
+ author to specify the attributes that will be used for the
+ access control mediation. This component allows access
+ control rules, using these attributes, to be
+ specified.
+
+ Examples of the attributes that a PP/ST author might
+ assign are presented in the following paragraphs.
+
+ An identity attribute may be associated with users,
+ subjects, or objects to be used for mediation. Examples of
+ such attributes might be the name of the program image
+ used in the creation of the subject, or a security
+ attribute assigned to the program image.
+
+ A time attribute can be used to specify that access will
+ be authorised during certain times of the day, during
+ certain days of the week, or during a certain calendar
+ year.
+
+ A location attribute could specify whether the location is
+ the location of the request for the operation, the
+ location where the operation will be carried out, or
+ both. It could be based upon internal tables to translate
+ the logical interfaces of the TSF into locations such as
+ through terminal locations, CPU locations, etc.
+
+ A grouping attribute allows a single group of users to be
+ associated with an operation for the purposes of access
+ control. If required, the refinement operation should be
+ used to specify the maximum number of definable groups,
+ the maximum membership of a group, and the maximum number
+ of groups to which a user can concurrently be
+ associated.
+
+ This component also provides requirements for the access
+ control security functions to be able to explicitly
+ authorise or deny access to an object based upon security
+ attributes. This could be used to provide privilege,
+ access rights, or access authorisations within the
+ TOE. Such privileges, rights, or authorisations could
+ apply to users, subjects (representing users or
+ applications), and objects.
+
+
+
+ This family addresses security attribute usage and
+ characteristics of policies. The component within this
+ family is meant to be used to describe the rules for the
+ function that implements the SFP as identified in . The PP/ST author may also
+ iterate this component to address multiple policies in the
+ TOE.
+
+ Security attribute
+ based access control allows the TSF to enforce access
+ based upon security attributes and named groups of
+ attributes. Furthermore, the TSF may have the ability to
+ explicitly authorise or deny access to an object based
+ upon security attributes.
+
+
+ Managing the attributes used to make explicit access or
+ denial based decisions.
+
+
+ Successful requests to perform an operation on an object
+ covered by the SFP.
+
+
+ All requests to perform an operation on an object covered by
+ the SFP.
+
+
+ The specific security attributes used in making an access
+ check.
+
+
+ The TSF shall enforce the
+
+ access control SFP
+
+ the PP/ST author should specify an access control SFP
+ name that the TSF is to enforce. The name of the access
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+ to objects based on the following:
+
+ list of subjects and objects controlled under the
+ indicated SFP, and for each, the SFP-relevant security
+ attributes, or named groups of SFP-relevant security
+ attributes
+
+ the PP/ST author should specify, for each controlled
+ subject and object, the security attributes and/or named
+ groups of security attributes that the function will use
+ in the specification of the rules. For example, such
+ attributes may be things such as the user identity,
+ subject identity, role, time of day, location, ACLs, or
+ any other attribute specified by the PP/ST author. Named
+ groups of security attributes can be specified to
+ provide a convenient means to refer to multiple security
+ attributes. Named groups could provide a useful way to
+ associate ``roles'' defined in , and
+ all of their relevant attributes, with subjects. In
+ other words, each role could relate to a named group of
+ attributes..
+
+
+ The TSF shall enforce the following rules to determine if an
+ operation among controlled subjects and controlled objects
+ is allowed:
+
+
+ rules governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects
+
+
+
+ the PP/ST author should specify the SFP rules
+ governing access among controlled subjects and
+ controlled objects using controlled operations on
+ controlled objects. These rules specify when access
+ is granted or denied. It can specify general access
+ control functions (e.g. typical permission bits) or
+ granular access control functions (e.g. ACLs).
+
+ .
+
+
+ The TSF shall explicitly authorise access of subjects to
+ objects based on the following additional rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise access of subjects to objects
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise access
+ of subjects to objects that will be used to explicitly
+ authorise access. These rules are in addition to those
+ specified in . They are
+ included in as they are
+ intended to contain exceptions to the rules in . An example of rules to explicitly
+ authorise access is based on a privilege vector
+ associated with a subject that always grants access to
+ objects covered by the access control SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny access of subjects to objects based on the
+ following additional rules:
+ rules, based on security attributes, that
+ explicitly deny access of subjects to objects the PP/ST author should specify the rules,
+ based on security attributes, that explicitly deny access of subjects
+ to objects. These rules are in addition to those specified in
+
+ . They are included in
+
+ as they are intended to contain exceptions to the rules in
+
+ . An example of rules to explicitly deny access is based on a privilege
+ vector associated with a subject
+ that always denies access to objects covered by the access control SFP
+ that has been specified. If such a capability is not desired, then the
+ PP/ST author should specify ``none''..
+
+
+
+
+
+
+
+ Data authentication permits an entity to accept
+ responsibility for the authenticity of information (e.g., by
+ digitally signing it). This family provides a method of
+ providing a guarantee of the validity of a specific unit of
+ data that can be subsequently used to verify that the
+ information content has not been forged or fraudulently
+ modified. In contrast to , this family is
+ intended to be applied to "static" data rather
+ than data that is being transferred.
+
+
+
+ This family describes specific functions that can be used to
+ authenticate ``static'' data.
+
+ Components in this family are to be used when there is a
+ requirement for ``static'' data
+ authentication, i.e. where data is to be signed but not
+ transmitted. (Note that the family
+ provides for non-repudiation of origin of information
+ received during a data exchange.)
+
+
+
+
+
+ This component may be satisfied by one-way hash functions
+ (cryptographic checksum, fingerprint, message digest), to
+ generate a hash value for a definitive document that may
+ be used as verification of the validity or authenticity of
+ its information content.
+
+
+
+ , requires that the TSF is capable
+ of generating a guarantee of authenticity of the
+ information content of objects (e.g. documents).
+
+
+ The assignment or modification of the objects for which data
+ authentication may apply could be configurable.
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element. The list of subjects could be
+ very specific, if the subjects are known, or it could
+ be more generic and refer to a
+ ``type'' of subject such
+ as an identified role.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information.
+
+
+
+
+
+
+
+
+
+
+ This component additionally requires the ability to verify
+ the identity of the user that provided the guarantee of
+ authenticity (e.g. a trusted third party).
+
+
+
+ additionally requires that the TSF
+ is capable of establishing the identity of the subject who
+ provided the guarantee of authenticity.
+
+
+
+ Successful generation of validity evidence.
+
+
+ Unsuccessful generation of validity evidence.
+
+
+ The identity of the subject that requested the evidence.
+
+
+ The identity of the subject that generated the evidence.
+
+
+ The TSF shall provide a capability to generate evidence that
+ can be used as a guarantee of the validity of
+
+
+ list of objects or information types
+
+
+
+ the PP/ST author should specify the list of objects or
+ information types for which the TSF shall be capable
+ of generating data authentication evidence.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of subjects
+
+
+
+ the PP/ST author should specify the list of subjects
+ that will have the ability to verify data
+ authentication evidence for the objects identified in
+ the previous element as well as the identity of the
+ user that created the data authentication evidence.
+
+
+ with the ability to verify evidence of the validity of the
+ indicated information and the identity of the user that
+ generated the evidence.
+
+
+
+
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes and protection
+ either can be explicitly preserved or can be ignored once it
+ has been exported. It is concerned with limitations on
+ export and with the association of security attributes with
+ the exported user data.
+
+
+
+ This family defines functions for TSF-mediated exporting of user data from
+ the TOE such that its security attributes either can be
+ explicitly preserved or can be ignored once it has been
+ exported. Consistency of these security attributes are
+ addressed by .
+
+ is concerned with limitations on export
+ and association of security attributes with the exported
+ user data.
+
+ This family, and the corresponding Import family , address how the TOE deals with user data
+ transferred into and outside its control. In principle this
+ family is concerned with the TSF-mediated exporting of user data and its
+ related security attributes.
+
+ A variety of activities might be involved here:
+
+
+ exporting of user data without any security attributes;
+
+
+ exporting user data including security attributes where
+ the two are associated with one another and the security
+ attributes unambiguously represent the exported user
+ data.
+
+
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the TSF-mediated exporting of user data
+ without the export of its security attributes.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs when exporting user data outside the
+ TSF. User data that is exported by this function is
+ exported without its associated security attributes.
+
+
+ Successful export of information.
+
+
+ All attempts to export information.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data without the user
+ data's associated security attributes
+
+
+
+
+
+
+
+
+
+
+
+
+ The user data is exported together with its security
+ attributes. The security attributes are unambiguously
+ associated with the user data. There are several ways of
+ achieving this association. One way that this can be
+ achieved is by physically collocating the user data and
+ the security attributes (e.g. the same floppy), or by
+ using cryptographic techniques such as secure signatures
+ to associate the attributes and the user data. could be used to assure that the attributes
+ are correctly received at the other trusted IT product
+ while can be used to make sure that
+ those attributes are properly interpreted. Furthermore,
+ could be used to make sure that the
+ export is being initiated by the proper user.
+
+
+
+ , requires that the TSF enforce the
+ appropriate SFPs using a function that accurately and
+ unambiguously associates security attributes with the user
+ data that is exported.
+
+
+ The additional exportation control rules could be
+ configurable by a user in a defined role.
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when exporting user data. The user
+ data that this function exports is scoped by the
+ assignment of these SFPs.
+
+
+ when exporting user data, controlled under the SFP(s),
+ outside of the TOE.
+
+
+ The TSF shall export the user data with the user
+ data's associated security attributes.
+
+
+ The TSF shall ensure that the security attributes, when
+ exported outside the TOE, are unambiguously associated with
+ the exported user data.
+
+
+ The TSF shall enforce the following rules when user data is
+ exported from the TOE:
+
+
+ additional exportation control rules
+
+
+
+ the PP/ST author should specify any additional
+ exportation control rules or
+ ``none'' if there are no
+ additional exportation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family identifies the information flow control SFPs (by
+ name) and defines the scope of control for each named
+ information flow control SFP. This scope of control is
+ characterised by three sets: the subjects under control of the
+ policy, the information under control of the policy, and
+ operations which cause controlled information to flow to and
+ from controlled subjects covered by the policy. The criteria
+ allows multiple policies to exist, each having a unique name.
+ This is accomplished by iterating components from this family
+ once for each named information flow control policy. The rules
+ that define the functionality of an information flow control SFP
+ will be defined by other families such as and . The names
+ of the information flow control SFPs identified here in are meant to be used throughout the
+ remainder of the functional components that have an operation
+ that calls for an assignment or selection of an ``information
+ flow control SFP.''
+
+ The TSF mechanism controls the flow of information in
+ accordance with the information flow control SFP. Operations
+ that would change the security attributes of information are
+ not generally permitted as this would be in violation of an
+ information flow control SFP. However, such operations may
+ be permitted as exceptions to the information flow control
+ SFP if explicitly specified.
+
+
+
+ This family covers the identification of information flow
+ control SFPs; and, for each, specifies the scope of control
+ of the SFP.
+
+ The components in this family are capable of identifying the
+ information flow control SFPs to be enforced by the traditional
+ Mandatory Access Control mechanisms that would be found in a
+ TOE. However, they go beyond just the traditional MAC mechanisms
+ and can be used to identify and describe non-interference
+ policies and state-transitions. It further defines the subjects
+ under control of the policy, the information under control of
+ the policy, and operations which cause controlled information to
+ flow to and from controlled subjects for each information flow
+ control SFP in the TOE. The information flow control SFP will be
+ defined by other families such as and . The
+ information flow control SFPs named here in are meant to be used throughout the remainder of
+ the functional components that have an operation that calls for
+ an assignment or selection of an ``information flow control
+ SFP.''
+
+ These components are quite flexible. They allow the domain
+ of flow control to be specified and there is no requirement
+ that the mechanism be based upon labels. The different
+ elements of the information flow control components also
+ permit different degrees of exception to the policy.
+
+ Each SFP covers a set of triplets: subject, information, and
+ operations that cause information to flow to and from
+ subjects. Some information flow control policies may be at a
+ very low level of detail and explicitly describe subjects in
+ terms of processes within an operating system. Other
+ information flow control policies may be at a high level and
+ describe subjects in the generic sense of users or
+ input/output channels. If the information flow control
+ policy is at too high a level of detail, it may not clearly
+ define the desired IT security functions. In such cases, it
+ is more appropriate to include such descriptions of
+ information flow control policies as objectives. Then the
+ desired IT security functions can be specified as supportive
+ of those objectives.
+
+ In the second component (), each
+ information flow control SFP will cover all possible
+ operations that cause information covered by that SFP to
+ flow to and from subjects covered by that SFP. Furthermore,
+ all information flows will need to be covered by a
+ SFP. Therefore for each action that causes information to
+ flow, there will be a set of rules that define whether the
+ action is allowed. If there are multiple SFPs that are
+ applicable for a given information flow, all involved SFPs
+ must allow this flow before it is permitted to take place.
+
+ An information flow control SFP covers a well-defined set of
+ operations. The SFPs coverage may be
+ ``complete'' with respect to some
+ information flows, or it may address only some of the
+ operations that affect the information flow.
+
+ An access control SFP controls access to the objects that
+ contain information. An information flow control SFP
+ controls access to the information, independent of its
+ container. The attributes of the information, which may be
+ associated with the attributes of the container (or may not,
+ as in the case of a multi-level database) stay with the
+ information as it flows. The accessor does not have the
+ ability, in the absence of an explicit authorisation, to
+ change the attributes of the information.
+
+ Information flows and operations can be expressed at
+ multiple levels. In the case of a ST, the information flows
+ and operations might be specified at a system-specific
+ level: TCP/IP packets flowing through a firewall based upon
+ known IP addresses. For a PP, the information flows and
+ operations might be expressed as types: email, data
+ repositories, observe accesses, etc.
+
+ The components in this family can be applied multiple times
+ in a PP/ST to different subsets of operations and
+ objects. This will accommodate TOEs that contain multiple
+ policies, each addressing a particular set of objects,
+ subjects, and operations.
+
+
+
+
+
+
+
+
+ This component requires that an information flow control
+ policy apply to a subset of the possible operations in the
+ TOE.
+
+
+
+ , requires that each identified
+ information flow control SFPs be in place for a subset of
+ the possible operations on a subset of information flows
+ in the TOE.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects, information, and operations that cause
+ controlled information to flow to and from controlled
+ subjects covered by the SFP
+
+
+
+ the PP/ST author should specify the list of subjects,
+ information, and operations which cause controlled
+ information to flow to and from controlled subjects
+ covered by the SFP. As mentioned above, the list of
+ subjects could be at various levels of detail
+ depending on the needs of the PP/ST author. It could
+ specify users, machines, or processes for
+ example. Information could refer to data such as email
+ or network protocols, or more specific objects similar
+ to those specified under an access control policy. If
+ the information that is specified is contained within
+ an object that is subject to an access control policy,
+ then both the access control policy and information
+ flow control policy must be enforced before the
+ specified information could flow to or from the
+ object.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component requires that all possible operations that
+ cause information to flow to and from subjects included in
+ the SFP, are covered by an information flow control SFP.
+
+ The PP/ST author must demonstrate that each combination of
+ information flows and subjects is covered by an
+ information flow control SFP.
+
+
+
+ , requires that each identified
+ information flow control SFP cover all operations on
+ subjects and information covered by that SFP. It further
+ requires that all information flows and operations controlled
+ by the TSF are covered by at least one identified information
+ flow control SFP.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify a uniquely named
+ information flow control SFP to be enforced by the
+ TSF.
+
+
+ on
+
+
+ list of subjects and information
+
+
+
+ the PP/ST author should specify the list of subjects
+ and information that will be covered by the SFP. All
+ operations that cause that information to flow to and
+ from subjects will be covered by the SFP. As mentioned
+ above, the list of subjects could be at various levels
+ of detail depending on the needs of the PP/ST
+ author. It could specify users, machines, or processes
+ for example. Information could refer to data such as
+ email or network protocols, or more specific objects
+ similar to those specified under an access control
+ policy. If the information that is specified is
+ contained within an object that is subject to an
+ access control policy, then both the access control
+ policy and information flow control policy must be
+ enforced before the specified information could flow
+ to or from the object.
+
+
+ and all operations that cause that information to flow to
+ and from subjects covered by the SFP.
+
+
+ The TSF shall ensure that all operations that cause any
+ information in the TOE to flow to and from any subject in
+ the TOE are covered by an information flow control SFP.
+
+
+
+
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policy. It consists of two kinds of
+ requirements: one addressing the common information flow
+ function issues, and a second addressing illicit information
+ flows (i.e. covert channels). This division arises because
+ the issues concerning illicit information flows are, in some
+ sense, orthogonal to the rest of an information flow control
+ SFP. By their nature they circumvent the information flow
+ control SFP resulting in a violation of the policy. As such,
+ they require special functions to either limit or prevent
+ their occurrence.
+
+
+
+ This family describes the rules for the specific functions
+ that can implement the information flow control SFPs named
+ in , which also specifies the scope of
+ control of the policies. It consists of two
+ ``trees:'' one addressing the common
+ information flow control function issues, and a second
+ addressing illicit information flows (i.e. covert channels)
+ with respect to one or more information flow control
+ SFPs. This division arises because the issues concerning
+ illicit information flows are, in some sense, orthogonal to
+ the rest of an SFP. Illicit information flows are flows in
+ violation of policy; thus they are not a policy issue.
+
+ In order to implement strong protection against disclosure
+ or modification in the face of untrusted software, controls
+ on information flow are required. Access controls alone are
+ not sufficient because they only control access to
+ containers, allowing the information they contain to flow,
+ without controls, throughout a system.
+
+ In this family, the phrase ``types of illicit
+ information flows'' is used. This phrase may be
+ used to refer to the categorisation of flows as
+ ``Storage Channels'' or
+ ``Timing Channels'', or it can refer to
+ improved categorisations reflective of the needs of a PP/ST
+ author.
+
+ The flexibility of these components allows the definition of
+ a privilege policy within and to allow the controlled bypass of all or
+ part of a particular SFP. If there is a need for a
+ predefined approach to SFP bypass, the PP/ST author should
+ consider incorporating a privilege policy.
+
+
+
+
+
+
+
+
+
+ This component requires security attributes on
+ information, and on subjects that cause that information
+ to flow and subjects that act as recipients of that
+ information. The attributes of the containers of the
+ information should also be considered if it is desired
+ that they should play a part in information flow control
+ decisions or if they are covered by an access control
+ policy. This component specifies the key rules that are
+ enforced, and describes how security attributes are
+ derived.
+
+ This component does not specify the details of how a
+ security attribute is assigned (i.e. user versus
+ process). Flexibility in policy is provided by having
+ assignments that allow specification of additional policy
+ and function requirements, as necessary.
+
+ This component also provides requirements for the
+ information flow control functions to be able to
+ explicitly authorise and deny an information flow based
+ upon security attributes. This could be used to implement
+ a privilege policy that covers exceptions to the basic
+ policy defined in this component.
+
+
+
+ , requires security attributes on
+ information, and on subjects that cause that information
+ to flow and on subjects that act as recipients of that
+ information. It specifies the rules that must be enforced
+ by the function, and describes how security attributes are
+ derived by the function.
+
+
+ Managing the attributes used to make explicit access based
+ decisions.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+ the PP/ST author should specify any additional information
+ flow control SFP rules that the TSF is to enforce. This
+ includes all rules of the SFP that are either not based on the
+ security attributes of the information and the subject or
+ rules that automatically modify the security attributes of
+ information or subjects as a result of an access operation.
+ An example for the first case is a rule of the SFP controlling
+ a threshold value for specific types of information. This
+ would for example be the case when the information flow SFP
+ contains rules on access to statistical data where a subject
+ is only allowed to access this type of information up to a
+ specific number of accesses. An example for the second case
+ would be a rule stating under which conditions and how the
+ security attributes of a subject or object change as the
+ result of an access operation. Some information flow policies
+ for example may limit the number of access operations to
+ information with specific security attributes. If there are
+ no additional rules then the PP/ST author should specify
+ ``none''.
+ .
+
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on security
+ attributes, that explicitly deny information flows. These rules
+ are in addition to those specified in the preceding
+ elements. They are included in as they
+ are intended to contain exceptions to the rules in the preceding
+ elements. An example of rules to explicitly deny information
+ flows is based on a privilege vector associated with a subject
+ that always denies the subject the ability to cause an
+ information flow for information that is covered by the SFP that
+ has been specified. If such a capability is not desired, then
+ the PP/ST author should specify ``none''.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+ This component requires that the named information flow control
+ SFP uses hierarchical security attributes that
+ form a lattice.
+
+ It is important to note that the hierarchical relationship
+ requirements identified in need
+ only apply to the information flow control security
+ attributes for the information flow control SFPs that have
+ been identified in . This
+ component is not meant to apply to other SFPs such as
+ access control SFPs.
+ phrases the requirements for the set of
+ security attributes to form a lattice. A number of information
+ flow policies defined in the literature and implemented in IT
+ products are based on a set of security attributes that form a
+ lattice. is specifically included to
+ address this type of information flow policies.
+
+ If it is the case that multiple information flow control
+ SFPs are to be specified, and that each of these SFPs will
+ have their own security attributes that are not related to
+ one another, then the PP/ST author should iterate this
+ component once for each of those SFPs. Otherwise a
+ conflict might arise with the sub-items of since the required relationships will
+ not exist.
+
+
+ expands on the requirements
+ of by requiring that all
+ information flow control SFPs in the set of SFRs use
+ hierarchical security attributes that form a lattice (as defined
+ in mathematics). is derived from the
+ mathematical properties of a lattice. A lattice consists of a
+ set of elements with an ordering relationship with the property
+ defined in the first bullet, a least upper bound which is the
+ unique element in the set that is greater or equal (in the
+ ordering relationship) than any other element of the lattice,
+ and a greatest lower bound, which is the unique element in the set
+ that is smaller or equal than any other element of the lattice.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ based on the following types of subject and
+ information security attributes:
+
+ list of subjects and information controlled under the
+ indicated SFP, and for each, the security attributes
+
+ the PP/ST author should specify, for each type of
+ controlled subject and information, the security
+ attributes that are relevant to the specification of the
+ SFP rules. For example, such security attributes may be
+ things such the subject identifier, subject sensitivity
+ label, subject clearance label, information sensitivity
+ label, etc. The types of security attributes should be
+ sufficient to support the environmental needs..
+
+
+ The TSF shall permit an information flow between a
+ controlled subject and controlled information via a
+ controlled operation if the following rules, based on the
+ ordering relationships between security attributes hold:
+
+
+ for each operation, the security attribute-based
+ relationship that must hold between subject and
+ information security attributes
+
+
+
+ the PP/ST author should specify for each operation,
+ the security attribute-based relationship that must
+ hold between subject and information security
+ attributes that the TSF will enforce. These
+ relationships should be based upon the ordering
+ relationships between the security attributes.
+
+ .
+
+
+ The TSF shall enforce the
+
+
+ additional information flow control SFP rules
+
+
+ the PP/ST author should specify any additional information
+ flow control SFP rules that the TSF is to enforce. This
+ includes all rules of the SFP that are either not based on the
+ security attributes of the information and the subject or
+ rules that automatically modify the security attributes of
+ information or subjects as a result of an access operation.
+ An example for the first case is a rule of the SFP controlling
+ a threshold value for specific types of information. This
+ would for example be the case when the information flow SFP
+ contains rules on access to statistical data where a subject
+ is only allowed to access this type of information up to a
+ specific number of accesses. An example for the second case
+ would be a rule stating under which conditions and how the
+ security attributes of a subject or object change as the
+ result of an access operation. Some information flow policies
+ for example may limit the number of access operations to
+ information with specific security attributes. If there are
+ no additional rules then the PP/ST author should specify
+ ``none''.
+ .
+
+
+
+ The TSF shall explicitly authorise an information flow based
+ on the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ authorise information flows
+
+
+
+ the PP/ST author should specify the rules, based on
+ security attributes, that explicitly authorise
+ information flows. These rules are in addition to
+ those specified in the preceding elements. They are
+ included in as they are
+ intended to contain exceptions to the rules in the
+ preceding elements. An example of rules to explicitly
+ authorise information flows is based on a privilege
+ vector associated with a subject that always grants
+ the subject the ability to cause an information flow
+ for information that is covered by the SFP that has
+ been specified. If such a capability is not desired,
+ then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall explicitly deny an information flow based on
+ the following rules:
+
+
+ rules, based on security attributes, that explicitly
+ deny information flows
+
+
+
+ the PP/ST author should specify the rules, based on security
+ attributes, that explicitly deny information flows. These rules
+ are in addition to those specified in the preceding
+ elements. They are included in as they are intended to contain exceptions to the
+ rules in the preceding elements. An example of rules to
+ explicitly deny information flows is based on a privilege vector
+ associated with a subject that always denies the subject the
+ ability to cause an information flow for information that is
+ covered by the SFP that has been specified. If such a capability
+ is not desired, then the PP/ST author should specify
+ ``none''.
+
+ .
+
+
+ The TSF shall enforce the following relationships for any
+ two valid information flow control security attributes:
+
+
+ There exists an ordering function that, given two valid
+ security attributes, determines if the security
+ attributes are equal, if one security attribute is
+ greater than the other, or if the security attributes
+ are incomparable; and
+
+
+ There exists a ``least upper bound''
+ in the set of security attributes, such that, given any
+ two valid security attributes, there is a valid security
+ attribute that is greater than or equal to the two valid
+ security attributes; and
+
+
+ There exists a ``greatest lower
+ bound'' in the set of security attributes,
+ such that, given any two valid security attributes,
+ there is a valid security attribute that is not greater
+ than the two valid security attributes.
+
+
+
+
+
+
+
+
+
+
+
+ This component should be used when at least one of the
+ SFPs that requires control of illicit information flows
+ does not require elimination of flows.
+
+ For the specified illicit information flows, certain
+ maximum capacities should be provided. In addition a PP/ST
+ author has the ability to specify whether the illicit
+ information flows must be audited.
+
+
+
+ , requires the SFP to cover illicit
+ information flows, but not necessarily eliminate them.
+
+
+ Decisions to permit requested information flows.
+
+
+ All decisions on requests for information flow.
+
+
+ The use of identified illicit information flow channels.
+
+
+ The specific security attributes used in making an
+ information flow enforcement decision.
+
+
+ Some specific subsets of the information that has flowed
+ based upon policy goals (e.g. auditing of downgraded
+ material).
+
+
+ The use of identified illicit information flow channels with
+ estimated maximum capacity exceeding a specified value.
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when all the SFPs that
+ requires control of illicit information flows require
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+ , requires the SFP to cover the
+ elimination of some (but not necessarily all) illicit
+ information flows.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to limit the capacity of
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows which are subject to a maximum
+ capacity limitation.
+
+
+ to a
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ permitted for any identified illicit information
+ flows.
+
+ .
+
+
+ The TSF shall prevent
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows to be eliminated. This list may not
+ be empty as this component requires that some illicit
+ information flows are to be eliminated.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component should be used when the SFPs that require
+ control of illicit information flows require elimination
+ of all illicit information flows. However, the PP/ST
+ author should carefully consider the potential impact that
+ eliminating all illicit information flows might have on
+ the normal functional operation of the TOE. Many practical
+ applications have shown that there is an indirect
+ relationship between illicit information flows and normal
+ functionality within a TOE and eliminating all illicit
+ information flows may result in less than desired
+ functionality.
+
+
+
+ , requires SFP to cover the
+ elimination of all illicit information flows.
+
+
+
+
+
+ The TSF shall ensure that no illicit information flows exist
+ to circumvent
+
+
+ name of information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFP for which illicit information flows are to
+ be eliminated. The name of the information flow
+ control SFP, and the scope of control for that policy
+ are defined in components from .
+
+ .
+
+
+
+
+
+
+
+
+
+ This component should be used when it is desired that the
+ TSF provide the ability to monitor the use of illicit
+ information flows that exceed a specified capacity. If it
+ is desired that such flows be audited, then this component
+ could serve as the source of audit events to be used by
+ components from the family.
+
+
+
+ , requires the SFP to monitor
+ illicit information flows for specified and maximum
+ capacities.
+
+
+ The enabling or disabling of the monitoring function.
+
+
+ Modification of the maximum capacity at which the monitoring
+ occurs.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ information flow control SFP
+
+
+
+ the PP/ST author should specify the information flow
+ control SFPs enforced by the TSF. The name of the
+ information flow control SFP, and the scope of control
+ for that policy are defined in components from
+ .
+
+
+ to monitor
+
+
+ types of illicit information flows
+
+
+
+ the PP/ST author should specify the types of illicit
+ information flows that will be monitored for exceeding
+ a maximum capacity.
+
+
+ when it exceeds the
+
+
+ maximum capacity
+
+
+
+ the PP/ST author should specify the maximum capacity
+ above which illicit information flows will be
+ monitored by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family defines the mechanisms for TSF-mediated importing of user
+ data into the TOE such that it has appropriate security
+ attributes and is appropriately protected. It is concerned
+ with limitations on importation, determination of desired
+ security attributes, and interpretation of security
+ attributes associated with the user data.
+
+
+
+ This family defines mechanisms for TSF-mediated importing of user data from
+ outside the TOE into the TOE such that the user data
+ security attributes can be preserved. Consistency of these
+ security attributes are addressed by .
+
+ is concerned with limitations on
+ import, user specification of security attributes, and
+ association of security attributes with the user data.
+
+ This family, and the corresponding export family , address how the TOE deals with user data
+ outside its control. This family is concerned with assigning
+ and abstraction of the user data security attributes.
+
+ A variety of activities might be involved here:
+
+
+ importing user data from an unformatted medium
+ (e.g. floppy disk, tape, scanner, video or audit
+ signal), without including any security attributes, and
+ physically marking the medium to indicate its contents;
+
+
+ importing user data, including security attributes, from
+ a medium and verifying that the object security
+ attributes are appropriate;
+
+
+ importing user data, including security attributes, from
+ a medium using a cryptographic sealing technique to
+ protect the association of user data and security
+ attributes.
+
+
+
+ This family is not concerned with the determination of
+ whether the user data may be imported. It is concerned with
+ the values of the security attributes to associate with the
+ imported user data.
+
+ There are two possibilities for the import of user data:
+ either the user data is unambiguously associated with
+ reliable object security attributes (values and meaning of
+ the security attributes is not modified), or no reliable
+ security attributes (or no security attributes at all) are
+ available from the import source. This family addresses both
+ cases.
+
+ If there are reliable security attributes available, they
+ may have been associated with the user data by physical
+ means (the security attributes are on the same media), or by
+ logical means (the security attributes are distributed
+ differently, but include unique object identification,
+ e.g. cryptographic checksum).
+
+ This family is concerned with TSF-mediated importing of user data and
+ maintaining the association of security attributes as
+ required by the SFP. Other families are concerned with other
+ import aspects such as consistency, trusted channels, and
+ integrity that are beyond the scope of this
+ family. Furthermore, is only concerned
+ with the interface to the import medium. is responsible for the other end point of the
+ medium (the source).
+
+ Some of the well known import requirements are:
+
+
+ importing of user data without any security attributes;
+
+
+ importing of user data including security attributes
+ where the two are associated with one another and the
+ security attributes unambiguously represent the
+ information being imported.
+
+
+
+ These import requirements may be handled by the TSF with or
+ without human intervention, depending on the IT limitations
+ and the organisational security policy. For example, if user
+ data is received on a ``confidential''
+ channel, the security attributes of the objects will be set
+ to ``confidential''.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that does not have reliable (or any) security attributes
+ associated with it. This function requires that the
+ security attributes for the imported user data be
+ initialised within the TSF. It could also be the case that
+ the PP/ST author specifies the rules for import. It may be
+ appropriate, in some environments, to require that these
+ attributes be supplied via a trusted path or a trusted
+ channel mechanism.
+
+
+
+ , requires that the security
+ attributes correctly represent the user data and are
+ supplied separately from the object.
+
+
+ The modification of the additional control rules used for
+ import.
+
+
+ Successful import of user data, including any security
+ attributes.
+
+
+ All attempts to import user data, including any security
+ attributes.
+
+
+ The specification of security attributes for imported user
+ data supplied by an authorised user.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s) and/or information flow control SFP(s)
+
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be
+ enforced when importing user data from outside of the
+ TOE. The user data that this function imports is
+ scoped by the assignment of these SFPs.
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall ignore any security attributes associated with
+ the user data when imported from outside the TOE.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used to specify the import of user data
+ that has reliable security attributes associated with
+ it. This function relies upon the security attributes that
+ are accurately and unambiguously associated with the
+ objects on the import medium. Once imported, those objects
+ will have those same attributes. This requires to ensure the consistency of the data. It
+ could also be the case that the PP/ST author specifies the
+ rules for import.
+
+
+
+ , requires that security attributes
+ correctly represent the user data and are accurately and
+ unambiguously associated with the user data imported from
+ outside the TOE.
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when importing user data from outside
+ of the TOE. The user data that this function imports
+ is scoped by the assignment of these SFPs.
+
+
+ when importing user data, controlled under the SFP, from
+ outside of the TOE.
+
+
+ The TSF shall use the security attributes associated with
+ the imported user data.
+
+
+ The TSF shall ensure that the protocol used provides for the
+ unambiguous association between the security attributes and
+ the user data received.
+
+
+ The TSF shall ensure that interpretation of the security
+ attributes of the imported user data is as intended by the
+ source of the user data.
+
+
+ The TSF shall enforce the following rules when importing
+ user data controlled under the SFP from outside the TOE:
+
+
+ additional importation control rules
+
+
+
+ the PP/ST author should specify any additional
+ importation control rules or
+ ``none'' if there are no
+ additional importation control rules. These rules will
+ be enforced by the TSF in addition to the access
+ control SFPs and/or information flow control SFPs
+ selected in .
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between separated parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and families,
+ which provide protection for user data when it is
+ transferred between distinct TSFs across an external
+ channel, and and ,
+ which address TSF-mediated transfer of data to or from outside the
+ TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data when it is transferred between parts of a TOE
+ across an internal channel. This may be contrasted with the
+ and family, which
+ provide protection for user data when it is transferred
+ between distinct TSFs across an external channel, and and , which address
+ TSF-mediated transfer of data to or from outside the TOE.
+
+ The requirements in this family allow a PP/ST author to
+ specify the desired security for user data while in transit
+ within the TOE. This security could be protection against
+ disclosure, modification, or loss of availability.
+
+ The determination of the degree of physical separation above
+ which this family should apply depends on the intended
+ environment of use. In a hostile environment, there may be
+ risks arising from transfers between parts of the TOE
+ separated by only a system bus. In more benign environments,
+ the transfers may be across more traditional network media.
+
+ If there are multiple SFPs (access control and/or
+ information flow control) then it may be appropriate to
+ iterate these components once for each named SFP.
+
+
+
+
+
+
+
+
+
+
+
+ , requires that user data be
+ protected when transmitted between parts of the TOE.
+
+
+ If the TSF provides multiple methods to protect user data
+ during transmission between physically separated parts of
+ the TOE, the TSF could provide a pre-defined role with the
+ ability to select the method that will be used.
+
+
+ Successful transfers of user data, including identification
+ of the protection method used.
+
+
+ All attempts to transfer user data, including the protection
+ method used and any errors that occurred.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component could, for example, be used to provide
+ different forms of protection to information with
+ different clearance levels.
+
+ One of the ways to achieve separation of data when it is
+ transmitted is through the use of separate logical or
+ physical channels.
+
+
+
+ , requires separation of data based
+ on the value of SFP-relevant attributes in addition to the
+ first component.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred.
+
+
+ to prevent the
+
+
+ disclosure
+
+
+ modification
+
+
+ loss of use
+
+
+
+ the PP/ST author should specify the types of
+ transmission errors that the TSF should prevent
+ occurring for user data while in transport. The options
+ are disclosure, modification, loss of use.
+
+
+ of user data when it is transmitted between
+ physically-separated parts of the TOE.
+
+
+ The TSF shall separate data controlled by the SFP(s) when
+ transmitted between physically-separated parts of the TOE,
+ based on the values of the following:
+
+
+ security attributes that require separation
+
+
+
+ the PP/ST author should specify the security
+ attributes, the values of which the TSF will use to
+ determine when to separate data that is being
+ transmitted between physically-separated parts of the
+ TOE. An example is that user data associated with the
+ identity of one owner is transmitted separately from
+ the user data associated with the identify of a
+ different owner. In this case, the value of the
+ identity of the owner of the data is what is used to
+ determine when to separate the data for transmission.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with either or . It ensures
+ that the TSF checks received user data (and their
+ attributes) for integrity. or will provide the data in a manner such
+ that it is protected from modification (so that can detect any modifications).
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ , requires that the TSF monitor user
+ data transmitted between parts of the TOE for identified
+ integrity errors.
+
+
+ The specification of the actions to be taken upon detection
+ of an integrity error could be configurable.
+
+
+ Successful transfers of user data, including identification
+ of the integrity protection method used.
+
+
+ All attempts to transfer user data, including the integrity
+ protection method used and any errors that occurred.
+
+
+ Unauthorised attempts to change the integrity protection
+ method.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component is used in combination with . It ensures that the TSF checks received
+ user data, that has been transmitted by separate channels
+ (based on values of specified security attributes), for
+ integrity. It allows the PP/ST author to specify actions
+ to be taken upon detection of an integrity error.
+
+ For example, this component could be used to provide
+ different integrity error detection and action for
+ information at different integrity levels.
+
+ The PP/ST author has to specify the types of errors that
+ must be detected. The PP/ST author should consider:
+ modification of data, substitution of data, unrecoverable
+ ordering change of data, replay of data, incomplete data,
+ in addition to other integrity errors.
+
+ The PP/ST author should specify the attributes (and
+ associated transmission channels) that necessitate
+ integrity error monitoring
+
+ The PP/ST author must specify the actions that the TSF
+ should take on detection of a failure. For example: ignore
+ the user data, request the data again, inform the
+ authorised administrator, reroute traffic for other lines.
+
+
+
+ expands on the third component by
+ allowing the form of integrity monitoring to differ by
+ SFP-relevant attribute.
+
+
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow
+ control SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) covering
+ the information being transferred and monitored for
+ integrity errors.
+
+
+ to monitor user data transmitted between
+ physically-separated parts of the TOE for the following
+ errors:
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the type of possible
+ integrity errors to be monitored during transmission
+ of the user data.
+
+ , based on the following attributes:
+
+
+ security attributes that require separate transmission
+ channels
+
+
+
+ the PP/ST author should specify a list of security
+ attributes that require separate transmission
+ channels. This list is used to determine which user
+ data to monitor for integrity errors., based on its
+ security attributes and its transmission channel. This
+ element is directly related to .
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ specify the action to be taken upon integrity
+ error
+
+
+
+ the PP/ST author should specify the action to be taken
+ by the TSF when an integrity error is encountered. An
+ example might be that the TSF should request the
+ resubmission of the user data. The SFP(s) specified in
+ will be enforced as the
+ actions are taken by the TSF.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the need to ensure that any data contained
+ in a resource is not available when the resource is de-allocated
+ from one object and reallocated to a different object. This
+ family requires protection for any data contained in a resource
+ that has been logically deleted or released, but may still be
+ present within the TSF-controlled resource which in turn may be
+ re-allocated to another object.
+
+
+
+ Residual information protection ensures that TSF-controlled
+ resources when de-allocated from an object and before they are
+ reallocated to another object are treated by the TSF in a way
+ that it is not possible to reconstruct all or part of the data
+ contained in the resource before it was de-allocated.
+
+ A TOE usually has a number of functions that potentially
+ de-allocate resources from an object and potentially re-allocate
+ those resources to objects. Some, but not all of those resources
+ may have been used to store critical data from the previous use
+ of the resource and for those resources FDP_RIP requires that
+ they are prepared for reuse. Object reuse applies to explicit
+ requests of a subject or user to release resources as well as
+ implicit actions of the TSF that result in the de-allocation and
+ subsequent re-allocation of resources to different
+ objects. Examples of explicit requests are the deletion or
+ truncation of a file or the release of an area of main
+ memory. Examples of implicit actions of the TSF are the
+ de-allocation and re-allocation of cache regions.
+ The requirement for object reuse is related to the content of
+ the resource belonging to an object, not all information about
+ the resource or object that may be stored elsewhere in the
+ TSF. As an example to satisfy the FDP_RIP requirement for files
+ as objects requires that all sectors that make up the file need
+ to be prepared for re-use.
+
+ It also applies to resources that are serially reused by
+ different subjects within the system. For example, most
+ operating systems typically rely upon hardware registers
+ (resources) to support processes within the system. As
+ processes are swapped from a ``run'' state to a ``sleep''
+ state (and vice versa), these registers are serially reused
+ by different subjects. While this ``swapping'' action may
+ not be considered an allocation or deallocation of a
+ resource, could apply to
+ such events and resources.
+
+ typically controls access
+ to information that is not part of any currently defined or
+ accessible object; however, in certain cases this may not be
+ true. For example, object ``A'' is a file and object ``B''
+ is the disk upon which that file resides. If object ``A'' is
+ deleted, the information from object ``A'' is under the
+ control of even though it
+ is still part of object ``B''.
+
+ It is important to note that applies only to on-line objects and not
+ off-line objects such as those backed-up on tapes. For
+ example, if a file is deleted in the TOE, can be instantiated to require that no
+ residual information exists upon deallocation; however, the
+ TSF cannot extend this enforcement to that same file that
+ exists on the off-line back-up. Therefore that same file is
+ still available. If this is a concern, then the PP/ST author
+ should make sure that the proper environmental objectives
+ are in place to support operational user guidance to address
+ off-line objects.
+
+ and can conflict when is instantiated to require that residual
+ information be cleared at the time the application releases
+ the object to the TSF (i.e. upon deallocation). Therefore,
+ the selection of
+ ``deallocation'' should not be used with since there would be no information to roll
+ back. The other selection, ``unavailability upon
+ allocation'', may be used with , but there is the risk that the resource
+ which held the information has been allocated to a new
+ object before the roll back took place. If that were to
+ occur, then the roll back would not be possible.
+
+ There are no audit requirements in because this is not a user-invokable
+ function. Auditing of allocated or deallocated resources
+ would be auditable as part of the access control SFP or the
+ information flow control SFP operations.
+
+ This family should apply to the objects specified in the
+ access control SFP(s) or the information flow control SFP(s)
+ as specified by the PP/ST author.
+
+
+
+
+
+ This component requires that, for a subset of the objects
+ in the TOE, the TSF will ensure that there is no available
+ residual information contained in a resource allocated to
+ those objects or deallocated from those objects.
+
+
+
+ , requires that the TSF
+ ensure that any residual information content of any
+ resources is unavailable to a defined subset of the
+ objects controlled by the TSF upon the resource's
+ allocation or deallocation.
+
+
+ The choice of when to perform residual information
+ protection (i.e. upon allocation or deallocation) could be
+ made configurable within the TOE.
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ the following objects:
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ subject to residual information protection.
+
+ .
+
+
+
+
+
+
+
+ This component requires that for all objects in the TOE,
+ the TSF will ensure that there is no available residual
+ information contained in a resource allocated to those
+ objects or deallocated from those objects.
+
+
+
+ , requires that the TSF ensure that
+ any residual information content of any resources is
+ unavailable to all objects upon the resource's
+ allocation or deallocation.
+
+
+
+ The TSF shall ensure that any previous information content
+ of a resource is made unavailable upon the
+
+
+ allocation of the resource to
+
+
+ deallocation of the resource from
+
+
+
+ the PP/ST author should specify the event, allocation
+ of the resource to or deallocation of the resource
+ from, that invokes the residual information protection
+ function.
+
+
+ all objects.
+
+
+
+
+
+
+
+ The rollback operation involves undoing the last operation
+ or a series of operations, bounded by some limit, such as a
+ period of time, and return to a previous known
+ state. Rollback provides the ability to undo the effects of
+ an operation or series of operations to preserve the
+ integrity of the user data.
+
+
+
+ This family addresses the need to return to a well defined
+ valid state, such as the need of a user to undo
+ modifications to a file or to undo transactions in case of
+ an incomplete series of transaction as in the case of
+ databases.
+
+ This family is intended to assist a user in returning to a
+ well defined valid state after the user undoes the last set
+ of actions, or, in distributed databases, the return of all
+ of the distributed copies of the databases to the state
+ before an operation failed.
+
+ and conflict when
+ enforces that the contents will be made
+ unavailable at the time that a resource is deallocated from
+ an object. Therefore, this use of
+ cannot be combined with as there would
+ be no information to roll back. can be
+ used only with when it enforces that
+ the contents will be unavailable at the time that a resource
+ is allocated to an object. This is because the mechanism will have an opportunity to access
+ the previous information that may still be present in the
+ TOE in order to successfully roll back the operation.
+
+ The rollback requirement is bounded by certain limits. For
+ example a text editor typically only allows you roll back up
+ to a certain number of commands. Another example would be
+ backups. If backup tapes are rotated, after a tape is
+ reused, the information can no longer be retrieved. This
+ also poses a bound on the rollback requirement.
+
+
+
+
+
+
+
+
+
+
+
+ This component allows a user or subject to undo a set of
+ operations on a predefined set of objects. The undo is
+ only possible within certain limits, for example up to a
+ number of characters or up to a time limit.
+
+
+
+ addresses a need to roll back or
+ undo a limited number of operations within the defined
+ bounds.
+
+
+ The boundary limit to which rollback may be performed could
+ be a configurable item within the TOE.
+
+
+ Permission to perform a rollback operation could be
+ restricted to a well defined role.
+
+
+ All successful rollback operations.
+
+
+ All attempts to perform rollback operations.
+
+
+ All attempts to perform rollback operations, including
+ identification of the types of operations rolled back.
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of the
+
+
+ list of operations
+
+
+
+ the PP/ST author should specify the list of operations
+ that can be rolled back.
+
+
+ on the
+
+ information and/or list of objects
+
+ the PP/ST author should specify the information and/or
+ list of objects that are subjected to the rollback policy..
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component enforces that the TSF provide the
+ capability to rollback all operations; however, the user
+ can choose to rollback only a part of them.
+
+
+
+ addresses the need to roll back or
+ undo all operations within the defined bounds.
+
+
+
+
+
+
+ The TSF shall enforce
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when performing rollback
+ operations. This is necessary to make sure that roll
+ back is not used to circumvent the specified SFPs.
+
+
+ to permit the rollback of all the operations on the
+
+
+ list of objects
+
+
+
+ the PP/ST author should specify the list of objects
+ that are subjected to the rollback policy.
+
+ .
+
+
+ The TSF shall permit operations to be rolled back within the
+
+
+ boundary limit to which rollback may be performed
+
+
+
+ the PP/ST author should specify the boundary limit to
+ which rollback operations may be performed. The
+ boundary may be specified as a predefined period of
+ time, for example, operations may be undone which were
+ performed within the past two minutes. Other possible
+ boundaries may be defined as the maximum number of
+ operations allowable or the size of a buffer.
+
+ .
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF. Integrity
+ errors may affect user data stored in memory, or in a
+ storage device. This family differs from which protects the user data from integrity
+ errors while being transferred within the TOE.
+
+
+
+ This family provides requirements that address protection of
+ user data while it is stored within containers controlled by the TSF.
+
+ Hardware glitches or errors may affect data stored in
+ memory. This family provides requirements to detect these
+ unintentional errors. The integrity of user data while
+ stored on storage devices controlled by the TSF are also addressed
+ by this family.
+
+ To prevent a subject from modifying the data, the or families are required
+ (rather than this family).
+
+ This family differs from that protects
+ the user data from integrity errors while being transferred
+ within the TOE.
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify different kinds of
+ user data attributes that will be used as the basis for
+ monitoring.
+
+
+
+ , requires that the TSF monitor user
+ data stored within containers controlled by the TSF for identified integrity
+ errors.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+
+
+
+
+
+ This component monitors data stored on media for integrity
+ errors. The PP/ST author can specify which action should
+ be taken in case an integrity error is detected.
+
+
+
+ adds the additional capability to
+ the first component by allowing for actions to be taken as
+ a result of an error detection.
+
+
+ The actions to be taken upon the detection of an integrity
+ error could be configurable.
+
+
+ Successful attempts to check the integrity of user data,
+ including an indication of the results of the check.
+
+
+ All attempts to check the integrity of user data, including
+ an indication of the results of the check, if performed.
+
+
+ The type of integrity error that occurred.
+
+
+ The action taken upon detection of an integrity error.
+
+
+ The TSF shall monitor user data stored in containers controlled by the TSF for
+
+
+ integrity errors
+
+
+
+ the PP/ST author should specify the integrity errors
+ that the TSF will detect.
+
+
+ on all objects, based on the following attributes:
+
+
+ user data attributes
+
+
+
+ the PP/ST author should specify the user data
+ attributes that will be used as the basis for the
+ monitoring.
+
+ .
+
+
+ Upon detection of a data integrity error, the TSF shall
+
+
+ action to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken in case an integrity error is detected.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT product.
+
+
+
+ This family defines the requirements for ensuring the
+ confidentiality of user data when it is transferred using an
+ external channel between the TOE and another trusted IT
+ product. Confidentiality is enforced by preventing
+ unauthorised disclosure of user data in transit between the
+ two end points. The end points may be a TSF or a user.
+
+ This family provides a requirement for the protection of user
+ data during transit. In contrast, handles TSF data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Depending on the access control or information flow policies the TSF is
+ required to send or receive user data in a manner such that the
+ confidentiality of the user data is protected.
+
+
+
+ In , the goal is to provide
+ protection from disclosure of user data while in transit.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any unauthorised user or subject attempting
+ to use the data exchange mechanisms.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the information.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s) and/or information flow control SFP(s)
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be enforced when exchanging
+ user data. The specified policies will be enforced to make decisions about
+ who can exchange data and which data can be exchanged.
+ to
+ transmitreceivethe PP/ST author should specify whether this element
+ applies to a mechanism that transmits or receives user data.
+ user data in a manner protected from unauthorised disclosure.
+
+
+
+
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TOE and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+
+
+ This family defines the requirements for providing integrity
+ for user data in transit between the TSF and another trusted
+ IT product and recovering from detectable errors. At a
+ minimum, this family monitors the integrity of user data for
+ modifications. Furthermore, this family supports different
+ ways of correcting detected integrity errors.
+
+ This family defines the requirements for providing integrity
+ for user data in transit; while handles
+ TSF data.
+
+ and are duals of
+ each other, as addresses user data
+ confidentiality. Therefore, the same mechanism that
+ implements could possibly be used to
+ implement other families such as and
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Depending on the access control or information flow policies the TSF is
+ required to send or receive user data in a manner such that modification
+ of the user data is detected. There is no requirement for a TSF mechanism
+ to attempt to recover from the modification.
+
+
+
+ addresses detection of
+ modifications, deletions, insertions, and replay errors of
+ the user data transmitted.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+ access control SFP(s) and/or information flow control SFP(s)
+ the PP/ST author should specify the access control SFP(s)
+ and/or information flow control SFP(s) that will be enforced on the transmitted
+ data or on the received data. The specified policies will be enforced to make
+ decisions about who can transmit or who can receive data, and which data can be
+ transmitted or received.
+ to
+ transmitreceivethe PP/ST author should specify whether this element applies
+ to a TSF that is transmitting or receiving objects.
+ user data in a manner protected from
+ modificationdeletioninsertionreplaythe PP/ST author should specify whether the data should be
+ protected from modification, deletion, insertion or replay.
+ errors.
+
+
+ The TSF shall be able to determine on receipt of user data,
+ whether
+
+
+ modification
+
+
+ deletion
+
+
+ insertion
+
+
+ replay
+
+
+
+ the PP/ST author should specify whether the errors of
+ the type: modification, deletion, insertion or replay
+ are detected.
+
+
+ has occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors, if required, with the
+ help of the other trusted IT product. As the other trusted
+ IT product is outside the TOE, the TSF cannot control its
+ behaviour. However, it can provide functions that have the
+ ability to cooperate with the other trusted IT product for
+ the purposes of recovery. For example, the TSF could
+ include functions that depend upon the source trusted IT
+ product to re-send the data in the event that an error is
+ detected. This component deals with the ability of the TSF
+ to handle such an error recovery.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF with help from the source
+ trusted IT product.
+
+
+ The identity of any user or subject using the data exchange
+ mechanisms.
+
+
+ Successful recovery from errors including they type of error
+ that was detected.
+
+
+ The identity of any user or subject attempting to use the
+ user data exchange mechanisms, but who is unauthorised to do
+ so.
+
+
+ A reference to the names or other indexing information
+ useful in identifying the user data that was transmitted or
+ received. This could include security attributes associated
+ with the user data.
+
+
+ Any identified attempts to block transmission of user data.
+
+
+ The types and/or effects of any detected modifications of
+ transmitted user data.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the TSF, with the help of the source
+ trusted IT product, is be able to recover the original
+ user data.
+
+
+ with the help of the source trusted IT product.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component provides the ability to recover from a set
+ of identified transmission errors. It accomplishes this
+ task without help from the source trusted IT product. For
+ example, if certain errors are detected, the transmission
+ protocol must be robust enough to allow the TSF to recover
+ from the error based on checksums and other information
+ available within that protocol.
+
+
+
+ addresses recovery of the original
+ user data by the receiving TSF on its own without any help
+ from the source trusted IT product.
+
+
+
+
+
+ The TSF shall enforce the
+
+
+ access control SFP(s) and/or information flow control
+ SFP(s)
+
+
+
+ the PP/ST author should specify the access control
+ SFP(s) and/or information flow control SFP(s) that
+ will be enforced when recovering user data. The
+ specified policies will be enforced to make decisions
+ about which data can be recovered and how it can be
+ recovered.
+
+
+ to be able to recover from
+
+
+ list of recoverable errors
+
+
+
+ the PP/ST author should specify the list of integrity
+ errors from which the receiving TSF, alone, is able to
+ recover the original user data.
+
+
+ without any help from the source trusted IT product.
+
+
+
+
+
+
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user identity.
+
+ Identification and Authentication is required to ensure that
+ users are associated with the proper security attributes
+ (e.g. identity, groups, roles, security or integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the intended
+ security policies. The families in this class deal with
+ determining and verifying the identity of users, determining
+ their authority to interact with the TOE, and with the correct
+ association of security attributes for each authorised
+ user. Other classes of requirements (e.g. User Data
+ Protection, Security Audit) are dependent upon correct
+ identification and authentication of users in order to be
+ effective.
+
+
+
+ A common security requirement is to unambiguously identify the
+ person and/or entity performing functions in a TOE. This
+ involves not only establishing the claimed identity of each
+ user, but also verifying that each user is indeed who he/she
+ claims to be. This is achieved by requiring users to provide
+ the TSF with some information that is known by the TSF to be
+ associated with the user in question.
+
+ Families in this class address the requirements for functions
+ to establish and verify a claimed user
+ identity. Identification and Authentication is required to
+ ensure that users are associated with the proper security
+ attributes (e.g. identity, groups, roles, security or
+ integrity levels).
+
+ The unambiguous identification of authorised users and the
+ correct association of security attributes with users and
+ subjects is critical to the enforcement of the security
+ policies.
+
+ The family addresses determining the
+ identity of a user.
+
+ The family addresses verifying the
+ identity of a user.
+
+ The family addresses defining limits on
+ repeated unsuccessful authentication attempts.
+
+ The family address the definition of user
+ attributes that are used in the enforcement of the SFRs.
+
+ The family addresses the correct
+ association of security attributes for each authorised user.
+
+ The family addresses the generation and
+ verification of secrets that satisfy a defined metric.
+
+
+
+
+
+ This family contains requirements for defining values for
+ some number of unsuccessful authentication attempts and TSF
+ actions in cases of authentication attempt
+ failures. Parameters include, but are not limited to, the
+ number of failed authentication attempts and time
+ thresholds.
+
+
+
+ This family addresses requirements for defining values for
+ authentication attempts and TSF actions in cases of
+ authentication attempt failure. Parameters include, but are
+ not limited to, the number of attempts and time thresholds.
+
+ The session establishment process is the interaction with
+ the user to perform the session establishment independent of
+ the actual implementation. If the number of unsuccessful
+ authentication attempts exceeds the indicated threshold,
+ either the user account or the terminal (or both) will be
+ locked. If the user account is disabled, the user cannot
+ log-on to the system. If the terminal is disabled, the
+ terminal (or the address that the terminal has) cannot be
+ used for any log-on. Both of these situations continue until
+ the condition for re-establishment is satisfied.
+
+
+
+
+
+
+
+
+ The PP/ST author may define the number of unsuccessful
+ authentication attempts or may choose to let the TOE
+ developer or the authorised user to define this
+ number. The unsuccessful authentication attempts need not
+ be consecutive, but rather related to an authentication
+ event. Such an authentication event could be the count
+ from the last successful session establishment at a given
+ terminal.
+
+ The PP/ST author could specify a list of actions that the
+ TSF shall take in the case of authentication failure. An
+ authorised administrator could also be allowed to manage
+ the events, if deemed opportune by the PP/ST author. These
+ actions could be, among other things, terminal
+ deactivation, user account deactivation, or administrator
+ alarm. The conditions under which the situation will be
+ restored to normal must be specified on the action.
+
+ In order to prevent denial of service, TOEs usually ensure
+ that there is at least one user account that cannot be
+ disabled.
+
+ Further actions for the TSF can be stated by the PP/ST
+ author, including rules for re-enabling the user session
+ establishment process, or sending an alarm to the
+ administrator. Examples of these actions are: until a
+ specified time has lapsed, until the authorised
+ administrator re-enables the terminal/account, a time
+ related to failed previous attempts (every time the
+ attempt fails, the disabling time is doubled).
+
+
+
+ , requires that the TSF be able to
+ terminate the session establishment process after a
+ specified number of unsuccessful user authentication
+ attempts. It also requires that, after termination of the
+ session establishment process, the TSF be able to disable
+ the user account or the point of entry (e.g. workstation)
+ from which the attempts were made until an
+ administrator-defined condition occurs.
+
+
+ management of the threshold for unsuccessful authentication
+ attempts;
+
+
+ management of actions to be taken in the event of an
+ authentication failure.
+
+
+ the reaching of the threshold for the unsuccessful
+ authentication attempts and the actions (e.g. disabling of a
+ terminal) taken and the subsequent, if appropriate,
+ restoration to the normal state (e.g. re-enabling of a
+ terminal).
+
+
+ The TSF shall detect when
+
+ positive integer number
+
+ if the assignment of a positive integer is selected,
+ the PP/ST author should specify the default number
+ (positive integer) of unsuccessful authentication
+ attempts that, when met or surpassed, will trigger
+ the events.
+ an administrator configurable positive integer within
+
+ range of acceptable values
+
+ if an administrator configurable positive integer is
+ selected, the PP/ST author should specify the range of
+ acceptable values from which the administrator of the
+ TOE may configure the number of unsuccessful
+ authentication attempts. The number of authentication
+ attempts should be less than or equal to the upper
+ bound and greater or equal to the lower bound values.
+ the PP/ST author should select either the assignment of a positive integer,
+ or the phrase ``an administrator configurable positive integer'' specifying
+ the range of acceptable values.
+ unsuccessful authentication attempts occur related to
+
+
+ list of authentication events
+
+
+
+ the PP/ST author should specify the authentication
+ events. Examples of these authentication events are:
+ the unsuccessful authentication attempts since the
+ last successful authentication for the indicated user
+ identity, the unsuccessful authentication attempts
+ since the last successful authentication for the
+ current terminal, the number of unsuccessful
+ authentication attempts in the last 10 minutes. At
+ least one authentication event must be specified.
+
+ .
+
+
+ When the defined number of unsuccessful authentication
+ attempts has been
+ metsurpassed
+ the PP/ST author should select whether the event of
+ meeting or surpassing the defined number of unsuccessful
+ authentication attemps shall trigger an action by the
+ TSF., the TSF shall
+
+ list of actions
+
+ the PP/ST author should specify the actions to be taken in
+ case the threshold is met or surpassed, as selected. These
+ actions could be disabling of an account for 5 minutes,
+ disabling the terminal for an increasing amount of time (2
+ to the power of the number of unsuccessful attempts in
+ seconds), or disabling of the account until unlocked by
+ the administrator and simultaneously informing the
+ administrator. The actions should specify the measures and
+ if applicable the duration of the measure (or the
+ conditions under which the measure will be ended)..
+
+
+
+
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that is used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+
+
+ All authorised users may have a set of security attributes,
+ other than the user's identity, that are used to
+ enforce the SFRs. This family defines the requirements for
+ associating user security attributes with users as needed to
+ support the TSF in making security decisions.
+
+ There are dependencies on the individual security policy (SFP)
+ definitions. These individual definitions should contain the
+ listing of attributes that are necessary for policy
+ enforcement.
+
+
+
+
+
+ This component specifies the security attributes that
+ should be maintained at the level of the user. This means
+ that the security attributes listed are assigned to and
+ can be changed at the level of the user. In other words,
+ changing a security attribute in this list associated with
+ a user should have no impact on the security attributes of
+ any other user.
+
+ In case security attributes belong to a group of users
+ (such as Capability List for a group), the user will need
+ to have a reference (as security attribute) to the
+ relevant group.
+
+
+
+ , allows user security attributes
+ for each user to be maintained individually.
+
+
+ if so indicated in the assignment, the authorised
+ administrator might be able to define additional security
+ attributes for users.
+
+
+ The TSF shall maintain the following list of security
+ attributes belonging to individual users:
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that are associated to an individual
+ user. An example of such a list is
+ {``clearance'', ``group
+ identifier'', ``rights''}.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets and generate
+ secrets to satisfy the defined metric.
+
+
+
+ This family defines requirements for mechanisms that enforce
+ defined quality metrics on provided secrets, and generate
+ secrets to satisfy the defined metric. Examples of such
+ mechanisms may include automated checking of user supplied
+ passwords, or automated password generation.
+
+ A secret can be generated outside the TOE (e.g. selected by
+ the user and introduced in the TOE). In such cases, the
+ component can be used to
+ ensure that the external generated secret adheres to certain
+ standards, for example a minimum size, not present in a
+ dictionary, and/or not previously used.
+
+ Secrets can also be generated by the TOE. In those cases,
+ the component can be used
+ to require the TOE to ensure that the secrets that will
+ adhere to some specified metrics.
+
+ Secrets contain the authentication data provided by the user
+ for an authentication mechanism that is based on knowledge
+ the user possesses. When cryptographic keys are employed,
+ the class should be used instead of this
+ family.
+
+
+
+
+
+ Secrets can be generated by the user. This component
+ ensures that those user generated secrets can be verified
+ to meet a certain quality metric.
+
+
+
+ , requires the TSF to verify that
+ secrets meet defined quality metrics.
+
+
+ the management of the metric used to verify the secrets.
+
+
+ Rejection by the TSF of any tested secret;
+
+
+ Rejection or acceptance by the TSF of any tested secret;
+
+
+ Identification of any changes to the defined quality
+ metrics.
+
+
+ The TSF shall provide a mechanism to verify that secrets
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed, or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+
+
+
+
+ This component allows the TSF to generate secrets for
+ specific functions such as authentication by means of
+ passwords.
+
+ When a pseudo-random number generator is used in a secret
+ generation algorithm, it should accept as input random
+ data that would provide output that has a high degree of
+ unpredictability. This random data (seed) can be derived
+ from a number of available parameters such as a system
+ clock, system registers, date, time, etc. The parameters
+ should be selected to ensure that the number of unique
+ seeds that can be generated from these inputs should be at
+ least equal to the minimum number of secrets that must be
+ generated.
+
+
+
+ , requires the TSF to be able to
+ generate secrets that meet defined quality metrics.
+
+
+ the management of the metric used to generate the secrets.
+
+
+
+
+
+ The TSF shall provide a mechanism to generate secrets that
+ meet
+
+
+ a defined quality metric
+
+
+
+ the PP/ST author should provide a defined quality
+ metric. The quality metric specification can be as
+ simple as a description of the quality checks to be
+ performed or as formal as a reference to a government
+ published standard that defines the quality metrics
+ that secrets must meet. Examples of quality metrics
+ could include a description of the alphanumeric
+ structure of acceptable secrets and/or the space size
+ that acceptable secrets must meet.
+
+ .
+
+
+ The TSF shall be able to enforce the use of TSF generated
+ secrets for
+
+
+ list of TSF functions
+
+
+
+ the PP/ST author should provide a list of TSF
+ functions for which the TSF generated secrets must be
+ used. An example of such a function could include a
+ password based authentication mechanism.
+
+ .
+
+
+
+
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family also defines
+ the required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+ This family defines the types of user authentication
+ mechanisms supported by the TSF. This family defines the
+ required attributes on which the user authentication
+ mechanisms must be based.
+
+
+
+
+
+
+
+
+ This component requires that the PP/ST author define the
+ TSF-mediated actions that can be performed by the TSF on
+ behalf of the user before the claimed identity of the user
+ is authenticated. The TSF-mediated actions should have no
+ security concerns with users incorrectly identifying
+ themselves prior to being authenticated. For all other
+ TSF-mediated actions not in the list, the user must be
+ authenticated before the action can be performed by the
+ TSF on behalf of the user.
+
+ This component cannot control whether the actions can also
+ be performed before the identification took place. This
+ requires the use of either or
+ with the appropriate assignments.
+
+
+
+ , allows a user to perform certain
+ actions prior to the authentication of the
+ user's identity.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the associated
+ user;
+
+
+ managing the list of actions that can be taken before the
+ user is authenticated.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism;
+
+
+ All TSF mediated actions performed before authentication of
+ the user.
+
+
+ The TSF shall allow
+
+
+ list of TSF mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the claimed identity of the user is
+ authenticated. This list cannot be empty. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ authenticated.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+
+
+
+
+ This component requires that a user is authenticated before any other
+ TSF-mediated action can take place on behalf of that user.
+
+
+ , requires that users are
+ authenticated before any other action will be allowed by the TSF.
+
+
+ management of the authentication data by an administrator;
+
+
+ management of the authentication data by the user associated
+ with this data.
+
+
+ Unsuccessful use of the authentication mechanism;
+
+
+ All use of the authentication mechanism.
+
+
+ The TSF shall require each user to be successfully
+ authenticated before allowing any other TSF-mediated actions
+ on behalf of that user.
+
+
+
+
+
+
+ This component addresses requirements for mechanisms that
+ provide protection of authentication data. Authentication
+ data that is copied from another user, or is in some way
+ constructed should be detected and/or rejected. These
+ mechanisms provide confidence that users authenticated by
+ the TSF are actually who they claim to be.
+
+ This component may be useful only with authentication
+ mechanisms that are based on authentication data that
+ cannot be shared (e.g. biometrics). It is impossible for a
+ TSF to detect or prevent the sharing of passwords outside
+ the control of the TSF.
+
+
+
+ Unforgeable authentication,
+ requires the authentication mechanism to be able to detect
+ and prevent the use of authentication data that has been
+ forged or copied.
+
+
+ Detection of fraudulent authentication data;
+
+
+ All immediate measures taken and results of checks on the
+ fraudulent data.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent forging of
+ authentication data.
+
+
+ use of authentication data that has been forged by any user
+ of the TSF.
+
+
+ The TSF shall
+
+
+ detect
+
+
+ prevent
+
+
+
+ the PP/ST author should specify whether the TSF will
+ detect, prevent, or detect and prevent copying of
+ authentication data.
+
+
+ use of authentication data that has been copied from any
+ other user of the TSF.
+
+
+
+
+
+
+ This component addresses requirements for authentication
+ mechanisms based on single-use authentication
+ data. Single-use authentication data can be something the
+ user has or knows, but not something the user is. Examples
+ of single-use authentication data include single-use
+ passwords, encrypted time-stamps, and/or random numbers
+ from a secret lookup table.
+
+ The PP/ST author can specify to which authentication
+ mechanism(s) this requirement applies.
+
+
+
+ , requires an authentication
+ mechanism that operates with single-use authentication
+ data.
+
+
+ Attempts to reuse authentication data.
+
+
+ The TSF shall prevent reuse of authentication data related
+ to
+
+
+ identified authentication mechanism(s)
+
+
+
+ the PP/ST author should specify the list of
+ authentication mechanisms to which this requirement
+ applies. This assignment can be ``all
+ authentication mechanisms''. An example of
+ this assignment could be ``the
+ authentication mechanism employed to authenticate
+ people on the external network''.
+
+ .
+
+
+
+
+
+
+ The use of this component allows specification of
+ requirements for more than one authentication mechanism to
+ be used within a TOE. For each distinct mechanism,
+ applicable requirements must be chosen from the class to be applied to each
+ mechanism. It is possible that the same component could be
+ selected multiple times in order to reflect different
+ requirements for the different use of the authentication
+ mechanism.
+
+ The management functions in the class FMT may provide
+ maintenance capabilities for the set of authentication
+ mechanisms, as well as the rules that determine whether
+ the authentication was successful.
+
+ To allow anonymous users to interact with the TOE, a
+ ``none'' authentication mechanism can be incorporated. The
+ use of such access should be clearly explained in the
+ rules of .
+
+
+
+ , requires that different
+ authentication mechanisms be provided and used to
+ authenticate user identities for specific events.
+
+
+ the management of authentication mechanisms;
+
+
+ the management of the rules for authentication.
+
+
+ The final decision on authentication;
+
+
+ The result of each activated mechanism together with the
+ final decision.
+
+
+ The TSF shall provide
+
+
+ list of multiple authentication mechanisms
+
+
+
+ the PP/ST author should define the available
+ authentication mechanisms. An example of such a list
+ could be: ``none, password mechanism,
+ biometric (retinal scan), S/key mechanism''.
+
+
+ to support user authentication.
+
+
+ The TSF shall authenticate any user's claimed
+ identity according to the
+
+
+ rules describing how the multiple authentication
+ mechanisms provide authentication
+
+
+
+ the PP/ST author should specify the rules that
+ describe how the authentication mechanisms provide
+ authentication and when each is to be used. This means
+ that for each situation the set of mechanisms that
+ might be used for authenticating the user must be
+ described. An example of a list of such rules is:
+ ``if the user has special privileges a
+ password mechanism and a biometric mechanism both
+ shall be used, with success only if both succeed; for
+ all other users a password mechanism shall be
+ used.''
+
+ The PP/ST author might give the boundaries within
+ which the authorised administrator may specify
+ specific rules. An example of a rule is:
+ ``the user shall always be authenticated by
+ means of a token; the administrator might specify
+ additional authentication mechanisms that also must be
+ used.'' The PP/ST author also might choose
+ not to specify any boundaries but leave the
+ authentication mechanisms and their rules completely
+ up to the authorised administrator.
+
+ .
+
+
+
+
+
+
+ This component addresses potential needs to
+ re-authenticate users at defined points in time. These may
+ include user requests for the TSF to perform security
+ relevant actions, as well as requests from non-TSF
+ entities for re-authentication (e.g. a server application
+ requesting that the TSF re-authenticate the client it is
+ serving).
+
+
+
+ , requires the ability to specify
+ events for which the user needs to be re-authenticated.
+
+
+ if an authorised administrator could request
+ re-authentication, the management includes a
+ re-authentication request.
+
+
+ Failure of reauthentication;
+
+
+ All reauthentication attempts.
+
+
+ The TSF shall re-authenticate the user under the conditions
+
+
+ list of conditions under which re-authentication is
+ required
+
+
+
+ the PP/ST author should specify the list of conditions
+ requiring re-authentication. This list could include a
+ specified user inactivity period that has elapsed, the
+ user requesting a change in active security
+ attributes, or the user requesting the TSF to perform
+ some security critical function.
+
+ The PP/ST author might give the boundaries within
+ which the reauthentication should occur and leave the
+ specifics to the authorised administrator. An example
+ of such a rule is: ``the user shall always
+ be re-authenticated at least once a day; the
+ administrator might specify that the re-authentication
+ should happen more often but not more often than once
+ every 10 minutes.''
+
+ .
+
+
+
+
+
+
+
+
+
+ This component addresses the feedback on the
+ authentication process that will be provided to the
+ user. In some systems the feedback consists of indicating
+ how many characters have been typed but not showing the
+ characters themselves, in other systems even this
+ information might not be appropriate.
+
+ This component requires that the authentication data is
+ not provided as-is back to the user. In a workstation
+ environment, it could display a
+ ``dummy'' (e.g. star) for each
+ password character provided, and not the original
+ character.
+
+
+
+ , requires that only limited
+ feedback information is provided to the user during the
+ authentication.
+
+
+ The TSF shall provide only
+
+
+ list of feedback
+
+
+
+ the PP/ST author should specify the feedback related
+ to the authentication process that will be provided to
+ the user. An example of a feedback assignment is
+ ``the number of characters
+ typed'', another type of feedback is
+ ``the authentication mechanism that failed
+ the authentication''.
+
+
+ to the user while the authentication is in progress.
+
+
+
+
+
+
+
+ This family defines the conditions under which users shall
+ be required to identify themselves before performing any
+ other actions that are to be mediated by the TSF and which
+ require user identification.
+
+
+
+ This family defines the conditions under which users are
+ required to identify themselves before performing any other
+ actions that are to be mediated by the TSF and that require
+ user identification.
+
+
+
+
+
+ This component poses requirements for the user to be
+ identified. The PP/ST author can indicate specific actions
+ that can be performed before the identification takes
+ place.
+
+ If is used, the TSF-mediated
+ actions mentioned in should also
+ appear in this .
+
+
+
+ , allows users to perform certain
+ actions before being identified by the TSF.
+
+
+ the management of the user identities;
+
+
+ if an authorised administrator can change the actions
+ allowed before identification, the managing of the action
+ lists.
+
+
+ Unsuccessful use of the user identification mechanism,
+ including the user identity provided;
+
+
+ All use of the user identification mechanism, including the
+ user identity provided.
+
+
+ The TSF shall allow
+
+
+ list of TSF-mediated actions
+
+
+
+ the PP/ST author should specify a list of TSF-mediated
+ actions that can be performed by the TSF on behalf of
+ a user before the user has to identify itself. If no
+ actions are appropriate, component should be used instead. An example of
+ such an action might include the request for help on
+ the login procedure.
+
+
+ on behalf of the user to be performed before the user is
+ identified.
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ In this component users will be identified. A user is not
+ allowed by the TSF to perform any action before being
+ identified.
+
+
+
+ , requires that users identify
+ themselves before any other action will be allowed by the TSF.
+
+
+ the management of the user identities.
+
+
+
+
+ The TSF shall require each user to be successfully identified before
+ allowing any other TSF-mediated actions on behalf of that user.
+
+
+
+
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ An authenticated user, in order to use the TOE, typically
+ activates a subject. The user's security
+ attributes are associated (totally or partially) with this
+ subject. This family defines requirements to create and
+ maintain the association of the user's security
+ attributes to a subject acting on the user's
+ behalf.
+
+
+
+ It is intended that a subject is
+ acting on behalf of the user who caused the subject to come into
+ being or to be activated to perform a certain task.
+ Therefore, when a subject is created, that subject is acting on
+ behalf of the user who initiated the creation. In cases where
+ anonymity is used, the subject is still acting on behalf of a
+ user, but the identity of that user is unknown. A special
+ category of subjects are those subjects that serve multiple
+ users (e.g. a server process). In such cases the user that
+ created this subject is assumed to be the ``owner''., requires the specification of any rules
+ governing the association between user attributes and the
+ subject attributes into which they are mapped.
+ an authorised administrator can define default subject security
+ attributes.
+
+ an authorised administrator can change subject security
+ attributes.
+
+ Unsuccessful binding of user security attributes to a subject
+ (e.g. creation of a subject).
+
+ Success and failure of binding of user security attributes to a
+ subject (e.g. success or failure to create a subject).
+
+ The TSF shall associate the following user security attributes
+ with subjects acting on the behalf of that user:
+
+ list of user security attributes
+
+ the PP/ST author should specify a list of the user security
+ attributes that are to be bound to subjects..
+
+ The TSF shall enforce the following rules on the initial
+ association of user security attributes with subjects acting on
+ the behalf of users:
+
+ rules for the initial association of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ upon initial association of attributes with subjects, or
+ ``none''..
+
+ The TSF shall enforce the following rules governing changes to the
+ user security attributes associated with subjects acting on the
+ behalf of users:
+
+ rules for the changing of attributes
+
+ the PP/ST author should specify any rules that are to apply
+ when changes are made to the user security attributes
+ associated with subjects acting on behalf of users, or
+ ``none''..
+
+
+
+
+
+
+ This class is intended to specify the management of several
+ aspects of the TSF: security attributes, TSF data and
+ functions. The different management roles and their
+ interaction, such as separation of capability, can be
+ specified.
+
+ This class has several objectives:
+
+
+ management of TSF data, which include, for example,
+ banners;
+
+
+ management of security attributes, which include, for
+ example, the Access Control Lists, and Capability Lists;
+
+
+ management of functions of the TSF, which includes, for
+ example, the selection of functions, and rules or
+ conditions influencing the behaviour of the TSF;
+
+
+ definition of security roles.
+
+
+
+
+
+ This class specifies the management of several aspects of the
+ TSF: security attributes, TSF data and functions in the
+ TSF. The different management roles and their interaction,
+ such as separation of capability, can also be specified
+
+ In an environment where the TOE is made up of multiple
+ physically separated parts, the timing issues with respect to
+ propagation of security attributes, TSF data, and function
+ modification become very complex, especially if the
+ information is required to be replicated across the parts of
+ the TOE. This should be considered when selecting components
+ such as , or , where the behaviour might be
+ impaired. In such situations, use of components from is advisable.
+
+
+
+
+
+ This family allows authorised users control over the
+ management of functions in the TSF. Examples of functions in
+ the TSF include the audit functions and the multiple
+ authentication functions.
+
+
+
+ The TSF management functions enable authorised users to set
+ up and control the secure operation of the TOE. These
+ administrative functions typically fall into a number of
+ different categories:
+
+
+ Management functions that relate to access control,
+ accountability and authentication controls enforced by
+ the TOE. For example, definition and update of user
+ security characteristics (e.g. unique identifiers
+ associated with user names, user accounts, system entry
+ parameters) or definition and update of auditing system
+ controls (e.g. selection of audit events, management of
+ audit trails, audit trail analysis, and audit report
+ generation), definition and update of per-user policy
+ attributes (such as user clearance), definition of known
+ system access control labels, and control and management
+ of user groups.
+
+
+ Management functions that relate to controls over
+ availability. For example, definition and update of
+ availability parameters or resource quotas.
+
+
+ Management functions that relate to general installation
+ and configuration. For example, TOE configuration,
+ manual recovery, installation of TOE security fixes (if
+ any), repair and reinstallation of hardware.
+
+
+ Management functions that relate to routine control and
+ maintenance of TOE resources. For example, enabling and
+ disabling peripheral devices, mounting of removable
+ storage media, backup and recovery.
+
+
+
+ Note that these functions need to be present in a TOE based
+ on the families included in the PP or ST. It is the
+ responsibility of the PP/ST author to ensure that adequate
+ functions will be provided to manage the TOE in a secure
+ fashion.
+
+ The TSF might contain functions that can be controlled by an
+ administrator. For example, the auditing functions could be
+ switched off, the time synchronisation could be switchable,
+ and/or the authentication mechanism could be modifiable.
+
+
+
+
+
+
+
+
+
+ This component allows identified roles to manage the
+ security functions of the TSF. This might entail obtaining
+ the current status of a security function, disabling or
+ enabling the security function, or modifying the behaviour
+ of the security function. An example of modifying the
+ behaviour of the security functions is changing of
+ authentication mechanisms.
+
+
+
+ allows the authorised users (roles)
+ to manage the behaviour of functions in the TSF that use
+ rules or have specified conditions that may be manageable.
+
+
+ managing the group of roles that can interact with the
+ functions in the TSF;
+
+
+ All modifications in the behaviour of the functions in the
+ TSF.
+
+
+ The TSF shall restrict the ability to
+
+
+ determine the behaviour of
+
+
+ disable
+
+
+ enable
+
+
+ modify the behaviour of
+
+
+
+ the PP/ST author should select whether the role can
+ determine the behaviour of, disable, enable, and/or
+ modify the behaviour of the security functions.
+
+
+ the functions
+
+
+ list of functions
+
+
+
+ the PP/ST author should specify the functions that can
+ be modified by the identified roles. Examples include
+ auditing and time determination.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the functions in the TSF. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+ This family allows authorised users control over the
+ management of security attributes. This management might
+ include capabilities for viewing and modifying of security
+ attributes.
+
+
+
+ This family defines the requirements on the management of
+ security attributes.
+
+ Security attributes affect the behaviour of the TSF. Examples of
+ security attributes are the groups to which a user belongs, the
+ roles he/she might assume, the priority of a process (subject),
+ and the rights belonging to a role or a user. These security
+ attributes might need to be managed by the user, a subject, a
+ specific authorised user (a user with explicitly given rights
+ for this management) or inherit values according to a given
+ policy/set of rules.
+
+ It is noted that the right to assign rights to users is
+ itself a security attribute and/or potentially subject to
+ management by .
+ can be used to ensure that any
+ accepted combination of security attributes is within a
+ secure state. The definition of what
+ ``secure'' means is left to the TOE guidance.
+
+ In some instances subjects, objects or user accounts are
+ created. If no explicit values for the related security
+ attributes are given, default values need to be used. can be used to specify that these default
+ values can be managed.
+
+
+
+
+
+
+
+
+
+
+
+
+ This component allows users acting in certain roles to
+ manage identified security attributes. The users are
+ assigned to a role within the component .
+
+ The default value of a parameter is the value the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter, and
+ overrides the default value.
+
+
+
+ allows authorised users (roles) to
+ manage the specified security attributes.
+
+
+ managing the group of roles that can interact with the
+ security attributes;
+
+ management of rules by which security attributes inherit
+ specified values.
+
+
+ All modifications of the values of security attributes.
+
+
+ The TSF shall enforce the
+
+ access control SFP(s), information flow control SFP(s)
+
+ the PP/ST author should list the access control SFP(s) or
+ the information flow control SFP(s) for which the security
+ attributes are applicable.
+ to restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example of such an operation could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified security
+ attributes. The PP/ST author can specify that the role
+ can modify the default value (change_default), query,
+ modify the security attribute, delete the security
+ attributes entirely or define their own operation.
+
+
+ the security attributes
+
+
+ list of security attributes
+
+
+
+ the PP/ST author should specify the security
+ attributes that can be operated on by the identified
+ roles. It is possible for the PP/ST author to specify
+ that the default value such as default access-rights
+ can be managed. Examples of these security attributes
+ are user-clearance, priority of service level, access
+ control list, default access rights.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the security attributes. The
+ possible roles are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This component contains requirements on the values that
+ can be assigned to security attributes. The assigned
+ values should be such that the TOE will remain in a secure
+ state.
+
+ The definition of what ``secure'' means is
+ not answered in this component but is left to the
+ development of the TOE and the resulting information in the
+ guidance. An example could be that if a user account is
+ created, it should have a non-trivial password.
+
+
+
+ ensures that values assigned to
+ security attributes are valid with respect to the secure
+ state.
+
+ management of rules by which security attributes inherit
+ specified values.
+
+
+ All offered and rejected values for a security attribute;
+
+
+ All offered and accepted secure values for a security
+ attribute.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for
+ list of security attributes
+
+ the PP/ST author should specify the list of security
+ attributes that require only secure values to be provided..
+
+
+
+
+
+
+
+
+
+
+ This component requires that the TSF provide default
+ values for relevant object security attributes, which can
+ be overridden by an initial value. It may still be
+ possible for a new object to have different security
+ attributes at creation, if a mechanism exists to specify
+ the permissions at time of creation.
+
+
+
+ ensures that the default values of
+ security attributes are appropriately either permissive or
+ restrictive in nature.
+
+
+ managing the group of roles that can specify initial values;
+
+
+ managing the permissive or restrictive setting of default values
+ for a given access control SFP;
+
+ management of rules by which security attributes inherit specified values.
+
+
+ Modifications of the default setting of permissive or
+ restrictive rules.
+
+
+ All modifications of the initial values of security
+ attributes.
+
+
+ The TSF shall enforce the
+
+
+ access control SFP, information flow control SFP
+
+
+
+ the PP/ST author should list the access control SFP or
+ the information flow control SFP for which the
+ security attributes are applicable.
+
+
+ to provide
+
+
+ restrictive
+
+
+ permissive
+
+
+ other property
+
+ if the PP/ST author selects another property, the PP/ST
+ author should specify the desired characteristics of the
+ default values.
+
+
+ the PP/ST author should select whether the default property
+ of the access control attribute will be restrictive,
+ permissive, or another property. Only one of these options
+ may be chosen.
+
+
+ default values for security attributes that are used to
+ enforce the SFP.
+
+
+ The TSF shall allow the
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the values of the security
+ attributes. The possible roles are specified in .
+
+
+ to specify alternative initial values to override the
+ default values when an object or information is created.
+
+
+ This component requires specification of the set of rules
+ through which the security attribute inherits values and the
+ conditions to be met for these rules to be applied. allows the rules/policies
+ to be specified that will dictate the value to be inherited
+ by a security attribute.
+ specification of the role permitted to establish or modify
+ security attributes.
+
+ Modifications of security attributes, possibly with the old
+ and/or values of security attributes that were modified.
+
+ The TSF shall use the following rules to set the value of security attributes:
+
+ rules for setting the values of security attributes
+
+ the PP/ST author specifies the rules governing the value
+ that will be inherited by the specified security
+ attribute, including the conditions that are to be met
+ for the rules to be applied. For example, if a new file
+ or directory is created (in a multilevel filesystem),
+ its label is the label at which the user is logged in at
+ the time it is created.
+
+
+
+
+
+ This family allows authorised users (roles) control over the
+ management of TSF data. Examples of TSF data include audit
+ information, clock and other TSF
+ configuration parameters.
+
+
+
+ This component imposes requirements on the management of TSF
+ data. Examples of TSF data are the current time and the
+ audit trail. So, for example, this family allows the
+ specification of whom can read, delete or create the audit
+ trail.
+
+
+
+
+
+
+
+
+ This component allows users with a certain role to manage
+ values of TSF data. The users are assigned to a role
+ within the component .
+
+ The default value of a parameter is the values the
+ parameter takes when it is instantiated without
+ specifically assigned values. An initial value is provided
+ during the instantiation (creation) of a parameter and
+ overrides the default value.
+
+
+
+ allows authorised users to manage
+ TSF data.
+
+
+ managing the group of roles that can interact with the TSF
+ data.
+
+
+ All modifications to the values of TSF data.
+
+
+ The TSF shall restrict the ability to
+
+
+ change_default
+
+
+ query
+
+
+ modify
+
+
+ delete
+
+
+ clear
+
+
+
+
+ other operations
+
+
+
+ if selected, the PP/ST author should specify which
+ other operations the role could perform. An
+ example could be
+ ``create''.
+
+
+
+
+
+ the PP/ST author should specify the operations that
+ can be applied to the identified TSF data. The PP/ST
+ author can specify that the role can modify the
+ default value (change_default), clear, query or modify
+ the TSF data, or delete the TSF data entirely. If so
+ desired the PP/ST author could specify any type of
+ operation. To clarify ``clear TSF data'' means that
+ the content of the TSF data is removed, but that the
+ entity that stores the TSF data remains in the
+ TOE.
+
+
+ the
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ be operated on by the identified roles. It is possible
+ for the PP/ST author to specify that the default value
+ can be managed.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to operate on the TSF data. The possible roles
+ are specified in .
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component specifies limits on TSF data, and actions
+ to be taken if these limits are exceeded. This component,
+ for example, will allow limits on the size of the audit
+ trail to be defined, and specification of the actions to
+ be taken when these limits are exceeded.
+
+
+
+ specifies the action to be taken if
+ limits on TSF data are reached or exceeded.
+
+
+ managing the group of roles that can interact with the
+ limits on the TSF data.
+
+
+ All modifications to the limits on TSF data;
+
+
+ All modifications in the actions to be taken in case of
+ violation of the limits.
+
+
+ The TSF shall restrict the specification of the limits for
+
+
+ list of TSF data
+
+
+
+ the PP/ST author should specify the TSF data that can
+ have limits, and the value of those limits. An example
+ of such TSF data is the number of users logged-in.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the limits on the TSF data and the
+ actions to be taken. The possible roles are specified
+ in .
+
+ .
+
+
+ The TSF shall take the following actions, if the TSF data
+ are at, or exceed, the indicated limits:
+
+
+ actions to be taken
+
+
+
+ the PP/ST author should specify the actions to be
+ taken if the specified limit on the specified TSF data
+ is exceeded. An example of such TSF action is that the
+ authorised user is informed and an audit record is
+ generated.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component covers requirements on the values that can
+ be assigned to TSF data. The assigned values should be
+ such that the TOE will remain in a secure state.
+
+ The definition of what ``secure'' means is not
+ answered in this component but is left to the development of
+ the TOE and the
+ resulting information in the guidance.
+
+
+
+ ensures that values assigned to TSF
+ data are valid with respect to the secure state.
+
+
+ All rejected values of TSF data.
+
+
+ The TSF shall ensure that only secure values are accepted
+ for
+ list of TSF data
+
+ the PP/ST author should specify what TSF data require only
+ secure values to be accepted..
+
+
+
+
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+ This family addresses revocation of security attributes for
+ a variety of entities within a TOE.
+
+
+
+
+
+
+
+
+ This component specifies requirements on the revocation of
+ rights. It requires the specification of the revocation
+ rules. Examples are:
+
+
+ Revocation will take place on the next login of the
+ user;
+
+
+ Revocation will take place on the next attempt to open
+ the file;
+
+
+ Revocation will take place within a fixed time. This
+ might mean that all open connections are re-evaluated
+ every x minutes.
+
+
+
+
+
+ provides for revocation of security
+ attributes to be enforced at some point in time.
+
+
+ managing the group of roles that can invoke revocation of
+ security attributes;
+
+
+ managing the lists of users, subjects, objects and other
+ resources for which revocation is possible;
+
+
+ managing the revocation rules.
+
+
+ Unsuccessful revocation of security attributes;
+
+
+ All attempts to revoke security attributes.
+
+
+ The TSF shall restrict the ability to revoke
+
+ list of security attributes
+
+ the PP/ST author should specify which security attributes
+ are to be revoked when a change is made to the associated
+ object/subject/user/other resource.
+ associated with the
+
+ users
+
+ subjects
+
+ objects
+ other additional resources
+ the PP/ST author should, if additional resources is
+ selected, specify whether the ability to revoke their
+ security attributes shall be provided by the
+ TSF.
+ the PP/ST author should specify whether the ability to
+ revoke security attributes from users, subjects, objects,
+ or any additional resources shall be provided by the
+ TSF.
+ under the control of the TSF to
+
+ the authorised identified roles
+
+ the PP/ST author should specify the roles that are allowed
+ to modify the functions in the TSF. The possible roles are
+ specified in ..
+
+
+ The TSF shall enforce the rules
+
+
+ specification of revocation rules
+
+
+
+ the PP/ST author should specify the revocation
+ rules. Examples of these rules could include:
+ ``prior to the next operation on the
+ associated resource'', or ``for
+ all new subject creations''.
+
+ .
+
+
+
+
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes.
+
+
+
+ This family addresses the capability to enforce time limits
+ for the validity of security attributes. This family can be
+ applied to specify expiration requirements for access
+ control attributes, identification and authentication
+ attributes, certificates (key certificates such as ANSI X509
+ for example), audit attributes, etc.
+
+
+
+
+
+
+
+
+
+ provides the capability for an
+ authorised user to specify an expiration time on specified
+ security attributes.
+
+
+ managing the list of security attributes for which
+ expiration is to be supported;
+
+
+ the actions to be taken if the expiration time has passed.
+
+
+ Specification of the expiration time for an attribute;
+
+
+ Action taken due to attribute expiration.
+
+
+ The TSF shall restrict the capability to specify an
+ expiration time for
+
+
+ list of security attributes for which expiration is to
+ be supported
+
+
+
+ the PP/ST author should provide the list of security
+ attributes for which expiration is to be supported. An
+ example of such an attribute might be a
+ user's security clearance.
+
+
+ to
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ allowed to modify the security attributes in the
+ TSF. The possible roles are specified in .
+
+ .
+
+
+ For each of these security attributes, the TSF shall be able
+ to
+
+
+ list of actions to be taken for each security attribute
+
+
+
+ the PP/ST author should provide a list of actions to
+ be taken for each security attribute when it
+ expires. An example might be that the
+ user's security clearance, when it expires,
+ is set to the lowest allowable clearance on the
+ TOE. If immediate revocation is desired by the PP/ST,
+ the action ``immediate
+ revocation'' should be specified.
+
+
+ after the expiration time for the indicated security
+ attribute has passed.
+
+
+
+ This family allows the specification of the management
+ functions to be provided by the TOE. Management functions
+ provide TSFI that allow administrators to define the
+ parameters that control the operation of security-related
+ aspects of the TOE, such as data protection attributes, TOE
+ protection attributes, audit attributes, and identification
+ and authentication attributes. Management functions also
+ include those functions performed by an operator to ensure
+ continued operation of the TOE, such as backup and
+ recovery. This family works in conjunction with the other
+ components in the class: the component in
+ this family calls out the management functions, and other
+ families in restrict the ability to use
+ these management functions.
+ This family allows the specification of the management
+ functions to be provided by the TOE. Each security
+ management function that is listed in fulfilling the
+ assignment is either security attribute management, TSF data
+ management, or security function management.
+ This component specifies the management functions to be
+ provided.
+ PP/ST authors should consult the ``Management'' sections
+ for components included in their PP/ST to provide a basis
+ for the management functions to be listed via this
+ component. requires that the TSF provide
+ specific management functions.
+ Use of the management functions.
+
+ The TSF shall be capable of performing the following
+ management functions:
+
+ list of management functions to be provided by
+ the TSF
+
+ the PP/ST author should specify the management
+ functions to be provided by the TSF, either security
+ attribute management, TSF data management, or security
+ function management..
+
+
+
+
+
+ This family is intended to control the assignment of
+ different roles to users. The capabilities of these roles
+ with respect to security management are described in the
+ other families in this class.
+
+
+
+ This family reduces the likelihood of damage resulting from
+ users abusing their authority by taking actions outside
+ their assigned functional responsibilities. It also
+ addresses the threat that inadequate mechanisms have been
+ provided to securely administer the TSF.
+
+ This family requires that information be maintained to
+ identify whether a user is authorised to use a particular
+ security-relevant administrative function.
+
+ Some management actions can be performed by users, others
+ only by designated people within the organisation. This
+ family allows the definition of different roles, such as
+ owner, auditor, administrator, daily-management.
+
+ The roles as used in this family are security related
+ roles. Each role can encompass an extensive set of
+ capabilities (e.g. root in UNIX), or can be a single right
+ (e.g. right to read a single object such as the
+ helpfile). This family defines the roles. The capabilities
+ of the role are defined in , and .
+
+ Some type of roles might be mutually exclusive. For example
+ the daily-management might be able to define and activate
+ users, but might not be able to remove users (which is
+ reserved for the administrator (role)). This class will
+ allow policies such as two-person control to be specified.
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise. Often the system distinguishes between
+ the owner of an entity, an administrator and other users.
+
+
+
+ specifies the roles with respect to
+ security that the TSF recognises.
+
+
+ managing the group of users that are part of a role.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles
+
+
+ the authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor and administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+
+
+
+
+
+
+
+
+ This component specifies the different roles that the TSF
+ should recognise, and conditions on how those roles could
+ be managed. Often the system distinguishes between the
+ owner of an entity, an administrator and other users.
+
+ The conditions on those roles specify the
+ interrelationship between the different roles, as well as
+ restrictions on when the role can be assumed by a user.
+
+
+
+ specifies that in addition to the
+ specification of the roles, there are rules that control
+ the relationship between the roles.
+
+
+ managing the group of users that are part of a role;
+
+
+ managing the conditions that the roles must satisfy.
+
+
+ modifications to the group of users that are part of a role;
+
+
+ unsuccessful attempts to use a role due to the given
+ conditions on the roles;
+
+
+ every use of the rights of a role.
+
+
+ The TSF shall maintain the roles:
+
+
+ authorised identified roles
+
+
+
+ the PP/ST author should specify the roles that are
+ recognised by the system. These are the roles that
+ users could occupy with respect to security. Examples
+ are: owner, auditor, administrator.
+
+ .
+
+
+ The TSF shall be able to associate users with roles.
+
+
+ The TSF shall ensure that the conditions
+
+
+ conditions for the different roles
+
+
+
+ the PP/ST author should specify the conditions that
+ govern role assignment. Examples of these conditions
+ are: ``an account cannot have both the
+ auditor and administrator role'' or
+ ``a user with the assistant role must also
+ have the owner role''.
+
+
+ are satisfied.
+
+
+
+
+
+
+
+
+
+ This component specifies that an explicit request must be
+ given to assume the specific role.
+
+
+
+ , requires that an explicit request
+ is given to the TSF to assume a role.
+
+
+ explicit request to assume a role.
+
+
+ The TSF shall require an explicit request to assume the
+ following roles:
+
+
+ the roles
+
+
+
+ the PP/ST author should specify the roles that require
+ an explicit request to be assumed. Examples are:
+ auditor and administrator.
+
+ .
+
+
+
+
+
+
+
+ This class contains privacy requirements. These requirements
+ provide a user protection against discovery and misuse of
+ identity by other users.
+
+
+
+ This class describes the requirements that could be levied to
+ satisfy the users' privacy needs, while still allowing
+ the system flexibility as far as possible to maintain
+ sufficient control over the operation of the system.
+
+ In the components of this class there is flexibility as to
+ whether or not authorised users are covered by the required
+ security functionality. For example, a PP/ST author might
+ consider it appropriate not to require protection of the privacy
+ of users against a suitably authorised user.
+
+ This class, together with other classes (such as those
+ concerned with audit, access control, trusted path, and
+ non-repudiation) provides the flexibility to specify the
+ desired privacy behaviour. On the other hand, the requirements
+ in this class might impose limitations on the use of the
+ components of other classes, such as or . For example, if
+ authorised users are not allowed to see the user identity
+ (e.g. Anonymity or Pseudonymity), it will obviously not be
+ possible to hold individual users accountable for any security
+ relevant actions they perform that are covered by the privacy
+ requirements. However, it may still be possible to include
+ audit requirements in a PP/ST, where the fact that a
+ particular security relevant event has occurred is more
+ important than knowing who was responsible for it.
+
+ Additional information is provided in the application notes
+ for class , where it is explained that the
+ definition of ``identity'' in the context of
+ auditing can also be an alias or other information that could
+ identify a user.
+
+ This class describes four families: Anonymity, Pseudonymity,
+ Unlinkability and Unobservability. Anonymity, Pseudonymity and
+ Unlinkability have a complex interrelationship. When choosing
+ a family, the choice should depend on the threats
+ identified. For some types of privacy threats, pseudonymity
+ will be more appropriate than anonymity (e.g. if there is a
+ requirement for auditing). In addition, some types of privacy
+ threats are best countered by a combination of components from
+ several families.
+
+ All families assume that a user does not explicitly perform an
+ action that discloses the user's own identity. For
+ example, the TSF is not expected to screen the user name in
+ electronic messages or databases.
+
+ All families in this class have components that can be scoped
+ through operations. These operations allow the PP/ST author to
+ state the cooperating users/subjects to which the TSF must be
+ resistant. An example of an instantiation of anonymity could
+ be: `` The TSF shall ensure that the users and/or
+ subjects are unable to determine the user identity bound to
+ the teleconsulting application''.
+
+ It is noted that the TSF should not only provide this
+ protection against individual users, but also against users
+ cooperating to obtain the information.
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing the user's identity. The
+ requirements for Anonymity provide protection of the user
+ identity. Anonymity is not intended to protect the subject
+ identity.
+
+
+
+ Anonymity ensures that a subject may use a resource or
+ service without disclosing its user identity.
+
+ The intention of this family is to specify that a user or
+ subject might take action without releasing its user
+ identity to others such as users, subjects, or objects. The
+ family provides the PP/ST author with a means to identify
+ the set of users that cannot see the identity of someone
+ performing certain actions.
+
+ Therefore if a subject, using anonymity, performs an action,
+ another subject will not be able to determine either the
+ identity or even a reference to the identity of the user
+ employing the subject. The focus of the anonymity is on the
+ protection of the users identity, not on the protection of
+ the subject identity; hence, the identity of the subject is
+ not protected from disclosure.
+
+ Although the identity of the subject is not released to
+ other subjects or users, the TSF is not explicitly
+ prohibited from obtaining the users identity. In case the
+ TSF is not allowed to know the identity of the user, could be invoked. In that case
+ the TSF should not request the user information.
+
+ The interpretation of ``determine'' should be
+ taken in the broadest sense of the word.
+
+ The component levelling distinguishes between the users and
+ an authorised user. An authorised user is often excluded
+ from the component, and therefore allowed to retrieve a
+ user's identity. However, there is no specific
+ requirement that an authorised user must be able to have the
+ capability to determine the user's identity. For
+ ultimate privacy the components would be used to say that no
+ user or authorised user can see the identity of anyone
+ performing any action.
+
+ Although some systems will provide anonymity for all
+ services that are provided, other systems provide anonymity
+ for certain subjects/operations. To provide this
+ flexibility, an operation is included where the scope of the
+ requirement is defined. If the PP/ST author wants to address
+ all subjects/operations, the words ``all subjects and
+ all operations'' could be provided.
+
+ Possible applications include the ability to make enquiries
+ of a confidential nature to public databases, respond to
+ electronic polls, or make anonymous payments or donations.
+
+ Examples of potential hostile users or subjects are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts (e.g. Trojan Horses) into
+ systems. All of these users can investigate usage patterns
+ (e.g. which users used which services) and misuse this
+ information.
+
+
+
+
+
+ This component ensures that the identity of a user is
+ protected from disclosure. There may be instances,
+ however, that a given authorised user can determine who
+ performed certain actions. This component gives the
+ flexibility to capture either a limited or total privacy
+ policy.
+
+
+
+ , requires that other users or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation.
+
+
+ The invocation of the anonymity mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+
+
+
+
+
+ This component is used to ensure that the TSF is not
+ allowed to know the identity of the user.
+
+
+
+ enhances the
+ requirements of by
+ ensuring that the TSF does not ask for the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the voting application''.
+
+ .
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the anonymity requirement, for
+ example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which the real user name of the subject should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to the real user name.
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without disclosing its user identity, but can still
+ be accountable for that use.
+
+
+
+ Pseudonymity ensures that a user may use a resource or
+ service without disclosing its identity, but can still be
+ accountable for that use. The user can be accountable by
+ directly being related to a reference (alias) held by the
+ TSF, or by providing an alias that will be used for
+ processing purposes, such as an account number.
+
+ In several respects, pseudonymity resembles anonymity. Both
+ pseudonymity and anonymity protect the identity of the user,
+ but in pseudonymity a reference to the user's
+ identity is maintained for accountability or other purposes.
+
+ The component does not
+ specify the requirements on the reference to the user's
+ identity. For the purpose of specifying requirements on this
+ reference two sets of requirements are presented: and .
+
+ A way to use the reference is by being able to obtain the
+ original user identity. For example, in a digital cash
+ environment it would be advantageous to be able to trace the
+ user's identity when a check has been issued multiple times
+ (i.e. fraud). In general, the user's identity needs to be
+ retrieved under specific conditions. The PP/ST author might
+ want to incorporate to
+ describe those services.
+
+ Another usage of the reference is as an alias for a
+ user. For example, a user who does not wish to be
+ identified, can provide an account to which the resource
+ utilisation should be charged. In such cases, the reference
+ to the user identity is an alias for the user, where other
+ users or subjects can use the alias for performing their
+ functions without ever obtaining the user's
+ identity (for example, statistical operations on use of the
+ system). In this case, the PP/ST author might wish to
+ incorporate to specify the rules to
+ which the reference must conform.
+
+ Using these constructs above, digital money can be created
+ using specifying that the user
+ identity will be protected and, if so specified in the
+ condition, that there be a requirement to trace the user
+ identity if the digital money is spent twice. When the user
+ is honest, the user identity is protected; if the user tries
+ to cheat, the user identity can be traced.
+
+ A different kind of system could be a digital credit card,
+ where the user will provide a pseudonym that indicates an
+ account from which the cash can be subtracted. In such
+ cases, for example, could be
+ used. This component would specify that the user identity
+ will be protected and, furthermore, that the same user will
+ only get assigned values for which he/she has provided money
+ (if so specified in the conditions).
+
+ It should be realised that the more stringent components
+ potentially cannot be combined with other requirements, such
+ as identification and authentication or audit. The
+ interpretation of ``determine the identity''
+ should be taken in the broadest sense of the word. The
+ information is not provided by the TSF during the operation,
+ nor can the entity determine the subject or the owner of the
+ subject that invoked the operation, nor will the TSF record
+ information, available to the users or subjects, which might
+ release the user identity in the future.
+
+ The intent is that the TSF not reveal any information that
+ would compromise the identity of the user, e.g. the identity
+ of subjects acting on the user's behalf. The
+ information that is considered to be sensitive depends on
+ the effort an attacker is capable of spending.
+
+ Possible applications include the ability to charge a caller
+ for premium rate telephone services without disclosing his
+ or her identity, or to be charged for the anonymous use of
+ an electronic payment system.
+
+ Examples of potential hostile users are providers, system
+ operators, communication partners and users, who smuggle
+ malicious parts (e.g. Trojan Horses) into systems. All of
+ these attackers can investigate which users used which
+ services and misuse this information. Additionally to
+ Anonymity services, Pseudonymity Services contains methods
+ for authorisation without identification, especially for
+ anonymous payment (``Digital Cash''). This
+ helps providers to obtain their payment in a secure way
+ while maintaining customer anonymity.
+
+
+
+
+
+ This component provides the user protection against
+ disclosure of identity to other users. The user will
+ remain accountable for its actions.
+
+
+
+ requires that a set of users and/or
+ subjects are unable to determine the identity of a user
+ bound to a subject or operation, but that this user is
+ still accountable for its actions.
+
+
+ The subject/user that requested resolution of the user
+ identity should be audited.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that under
+ specified conditions the user identity related to a
+ provided reference can be determined.
+
+ In the TSF shall provide an alias
+ instead of the user identity. When the specified
+ conditions are satisfied, the user identity to which the
+ alias belong can be determined. An example of such a
+ condition in an electronic cash environment is: ``
+ The TSF shall provide the notary a capability to determine
+ the user identity based on the provided alias only under
+ the conditions that a check has been issued
+ twice.''.
+
+
+
+ , requires the TSF to provide a
+ capability to determine the original user identity based
+ on a provided alias.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes that might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF, is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide
+
+
+ an authorised user
+
+
+
+
+ list of trusted subjects
+
+
+
+ the PP/ST author should identify the list of trusted
+ subjects that can obtain the real user name under a
+ specified condition, for example, a notary or
+ special authorised user.
+
+
+
+
+
+ the PP/ST author should select whether the authorised
+ user and/or trusted subjects can determine the real
+ user name.
+
+
+ a capability to determine the user identity based on the
+ provided alias only under the following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions under which the trusted subjects and
+ authorised user can determine the real user name based
+ on the provided reference. These conditions can be
+ conditions such as time of day, or they can be
+ administrative such as on a court order.
+
+ .
+
+
+
+
+
+
+
+ In this component, the TSF shall ensure that the provided
+ reference meets certain construction rules, and thereby
+ can be used in a secure way by potentially insecure
+ subjects.
+
+ If a user wants to use disk resources without disclosing
+ its identity, pseudonymity can be used. However, every
+ time the user accesses the system, the same alias must be
+ used. Such conditions can be specified in this component.
+
+
+
+ , requires the TSF to
+ follow certain construction rules for the alias to the user
+ identity.
+
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine the real user name bound to
+
+
+ list of subjects and/or operations and/or objects
+
+
+
+ the PP/ST author should identify the list of subjects
+ and/or operations and/or objects where the real user
+ name of the subject should be protected, for example,
+ ``the accessing of job offers''. Note
+ that ``objects'' includes any other
+ attributes which might enable another user or subject
+ to derive the actual identity of the user.
+
+ .
+
+
+ The TSF shall be able to provide
+
+
+ number of aliases
+
+
+
+ the PP/ST author should identify the (one or more)
+ number of aliases the TSF is able to provide.
+
+
+ aliases of the real user name to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ to whom the TSF is able to provide an alias.
+
+ .
+
+
+ The TSF shall
+
+
+ determine an alias for a user
+
+
+ accept the alias from the user
+
+
+
+ the PP/ST author should specify whether the user alias is
+ generated by the TSF, or supplied by the user. Only one of
+ these options may be chosen.
+
+
+ and verify that it conforms to the
+
+
+ alias metric
+
+
+
+ the PP/ST author should identify the metric to which
+ the TSF-generated or user-generated alias should
+ conform.
+
+ .
+
+
+ The TSF shall provide an alias to the real user name which
+ shall be identical to an alias provided previously under the
+ following
+
+
+ list of conditions
+
+
+
+ the PP/ST author should identify the list of
+ conditions that indicate when the used reference for
+ the real user name shall be identical and when it
+ shall be different, for example, ``when the
+ user logs on to the same host'' it will use a
+ unique alias.
+
+
+ otherwise the alias provided shall be unrelated to
+ previously provided aliases.
+
+
+
+
+
+
+ This family ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together.
+
+
+
+ Unlinkability ensures that a user may make multiple uses of
+ resources or services without others being able to link
+ these uses together. Unlinkability differs from pseudonymity
+ that, although in pseudonymity the user is also not known,
+ relations between different actions can be provided.
+
+ The requirements for unlinkability are intended to protect
+ the user identity against the use of profiling of the
+ operations. For example, when a telephone smart card is
+ employed with a unique number, the telephone company can
+ determine the behaviour of the user of this telephone
+ card. When a telephone profile of the users is known, the
+ card can be linked to a specific user. Hiding the
+ relationship between different invocations of a service or
+ access of a resource will prevent this kind of information
+ gathering.
+
+ As a result, a requirement for unlinkability could imply
+ that the subject and user identity of an operation must be
+ protected. Otherwise this information might be used to link
+ operations together.
+
+ Unlinkability requires that different operations cannot be
+ related. This relationship can take several forms. For
+ example, the user associated with the operation, or the
+ terminal which initiated the action, or the time the action
+ was executed. The PP/ST author can specify what kind of
+ relationships are present that must be countered.
+
+ Possible applications include the ability to make multiple
+ use of a pseudonym without creating a usage pattern that
+ might disclose the user's identity.
+
+ Examples for potential hostile subjects and users are
+ providers, system operators, communication partners and
+ users, who smuggle malicious parts, (e.g. Trojan Horses)
+ into systems, they do not operate but want to get
+ information about. All of these attackers can investigate
+ (e.g. which users used which services) and misuse this
+ information. Unlinkability protects users from linkages,
+ which could be drawn between several actions of a
+ customer. An example is a series of phone calls made by an
+ anonymous customer to different partners, where the
+ combination of the partner's identities might disclose the
+ identity of the customer.
+
+
+
+
+
+ This component ensures that users cannot link different
+ operations in the system and thereby obtain information.
+
+
+
+ , requires that users and/or subjects
+ are unable to determine whether the same user caused
+ certain specific operations.
+
+
+ the management of the unlinkability function.
+
+
+ The invocation of the unlinkability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ set of users and/or subjects
+
+
+
+ the PP/ST author should specify the set of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to determine whether
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations which should be subjected to the
+ unlinkability requirement, for example,
+ ``sending email''.
+
+
+
+
+ were caused by the same user
+
+
+ are related as follows
+
+
+ list of relations
+
+
+
+ the PP/ST author should identify the list of
+ relations which should be protected against, for
+ example, ``originate from the same
+ terminal''.
+
+
+
+
+
+ the PP/ST author should select the relationships that
+ should be obscured. The selection allows either the
+ user identity or an assignment of relations to be
+ specified.
+
+ .
+
+
+
+
+
+
+
+ This family ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+
+
+ Unobservability ensures that a user may use a resource or
+ service without others, especially third parties, being able
+ to observe that the resource or service is being used.
+
+ Unobservability approaches the user identity from a
+ different direction than the previous families Anonymity,
+ Pseudonymity and Unlinkability. In this case, the intent is
+ to hide the use of a resource or service, rather than to
+ hide the user's identity.
+
+ A number of techniques can be applied to implement
+ unobservability. Examples of techniques to provide
+ unobservability are:
+
+
+ Allocation of information impacting unobservability:
+ Unobservability relevant information (e.g. information
+ that describes that an operation occurred) can be
+ allocated in several locations within the TOE. The
+ information might be allocated to a single randomly
+ chosen part of the TOE such that an attacker does not
+ know which part of the TOE should be attacked. An
+ alternative system might distribute the information such
+ that no single part of the TOE has sufficient
+ information that, if circumvented, the privacy of the
+ user would be compromised. This technique is explicitly
+ addressed in .
+
+
+ Broadcast: When information is broadcast (e.g. ethernet,
+ radio), users cannot determine who actually received and
+ used that information. This technique is especially
+ useful when information should reach receivers which
+ have to fear a stigma for being interested in that
+ information (e.g. sensitive medical information).
+
+
+ Cryptographic protection and message padding: People
+ observing a message stream might obtain information from
+ the fact that a message is transferred and from
+ attributes on that message. By traffic padding, message
+ padding and encrypting the message stream, the
+ transmission of a message and its attributes can be
+ protected.
+
+
+
+ Sometimes, users should not see the use of a resource, but an
+ authorised user must be allowed to see the use of the resource
+ in order to perform his duties. In such cases, the could be used, which provides the
+ capability for one or more authorised users to see the
+ usage.
+
+ This family makes use of the concept ``parts of the
+ TOE''. This is considered any part of the TOE that is either
+ physically or logically separated from other parts of the
+ TOE.
+
+ Unobservability of communications may be an important factor
+ in many areas, such as the enforcement of constitutional
+ rights, organisational policies, or in defence related
+ applications.
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by unauthorised users.
+
+
+
+ , requires that users and/or
+ subjects cannot determine whether an operation is being
+ performed.
+
+
+ the management of the behaviour of the unobservability
+ function.
+
+
+ The invocation of the unobservability mechanism.
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users and/or
+ subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual user
+ or subject, but must protect with respect to cooperating
+ users and/or subjects. A set of users, for example,
+ could be a group of users which can operate under the
+ same role or can all use the same process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+
+
+
+
+
+
+ This component requires that the use of a function or
+ resource cannot be observed by specified users or
+ subjects. Furthermore this component specifies that
+ information related to the privacy of the user is
+ distributed within the TOE such that attackers might not
+ know which part of the TOE to target, or they need to
+ attack multiple parts of the TOE.
+
+ An example of the use of this component is the use of a
+ randomly allocated node to provide a function. In such a
+ case the component might require that the privacy related
+ information shall only be available to one identified part
+ of the TOE, and will not be communicated outside this part
+ of the TOE.
+
+ A more complex example can be found in some
+ ``voting algorithms''. Several parts of the
+ TOE will be involved in the service, but no individual
+ part of the TOE will be able to violate the policy. So a
+ person may cast a vote (or not) without the TOE being able
+ to determine whether a vote has been cast and what the
+ vote happened to be (unless the vote was unanimous).
+
+
+
+
+ , requires that the TSF
+ provide specific mechanisms to avoid the concentration of
+ privacy related information within the TOE. Such
+ concentrations might impact unobservability if a security
+ compromise occurs.
+
+
+
+
+
+ The TSF shall ensure that
+
+
+ list of users and/or subjects
+
+
+
+ the PP/ST author should specify the list of users
+ and/or subjects against which the TSF must provide
+ protection. For example, even if the PP/ST author
+ specifies a single user or subject role, the TSF must
+ not only provide protection against each individual
+ user or subject, but must protect with respect to
+ cooperating users and/or subjects. A set of users, for
+ example, could be a group of users which can operate
+ under the same role or can all use the same
+ process(es).
+
+
+ are unable to observe the operation
+
+
+ list of operations
+
+
+
+ the PP/ST author should identify the list of
+ operations that are subjected to the unobservability
+ requirement. Other users/subjects will then not be
+ able to observe the operations on a covered object in
+ the specified list (e.g. reading and writing to the
+ object).
+
+
+ on
+
+
+ list of objects
+
+
+
+ the PP/ST author should identify the list of objects
+ which are covered by the unobservability
+ requirement. An example could be a specific mail
+ server or ftp site.
+
+
+ by
+
+
+ list of protected users and/or subjects
+
+
+
+ the PP/ST author should specify the set of protected
+ users and/or subjects whose unobservability
+ information will be protected. An example could be:
+ ``users accessing the system through the
+ internet''.
+
+ .
+
+
+ The TSF shall allocate the
+
+
+ unobservability related information
+
+
+
+ the PP/ST author should identify which privacy related
+ information should be distributed in a controlled
+ manner. Examples of this information could be: IP
+ address of subject, IP address of object, time, used
+ encryption keys.
+
+
+ among different parts of the TOE such that the following
+ conditions hold during the lifetime of the information:
+
+
+ list of conditions
+
+
+
+ the PP/ST author should specify the conditions to
+ which the dissemination of the information should
+ adhere. These conditions should be maintained
+ throughout the lifetime of the privacy related
+ information of each instance. Examples of these
+ conditions could be: ``the information shall
+ only be present at a single separated part of the TOE
+ and shall not be communicated outside this part of the
+ TOE.'', ``the information shall only
+ reside in a single separated part of the TOE, but
+ shall be moved to another part of the TOE
+ periodically'', ``the information shall
+ be distributed between the different parts of the TOE
+ such that compromise of any 5 separated parts of the
+ TOE will not compromise the security policy''.
+
+ .
+
+
+
+
+
+
+
+
+
+ This component is used to require that the TSF does not
+ try to obtain information that might compromise
+ unobservability when provided specific services. Therefore
+ the TSF will not solicit (i.e. try to obtain from other
+ entities) any information that might be used to compromise
+ unobservability.
+
+
+
+ , requires that the TSF
+ does not try to obtain privacy related information that
+ might be used to compromise unobservability.
+
+
+ The TSF shall provide
+
+
+ list of services
+
+
+
+ the PP/ST author should identify the list of services
+ which are subject to the unobservability requirement,
+ for example, ``the accessing of job
+ descriptions''.
+
+
+ to
+
+
+ list of subjects
+
+
+
+ the PP/ST author should identify the list of subjects
+ from which privacy related information should be
+ protected when the specified services are provided.
+
+
+ without soliciting any reference to
+
+
+ privacy related information
+
+
+
+ the PP/ST author should specify the privacy related
+ information that will be protected from the specified
+ subjects. Examples include the identity of the subject
+ that used a service and the quantity of a service that
+ has been used such as memory resource
+ utilisation.
+
+ .
+
+
+
+
+
+
+ This component is used to require that there will be one
+ or more authorised users with the rights to view the
+ resource utilisation. Without this component, this review
+ is allowed, but not mandated.
+
+
+
+ , requires the TSF to
+ provide one or more authorised users with a capability to
+ observe the usage of resources and/or services.
+
+
+ the list of authorised users that are capable of determining
+ the occurrence of operations.
+
+
+ The observation of the use of a resource or service by a
+ user or subject.
+
+
+ The TSF shall provide
+
+
+ set of authorised users
+
+
+
+ the PP/ST author should specify the set of authorised
+ users for which the TSF must provide the capability to
+ observe the resource utilisation. A set of authorised
+ users, for example, could be a group of authorised users
+ which can operate under the same role or can all use the
+ same process(es).
+
+
+ with the capability to observe the usage of
+
+
+ list of resources and/or services
+
+
+
+ the PP/ST author should specify the set of resources
+ and/or services that the authorised user must be able
+ to observe.
+
+ .
+
+
+
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the integrity of TSF data. In some
+ sense, families in this class may appear to duplicate
+ components in the class; they may
+ even be implemented using the same mechanisms. However, focuses on user data protection, while
+ focuses on TSF data
+ protection. In fact, components from the class are necessary to provide requirements that
+ the SFPs in the TOE cannot be tampered with or
+ bypassed.
+
+ From the point of view of this class, regarding to the
+ TSF there are three significant elements:
+
+ The TSF's implementation, which executes and implements the
+ mechanisms that enforce the SFRs.
+
+ The TSF's data, which are the administrative databases that guide the
+ enforcement of the SFRs.
+
+ The external entities that the TSF may interact with in order to
+ enforce the SFRs.
+
+
+
+
+ This class contains families of functional requirements that
+ relate to the integrity and management of the mechanisms that
+ constitute the TSF and to the
+ integrity of TSF data. In some sense, families in this class may
+ appear to duplicate components in the
+ class; they may even be implemented using the
+ same mechanisms. However, focuses on user
+ data protection, while focuses on TSF data
+ protection. In fact, components from the
+ class are necessary to provide requirements that the SFPs in
+ the TOE cannot be tampered with or bypassed.
+
+ From the point of view of this class, regarding to the
+ TSF there are three significant elements:
+
+ The TSF's implementation, which executes and implements the
+ mechanisms that enforce the SFRs.
+
+ The TSF's data, which are the administrative databases that guide the
+ enforcement of the SFRs.
+
+ The external entities that the TSF may interact with in order to
+ enforce the SFRs.
+
+
+ All of the families in the class can be
+ related to these areas, and fall into the following groupings:
+ , which provides an authorised user
+ with the ability to detect external attacks on the parts
+ of the TOE that comprise the TSF.
+ and ,
+ which provide an authorised user with the ability to verify the correct
+ operation of the external entities interacting with the TSF to enforce
+ the SFRs, and the integrity of the TSF data and TSF itself.
+ , , and , which address the behaviour of the TSF
+ when failure occurs and immediately after.
+ , , ,
+ which address the protection and availability of TSF data between the TSF and another trusted IT product.
+ , which addresses protection of TSF
+ data when it is transmitted between physically-separated
+ parts of the TOE.
+ , which addresses the replay of
+ various types of information and/or operations.
+ , which addresses the synchronisation
+ of states, based upon TSF data, between different parts of
+ a distributed TSF.
+ , which addresses reliable timing.
+ , which addresses the consistency of
+ TSF data shared between the TSF and another trusted IT product.
+
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TOE will always enforce
+ its SFRs in the event of identified categories of
+ failures in the TSF.
+
+
+
+ The requirements of this family ensure that the TOE will
+ always enforce its SFRs in the event of certain
+ types of failures in the TSF.
+
+
+
+
+
+ The term ``secure state'' refers to a state in which the
+ TSF data are consistent and the TSF continues correct
+ enforcement of the SFRs.
+
+ Although it is desirable to audit situations in which
+ failure with preservation of secure state occurs, it is
+ not possible in all situations. The PP/ST author should
+ specify those situations in which audit is desired and
+ feasible.
+
+ Failures in the TSF may include
+ ``hard'' failures, which indicate an
+ equipment malfunction and which may require maintenance,
+ service or repair of the TSF. Failures in the TSF may also
+ include recoverable ``soft'' failures,
+ which may only require initialisation or resetting of the
+ TSF.
+
+
+
+ This family consists of only one component, , which requires that the TSF preserve a
+ secure state in the face of the identified failures.
+
+
+ Failure of the TSF.
+
+
+ The TSF shall preserve a secure state when the following
+ types of failures occur:
+
+
+ list of types of failures in the TSF
+
+
+
+ the PP/ST author should list the types of failures in
+ the TSF for which the TSF should ``fail
+ secure,'' that is, should preserve a secure
+ state and continue to correctly enforce the SFRs.
+
+ .
+
+
+
+
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and another
+ trusted IT product. This data could, for example, be TSF
+ critical data such as passwords, keys, audit data, or TSF
+ executable code.
+
+
+
+ This family defines the rules for the prevention of loss of
+ availability of TSF data moving between the TSF and another
+ trusted IT product. This data could be TSF critical data
+ such as passwords, keys, audit data, or TSF executable code.
+
+ This family is used in a distributed context where the TSF
+ is providing TSF data to another trusted IT product. The
+ TSF can only take the measures at its site and cannot be
+ held responsible for the TSF at the other trusted IT
+ product.
+
+ If there are different availability metrics for different
+ types of TSF data, then this component should be iterated
+ for each unique pairing of metrics and types of TSF data.
+
+
+
+
+
+ This family consists of only one component, .
+ This component requires that the TSF ensure, to an identified degree of probability, the
+ availability of TSF data provided to another trusted IT product.
+
+
+ management of the list of types of TSF data that must be
+ available to another trusted IT product.
+
+
+ the absence of TSF data when required by a TOE.
+
+
+ The TSF shall ensure the availability of
+
+ list of types of TSF data
+
+ the PP/ST author should specify the types of TSF data
+ that are subject to the availability metric.
+ provided to another trusted IT product within
+
+ a defined availability metric
+
+ the PP/ST should specify the availability metric for
+ the applicable TSF data.
+ given the following conditions
+
+ conditions to ensure availability
+
+ the PP/ST author should specify the conditions under
+ which availability must be ensured. For example:
+ there must be a connection between the TOE and
+ another trusted IT product..
+
+
+
+
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data during transmission
+ between the TSF and another trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection from
+ unauthorised disclosure of TSF data moving between the TSF
+ and another trusted IT product. Examples of this data are
+ TSF critical data such as passwords, keys, audit data, or
+ TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is providing TSF data to another trusted IT
+ product. The TSF can only take the measures at its site and
+ cannot be held responsible for the behaviour of the other
+ trusted IT product.
+
+
+
+
+
+ Confidentiality of TSF Data during transmission is
+ necessary to protect such information from
+ disclosure. Some possible implementations that could
+ provide confidentiality include the use of cryptographic
+ algorithms as well as spread spectrum techniques.
+
+
+
+ This family consists of only one component, ,
+ which requires that the TSF ensure that data transmitted between the TSF and another trusted IT
+ product is protected from disclosure while in transit.
+
+
+ The TSF shall protect all TSF data transmitted from the TSF
+ to another trusted IT product from unauthorised disclosure
+ during transmission.
+
+
+
+
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and another trusted IT product. This data
+ could, for example, be TSF critical data such as passwords,
+ keys, audit data, or TSF executable code.
+
+
+
+ This family defines the rules for the protection, from
+ unauthorised modification, of TSF data during transmission
+ between the TSF and another trusted IT product. Examples of
+ this data are TSF critical data such as passwords, keys,
+ audit data, or TSF executable code.
+
+ This family is used in a distributed context where
+ the TSF is exchanging TSF data with another trusted IT
+ product. Note that a requirement that addresses
+ modification, detection, or recovery at another trusted
+ IT product cannot be specified, as the mechanisms that
+ another trusted IT product will use to protect its data
+ cannot be determined in advance. For this reason, these
+ requirements are expressed in terms of the ``TSF
+ providing a capability'' which another trusted
+ IT product can use.
+
+
+
+
+
+ This component should be used in situations where it is
+ sufficient to detect when data have been modified. An
+ example of such a situation is one in which another
+ trusted IT product can request the TOE's TSF to
+ retransmit data when modification has been detected, or
+ respond to such types of request.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a weak checksum
+ and parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches.
+
+
+ , provides the ability to detect
+ modification of TSF data during transmission between the
+ TSF and another trusted IT product, under the assumption
+ that another trusted IT product is cognisant of the mechanism used.
+
+
+ the detection of modification of transmitted TSF data.
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and
+ another trusted IT product within the following metric:
+
+ a defined modification metric
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection..
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and another
+ trusted IT product and perform
+
+ action to be taken
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+ if modifications are detected.
+
+
+
+
+
+
+
+ This component should be used in situations where it is
+ necessary to detect or correct modifications of TSF
+ critical data.
+
+ The desired strength of modification detection is based
+ upon a specified modification metric that is a function of
+ the algorithm used, which may range from a checksum and
+ parity mechanisms that may fail to detect multiple bit
+ changes, to more complicated cryptographic checksum
+ approaches. The metric that needs to be defined can either
+ refer to the attacks it will resist (e.g. only 1 in a 1000
+ random messages will be accepted), or to mechanisms that
+ are well known in the public literature (e.g. the strength
+ must be conformant to the strength offered by Secure Hash
+ Algorithm).
+
+ The approach taken to correct modification might be done
+ through some form of error correcting checksum.
+
+
+
+ Some possible means of satisfying this requirement
+ involves the use of cryptographic functions or some form
+ of checksum.
+
+
+ , provides the ability for
+ another trusted IT product not only to detect modification,
+ but to correct modified TSF data under the assumption that
+ another trusted IT product is cognisant of the mechanism used.
+
+
+ management of the types of TSF data that the TSF should try
+ to correct if modified in transit;
+
+
+ management of the types of action that the TSF could take if
+ TSF data is modified in transit.
+
+
+ the detection of modification of transmitted TSF data;
+
+
+ the action taken upon detection of modification of
+ transmitted TSF data.
+
+
+ the use of the correction mechanism.
+
+
+ The TSF shall provide the capability to detect modification
+ of all TSF data during transmission between the TSF and
+ another trusted IT product within the following metric:
+
+ a defined modification metric
+
+ the PP/ST should specify the modification metric that
+ the detection mechanism must satisfy. This
+ modification metric shall specify the desired strength
+ of the modification detection..
+
+
+ The TSF shall provide the capability to verify the integrity
+ of all TSF data transmitted between the TSF and another
+ trusted IT product and perform
+
+ action to be taken
+
+ the PP/ST should specify the actions to be taken if a
+ modification of TSF data has been detected. An example
+ of an action is: ``ignore the TSF data, and
+ request the originating trusted product to send the
+ TSF data again''.
+ if modifications are detected.
+
+
+ The TSF shall provide the capability to correct
+
+ type of modification
+
+ the PP/ST author should define the types of
+ modification from which the TSF should be capable of
+ recovering.
+ of all TSF data transmitted between the TSF and another
+ trusted IT product.
+
+
+
+
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+
+
+ This family provides requirements that address protection of
+ TSF data when it is transferred between separate parts of a
+ TOE across an internal channel.
+
+ The determination of the degree of separation (i.e.,
+ physical or logical) that would make application of this
+ family useful depends on the intended environment of use. In
+ a hostile environment, there may be risks arising from
+ transfers between parts of the TOE separated by only a
+ system bus or an inter-process communications channel. In
+ more benign environments, the transfers may be across more
+ traditional network media.
+
+
+
+ One practical mechanism available to a TSF to provide this
+ protection is cryptographically-based.
+
+
+
+
+
+ , requires that TSF data be
+ protected when transmitted between separate parts of the
+ TOE.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+ One of the ways to achieve separation of TSF data based on
+ SFP-relevant attributes is through the use of separate
+ logical or physical channels.
+
+
+
+ , requires that the TSF separate
+ user data from TSF data during transmission.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the separation mechanism.
+
+
+ The TSF shall protect TSF data from
+
+
+ disclosure
+
+
+ modification
+
+
+
+ the PP/ST author should specify the desired type of
+ protection to be provided from the choices:
+ disclosure, modification.
+
+
+ when it is transmitted between separate parts of the TOE.
+
+
+ The TSF shall separate user data from TSF data when such
+ data is transmitted between separate parts of the TOE.
+
+
+
+
+
+
+
+
+
+ , requires that the TSF data
+ transmitted between separate parts of the TOE is monitored
+ for identified integrity errors.
+
+
+ management of the types of modification against which the
+ TSF should protect;
+
+
+ management of the mechanism used to provide the protection
+ of the data in transit between different parts of the TSF;
+
+
+ management of the types of modification of TSF data the TSF
+ should try to detect;
+
+
+ management of the action>s that will be taken.
+
+
+ the detection of modification of TSF data;
+
+
+ the action taken following detection of an integrity error.
+
+
+ The TSF shall be able to detect
+
+
+ modification of data
+
+
+ substitution of data
+
+
+ re-ordering of data
+
+
+ deletion of data
+
+
+
+
+ other integrity errors
+
+
+
+ if the PP/ST author chooses the latter selection
+ noted in the preceding paragraph, then the author
+ should also specify what those other integrity
+ errors are that the TSF should be capable of
+ detecting.
+
+
+
+
+
+ the PP/ST author should specify the desired type of
+ modification that the TSF shall be able to detect. The
+ PP/ST author should select from: modification of data,
+ substitution of data, re-ordering of data, deletion of
+ data, or any other integrity errors.
+
+
+ for TSF data transmitted between separate parts of the TOE.
+
+
+ Upon detection of a data integrity error, the TSF shall take
+ the following actions:
+
+
+ specify the action to be taken
+
+
+
+ the PP/ST author should specify the action to be taken
+ when an integrity error is identified.
+
+ .
+
+
+
+
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements of components in this family ensure that
+ the TSF is protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is enforced. Without these
+ components, the protection functions of a TSF lose their
+ effectiveness in environments where physical damage cannot
+ be prevented. This family also provides requirements
+ regarding how the TSF shall respond to physical tampering
+ attempts.
+
+
+
+ TSF physical protection components refer to restrictions on
+ unauthorised physical access to the TSF, and to the
+ deterrence of, and resistance to, unauthorised physical
+ modification, or substitution of the TSF.
+
+ The requirements in this family ensure that the TSF is
+ protected from physical tampering and
+ interference. Satisfying the requirements of these
+ components results in the TSF being packaged and used in
+ such a manner that physical tampering is detectable, or
+ resistance to physical tampering is measurable based on
+ defined work factors. Without these components, the
+ protection functions of a TSF lose their effectiveness in
+ environments where physical damage cannot be prevented. This
+ component also provides requirements regarding how the TSF
+ must respond to physical tampering attempts.
+
+ Examples of physical tampering scenarios include mechanical
+ attack, radiation, changing the temperature.
+
+ It is acceptable for the functions that are available to an
+ authorised user for detecting physical tampering to be
+ available only in an off-line or maintenance mode. Controls
+ should be in place to limit access during such modes to
+ authorised users. As the TSF may not be
+ ``operational'' during those modes, it
+ may not be able to provide normal enforcement for authorised
+ user access. The physical implementation of a TOE might
+ consist of several structures: for example an outer
+ shielding, cards, and chips. This set of
+ ``elements'' as a whole must protect
+ (protect, notify and resist) the TSF from physical
+ tampering. This does not mean that all devices must provide
+ these features, but the complete physical construct as a
+ whole should.
+
+ Although there is only minimal auditing associating with
+ these components, this is solely because there is the
+ potential that the detection and alarm mechanisms may be
+ implemented completely in hardware, below the level of
+ interaction with an audit subsystem (for example, a
+ hardware-based detection system based on breaking a circuit
+ and lighting a light emitting diode (LED) if the circuit is
+ broken when a button is pressed by the authorised
+ user). Nevertheless, a PP/ST author may determine that for a
+ particular anticipated threat environment, there is a need
+ to audit physical tampering. If this is the case, the PP/ST
+ author should include appropriate requirements in the list
+ of audit events. Note that inclusion of these requirements
+ may have implications on the hardware design and its
+ interface to the software.
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are not
+ countered by procedural methods. It addresses the threat of
+ undetected physical tampering with the TSF. Typically, an
+ authorised user would be given the function to verify whether
+ tampering took place. As written, this component simply provides
+ a TSF capability to detect tampering. Specification of
+ management functions in should be
+ considered to specify who can make use of that capability, and
+ how they can make use of that capability. If this is done by non-IT mechanisms
+ (e.g. physical inspection) management functions are not required.
+
+
+
+ , provides for features that
+ indicate when a TSF device or TSF element is subject to
+ tampering. However, notification of tampering is not
+ automatic; an authorised user must invoke a security
+ administrative function or perform manual inspection to
+ determining if tampering has occurred.
+
+ management of the user or role that determines whether physical
+ tampering has occurred.
+
+
+ if detection by IT means, detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether
+ physical tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+
+
+
+
+
+
+
+ should be used when threats from
+ unauthorised physical tampering with parts of the TOE are
+ not countered by procedural methods, and it is required
+ that designated individuals be notified of physical
+ tampering. It addresses the threat that physical tampering
+ with TSF elements, although detected, may not be noticed.
+ Specification of management functions in FMT_MOF.1 Management of
+ security functions behaviour should be considered to specify who
+ can make use of that capability, and how they can make use of that capability.
+
+
+
+ , provides for automatic
+ notification of tampering for an identified subset of
+ physical penetrations.
+
+
+ management of the user or role that gets informed about
+ intrusions;
+
+
+ management of the list of devices that should inform the
+ indicated user or role about the intrusion.
+
+
+ detection of intrusion.
+
+
+ The TSF shall provide unambiguous detection of physical
+ tampering that might compromise the TSF.
+
+
+ The TSF shall provide the capability to determine whether physical
+ tampering with the TSF's devices or
+ TSF's elements has occurred.
+
+
+ For
+
+
+ list of TSF devices/elements for which active detection
+ is required
+
+
+
+ the PP/ST author should provide a list of TSF
+ devices/elements for which active detection of
+ physical tampering is required.
+
+ , the TSF shall monitor the devices and
+ elements and notify
+
+
+ a designated user or role
+
+
+
+ the PP/ST author should designate a user or role that
+ is to be notified when tampering is detected. The type
+ of user or role may vary depending on the particular
+ security administration component (from the family) included in the PP/ST.
+
+
+ when physical tampering with the
+ TSF's devices or TSF's elements has
+ occurred.
+
+
+
+
+
+
+ For some forms of tampering, it is necessary that the TSF
+ not only detects the tampering, but actually resists it or
+ delays the attacker.
+
+ This component should be used when TSF devices and TSF
+ elements are expected to operate in an environment where a
+ physical tampering (e.g. observation, analysis, or
+ modification) of the internals of a TSF device or TSF
+ element itself is a threat.
+
+
+
+ , provides for features that prevent
+ or resist physical tampering with TSF devices and TSF
+ elements.
+
+
+ management of the automatic responses to physical tampering.
+
+
+ The TSF shall resist
+
+
+ physical tampering scenarios
+
+
+
+ the PP/ST author should specify tampering scenarios to
+ a list of TSF devices/elements for which the TSF
+ should resist physical tampering. This list may be
+ applied to a defined subset of the TSF physical
+ devices and elements based on considerations such as
+ technology limitations and relative physical exposure
+ of the device. Such subsetting should be clearly
+ defined and justified. Furthermore, the TSF should
+ automatically respond to physical tampering. The
+ automatic response should be such that the policy of
+ the device is preserved; for example, with a
+ confidentiality policy, it would be acceptable to
+ physically disable the device so that the protected
+ information may not be retrieved.
+
+
+ to the
+
+
+ list of TSF devices/elements
+
+
+
+ the PP/ST author should specify the list of TSF
+ devices/elements for which the TSF should resist
+ physical tampering in the scenarios that have been
+ identified.
+
+
+ by responding automatically such that the SFRs are always enforced.
+
+
+
+
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+
+
+ The requirements of this family ensure that the TSF can
+ determine that the TOE is started-up without protection
+ compromise and can recover without protection compromise
+ after discontinuity of operations. This family is important
+ because the start-up state of the TSF determines the
+ protection of subsequent states.
+
+ Recovery components reconstruct the TSF secure states, or
+ prevent transitions to insecure states, as a direct response
+ to occurrences of expected failures, discontinuity of
+ operation or start-up. Failures that must be generally
+ anticipated include the following:
+
+
+ Unmaskable action failures that always result in a
+ system crash (e.g. persistent inconsistency of critical
+ system tables, uncontrolled transfers within the TSF
+ code caused by transient failures of hardware or
+ firmware, power failures, processor failures,
+ communication failures).
+
+
+ Media failures causing part or all of the media
+ representing the TSF objects to become inaccessible or
+ corrupt (e.g. parity errors, disk head crash, persistent
+ read/write failure caused by misaligned disk heads,
+ worn-out magnetic coating, dust on the disk surface).
+
+
+ Discontinuity of operation caused by erroneous
+ administrative action or lack of timely administrative
+ action (e.g. unexpected shutdowns by turning off power,
+ ignoring the exhaustion of critical resources,
+ inadequate installed configuration).
+
+
+
+ Note that recovery may be from either a complete or partial
+ failure scenario. Although a complete failure might occur in
+ a monolithic operating system, it is less likely to occur in
+ a distributed environment. In such environments, subsystems
+ may fail, but other portions remain operational. Further,
+ critical components may be redundant (disk mirroring,
+ alternative routes), and checkpoints may be available. Thus,
+ recovery is expressed in terms of recovery to a secure
+ state.
+ There are different interactions between
+ and components to be considered when
+ selecting :
+
+ The need for trusted recovery may be indicated through
+ the results of TSF self-testing, where the results of
+ the self-tests indicate that the TSF is in an insecure
+ state and return to a secure state or entrance in
+ maintenance mode is required.
+
+ A failure, as discussed above, may be identified by an
+ administrator. Either the administrator may perform
+ the actions to return the TOE to a secure state and
+ then invoke TSF self-tests to confirm that the secure
+ state has been achieved. Or, the TSF self-tests may be
+ invoked to complete the recovery process.
+
+ A combination of a. and b. above, where the need for
+ trusted recovery is indicated through the results of
+ TSF self-testing, the administrator performs the
+ actions to return the TOE to a secure state and then
+ invokes TSF self-tests to confirm that the secure
+ state has been achieved.
+
+ Self tests detect a failure/service discontinuity,
+ then either automated recovery or entrance to a
+ maintenance mode.
+
+
+ This family identifies a maintenance mode. In this
+ maintenance mode normal operation might be impossible or
+ severely restricted, as otherwise insecure situations might
+ occur. Typically, only authorised users should be allowed
+ access to this mode but the real details of who can access
+ this mode is a function of . If does not put any controls on who can access this
+ mode, then it may be acceptable to allow any user to restore
+ the system if the TOE enters such a state. However, in
+ practice, this is probably not desirable as the user
+ restoring the system has an opportunity to configure the TOE
+ in such a way as to violate the SFRs.
+
+ Mechanisms designed to detect exceptional conditions during
+ operation fall under , , and other areas that address the
+ concept of ``Software Safety.'' It is likely that the use of
+ one of these families will be required to support the adoption
+ of . This is to ensure that
+ the TOE will be able to detect when recovery is
+ required.
+
+ Throughout this family, the phrase ``secure state'' is
+ used. This refers to some state in which the TOE has
+ consistent TSF data and a TSF that can correctly enforce the
+ policy. This state may be the initial ``boot'' of a clean
+ system, or it might be some checkpointed state.
+
+ Following recovery, it may be necessary to confirm that the
+ secure state has been achieved through self-testing of the
+ TSF. However, if the recovery is performed in a manner such
+ that only a secure state can be achieved, else recovery
+ fails, then the dependency to the TSF
+ self-test component may be argued away.
+
+
+
+
+
+
+
+
+ In the hierarchy of the trusted recovery family, recovery
+ that requires only manual intervention is the least
+ desirable, for it precludes the use of the system in an
+ unattended fashion.
+
+ This component is intended for use in TOEs that do not
+ require unattended recovery to a secure state. The
+ requirements of this component reduce the threat of
+ protection compromise resulting from an attended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+
+
+ , allows a TOE to only provide
+ mechanisms that involve human intervention to return to a
+ secure state.
+
+
+ management of who can access the restore capability within
+ the maintenance mode.
+
+
+ the fact that a failure or service discontinuity occurred;
+
+
+ resumption of the regular operation;
+
+
+ type of failure or service discontinuity.
+
+
+ After
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion, any failure or discontinuity)
+ following which the TOE will enter a maintenance mode. the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, as it allows the machine to operate in an
+ unattended fashion.
+
+ The component extends the feature
+ coverage of by requiring that there
+ be at least one automated method of recovery from failure
+ or service discontinuity. It addresses the threat of
+ protection compromise resulting from an unattended TOE
+ returning to an insecure state after recovery from a
+ failure or other discontinuity.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ For , it is the responsibility of
+ the developer of the TSF to determine the set of
+ recoverable failures and service discontinuities.
+
+ It is assumed that the robustness of the automated
+ recovery mechanisms will be verified.
+
+
+
+ , provides, for at least one type of
+ service discontinuity, recovery to a secure state without
+ human intervention; recovery for other discontinuities may
+ require human intervention.
+
+
+ management of who can access the restore capability within
+ the maintenance mode;
+
+
+ management of the list of failures/service discontinuities
+ that will be handled through the automatic procedures.
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode. is not possible, the TSF shall enter a
+ maintenance mode where the ability to return to a secure state
+ is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+
+
+
+
+
+
+
+
+ Automated recovery is considered to be more useful than
+ manual recovery, but it runs the risk of losing a
+ substantial number of objects. Preventing undue loss of
+ objects provides additional utility to the recovery
+ effort.
+
+ The component extends the feature
+ coverage of by requiring that there
+ not be undue loss of TSF data or objects under the control
+ of the TSF. At , the automated recovery
+ mechanisms could conceivably recover by deleting all
+ objects and returning the TSF to a known secure
+ state. This type of drastic automated recovery is
+ precluded in .
+
+ This component addresses the threat of protection
+ compromise resulting from an unattended TOE returning to
+ an insecure state after recovery from a failure or other
+ discontinuity with a large loss of TSF data or objects
+ under the control of the TSF.
+
+
+
+ It is acceptable for the functions that are available to
+ an authorised user for trusted recovery to be available
+ only in a maintenance mode. Controls should be in place to
+ limit access during maintenance to authorised users.
+
+ It is assumed that the evaluators will verify the
+ robustness of the automated recovery mechanisms.
+
+
+
+ , also provides for automated
+ recovery, but strengthens the requirements by disallowing
+ undue loss of protected objects.
+
+
+
+
+
+ When automated recovery from
+
+ list of failures/service discontinuities
+
+ the PP/ST author should specify the list of failures or
+ service discontinuities (e.g. power failure, audit
+ storage exhaustion) following which the TOE will need to
+ enter a maintenance mode.
+ is not possible, the TSF shall enter a maintenance mode where
+ the ability to return to a secure state is provided.
+
+
+ For
+
+
+ list of failures/service discontinuities
+
+
+
+ the PP/ST author should specify the list of failures
+ or other discontinuities for which automated recovery
+ must be possible.
+
+ , the TSF shall ensure the return of the TOE
+ to a secure state using automated procedures.
+
+
+ The functions provided by the TSF to recover from failure or
+ service discontinuity shall ensure that the secure initial
+ state is restored without exceeding
+
+
+ quantification
+
+
+
+ the PP/ST author should provide a quantification for
+ the amount of loss of TSF data or objects that is
+ acceptable.
+
+
+ for loss of TSF data or objects under the control of the TSF.
+
+
+ The TSF shall provide the capability to determine the
+ objects that were or were not capable of being recovered.
+
+
+
+
+
+
+ Function recovery requires that if there should be some
+ failure in the TSF, that certain functions in the TSF should
+ either complete successfully or recover to a secure state.
+
+
+
+ , provides for recovery at the level
+ of particular functions, ensuring either successful completion
+ or rollback of TSF data to a secure state.
+
+
+ if possible, the impossibility to return to a secure state
+ after a failure of the TSF;
+
+
+ if possible, the detection of a failure of a function.
+
+
+ The TSF shall ensure that
+
+
+ list of functions and failure scenarios
+
+
+
+ the PP/ST author should specify a list the functions and
+ failure scenarios. In the event that any of the
+ identified failure scenarios happen, the functions that have
+ been specified must either complete successfully or
+ recover to a consistent and secure state.
+
+
+ have the property that the function either completes successfully,
+ or for the indicated failure scenarios, recovers to a
+ consistent and secure state.
+
+
+
+
+
+
+
+ This family addresses detection of replay for various types
+ of entities (e.g. messages, service requests, service
+ responses) and subsequent actions to correct. In the case
+ where replay may be detected, this effectively prevents it.
+
+
+
+ This family addresses detection of replay for various types
+ of entities and subsequent actions to correct.
+
+
+
+
+
+ The entities included here are, for example, messages,
+ service requests, service responses, or sessions.
+
+
+
+ The family consists of only one component, , which requires that the TSF shall be
+ able to detect the replay of identified entities.
+
+
+ management of the list of identified entities for which
+ replay shall be detected;
+
+
+ management of the list of actions that need to be taken in
+ case of replay.
+
+
+ Detected replay attacks.
+
+
+ Action to be taken based on the specific actions.
+
+
+ The TSF shall detect replay for the following entities:
+
+
+ list of identified entities
+
+
+
+ the PP/ST author should provide a list of identified
+ entities for which detection of replay should be
+ possible. Examples of such entities might include:
+ messages, service requests, service responses, and
+ user sessions.
+
+ .
+
+
+ The TSF shall perform
+
+
+ list of specific actions
+
+
+
+ the PP/ST author should specify the list of actions to
+ be taken by the TSF when replay is detected. The
+ potential set of actions that can be taken includes:
+ ignoring the replayed entity, requesting confirmation
+ of the entity from the identified source, and
+ terminating the subject from which the re-played
+ entity originated.
+
+
+ when replay is detected.
+
+
+
+
+
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use this trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+
+
+ Distributed TOEs may give rise to greater complexity than
+ monolithic TOEs through the potential for differences in
+ state between parts of the TOE, and through delays in
+ communication. In most cases, synchronisation of state
+ between distributed functions involves an exchange protocol,
+ not a simple action. When malice exists in the distributed
+ environment of these protocols, more complex defensive
+ protocols are required.
+
+ establishes the requirement for certain
+ critical functions of the TSF to use a trusted
+ protocol. ensures that two distributed
+ parts of the TOE (e.g. hosts) have synchronised their states
+ after a security-relevant action.
+
+ Some states may never be synchronised, or the transaction
+ cost may be too high for practical use; encryption key
+ revocation is an example, where knowing the state after the
+ revocation action is initiated can never be known. Either
+ the action was taken and acknowledgment cannot be sent, or
+ the message was ignored by hostile communication partners
+ and the revocation never occurred. Indeterminacy is unique
+ to distributed TOEs. Indeterminacy and state synchrony
+ are related, and the same solution may apply. It is futile
+ to design for indeterminate states; the PP/ST author should
+ express other requirements in such cases (e.g. raise an
+ alarm, audit the event).
+
+
+
+
+
+
+
+
+ In this component, the TSF must supply an acknowledgement
+ to another part of the TSF when requested. This
+ acknowledgement should indicate that one part of a
+ distributed TOE successfully received an unmodified
+ transmission from a different part of the distributed TOE.
+
+
+
+ , requires only a simple
+ acknowledgment by the data recipient.
+
+
+ failure to receive an acknowledgement when expected.
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data transmission.
+
+
+
+
+
+
+
+
+
+
+ In this component, in addition to the TSF being able to
+ provide an acknowledgement for the receipt of a data
+ transmission, the TSF must comply with a request from
+ another part of the TSF for an acknowledgement to the
+ acknowledgement.
+
+ For example, the local TSF transmits some data to a remote
+ part of the TSF. The remote part of the TSF acknowledges
+ the successful receipt of the data and requests that the
+ sending TSF confirm that it receives the
+ acknowledgement. This mechanism provides additional
+ confidence that both parts of the TSF involved in the data
+ transmission know that the transmission completed
+ successfully.
+
+
+
+ , requires mutual acknowledgment of
+ the data exchange.
+
+
+
+ The TSF shall acknowledge, when requested by another part of
+ the TSF, the receipt of an unmodified TSF data
+ transmission.
+
+
+ The TSF shall ensure that the relevant parts of the TSF know
+ the correct status of transmitted data among its different
+ parts, using acknowledgements.
+
+
+
+
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+
+
+ This family addresses requirements for a reliable time stamp
+ function within a TOE.
+
+ It is the responsibility of the PP/ST author to clarify the
+ meaning of the phrase ``reliable time
+ stamp'', and to indicate where the responsibility
+ lies in determining the acceptance of trust.
+
+
+
+
+
+ Some possible uses of this component include providing
+ reliable time stamps for the purposes of audit as well as
+ for security attribute expiration.
+
+
+
+ This family consists of only one component, , which requires that the TSF provide
+ reliable time stamps for TSF functions.
+
+
+ management of the time.
+
+
+ changes to the time;
+
+
+ providing a timestamp.
+
+
+ The TSF shall be able to provide reliable time stamps.
+
+
+
+
+
+
+
+ In a distributed environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and a different trusted IT product.
+
+
+
+ In a distributed or composite environment, a TOE may
+ need to exchange TSF data (e.g. the SFP-attributes
+ associated with data, audit information, identification
+ information) with another trusted IT Product, This family
+ defines the requirements for sharing and consistent
+ interpretation of these attributes between the TSF of the
+ TOE and that of a different trusted IT Product.
+
+ The components in this family are intended to provide
+ requirements for automated support for TSF data consistency
+ when such data is transmitted between the TSF of the TOE and
+ another trusted IT Product. It is also possible that wholly
+ procedural means could be used to produce security attribute
+ consistency, but they are not provided for here.
+
+ This family is different from FDP_ETC and FDP_ITC, as those
+ two families are concerned only with resolving the security
+ attributes between the TSF and its import/export medium.
+
+ If the integrity of the TSF data is of concern, requirements
+ should be chosen from the family. These
+ components specify requirements for the TSF to be able to
+ detect or detect and correct modifications to TSF data in
+ transit.
+
+
+
+
+
+ The TSF is responsible for maintaining the consistency of
+ TSF data used by or associated with the specified function
+ and that are common between two or more trusted
+ systems. For example, the TSF data of two different
+ systems may have different conventions internally. For the
+ TSF data to be used properly (e.g. to afford the user data
+ the same protection as within the TOE) by the receiving
+ trusted IT product, the TOE and the other trusted IT
+ product must use a pre-established protocol to exchange
+ TSF data.
+
+
+
+ , requires that the TSF provide the
+ capability to ensure consistency of attributes between
+ TSFs.
+
+
+ Successful use of TSF data consistency mechanisms.
+
+
+ Use of the TSF data consistency mechanisms.
+
+
+ Identification of which TSF data have been interpreted.
+
+
+ Detection of modified TSF data.
+
+
+ The TSF shall provide the capability to consistently
+ interpret
+
+
+ list of TSF data types
+
+
+
+ the PP/ST author should define the list of TSF data
+ types, for which the TSF shall provide the capability
+ to consistently interpret, when shared between the TSF
+ and another trusted IT product.
+
+
+ when shared between the TSF and another trusted IT product.
+
+
+ The TSF shall use
+
+
+ list of interpretation rules to be applied by the TSF
+
+
+
+ the PP/ST should assign the list of interpretation
+ rules to be applied by the TSF,
+
+
+ when interpreting the TSF data from another trusted IT
+ product.
+
+
+
+ This family defines requirements for the TSF to perform tests
+ on one or more external entities.
+ This component is not intended to be applied to human users.
+ External entities may include applications running on the TOE, hardware or
+ software running ``underneath'' the TOE (platforms, operating systems etc.)
+ or applications/boxes connected to the TOE (intrusion detection systems,
+ firewalls, login servers, time servers etc.).
+ This family defines requirements for the testing of one or more external
+ entities by the TSF. These external entities are not human users, and they can
+ include combinations of software and/or hardware interacting with the TOE.
+ Examples of the types of tests that may be run are:
+
+ Tests for the presence of a firewall, and possibly whether it is
+ correctly configured;
+
+ Tests of some of the properties of the operating system that an
+ application TOE runs on;
+
+ Tests of some of the properties of the IC that a smart card OS TOE
+ runs on (e.g. the random number generator).
+
+ Note that the external entity may ``lie'' about the test results, either on
+ purpose or because it is not working correctly.
+ These tests can be carried out either in some maintenance state, at start-up,
+ on-line, or continuously. The actions to be taken by the TOE as the result of
+ testing are defined also in this family.
+ The tests of external entities should be sufficient to test all of the
+ characteristics of them upon which the TSF relies.
+ This component is not intended to be applied to human users.
+ This component provides support for the periodic testing of properties
+ related to external entities upon which the TSF's operation depends, by
+ requiring the ability to periodically invoke testing functions.
+ The PP/ST author may refine the requirement to state whether the function
+ should be available in off-line, on-line or maintenance mode.
+ It is acceptable for the functions for periodic testing to be available only in
+ an off-line or maintenance mode. Controls should be in place to limit access,
+ during maintenance, to authorised users., provides for testing of the
+ external entities by the TSF.
+ management of the conditions under which the testing of external
+ entities occurs, such as during initial start-up, regular interval, or
+ under specified conditions;
+
+ management of the time interval if appropriate.
+
+ Execution of the tests of the external entities and the results of
+ the tests.
+
+ The TSF shall run a suite of tests
+
+ during initial start-up
+
+ periodically during normal operation
+
+ at the request of an authorised user
+
+ other conditions
+
+ the PP/ST author should, if other conditions are
+ selected, specify the frequency with which the testing of external entities will be run.
+ An example of this other frecuency or condition may be to run the
+ tests each time a user requests to initiate a session with the TOE. For
+ instance, this could be the case of testing a directory server before its
+ interaction with the TSF during the user authentication process.
+ the PP/ST author should specify when the TSF will
+ run the testing of external entities, during initial start-up, periodically
+ during normal operation, at the request of an authorised user, or under
+ other conditions. If the tests are run often, then the end users should
+ have more confidence that the TOE is operating correctly than if the
+ tests are run less frequently. However, this need for confidence that
+ the TOE is operating correctly must be balanced with the potential
+ impact on the availability of the TOE, as often times, the testing of external entities may
+ delay the normal operation of a TOE.
+ to check the fulfillment of
+
+ list of properties of the external entities
+
+ the PP/ST author should specify the properties of the
+ external entities to be checked by the tests. Examples of these
+ properties may include configuration or availability properties of
+ a directory server supporting some access control part of the TSF.
+ .
+
+ If the test fails, the TSF shall
+
+ action(s)
+
+ the PP/ST author should specify what are the action(s)
+ that the TSF shall perform when the testing fails. Examples of these
+ action(s), illustrated by a directory server instance, may include to
+ connect to an alternative available server or otherwise to look for a
+ backup server.
+ .
+
+
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if
+ the internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network and parts of the TOE network connections are broken,
+ this may occur when parts become disabled.
+
+
+
+ The requirements of this family are needed to ensure the
+ consistency of TSF data when such data is replicated
+ internal to the TOE. Such data may become inconsistent if an
+ internal channel between parts of the TOE becomes
+ inoperative. If the TOE is internally structured as a
+ network of parts of the TOE, this can occur when parts
+ become disabled, network connections are broken, and so on.
+
+ The method of ensuring consistency is not specified in this
+ component. It could be attained through a form of
+ transaction logging (where appropriate transactions are
+ ``rolled back'' to a site upon
+ reconnection); it could be updating the replicated data
+ through a synchronisation protocol. If a particular protocol
+ is necessary for a PP/ST, it can be specified through
+ refinement.
+
+ It may be impossible to synchronise some states, or the cost
+ of such synchronisation may be too high. Examples of this
+ situation are communication channel and encryption key
+ revocations. Indeterminate states may also occur; if a
+ specific behaviour is desired, it should be specified via
+ refinement.
+
+
+
+
+
+
+
+
+ This family consists of only one component, , which requires that the TSF ensure the
+ consistency of TSF data that is replicated in multiple
+ locations.
+
+
+ restoring consistency upon reconnection.
+
+
+ Detected inconsistency between TSF data.
+
+
+ The TSF shall ensure that TSF data is consistent when
+ replicated between parts of the TOE.
+
+
+ When parts of the TOE containing replicated TSF data are
+ disconnected, the TSF shall ensure the consistency of the
+ replicated TSF data upon reconnection before processing any
+ requests for
+
+
+ list of functions dependent on TSF data replication
+ consistency
+
+
+
+ the PP/ST author should specify the list of functions
+ dependent on TSF data replication consistency.
+
+ .
+
+
+
+
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of the authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF data and TSF itself (i.e. TSF executable code or
+ TSF hardware component) by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+
+
+ The family defines the requirements for the self-testing of
+ the TSF with respect to some expected correct
+ operation. Examples are interfaces to enforcement functions,
+ and sample arithmetical operations on critical parts of the
+ TOE. These tests can be carried out at start-up,
+ periodically, at the request of an authorised user, or when
+ other conditions are met. The actions to be taken by the TOE
+ as the result of self testing are defined in other families.
+
+ The requirements of this family are also needed to detect
+ the corruption of TSF data and TSF itself (i.e. TSF executable code or
+ TSF hardware component) by various failures that do not necessarily
+ stop the TOE's operation (which would be handled by other
+ families). These checks must be performed because these
+ failures may not necessarily be prevented. Such failures can
+ occur either because of unforeseen failure modes or
+ associated oversights in the design of hardware, firmware,
+ or software, or because of malicious corruption of the TSF
+ due to inadequate logical and/or physical protection.
+
+ In addition, use of this component may, with appropriate
+ conditions, help to prevent inappropriate or damaging TSF
+ changes being applied to an operational TOE as the result of
+ maintenance activities.
+
+ The term ``correct operation of the TSF'' refers primarily to
+ the operation of the TSF and the integrity of the TSF data.
+
+
+
+
+
+
+ This component provides support for the testing of the
+ critical functions of the TSF's operation by
+ requiring the ability to invoke testing functions and
+ check the integrity of TSF data and executable code.
+
+
+
+ It is acceptable for the functions that are available to
+ the authorised user for periodic testing to be available
+ only in an off-line or maintenance mode. Controls should
+ be in place to limit access during these modes to
+ authorised users.
+
+
+ , provides the ability to test the
+ TSF's correct operation. These tests may be
+ performed at start-up, periodically, at the request of the
+ authorised user, or when other conditions are met. It also
+ provides the ability to verify the integrity of TSF data
+ and TSF itself.
+
+
+ management of the conditions under which TSF self testing
+ occurs, such as during initial start-up, regular interval,
+ or under specified conditions;
+
+
+ management of the time interval if appropriate.
+
+
+ Execution of the TSF self tests and the results of the
+ tests.
+
+
+ The TSF shall run a suite of self tests
+
+ during initial start-up
+
+ periodically during normal operation
+
+ at the request of the authorised user
+
+ at the conditions
+
+ conditions under which self test should occur
+
+ the PP/ST author should, if selected, specify the
+ conditions under which the self test should take
+ place.
+ the PP/ST author should specify when the TSF will execute
+ the TSF test; during initial start-up, periodically during
+ normal operation, at the request of an authorised user, at
+ other conditions. In the case of the latter option, the
+ PP/ST author should also assign what those conditions are
+ via the following assignment.
+ to demonstrate the correct operation of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of parts of the TSF that will be subject to TSF
+ self-testing.
+ the TSF
+
+ the PP/ST author should specify whether the self tests
+ are to be carried out to demonstrate the correct
+ operation of the entire TSF, or of only specified parts
+ of TSF..
+
+
+ The TSF shall provide authorised users with the capability to
+ verify the integrity of
+
+ parts of TSF data
+
+ the PP/ST author should, if selected, specify the
+ list of TSF data that will be verified for
+ integrity.
+ TSF data
+
+ the PP/ST author should specify whether data integrity
+ is to be verified for all TSF data, or only for selected
+ data..
+
+
+ The TSF shall provide authorised users with the capability to
+ verify the integrity of
+
+ parts of TSF
+
+ the PP/ST author should, if selected, specify the
+ list of TSF that will be verified for
+ integrity.
+ TSF
+
+ the PP/ST author should specify whether TSF integrity
+ is to be verified for all TSF, or only for selected
+ TSF..
+
+
+
+
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+ This class provides three families that support the
+ availability of required resources such as processing
+ capability and/or storage capacity. The family Fault Tolerance
+ provides protection against unavailability of capabilities
+ caused by failure of the TOE. The family Priority of Service
+ ensures that the resources will be allocated to the more
+ important or time-critical tasks, and cannot be monopolised by
+ lower priority tasks. The family Resource Allocation provides
+ limits on the use of available resources, therefore preventing
+ users from monopolising the resources.
+
+
+
+
+
+ The requirements of this family ensure that the TOE will
+ maintain correct operation even in the event of failures.
+
+
+
+ This family provides requirements for the availability of
+ capabilities even in the case of failures. Examples of such
+ failures are power failure, hardware failure, or software
+ error. In case of these errors, if so specified, the TOE
+ will maintain the specified capabilities. The PP/ST author
+ could specify, for example, that a TOE used in a nuclear
+ plant will continue the operation of the shut-down procedure
+ in the case of power-failure or communication-failure.
+
+ Because the TOE can only continue its correct operation if
+ the SFRs are enforced, there is a requirement that the system
+ must remain in a secure state after a failure. This
+ capability is provided by .
+
+ The mechanisms to provide fault tolerance could be active or
+ passive. In case of an active mechanism, specific functions
+ are in place that are activated in case the error
+ occurs. For example, a fire alarm is an active mechanism:
+ the TSF will detect the fire and can take action such as
+ switching operation to a backup. In a passive scheme, the
+ architecture of the TOE is capable of handling the
+ error. For example, the use of a majority voting scheme with
+ multiple processors is a passive solution; failure of one
+ processor will not disrupt the operation of the TOE
+ (although it needs to be detected to allow correction).
+
+ For this family, it does not matter whether the failure has
+ been initiated accidentally (such as flooding or unplugging
+ the wrong device) or intentionally (such as monopolising).
+
+
+
+
+
+
+
+
+ This component is intended to specify which capabilities
+ the TOE will still provide after a failure of the
+ system. Since it would be difficult to describe all
+ specific failures, categories of failures may be
+ specified. Examples of general failures are flooding of
+ the computer room, short term power interruption,
+ breakdown of a CPU or host, software failure, or buffer
+ overflow.
+
+
+
+ , requires the TOE to continue
+ correct operation of identified capabilities in the event
+ of identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ All TOE capabilities being discontinued due to a failure.
+
+
+ The TSF shall ensure the operation of
+
+
+ list of TOE capabilities
+
+
+
+ the PP/ST author should specify the list of TOE
+ capabilities the TOE will maintain during and after a
+ specified failure.
+
+
+ when the following failures occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+
+
+
+ This component is intended to specify against what type of
+ failures the TOE must be resistant. Since it would be
+ difficult to describe all specific failures, categories of
+ failures may be specified. Examples of general failures
+ are flooding of the computer room, short term power
+ interruption, breakdown of a CPU or host, software
+ failure, or overflow of buffer.
+
+
+
+ , requires the TOE to continue
+ correct operation of all capabilities in the event of
+ identified failures.
+
+
+ Any failure detected by the TSF.
+
+
+ The TSF shall ensure the operation of all the
+ TOE's capabilities when the following failures
+ occur:
+
+
+ list of type of failures
+
+
+
+ the PP/ST author should specify the list of type of
+ failures against which the TOE has to be explicitly
+ protected. If a failure in this list occurs, the TOE
+ will be able to continue its operation.
+
+ .
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without undue interference or delay caused by
+ low priority activities.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that high priority activities under the control of the TSF will always be
+ accomplished without interference or delay due to low
+ priority activities. In other words, time critical tasks
+ will not be delayed by tasks that are less time critical.
+
+ This family could be applicable to several types of
+ resources, for example, processing capacity, and
+ communication channel capacity.
+
+ The Priority of Service mechanism might be passive or
+ active. In a passive Priority of Service system, the system
+ will select the task with the highest priority when given a
+ choice between two waiting applications. While using passive
+ Priority of Service mechanisms, when a low priority task is
+ running, it cannot be interrupted by a high priority
+ task. While using an active Priority of Service mechanisms,
+ lower priority tasks might be interrupted by new high
+ priority tasks.
+
+ The audit requirement states that all reasons for rejection
+ should be audited. It is left to the developer to argue that
+ an operation is not rejected but delayed.
+
+
+
+
+
+ This component defines priorities for a subject, and the
+ resources for which this priority will be used. If a
+ subject attempts to take action on a resource controlled
+ by the Priority of Service requirements, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of a subset of the resources
+ under the control of the TSF.
+
+
+ assignment of priorities to each subject in the TSF.
+
+
+ Rejection of operation based on the use of priority within
+ an allocation.
+
+
+ All attempted uses of the allocation function which involves
+ the priority of the service functions.
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which the TSF enforces priority of service
+ (e.g. resources such as processes, disk space, memory,
+ bandwidth).
+
+
+ shall be mediated on the basis of the subjects assigned
+ priority.
+
+
+
+
+
+
+
+ This component defines priorities for a subject. All
+ shareable resources under the control of the TSF will be subjected to the
+ Priority of Service mechanism. If a subject attempts to
+ take action on a shareable TSF resource, the access and/or
+ time of access will be dependent on the subject's
+ priority, the priority of the currently acting subject,
+ and the priority of the subjects still in the queue.
+
+
+
+ , provides priorities for a
+ subject's use of all of the resources under the control of the TSF.
+
+
+
+
+
+ The TSF shall assign a priority to each subject in the TSF.
+
+
+ The TSF shall ensure that each access to all shareable
+ resources shall be mediated on the basis of the subjects
+ assigned priority.
+
+
+
+
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources by users and subjects such that denial of
+ service will not occur because of unauthorised
+ monopolisation of resources.
+
+
+
+ The requirements of this family allow the TSF to control the
+ use of resources under the control of the TSF by users and subjects such
+ that unauthorised denial of service will not take place by
+ means of monopolisation of resources by other users or
+ subjects.
+
+ Resource allocation rules allow the creation of quotas or
+ other means of defining limits on the amount of resource
+ space or time that may be allocated on behalf of a specific
+ user or subjects. These rules may, for example:
+
+
+ Provide for object quotas that constrain the number
+ and/or size of objects a specific user may allocate.
+
+
+ Control the allocation/deallocation of preassigned
+ resource units where these units are under the control
+ of the TSF.
+
+
+
+ In general, these functions will be implemented through the
+ use of attributes assigned to users and resources.
+
+ The objective of these components is to ensure a certain
+ amount of fairness among the users (e.g. a single user
+ should not allocate all the available space) and
+ subjects. Since resource allocation often goes beyond the
+ lifespan of a subject (i.e. files often exist longer than
+ the applications that generated them), and multiple
+ instantiations of subjects by the same user should not
+ negatively affect other users too much, the components allow
+ that the allocation limits are related to the users. In some
+ situations the resources are allocated by a subject
+ (e.g. main memory or CPU cycles). In those instances the
+ components allow that the resource allocation be on the
+ level of subjects.
+
+ This family imposes requirements on resource allocation, not
+ on the use of the resource itself. The audit requirements
+ therefore, as stated, also apply to the allocation of the
+ resource, not to the use of the resource.
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to only a specified set of the shareable
+ resources in the TOE. The requirements allow the quotas to
+ be associated with a user, possibly assigned to groups of
+ users or subjects as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will not
+ monopolise a controlled resource.
+
+
+ specifying maximum limits for a resource for groups and/or
+ individual users and/or subjects by an administrator.
+
+
+ Rejection of allocation operation due to resource limits.
+
+
+ All attempted uses of the resource allocation functions for
+ resources that are under control of the TSF.
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources:
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the list of controlled
+ resources for which maximum resource allocation limits
+ are required (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This component provides requirements for quota mechanisms
+ that apply to a specified set of the shareable resources
+ in the TOE. The requirements allow the quotas to be
+ associated with a user, or possibly assigned to groups of
+ users as applicable to the TOE.
+
+
+
+ , provides requirements for quota
+ mechanisms that ensure that users and subjects will always
+ have at least a minimum of a specified resource and that
+ they will not be able to monopolise a controlled resource.
+
+
+ specifying minimum and maximum limits for a resource for
+ groups and/or individual users and/or subjects by an
+ administrator.
+
+
+
+
+ The TSF shall enforce maximum quotas of the following
+ resources
+
+
+ controlled resources
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which maximum and minimum resource
+ allocation limits are required (e.g. processes, disk
+ space, memory, bandwidth). If all resources under the control of the TSF
+ need to be included, the words ``all TSF
+ resources'' can be specified.
+
+
+ that
+
+
+ individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ can use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the maximum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+ The TSF shall ensure the provision of minimum quantity of
+ each
+
+
+ controlled resource
+
+
+
+ the PP/ST author should specify the controlled
+ resources for which a minimum allocation limit needs
+ to be set (e.g. processes, disk space, memory,
+ bandwidth). If all resources under the control of the TSF need to be
+ included the words ``all TSF resources''
+ can be specified.
+
+
+ that is available for
+
+
+ an individual user
+
+
+ defined group of users
+
+
+ subjects
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas apply to individual users, to a defined group
+ of users, or subjects or any combination of these.
+
+
+ to use
+
+
+ simultaneously
+
+
+ over a specified period of time
+
+
+
+ the PP/ST author should select whether the minimum
+ quotas are applicable to any given time
+ (simultaneously), or over a specific time interval.
+
+ .
+
+
+
+
+
+
+
+ This family specifies functional requirements for controlling
+ the establishment of a user's session.
+
+
+
+ The establishment of a user's session typically
+ consists of the creation of one or more subjects that perform
+ operations in the TOE on behalf of the user. At the end of the
+ session establishment procedure, provided the TOE access
+ requirements are satisfied, the created subjects bear the
+ attributes determined by the identification and authentication
+ functions. This family specifies functional requirements for
+ controlling the establishment of a user's session.
+
+ A user session is defined as the period starting at the time
+ of the identification/authentication, or if more appropriate,
+ the start of an interaction between the user and the system,
+ up to the moment that all subjects (resources and attributes)
+ related to that session have been deallocated.
+
+
+
+
+
+ This family defines requirements to limit the scope of
+ session security attributes that a user may select for a
+ session.
+
+
+
+ This family defines requirements that will limit the session
+ security attributes a user may select, and the subjects to
+ which a user may be bound, based on: the method of access;
+ the location or port of access; and/or the time
+ (e.g. time-of-day, day-of-week).
+
+ This family provides the capability for a PP/ST author to
+ specify requirements for the TSF to place limits on the
+ domain of an authorised user's security attributes
+ based on an environmental condition. For example, a user may
+ be allowed to establish a ``secret session''
+ during normal business hours but outside those hours the
+ same user may be constrained to only establishing
+ ``unclassified sessions''. The identification of
+ relevant constraints on the domain of selectable attributes
+ can be achieved through the use of the selection
+ operation. These constraints can be applied on an
+ attribute-by-attribute basis. When there exists a need to
+ specify constraints on multiple attributes this component
+ will have to be replicated for each attribute. Examples of
+ attributes that could be used to limit the session security
+ attributes are:
+
+
+ The method of access can be used to specify in which
+ type of environment the user will be operating
+ (e.g. file transfer protocol, terminal, vtam).
+
+
+ The location of access can be used to constrain the
+ domain of a user's selectable attributes based
+ on a user's location or port of access. This
+ capability is of particular use in environments where
+ dial-up facilities or network facilities are available.
+
+
+ The time of access can be used to constrain the domain
+ of a user's selectable attributes. For example,
+ ranges may be based upon time-of-day, day-of-week, or
+ calendar dates. This constraint provides some
+ operational protection against user actions that could
+ occur at a time where proper monitoring or where proper
+ procedural measures may not be in place.
+
+
+
+
+
+
+
+ , provides the requirement for a TOE
+ to limit the scope of the session security attributes
+ during session establishment.
+
+
+ management of the scope of the session security attributes
+ by an administrator.
+
+
+ All failed attempts at selecting a session security
+ attributes;
+
+
+ All attempts at selecting a session security attributes;
+
+
+ Capture of the values of each session security attributes.
+
+
+ The TSF shall restrict the scope of the session security
+ attributes
+
+
+ session security attributes
+
+
+
+ the PP/ST author should specify the set of session
+ security attributes that are to be
+ constrained. Examples of these session security
+ attributes are user clearance level, integrity level
+ and roles.
+
+ , based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the set of attributes
+ that can be use to determine the scope of the session
+ security attributes. Examples of such attributes are
+ user identity, originating location, time of access,
+ and method of access.
+
+ .
+
+
+
+
+
+
+
+ This family defines requirements to place limits on the
+ number of concurrent sessions that belong to the same user.
+
+
+
+ This family defines how many sessions a user may have at the
+ same time (concurrent sessions). This number of concurrent
+ sessions can either be set for a group of users or for each
+ individual user.
+
+
+
+
+
+
+
+
+ This component allows the system to limit the number of
+ sessions in order to effectively use the resources of the
+ TOE.
+
+
+
+ , provides limitations that apply to
+ all users of the TSF.
+
+
+ management of the maximum allowed number of concurrent user
+ sessions by an administrator.
+
+
+ Rejection of a new session based on the limitation of
+ multiple concurrent sessions.
+
+
+ Capture of the number of currently concurrent user sessions
+ and the user security attribute(s).
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user.
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+
+
+
+ This component provides additional capabilities over those
+ of , by allowing further constraints
+ to be placed on the number of concurrent sessions that
+ users are able to invoke. These constraints are in terms
+ of a user's security attributes, such as a
+ user's identity, or membership of a role.
+
+
+
+ extends by
+ requiring the ability to specify limitations on the number
+ of concurrent sessions based on the related security
+ attributes.
+
+
+ management of the rules that govern the maximum allowed
+ number of concurrent user sessions by an administrator.
+
+
+
+
+ The TSF shall restrict the maximum number of concurrent
+ sessions that belong to the same user according to the rules
+
+
+ rules for the number of maximum concurrent sessions
+
+
+
+ the PP/ST author should specify the rules that
+ determine the maximum number of concurrent
+ sessions. An example of a rule is ``maximum
+ number of concurrent sessions is one if the user has a
+ classification level of ``secret''
+ and five otherwise''.
+
+ .
+
+
+ The TSF shall enforce, by default, a limit of
+
+
+ default number
+
+
+
+ the PP/ST author should specify the default number of
+ maximum concurrent sessions to be used.
+
+
+ sessions per user.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to provide the
+ capability for TSF-initiated and user-initiated locking,
+ unlocking, and termination of interactive sessions.
+
+
+ This family defines requirements for the TSF to provide the
+ capability for TSF-initiated and user-initiated locking,
+ unlocking, and termination of interactive sessions.
+ When a user is directly interacting with subjects in the TOE
+ (interactive session), the user's terminal is vulnerable if
+ left unattended. This family provides requirements for the TSF
+ to disable (lock) the terminal or terminate the session after
+ a specified period of inactivity, and for the user to initiate
+ the disabling (locking) of the terminal or terminate the
+ session. To reactivate the terminal, an event specified by the
+ PP/ST author, such as the user re-authentication must
+ occur.
+ A user is considered inactive, if he/she has not provided any
+ stimulus to the TOE for a specified period of time.
+ A PP/ST author should consider whether
+ should be included. In that case, the function ``session
+ locking'' should be included in the operation in .
+
+
+
+
+
+
+
+ , provides the capability for the
+ TSF to lock an active user session after a specified
+ period of time. Locking a terminal would prevent any
+ further interaction with an existing active session
+ through the use of the locked terminal.
+
+ If display devices are overwritten, the replacement
+ contents need not be static (i.e. ``screen
+ savers'' are permitted).
+
+ This component allows the PP/ST author to specify what
+ events will unlock the session. These events may be
+ related to the terminal (e.g. fixed set of keystrokes to
+ unlock the session), the user (e.g. reauthentication), or
+ time.
+
+
+
+ includes system initiated locking
+ of an interactive session after a specified period of user
+ inactivity.
+
+
+ specification of the time of user inactivity after which
+ lock-out occurs for an individual user;
+
+
+ specification of the default time of user inactivity after
+ which lock-out occurs;
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+ Locking of an interactive session by the session locking
+ mechanism.
+
+
+ Successful unlocking of an interactive session.
+
+
+ Any attempts at unlocking an interactive session.
+
+
+ The TSF shall lock an interactive session after
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the locking of an
+ interactive session. If so desired the PP/ST author
+ could, through the assignment, specify that the time
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+
+ by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'' or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+
+
+ , provides the capability for
+ an authorised user to lock and unlock his/her own interactive
+ session. This would provide authorised users with the ability to
+ effectively block further use of their active sessions without
+ having to terminate the active session.
+
+ If devices are overwritten, the replacement contents need
+ not be static (i.e. ``screen savers''
+ are permitted).
+
+
+
+ , provides capabilities for the user
+ to lock and unlock the user's own interactive
+ sessions.
+
+
+ management of the events that should occur prior to
+ unlocking the session.
+
+
+
+
+ The TSF shall allow user-initiated locking of the
+ user's own interactive session, by:
+
+
+ clearing or overwriting display devices, making the
+ current contents unreadable;
+
+
+ disabling any activity of the user's data
+ access/display devices other than unlocking the session.
+
+
+
+
+ The TSF shall require the following events to occur prior to
+ unlocking the session:
+
+
+ events to occur
+
+
+
+ the PP/ST author should specify the event(s) that
+ should occur before the session is unlocked. Examples
+ of such an event are: ``user
+ re-authentication'', or ``user
+ enters unlock key-sequence''.
+
+ .
+
+
+
+
+
+
+ , requires that the TSF terminate an
+ interactive user session after a period of inactivity.
+
+ The PP/ST author should be aware that a session may
+ continue after the user terminated his/her activity, for
+ example, background processing. This requirement would
+ terminate this background subject after a period of
+ inactivity of the user without regard to the status of the
+ subject.
+
+
+ , provides requirements for
+ the TSF to terminate the session after a specified period of
+ user inactivity.
+
+
+ specification of the time of user inactivity after which
+ termination of the interactive session occurs for an
+ individual user;
+
+
+ specification of the default time of user inactivity after
+ which termination of the interactive session occurs.
+
+
+ Termination of an interactive session by the session locking
+ mechanism.
+
+
+ The TSF shall terminate an interactive session after a
+
+
+ time interval of user inactivity
+
+
+
+ the PP/ST author should specify the interval of user
+ inactivity that will trigger the termination of an
+ interactive session. If so desired, the PP/ST author
+ could, through the assignment, specify that the
+ interval is left to the authorised administrator or
+ the user. The management functions in the FMT class
+ can specify the capability to modify this time
+ interval, making it the default value.
+
+ .
+
+ , provides the capability for an
+ authorised user to terminate his/her interactive
+ session..
+ The PP/ST author should be aware that a session may continue
+ after the user terminated his/her activity, for example,
+ background processing. This requirement would allow the user
+ to terminate this background subject without regard to the
+ status of the subject., provides capabilities for the user
+ to terminate the user's own interactive sessions.
+ Termination of an interactive session by the user.
+
+ The TSF shall allow user-initiated termination of the user's own
+ interactive session.
+
+
+
+
+
+
+ This family defines requirements to display a configurable
+ advisory warning message to users regarding the appropriate
+ use of the TOE.
+
+
+
+ Prior to identification and authentication, TOE access
+ requirements provide the ability for the TOE to display an
+ advisory warning message to potential users pertaining to
+ appropriate use of the TOE.
+
+
+
+
+
+ This component requires that there is an advisory warning
+ regarding the unauthorised use of the TOE. A PP/ST author
+ could refine the requirement to include a default banner.
+
+
+
+ , provides the requirement for a TOE
+ Access Banner. This banner is displayed prior to the
+ establishment dialogue for a session.
+
+
+ maintenance of the banner by the authorised administrator.
+
+
+ Before establishing a user session, the TSF shall display an
+ advisory warning message regarding unauthorised use of the
+ TOE.
+
+
+
+
+
+
+
+ This family defines requirements for the TSF to display to a
+ user, upon successful session establishment, a history of
+ successful and unsuccessful attempts to access the
+ user's account.
+
+
+
+ This family defines requirements for the TSF to display to
+ users, upon successful session establishment to the TOE, a
+ history of unsuccessful attempts to access the account. This
+ history may include the date, time, means of access, and
+ port of the last successful access to the TOE, as well as
+ the number of unsuccessful attempts to access the TOE since
+ the last successful access by the identified user.
+
+
+
+
+
+
+ This family can provide authorised users with information
+ that may indicate the possible misuse of their user
+ account.
+
+ This component request that the user is presented with the
+ information. The user should be able to review the
+ information, but is not forced to do so. If a user so
+ desires he might, for example, create scripts that ignore
+ this information and start other processes.
+
+
+
+ , provides the requirement for a TOE
+ to display information related to previous attempts to
+ establish a session.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last successful session establishment that will
+ be shown at the user interface. The items are: date,
+ time, method of access (such as ftp), and/or location
+ (e.g. terminal 50).
+
+
+ of the last successful session establishment to the user.
+
+
+ Upon successful session establishment, the TSF shall display
+ the
+
+
+ date
+
+
+ time
+
+
+ method
+
+
+ location
+
+
+
+ the PP/ST author should select the security attributes
+ of the last unsuccessful session establishment that
+ will be shown at the user interface. The items are:
+ date, time, method of access (such as ftp), and/or
+ location (e.g. terminal 50).
+
+
+ of the last unsuccessful attempt to session establishment
+ and the number of unsuccessful attempts since the last
+ successful session establishment.
+
+
+ The TSF shall not erase the access history information from
+ the user interface without giving the user an opportunity to
+ review the information.
+
+
+
+
+
+
+ This family defines requirements to deny a user permission
+ to establish a session with the TOE.
+
+
+
+ This family defines requirements to deny an user permission
+ to establish a session with the TOE based on attributes such
+ as the location or port of access, the user's security
+ attribute (e.g. identity, clearance level, integrity level,
+ membership in a role), ranges of time (e.g. time-of-day,
+ day-of-week, calendar dates) or combinations of parameters.
+
+ This family provides the capability for the PP/ST author to
+ specify requirements for the TOE to place constraints on the
+ ability of an authorised user to establish a session with
+ the TOE. The identification of relevant constraints can be
+ achieved through the use of the selection
+ operation. Examples of attributes that could be used to
+ specify the session establishment constraints are:
+
+
+ The location of access can be used to constrain the
+ ability of a user to establish an active session with
+ the TOE, based on the user's location or port
+ of access. This capability is of particular use in
+ environments where dial-up facilities or network
+ facilities are available.
+
+
+ The user's security attributes can be used to
+ place constraints on the ability of a user to establish
+ an active session with the TOE. For example, these
+ attributes would provide the capability to deny session
+ establishment based on any of the following:
+
+
+ a user's identity;
+
+
+ a user's clearance level;
+
+
+ a user's integrity level; and
+
+
+ a user's membership in a role.
+
+
+
+
+
+ This capability is particularly relevant in situations where
+ authorisation or login may take place at a different
+ location from where TOE access checks are performed.
+
+
+ The time of access can be used to constrain the ability
+ of a user to establish an active session with the TOE
+ based on ranges of time. For example, ranges may be
+ based upon time-of-day, day-of-week, or calendar
+ dates. This constraint provides some operational
+ protection against actions that could occur at a time
+ where proper monitoring or where proper procedural
+ measures may not be in place.
+
+
+
+
+
+
+
+ , provides requirements for denying
+ users access to the TOE based on attributes.
+
+
+ management of the session establishment conditions by the
+ authorised administrator.
+
+
+ Denial of a session establishment due to the session
+ establishment mechanism.
+
+
+ All attempts at establishment of a user session.
+
+
+ Capture of the value of the selected access parameters
+ (e.g. location of access, time of access).
+
+
+ The TSF shall be able to deny session establishment based on
+
+
+ attributes
+
+
+
+ the PP/ST author should specify the attributes that
+ can be used to restrict the session
+ establishment. Example of possible attributes are user
+ identity, originating location (e.g. no remote
+ terminals), time of access (e.g. outside hours), or
+ method of access (e.g. X-windows).
+
+ .
+
+
+
+
+
+
+
+ Families in this class provide requirements for a trusted
+ communication path between users and the TSF, and for a
+ trusted communication channel between the TSF and other
+ trusted IT products. Trusted paths and channels have the
+ following general characteristics:
+
+
+ The communications path is constructed using internal and
+ external communications channels (as appropriate for the
+ component) that isolate an identified subset of TSF data
+ and commands from the remainder of the TSF and user data.
+
+
+ Use of the communications path may be initiated by the
+ user and/or the TSF (as appropriate for the component).
+
+
+ The communications path is capable of providing assurance
+ that the user is communicating with the correct TSF, and
+ that the TSF is communicating with the correct user (as
+ appropriate for the component).
+
+
+
+ In this paradigm, a trusted channel is a communication channel
+ that may be initiated by either side of the channel, and
+ provides non-repudiation characteristics with respect to the
+ identity of the sides of the channel.
+
+ A trusted path provides a means for users to perform functions
+ through an assured direct interaction with the TSF. Trusted
+ path is usually desired for user actions such as initial
+ identification and/or authentication, but may also be desired
+ at other times during a user's session. Trusted
+ path exchanges may be initiated by a user or the TSF. User
+ responses via the trusted path are guaranteed to be protected
+ from modification by or disclosure to untrusted applications.
+
+
+
+ Users often need to perform functions through direct
+ interaction with the TSF. A trusted path provides confidence
+ that a user is communicating directly with the TSF whenever it
+ is invoked. A user's response via the trusted path
+ guarantees that untrusted applications cannot intercept or
+ modify the user's response. Similarly, trusted
+ channels are one approach for secure communication between the
+ TSF and another trusted IT product.
+
+ Absence of a trusted path may allow breaches of accountability
+ or access control in environments where untrusted applications
+ are used. These applications can intercept user-private
+ information, such as passwords, and use it to impersonate
+ other users. As a consequence, responsibility for any system
+ actions cannot be reliably assigned to an accountable
+ entity. Also, these applications could output erroneous
+ information on an unsuspecting user's display,
+ resulting in subsequent user actions that may be erroneous and
+ may lead to a security breach.
+
+
+
+
+
+ This family defines requirements for the creation of a
+ trusted channel between the TSF and other trusted IT
+ products for the performance of security critical
+ operations. This family should be included whenever there
+ are requirements for the secure communication of user or TSF
+ data between the TOE and other trusted IT products.
+
+
+
+ This family defines the rules for the creation of a trusted
+ channel connection that goes between the TSF and another
+ trusted IT product for the performance of security critical
+ operations between the products. An example of such a
+ security critical operation is the updating of the TSF
+ authentication database by the transfer of data from a
+ trusted product whose function is the collection of audit
+ data.
+
+
+
+
+
+ This component should be used when a trusted communication
+ channel between the TSF and another trusted IT product is
+ required.
+
+
+
+ , requires that the TSF provide a
+ trusted communication channel between itself and another
+ trusted IT product.
+
+
+ Configuring the actions that require trusted channel, if
+ supported.
+
+
+ Failure of the trusted channel functions.
+
+
+ Identification of the initiator and target of failed trusted
+ channel functions.
+
+
+ All attempted uses of the trusted channel functions.
+
+
+ Identification of the initiator and target of all trusted
+ channel functions.
+
+
+ The TSF shall provide a communication channel between itself
+ and another trusted IT product that is logically distinct
+ from other communication channels and provides assured
+ identification of its end points and protection of the
+ channel data from modification or disclosure.
+
+
+ The TSF shall permit
+
+ the TSF
+
+ another trusted IT product
+
+ the PP/ST author must specify whether the local TSF,
+ another trusted IT product, or both shall have the
+ capability to initiate the trusted channel.
+ to initiate communication via the trusted channel.
+
+
+ The TSF shall initiate communication via the trusted channel
+ for
+
+
+ list of functions for which a trusted channel is
+ required
+
+
+
+ the PP/ST author should specify the functions for
+ which a trusted channel is required. Examples of these
+ functions may include transfer of user, subject,
+ and/or object security attributes and ensuring
+ consistency of TSF data.
+
+ .
+
+
+
+
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+ This family defines the requirements to establish and
+ maintain trusted communication to or from users and the
+ TSF. A trusted path may be required for any
+ security-relevant interaction. Trusted path exchanges may be
+ initiated by a user during an interaction with the TSF, or
+ the TSF may establish communication with the user via a
+ trusted path.
+
+
+
+
+
+ This component should be used when trusted communication
+ between a user and the TSF is required, either for initial
+ authentication purposes only or for additional specified
+ user operations.
+
+
+
+ , requires that a trusted path
+ between the TSF and a user be provided for a set of events
+ defined by a PP/ST author. The user and/or the TSF may
+ have the ability to initiate the trusted path.
+
+
+ Configuring the actions that require trusted path, if
+ supported.
+
+
+ Failures of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ failures, if available.
+
+
+ All attempted uses of the trusted path functions.
+
+
+ Identification of the user associated with all trusted path
+ invocations, if available.
+
+
+ The TSF shall provide a communication path between itself and
+
+ remote
+
+ local
+
+ the PP/ST author should specify whether the trusted path
+ must be extended to remote and/or local users.
+ users that is logically distinct from other communication
+ paths and provides assured identification of its end points
+ and protection of the communicated data from
+
+ modification
+
+ disclosure
+
+ other types of integrity or confidentiality violation
+
+ if selected, the PP/ST author should identify any
+ additional types of integrity or confidentiality
+ violation against which the trusted path shall protect
+ the data.
+ the PP/ST author should specify whether the trusted path
+ shall protect the data from modification, disclosure,
+ and/or other types of integrity or confidentiality
+ violation..
+
+
+ The TSF shall permit
+
+
+ the TSF
+
+
+ local users
+
+
+ remote users
+
+
+
+ the PP/ST author should specify whether the TSF, local
+ users, and/or remote users should be able to initiate
+ the trusted path.
+
+
+ to initiate communication via the trusted path.
+
+
+ The TSF shall require the use of the trusted path for
+
+
+ initial user authentication
+
+
+
+
+ other services for which trusted path is required
+
+
+
+ if selected, the PP/ST author should identify
+ other services for which trusted path is required,
+ if any.
+
+
+
+
+
+ the PP/ST author should specify whether the trusted
+ path is to be used for initial user authentication
+ and/or for other specified services.
+
+ .
+
+
+
+
+
+
+
+ The class encompasses five
+ families. These families specify assurance requirements that
+ are designed to provide confidence that a composed TOE will
+ operate securely when relying upon security functionality
+ provided by previously evaluated software, firmware or
+ hardware components.
+
+ Composition involves taking two or more IT entities
+ successfully evaluated against CC security assurance
+ requirements packages (base components and dependent
+ components, see ) and
+ combining them for use, with no further development of either
+ IT entity. The development of additional IT entities is not
+ included (entities that have not previously been the subject
+ of a component evaluation). The composed TOE forms a new
+ product that can be installed and integrated into any specific
+ environment instance that meets the objectives for the
+ environment.
+
+ This approach does not provide an alternative approach for the
+ evaluation of components. Composition under provides a composed TOE integrator a method, which
+ can be used as an alternative to other assurance levels
+ specified in the CC, to gain confidence in a TOE that is the
+ combination of two or more successfully evaluated components
+ without having to re-evaluate the composite TSF. (The composed
+ TOE integrator is referred to as ``developer'' throughout the
+ class, with any references to the
+ developer of the base or dependent components clarified as
+ such.)
+
+ Composed Assurance Packages, as defined in Clauses and , is an
+ assurance scale for composed TOEs. This assurance scale is
+ required in addition to EALs because to combine components
+ evaluated against EALs and gain a resulting EAL assurance, all
+ SARs in the EAL have to be applied to the composed
+ TOE. Although reuse can be made of the component TOE
+ evaluation results, there are often additional aspects of the
+ components that have to be considered in the composed TOE, as
+ described in Annex . Due to the different parties involved in a
+ composed TOE evaluation activity it is generally not possible
+ to gain all necessary evidence about these additional aspects
+ of the components to apply the appropriate EAL. Hence, CAPs
+ have been defined to address the issue of combining evaluated
+ components and gaining a meaningful result. This is discussed
+ further in .
+
+
+
+
+ In a composed TOE it is generally the case that one component
+ relies on the services provided by another component. The
+ component requiring services is termed the dependent component
+ and the component providing the services is termed the base
+ component. This interaction and distinct is discussed further
+ in Annex B. It is assumed to be the case that the developer of
+ the dependent component is supporting the composed TOE
+ evaluation in some manner (as developer, sponsor, or just
+ cooperating and providing the necessary evaluation evidence
+ from the dependent component evaluation) The components included in the CAP assurance packages
+ should not be used as augmentations for component TOE
+ evaluations, as this would provide no meaningful assurance for
+ the component.
+
+ The families within the class
+ interact in a similar manner to the , and classes in a component TOE evaluation and hence
+ leverage from the specification of requirements from those
+ classes where applicable. There are however a few items
+ specific to composed TOE evaluations. To determine how the
+ components interact and identify any deviations from the
+ evaluations of the components, the dependencies that the
+ dependent component has upon the underlying base component are
+ identified (). This reliance on
+ the base component is specified in terms of the interfaces
+ through which the dependent component makes calls for services
+ in support of the dependent component SFRs. The interfaces,
+ and at higher levels the supporting behaviour, provided by the
+ base component in response to those service requests are
+ analysed in . The family is based on the family, as at the simplest level the
+ TSF of each component can be viewed as a subsystem of the
+ composed TOE, with additional portions of each component seen
+ as additional subsystems. Therefore, the interfaces between
+ the components are seen as interactions between subsystems in
+ a component TOE evaluation.
+
+ It is possible that the interfaces and supporting behaviour
+ descriptions provided for are
+ incomplete. This is determined during the conduct of . The
+ family takes the outputs of and
+ and determines whether the
+ components are being used in their evaluated configuration and
+ identifies where any specifications are incomplete, which are
+ then identified as inputs into testing () and vulnerability analysis () activities of the composed TOE.
+
+ Testing of the composed TOE is performed to determine that the
+ composed TOE exhibits the expected behaviour as determined by
+ the composed TOE SFRs, and at higher levels demonstrates the
+ compatibility of the interfaces between the components of the
+ composed TOE.
+
+ The vulnerability analysis of the composed TOE leverages from
+ the outputs of the vulnerability analysis of the component
+ evaluations. The composed TOE vulnerability analysis considers
+ any residual vulnerabilities from the component evaluations to
+ determine that the residual vulnerabilities are not applicable
+ to the composed TOE. A search of publicly available
+ information relating to the components is also performed to
+ identify any issues reported in the components since the
+ completion of the respective evaluations.
+
+ The interaction between the
+ families is depicted in Figure below. This shows by solid arrowed lines where
+ the evidence and understanding gained in one family feeds into
+ the next activity and the dashed arrows identify where an
+ activity explicitly traces back to the composed TOE SFRs, as
+ described above.
+
+
+
+
+ Further discussion of the definition and interactions within
+ composed TOEs is provided in .
+
+
+
+ Assurance class defines
+ requirements of the information necessary to ensure that two
+ or more components, which have themselves been the subject of
+ a CC evaluation, can be integrated in a secure manner.
+
+ The assurance requirements will
+ be applied to the composed TOE to:
+
+
+ determine that the required assurance is provided by the
+ base component;
+
+ determine that the base component and dependent component
+ are compatible; and
+
+ search for any vulnerabilities introduced through
+ composing the base and dependent components into a single
+ composed TOE entity.
+
+
+
+ The goal of this activity is to determine whether the
+ components can be integrated in a secure manner, as defined in
+ the ST for the composed TOE. This is achieved through
+ examination and testing of the interfaces between the
+ components, supported by examination of the design of the
+ components and the conduct of vulnerability analysis.
+
+
+
+ The family identifies where
+ the dependent component is reliant upon IT in its operational
+ environment (satisfied by a base component in the composed TOE
+ evaluation) in order to provide its own security
+ services. This reliance is identified in terms of the
+ interfaces expected by the dependent component to be provided
+ by the base component. then
+ determines which interfaces of the base component were
+ considered (as TSFI) during the component evaluation of the
+ base component.
+
+ It should be noted that does
+ not cover other evidence that may be needed to address the
+ technical integration problem of composing components
+ (e.g. descriptions of non-TSF interfaces of the operating
+ system, rules for integration, etc.). This is outside the
+ security assessment of the composition and is a functional
+ composition issue.
+
+ As part of the evaluator will
+ perform testing of the composed TOE SFRs at the composed TOE
+ interfaces and of the interfaces of the base component relied
+ upon by the dependent component to confirm they operate as
+ specified. The subset selected will consider the possible
+ effects of changes to the configuration/use of the base
+ component as used in the composed TOE. These changes are
+ identified from the configuration of the base component
+ determined during the base component evaluation. The developer
+ will provide test evidence for each of the base component
+ interfaces (the requirements for coverage are consistent with
+ those applied to the evaluation of the base component).
+
+ requires the evaluator to
+ determine whether the appropriate assurance measures have been
+ applied to the base component, and whether the base component
+ is being used in its evaluated configuration. This includes
+ determination of whether all security functionality required
+ by the dependent component was within the TSF of the base
+ component. The requirement
+ may be met through the production of evidence that each of
+ these is demonstrated to be upheld. This evidence may be in
+ the form of the security target and a public report of the
+ component evaluation (e.g. certification report).
+
+ If, on the other hand, one of the above have not been upheld,
+ then it may be possible that an argument can be made as to why
+ the assurance gained during an original evaluation is
+ unaffected. If this is not possible then additional evaluation
+ evidence for those aspects of the base component not covered
+ may have to be provided. This material is then assessed in
+ .
+
+ For example, it may be the case as described in the
+ Interactions between entities (see Annex in CC Part 3) that the
+ dependent component requires the base component to provide
+ more security functionality in the composed TOE than included
+ in the base component evaluation. This would be determined
+ during the application of the
+ and families. In this case
+ the composition rationale evidence provided for would demonstrate that the
+ assurance gained from the base component evaluation is
+ unaffected. This may be achieved by means including:
+
+
+ Performing a re-evaluation of the base component focusing
+ on the evidence relating to the extended part of the
+ TSF;
+
+ Demonstrating that the extended part of the TSF cannot
+ affect other portions of the TSF, and providing evidence
+ that the extended part of the TSF provides the necessary
+ security functionality.
+
+
+
+
+ This family addresses the requirement to demonstrate that
+ the base component can provide an appropriate level of
+ assurance for use in composition.
+
+
+
+ The family is used to
+ determine whether or not the appropriate assurance measures
+ have been applied to the base component for successful
+ integration in the composed TOE. That is, the SARs claimed
+ by the base component are consistent with the SARs in the
+ assurance package for the composed TOE. (e.g. if the
+ assurance package for the composed TOE included , a base component that was
+ evaluated against would
+ not have had the appropriate assurance measures applied, as
+ insufficient design evidence would have been
+ examined.)
+
+ The family calls for
+ evidence that the appropriate assurance is provided, without
+ being specific about how this is achieved. If the
+ appropriate evidence is not available, then it may be
+ necessary to report an assessment of the residual risk to
+ assist consumers of the composed TOE
+ (e.g. accreditors). This report would need to identify the
+ change to the base component that may have an effect on the
+ assurance gained during the original evaluation, along with
+ any known effects.
+
+
+
+
+ There is only a single component in this family.
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+ the composition rationale;
+
+ the reliance information;
+
+ the development information;
+
+ unique identifier.
+
+
+
+
+ The developer shall provide composition rationale for the
+ base component.
+
+
+ The composition rationale shall demonstrate that a level of
+ assurance at least as high as that of the dependent
+ component has been obtained for the support functionality of
+ the base component, when the base component is configured as
+ required to support the TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the correspondence analysis
+ with the development information and the reliance
+ information to identify the interfaces that are relied
+ upon by the dependent component which are not detailed
+ in the development information.
+
+ The evaluator's goal in this work unit is two fold:
+
+
+ to determine which interfaces relied upon by the
+ dependent component have had the appropriate
+ assurance measures applied.
+
+ to determine that the assurance package applied to
+ the base component during the base component
+ evaluation contained either the same assurance
+ requirements as those in the package applied to the
+ dependent component during its' evaluation, or
+ hierarchically higher assurance requirements.
+
+
+ The evaluator may use the correspondence tracing in the
+ development information developed during the activities (e.g. , , ) to
+ help identify the interfaces identified in the reliance
+ information that are not considered in the development
+ information.
+
+ The evaluator will record the SFR-enforcing interfaces
+ described in the reliance information that are not
+ included in the development information. These will
+ provide input to
+ work unit, helping to identify the portions of the base
+ component in which further assurance is required.
+
+ If the both the base and dependent components were
+ evaluated against the same assurance package, then the
+ determination of whether the level of assurance in the
+ portions within the base component evaluation is at
+ least as high as that of the dependent component is
+ trivial. If however, the assurance packages applied to
+ the components during the component evaluations differ,
+ the evaluator needs to determine that the assurance
+ requirements applied to the base component are all
+ hierarchically higher to the assurance requirements
+ applied to the dependent component.
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine, for those included base component interfaces
+ on which the dependent TSF relies, whether the interface
+ was considered during the evaluation of the base
+ component.
+
+ The ST, component public evaluation report (e.g. certification
+ report) and guidance documents for the base component all
+ provide information on the scope and boundary of the base
+ component. The ST provides details of the logical scope and
+ boundary of the composed TOE, allowing the evaluator to
+ determine whether an interface relates to a portion of the
+ product that was within the scope of the evaluation. The
+ guidance documentation provides details of use of all interfaces
+ for the composed TOE. Although the guidance documentation may
+ include details of interfaces in the product that are not within
+ the scope of the evaluation, any such interfaces should be
+ identifiable, either from the scoping information in the ST or
+ through a portion of the guidance that deals with the evaluated
+ configuration. The public evaluation report may provide any
+ additional constraints on the use of the composed TOE that are
+ necessary.
+
+ Therefore, the combination of these inputs allows the
+ evaluator to determine whether an interface described in
+ the composition rationale has the necessary assurance
+ associated with it, or whether further assurance is
+ required. The evaluator will record those interfaces of
+ the base component for which additional assurance is
+ required, for consideration during .
+
+
+
+
+ The evaluator shall examine the composition rationale to
+ determine that the necessary assurance measures have
+ been applied to the base component.
+
+ The evaluation verdicts, and resultant assurance, for
+ the base component can be reused provided the same
+ portions of the base component are used in the composed
+ TOE and they are used in a consistent manner.
+
+ In order to determine whether the necessary assurance
+ measures have already been applied to the component, and
+ the portions of the component for which assurance
+ measures still need to be applied, the evaluator should
+ use the output of the .*.2E action and the work units and :
+
+
+
+ For those interfaces identified in the reliance
+ information (), but
+ not discussed in development information (), additional information
+ is required. (Identified in .)
+
+ For those interfaces used inconsistently in the
+ composed TOE from the base component (difference
+ between the information provided in and the impact of the differences in use
+ need to be considered. (Identified in .*.2E.)
+
+ For those interfaces identified in composition
+ rationale for which no assurance has previously been
+ gained, additional information is
+ required. (Identified in .)
+
+ For those interfaces consistently described in the
+ reliance information, composition rationale and the
+ development information, no further action is
+ required as the results from the base component
+ evaluation can be re-used.
+
+ The interfaces of the base component reported to be
+ required by the reliance information but not included in
+ the development information indicate the portions of the
+ base component where further assurance is required. The
+ interfaces identify the entry points into the base
+ component.
+
+ For those interfaces included in both the development
+ information and reliance information, the evaluator is
+ to determine whether the interfaces are being used in
+ the composed TOE in a manner that is consistent with the
+ base component evaluation. The method of use of the
+ interface will be considered during the activities to determine that
+ the use of the interface is consistent in both the base
+ component and the composed TOE. The remaining
+ consideration is the determination of whether the
+ configurations of the base component and the composed
+ TOE are consistent. To determine this, the evaluator
+ will consider the guidance documentation of each to
+ ensure they are consistent (see further guidance below
+ regarding consistent guidance documentation). Any
+ deviation in the documentation will be further analysed
+ by the evaluation to determine the possible
+ effects.
+
+ For those interfaces that are consistently described in
+ the reliance information and development information,
+ and for which the guidance is consistent for the base
+ component and the composed TOE, the required level of
+ assurance has been provided.
+
+ The following subsubclauses provide guidance on how to
+ determine consistency between assurance gained in the
+ base component, the evidence provided for the composed
+ TOE, and the analysis performed by the evaluator in the
+ instances where inconsistencies are identified.
+
+
+ The reliance information identifies the interfaces in
+ the dependent component that are to be matched by the
+ base component. If an interface identified in the
+ reliance information is not identified in the
+ development information, then the composition
+ rationale is to provide a justification of how the
+ base component provides the required
+ interfaces.
+
+ If an interface identified in the reliance information
+ is identified in the development information, but
+ there are inconsistencies between the descriptions,
+ further analysis is required. The evaluator identifies
+ the differences in use of the base component as
+ considered in the base component evaluation and the
+ composed TOE evaluation. The evaluator will devise
+ testing to be performed (during the conduct of ) to test the
+ interface.
+
+ The patch status of the base and dependent components
+ as used in the composed TOE should be compared to the
+ patch status of the components during the component
+ evaluations. If any patches have been applied to the
+ components, the composition rationale is to include
+ details of the patches, including any potential impact
+ to the SFRs of the evaluated component. The evaluator
+ should consider the details of the changes provided
+ and verify the accuracy of the potential impact of the
+ change on the component SFRs. The evaluator should
+ then consider whether the changes made by the patch
+ should be verified through testing, and will identify
+ the necessary testing approach. The testing may take
+ the form of repeating the applicable
+ evaluator/developer testing performed for the
+ component evaluation of the component or it may be
+ necessary for the evaluator to devise new tests to
+ confirm the modified component.
+
+ If any of the individual components have been the
+ subject of assurance continuity activities since the
+ completion of the component evaluation, the evaluator
+ will consider the changes assessed in the assurance
+ continuity activities during the independent
+ vulnerability analysis activity for the composed TOE
+ (in ).
+
+
+
+ The guidance for the composed TOE is likely to make
+ substantial reference out to the guidance for the
+ individual components. The minimal guidance expected
+ to be necessary is the identification of any ordering
+ dependencies in the application of guidance for the
+ dependent and base components, particularly during the
+ preparation (installation) of the composed TOE.
+
+ In addition to the application of the and families to the guidance for the
+ composed TOE, it is necessary to analyse the
+ consistency between the guidance for the components
+ and the composed TOE, to identify any
+ deviations.
+
+ If the composed TOE guidance refers out to the base
+ component and dependent component guidance, then the
+ consideration for consistency is limited to
+ consistency between the guidance documentation
+ provided for each of the components (i.e. consistency
+ between the base component guidance and the dependent
+ component guidance). However, if additional guidance
+ is provided for the composed TOE, to that provided for
+ the components, greater analysis is required, as
+ consistency is also required between the guidance
+ documentation for the components and guidance
+ documentation for the composed TOE.
+
+ Consistent in this instance is
+ understood to mean that either the guidance is the
+ same or it places additional constraints on the
+ operation of the individual components when combined,
+ in a similar manner to refinement of
+ functional/assurance components.
+
+ With the information available (that used as input for
+ or the development
+ aspects discussed above) the evaluator may be able to
+ determine all possible impacts of the deviation from
+ the configuration of the base component specified in
+ the component evaluation. However, for high EALs
+ (where evaluation of the base component included requirements) it is
+ possible that, unless detailed design abstractions for
+ the base component are delivered as part of the
+ development information for the composed TOE, the
+ possible impacts of the modification to the guidance
+ cannot be fully determined as the internals are
+ unknown. In this case the evaluator will report the
+ residual risk of the analysis.
+
+ These residual risks are to be included in any public
+ evaluation report for the composed TOE.
+
+ The evaluator will note these variances in the
+ guidance for input into evaluator independent testing
+ activities ().
+
+ The guidance for the composed TOE may add to the
+ guidance for the components, particularly in terms of
+ installation and the ordering of installation steps
+ for the base component in relation to the installation
+ steps for the dependent component. The ordering of
+ the steps for the installation of the individual
+ components should not change, however they may need to
+ be interleaved. The evaluator will examine this
+ guidance to ensure that it still meets the requirement
+ of the activity
+ performed during the evaluations of the
+ components.
+
+ It may be the case that the reliance information
+ identifies that interfaces of the base component, in
+ addition to those identified as TSFIs of the base
+ component, are relied upon by the dependent component
+ are identified in the reliance information. It may be
+ necessary for guidance to be provided for the use of
+ any such additional interfaces in the base
+ component. Provided the consumer of the composed TOE
+ is to receive the guidance documentation for the base
+ component, then the results of the and
+ verdicts for the base component can be reused for
+ those interfaces considered in the evaluation of the
+ base component. However, for the additional interfaces
+ relied upon by the dependent component, the evaluator
+ will need to determine that the guidance documentation
+ for the base component meets the requirements of and , as applied in the base component
+ evaluations.
+
+ For those interfaces considered during the base
+ component evaluation, and therefore, for which
+ assurance has already been gained, the evaluator will
+ ensure that the guidance for the use of each interface
+ for the composed TOE is consistent with that provided
+ for the base component. To determine the guidance for
+ the composed TOE is consistent with that for the base
+ component, the evaluator should perform a mapping for
+ each interface to the guidance provided for both the
+ composed TOE and the base component. The evaluator
+ then compares the guidance to determine
+ consistency.
+
+ Examples of additional constraints provided in
+ composed TOE guidance that would be considered to be
+ consistent with component guidance are (guidance for a
+ component is given followed by an example of guidance
+ for a composed TOE that would be considered to provide
+ additional constraints):
+
+
+ Component: The password length must be set to a
+ minimum of 8 characters length, including
+ alphabetic and numeric characters.
+
+ Composed TOE: The password length must be set to a
+ minimum of 10 characters in length, including
+ alphabetic and numeric characters and at
+ least one of the following special characters: ( )
+ { } ^ < > - _
+
+ NOTE: It would only be acceptable to increase the
+ password length to [integer >
+ 8] characters while removing the mandate
+ for the inclusion of both alphabetic and numeric
+ characters for the composed TOE, if the same or a
+ higher metric was achieved for the strength rating
+ (taking into account the likelihood of the
+ password being guessed).
+
+ Component: The following services are to be
+ disabled in the registry settings: WWW Publishing
+ Service and ICDBReporter service.
+
+ Composed TOE: The following services are to be
+ disabled in the registry settings:
+ Publishing Service, ICDBReporter service,
+ Remote Procedure Call (RPC) Locator and Procedure
+ Call (RPC) Service.
+
+ Component: Select the following attributes to be
+ included in the accounting log files: date, time,
+ type of event, subject identity and
+ success/failure.
+
+ Composed TOE: Select the following attributes to
+ be included in the accounting log files: date,
+ time, type of event, subject identity,
+ success/failure, event message and process
+ thread.
+
+ If the guidance for the composed TOE deviates (is not
+ a refinement) from that provided for the base
+ component, the evaluator will assess the potential
+ risks of the modification to the guidance. The
+ evaluator will use the information available
+ (including that provided in the public domain, the
+ architectural description of the base component in the
+ public evaluation report (e.g. certification report),
+ the context of the guidance from the remainder of the
+ guidance documentation) to identify likely impact of
+ the modification to the guidance on the SFRs of the
+ composed TOE.
+
+ If during the dependent component evaluation the trial
+ installation used the base component to satisfy the
+ environment requirements of the dependent component
+ this work unit for the composed TOE is considered to
+ be satisfied. If the base component was not used in
+ satisfaction of the work unit during the dependent component
+ evaluation, the evaluator will apply the user
+ procedures provided for the composed TOE to prepare
+ the composed TOE, in accordance with the guidance
+ specified in . This will allow the evaluator to
+ determine that the preparative guidance provided for
+ the composed TOE is sufficient to prepare the composed
+ TOE and its operational environment securely.
+
+
+
+
+ If there is a different delivery mechanism used for
+ the delivery of the composed TOE (i.e. the
+ components are not delivered to the consumer in
+ accordance with the secure delivery procedures
+ defined and assessed during the evaluation of the
+ components), the delivery procedures for the
+ composed TOE will require evaluation against the
+ requirements
+ applied during the components evaluations.
+
+ The composed TOE may be delivered as an integrated
+ product or may require the components to be
+ delivered separately.
+
+ If the components are delivered separately, the
+ results of the delivery of the base component and
+ dependent component are reused. The delivery of the
+ base component is checked during the evaluator trial
+ installation of the dependent component, using the
+ specified guidance and checking the aspects of
+ delivery that are the responsibility of the user, as
+ described in the guidance documentation for the base
+ component.
+
+ If the composed TOE is delivered as a new entity,
+ then the method of delivery of that entity must be
+ considered in the composed TOE evaluation
+ activities.
+
+ The assessment of the delivery procedures for
+ composed TOE items is to be performed in accordance
+ with the methodology for as for any other [component] TOE,
+ ensuring any additional items (e.g. additional
+ guidance documents for the composed TOE) are
+ considered in the delivery procedures.
+
+
+
+ The unique identification of the composed TOE is
+ considered during the application of and the items from
+ which that composed TOE is comprised are considered
+ during the application of .
+
+ Although additional guidance may be produced for the
+ composed TOE, the unique identification of this
+ guidance (considered as part of the unique
+ identification of the composed TOE during ) is considered
+ sufficient control of the guidance.
+
+ The verdicts of the remaining (not considered above)
+ activities can be
+ reused from the base component evaluation, as no
+ further development is performed during integration
+ of the composed TOE.
+
+ There are no additional considerations for
+ development security as the integration is assumed
+ to take place at either the consumer's site or, in
+ the instance that the composed TOE is delivered as
+ an integrated product, at the site of the dependent
+ component developer. Control at the consumer's site
+ is outside the consideration of the CC. No
+ additional requirements or guidance are necessary if
+ integration is at the same site as that for the
+ dependent component, as all components are
+ considered to be configuration items for the
+ composed TOE, and should therefore be considered
+ under the dependent component developer's security
+ procedures anyway.
+
+ Tools and techniques adopted during integration will
+ be considered in the evidence provided by the
+ dependent component developer. Any tools/techniques
+ relevant to the base component will have been
+ considered during the evaluation of the base
+ component. For example, if the base component is
+ delivered as source code and requires compilation by
+ the consumer (e.g. dependent component developer who
+ is performing integration) the compiler would have
+ been specified and assessed, along with the
+ appropriate arguments, during evaluation of the base
+ component.
+
+ There is no life-cycle definition applicable to the
+ composed TOE, as no further development of items is
+ taking place.
+
+ The results of flaw remediation for a component are
+ not applicable to the composed TOE. If flaw
+ remediation is included in the assurance package for
+ the composed TOE, then the requirements are to be applied during
+ the composed TOE evaluation (as for any
+ augmentation).
+
+
+
+
+ The composed TOE will have been tested during the
+ conduct of the activities
+ for evaluation of the dependent component, as the
+ configurations used for testing of the dependent
+ component should have included the base component to
+ satisfy the requirements for IT in the operational
+ environment. If the base component was not used in the
+ testing of the dependent component for the dependent
+ component evaluation, or the configuration of either
+ component varied from their evaluated configurations,
+ then the developer testing performed for evaluation of
+ the dependent component to satisfy the requirements is to be repeated
+ on the composed TOE.
+
+
+
+
+
+
+
+
+ This family sets out requirements for a specification of the
+ base component in increasing levels of detail. Such
+ information is required to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component (as identified
+ in the reliance information).
+
+
+
+ provides details of the
+ base component interfaces and internals in increasing levels
+ of detail, mirroring the level of detail provided by . The application of these two
+ families will provide the specifications of security
+ services from each perspective of the TSF making the call
+ and the TSF servicing the call.
+
+ Having the two descriptions then allows a determination to
+ be made, as part of the
+ activities (.*.2E actions),
+ that these two descriptions are consistent.
+
+
+
+ The components are levelled on the basis of increasing
+ amounts of detail about the interfaces provided, and how
+ they are implemented.
+
+
+
+ The TSF of the base component is often defined without
+ knowledge of the dependencies of the possible applications
+ with which it may by composed. The TSF of this base
+ component is defined to include all parts of the base
+ component that have to be relied upon for enforcement of the
+ base component SFRs. This will include all parts of the base
+ component required to implement the base component
+ SFRs.
+
+ The functional specification of the base component will
+ describe the TSFI in terms of the interfaces the base
+ component provides to allow an external entity to invoke
+ operations of the TSF. This includes interfaces to the
+ human user to permit interaction with the operation of the
+ TSF invoking SFRs and also interfaces allowing an external
+ IT entity to make calls into the TSF.
+
+ The functional specification only provides a description of
+ what the TSF provides at its interface and the means by
+ which that TSF functionality are invoked. Therefore, the
+ functional specification does not necessarily provide a
+ complete interface specification of all possible interfaces
+ available between an external entity and the base
+ component. It does not include what the TSF expects/requires
+ from the operational environment. The description of what a
+ dependent component TSF relies upon of a base component is
+ considered in and the
+ development information evidence provides a response to the
+ interfaces specified.
+
+ The development information evidence includes a
+ specification of the base component. This may be the
+ evidence used during evaluation of the base component to
+ satisfy the requirements, or may
+ be another form of evidence produced by either the base
+ component developer or the composed TOE developer. This
+ specification of the base component is used during to gain confidence that the
+ appropriate security functionality is provided to support
+ the requirements of the dependent component. The level of
+ detail required of this evidence increases to reflect the
+ level of required assurance in the composed TOE. This is
+ expected to broadly reflect the increasing confidence gained
+ from the application of the assurance packages to the
+ components. The evaluator determines that this description
+ of the base component is consistent with the reliance
+ information provided for the dependent component.
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces of the base
+ component to determine that they are consistent with the
+ interfaces specified in the reliance information; those
+ required by the dependent component.
+
+ The description of the interfaces into the base component
+ is to be provided at a level of detail consistent with
+ although not all of the
+ aspects necessary for satisfaction of are required for , as once the interface has been identified
+ and the purpose described the remaining detail of the
+ interface specification can be reused from evaluation of
+ the base component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose of
+ each interface of the base component used in the composed
+ TOE.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during activity).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ In addition, the security behaviour of the base component
+ that supports the dependent component TSF is
+ described.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component, which
+ supports the enforcement of the dependent component SFRs.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component that supports the enforcement of the dependent
+ component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+
+ A description of the interfaces in the base component, on
+ which the dependent component relies, is required. This is
+ examined to determine whether or not it is consistent with
+ the description of interfaces on which the dependent
+ component relies, as provided in the reliance
+ information.
+
+ The interface description of the architecture of the base
+ component is provided to enable the evaluator to determine
+ whether or not that interface formed part of the TSF of
+ the base component.
+
+
+
+ The objective of this sub-activity is to determine that
+ the appropriate security functionality is provided by the
+ base component to support the dependent component. This is
+ achieved through examination of the interfaces and
+ associated security behaviour of the base component to
+ determine that they are consistent with the interfaces
+ specified in the reliance information; those required by
+ the dependent component.
+
+ In addition to the interface description, the subsystems
+ of the base component that provide the security
+ functionality required by the dependent component will be
+ described to enable the evaluator to determine whether or
+ not that interface formed part of the TSF of the base
+ component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the development information;
+
+
+ reliance information.
+
+
+
+
+ The developer shall provide development information for the
+ base component.
+
+
+ The development information shall describe the purpose and
+ method of use of each interface of the base component used
+ in the composed TOE.
+
+
+ The development information shall identify the subsystems of
+ the base component that provide interfaces of the base
+ component used in the composed TOE.
+
+
+ The development information shall provide a high-level
+ description of the behaviour of the base component
+ subsystems, which support the enforcement of the dependent
+ component SFRs.
+
+
+ The development information shall provide a mapping from the
+ interfaces to the subsystems of the base component.
+
+
+ The development information shall show correspondence
+ between the interfaces, used in the composed TOE, of the
+ base component and the dependent component to support the
+ TSF of the dependent component.
+
+
+ The evaluator shall confirm that the information meets all
+ requirements for content and presentation of evidence.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the purpose of each
+ interface.
+
+ The base component provides interfaces to support
+ interaction with the dependent component in the
+ provision of the dependent TSF. The purpose of each
+ interface is to be described at the same level as the
+ description of the interfaces to the dependent component
+ TSF functionality, as would be provided between
+ subsystems in the TOE design (). This description is to provide the
+ reader with an understanding of how the base component
+ provides the services required by the dependent
+ component TSF.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the method of use for
+ each interface.
+
+ The method of use for an interface summarises how the
+ interface is manipulated in order to invoke the
+ operations and obtain results associated with the
+ interface. The evaluator should be able to determine
+ from reading this material in the development
+ information how to use each interface. This does not
+ necessarily mean that there needs to be a separate
+ method of use for each interface, as it may be possible
+ to describe in general how APIs are invoked, for
+ instance, and then identify each interface using that
+ general style.
+
+ This work unit may be satisfied by the provision of the
+ functional specification for the base component for
+ those interfaces that are TSFIs of the base
+ component.
+
+
+
+ The evaluator shall examine the development information
+ to determine that all subsystems of the base component
+ that provide interfaces to the dependent component are
+ identified.
+
+ For those interfaces that are considered to form part of
+ the TSFI of the base component, the subsystems
+ associated with the interface will be subsystems
+ considered in the
+ activity during the base component evaluation. The
+ interfaces on which the dependent component relies that
+ did not form part of the TSFI of the base component will
+ map to subsystems outside of the base component
+ TSF.
+
+
+
+ The evaluator shall examine the development information
+ to determine that it describes the behaviour of the base
+ component subsystems that support the enforcement of the
+ dependent component SFRs.
+
+ The dependent component invokes interfaces of the base
+ component for the provision of services by the base
+ component. For the interfaces of the base component that
+ are invoked, the development information shall provide a
+ high-level description of the associated security
+ behaviour of the base component. The description of the
+ base component security behaviour will outline how the
+ base component provides the necessary service when the
+ call to the interface is made. This description is to be
+ at a level similar to that provided for . Therefore, the provision
+ of the TOE design evidence from the base component
+ evaluation would satisfy this work unit, where the
+ interfaces invoked by the dependent component are TSFI
+ of the base component. If the interfaces invoked by the
+ dependent component are not TSFIs of the base component
+ it is the associated security behaviour will not
+ necessarily be described in the base component TOE
+ design evidence.
+
+
+
+
+ The evaluator shall examine the development information
+ to determine that the correspondence between the
+ interfaces and subsystems of the base component is
+ accurate.
+
+ If the TOE design and functional specification evidence
+ from the base component evaluation is available, this
+ can be used to verify the accuracy of the correspondence
+ between the interfaces and subsystems of the base
+ component as used in the composed TOE. Those interfaces
+ of the base component, which formed part of the base
+ component TSFI will be described in the base component
+ functional specification, and the associated subsystems
+ will be described in the base component TOE design
+ evidence. The tracing between the two will be provided
+ in the base component TOE design evidence.
+
+ If, however, the base component interface did not form
+ part of the TSFI of the base component, the description
+ of the subsystem behaviour provided in the development
+ information will be used to verify the accuracy of the
+ correspondence.
+
+
+
+ The evaluator shall examine the development information
+ to determine the correspondence, between the interfaces
+ of the base component and the interfaces on which the
+ dependent component relies, is accurate.
+
+ The correspondence between the interfaces of the base
+ component and the interfaces on which the dependent
+ component relies may take the form of a matrix or
+ table. The interfaces that are relied upon by the
+ dependent component are identified in the reliance
+ information (as examined during ).
+
+ There is, during this activity, no requirement to
+ determine completeness of the coverage of interfaces
+ that are relied upon by the dependent component, only
+ that the correspondence is correct and ensuring that
+ interfaces of the base component are mapped to
+ interfaces required by the dependent component wherever
+ possible. The completeness of the coverage is considered
+ in activities.
+
+
+
+ The evaluator shall determine that the interface description
+ provided is consistent with the reliance information
+ provided for the dependent component.
+
+
+ The evaluator shall examine the development information
+ and the reliance information to determine that the
+ interfaces are described consistently.
+
+ The evaluator's goal in this work unit is to determine
+ that the interfaces described in the development
+ information for the base component and the reliance
+ information for the dependent component are represented
+ consistently.
+
+
+
+
+
+
+ The purpose of this family is to provide evidence that
+ describes the reliance that a dependent component has upon
+ the base component. This information is useful to persons
+ responsible for integrating the component with other
+ evaluated IT components to form the composed TOE, and for
+ providing insight into the security properties of the
+ resulting composition.
+
+ This provides a description of the interface between the
+ dependent and base components of the composed TOE that may
+ not have been analysed during evaluation of the individual
+ components, as the interfaces were not TSFIs of the
+ individual component TOEs.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant during
+ evaluation of the component, either because of the inherent
+ purpose of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces when evaluating the base component, and are in
+ addition to the security interfaces (TSFIs) considered in
+ the functional specification.
+
+
+
+ The components in this family are levelled according to the
+ amount of detail provided in the description of the reliance
+ by the dependent component upon the base component.
+
+
+
+ The family considers the
+ interactions between the components where the dependent
+ component relies upon a service from the base component to
+ support the operation of security functionality of the
+ dependent component. The interfaces into these services of
+ the base component may not have been considered during
+ evaluation of the base component because the service in the
+ base component was not considered security-relevant in the
+ component evaluation, either because of the inherent purpose
+ of the service (e.g., adjust type font) or because
+ associated CC SFRs are not being claimed in the base
+ component's ST (e.g. the login interface when no SFRs are claimed). These interfaces
+ into the base component are often viewed as functional
+ interfaces in the evaluation of the base component, and are
+ in addition to the security interfaces (TSFI) considered in
+ the functional specification.
+
+ In summary, the TSFIs described in the functional
+ specification only include the calls made into a TSF by
+ external entities and responses to those calls. Calls made
+ by a TSF, which were not explicitly considered during
+ evaluation of the components, are described by the reliance
+ information provided to satisfy .
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. These are
+ provided in terms of a high-level description.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF protects
+ itself from interference and tampering by the base
+ component.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer's reliance evidence provides
+ sufficient information to determine that the necessary
+ functionality is available in the base component, and the
+ means by which that functionality is invoked. This is
+ provided in terms of the interfaces between the
+ dependent and base component and the return values from
+ those interfaces called by the dependent component.
+
+
+
+
+ A dependent component whose TSF interacts with the base
+ component requires functionality provided by that base
+ component (e.g., remote authentication, remote audit data
+ storage). In these cases, those invoked services need to
+ be described for those charged with configuring the
+ composed TOE for end users. The rationale for requiring
+ this documentation is to aid integrators of the composed
+ TOE to determine what services in the base component might
+ have adverse effects on the dependent component, and to
+ provide information against which to determine the
+ compatibility of the components when applying the family.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed ST;
+
+
+ the dependent component functional specification;
+
+
+ the dependent component design;
+
+
+ the dependent component implementation representation;
+
+
+ the dependent component architectural design;
+
+
+ the reliance information.
+
+
+
+
+ The developer shall provide reliance information of the
+ dependent component.
+
+
+ The reliance information shall describe the functionality of
+ the base component hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+
+ The reliance information shall describe all interactions
+ through which the dependent component TSF requests services
+ from the base component.
+
+
+ The reliance information shall describe each interaction in
+ terms of the interface used and the return values from those
+ interfaces.
+
+
+ The reliance information shall describe how the dependent
+ TSF protects itself from interference and tampering by the
+ base component.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check the reliance information to
+ determine that it describes the functionality of the
+ base dependent hardware, firmware and/or software that
+ is relied upon by the dependent component TSF.
+
+ The evaluator assesses the description of the security
+ functionality that the dependent component TSF requires
+ to be provided by the base component's hardware,
+ firmware and software. The emphasis of this work unit is
+ on the level of detail of this description, rather than
+ on an assessment of the information's accuracy. (The
+ assessment of the accuracy of the information is the
+ focus of the next work unit.)
+
+ This description of the base component's functionality
+ need not be any more detailed than the level of the
+ description of a component of the TSF, as would be
+ provided in the TOE Design ()
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it accurately reflects the objectives
+ specified for the operational environment of the
+ dependent component.
+
+ The reliance information contains the description of the
+ base component's security functionality relied upon by
+ the dependent component. To ensure that the reliance
+ information is consistent with the expectations of the
+ operational environment of the dependent component, the
+ evaluator compares the reliance information with the
+ statement of objectives for the environment in the ST
+ for the dependent component.
+
+ For example, if the reliance information claims that the
+ dependent component TSF relies upon the base component
+ to store and protect audit data, yet other evaluation
+ evidence (e.g. the dependent component design) makes it
+ clear that the dependent component TSF itself is storing
+ and protecting the audit data, this would indicate an
+ inaccuracy.
+
+ It should be noted that the objectives for the
+ operational environment may include objectives that can
+ be met by non-IT measures. While the services that the
+ base component environment is expected to provide may be
+ described in the description of IT objectives for the
+ operational environment in the dependent component ST,
+ it is not required that all such expectations on the
+ environment be described in the reliance
+ information.
+
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes all interactions between the
+ dependent component and the base component, through
+ which the dependent component TSF requests services from
+ the base component.
+
+ The dependent component TSF may request services of the
+ base component that were not within the TSF of the base
+ component (see Annex in CC Part
+ 3).
+
+ The interfaces to the base component's functionality are
+ described at the same level as the description of the
+ interfaces to the dependent component TSF functionality,
+ as would be provided between subsystems in the TOE
+ design ().
+
+ The purpose of describing the interactions between the
+ dependent component and the base component is to provide
+ an understanding of how the dependent component TSF
+ relies upon the base component for the provision of
+ services to support the operation of security
+ functionality of the dependent component. These
+ interactions do not need to be characterised at the
+ implementation level (e.g. parameters passed from one
+ routine in a component to a routine in another
+ component), but the data elements identified for a
+ particular component that are going to be used by
+ another component should be covered in this
+ description. The statement should help the reader
+ understand in general why the interaction is
+ necessary.
+
+ Accuracy and completeness of the interfaces is based on
+ the security functionality that the TSF requires to be
+ provided by the base component, as assessed in work
+ units and . It should be possible to
+ map all of the functionality described in the earlier
+ work units to the interfaces identified in this work
+ unit, and vice versa. An interface that does not
+ correspond to described functionality would also
+ indicate an inadequacy.
+
+
+
+ The reliance information shall describe each interaction
+ in terms of the interface used and the return values
+ from those interfaces.
+
+ The identification of the interfaces used by the
+ dependent component TSF when making services requests of
+ the base component allows an integrator to determine
+ whether the base component provides all the necessary
+ corresponding interfaces. This understanding is further
+ gained through the specification of the return values
+ expected by the dependent component. The evaluator
+ ensures that interfaces are described for each
+ interaction specified (as analysed in ).
+
+
+
+ The evaluator shall examine the reliance information to
+ determine that it describes how the dependent TSF protects
+ itself from interference and tampering by the base
+ component.
+
+ The description of how the dependent component protects
+ itself from interference and tampering by the base
+ component is to be provided at the same level of detail
+ as necessary for .
+
+
+
+
+
+
+ This family requires that testing of composed TOE and
+ testing of the base component, as used in the composed TOE,
+ is performed.
+
+
+
+ The family details
+ requirements for testing to demonstrate that the composed
+ TOE operates as specified in the composed TOE SFRs and the
+ base component interfaces match the design descriptions as
+ provided in the development information (). Testing evidence is to be provided of all
+ SFRs specified in the composed TOE ST and to exercise all
+ base component interfaces used by the dependent component,
+ as identified in .
+
+
+
+ The components in this family are levelled on the basis of
+ increasing rigour of interface testing and increasing rigour
+ of the analysis of the sufficiency of the tests to
+ demonstrate that the composed TSF operates in accordance
+ with the reliance information and the composed TOE
+ SFRs.
+
+
+
+ There are two distinct aspects of testing associated with
+ this family:
+
+
+ testing of the interfaces between the base component and
+ the dependent component, which the dependent component
+ rely upon for enforcement of security functionality, to
+ demonstrate their compatibility;
+
+
+ testing of the composed TOE to demonstrate that the TOE
+ behaves in accordance with the SFRs for the composed
+ TOE.
+
+
+
+ If the test configurations used during evaluation of the
+ dependent component included use of the base component as a
+ ``platform'' and the test analysis sufficiently demonstrates
+ that the TSF behaves in accordance with the SFRs, the
+ developer need perform no further testing of the composed
+ TOE functionality. However, if the base component was not
+ used in the testing of the dependent component, or the
+ configuration of either component varied, then the developer
+ is to perform testing of the composed TOE. This may take
+ the form of repeating the dependent component developer
+ testing of the dependent component, provided this adequately
+ demonstrates the composed TOE TSF behaves in accordance with
+ the SFRs.
+
+ The developer is to provide evidence of testing the base
+ component interfaces used in the composition. The operation
+ of base component TSFIs would have been tested as part of
+ the activities during
+ evaluation of the base component. Therefore, provided the
+ appropriate interfaces were included within the test sample
+ of the base component evaluation and it was determined in
+ that the base component is
+ operating in accordance with the base component evaluated
+ configuration, with all security functionality required by
+ the dependent component included in the TSF, the evaluator
+ action may be met
+ through reuse of the base component verdicts.
+
+ If this is not the case, the base component interfaces used
+ relevant to the composition that are affected by any
+ variations to the evaluated configuration and any additional
+ security functionally will be tested to ensure they
+ demonstrate the expected behaviour. The expected behaviour
+ to be tested is that described in the reliance information
+ ( evidence).
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to ensure the expected behaviour of all composed TOE SFRs
+ and interfaces of the base component relied upon by the
+ dependent component is demonstrated.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the SFRs specified
+ for the composed TOE to identify which SFRs have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ The evaluator should construct a mapping between the
+ tests described in the test plan and the interfaces of
+ the base component relied upon by the dependent
+ component (as specified in the reliance information,
+ examined under ) to
+ identify which base component interfaces have been
+ tested by the developer.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to verify the
+ developer test results.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to confirm that the
+ TSF operates as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to ensure that each
+ interface of the base component, on which the dependent
+ component relies, is tested.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented tests for
+ each of the base component interfaces on which the
+ dependent component relies. As part of this determination
+ the evaluator repeats a sample of the tests performed by
+ the developer and performs any additional tests required
+ to fully demonstrate the expected behaviour of the
+ composed TOE and the interfaces of the base component
+ relied upon by the dependent component.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed TOE testing evidence;
+
+
+ the reliance information;
+
+
+ the development information.
+
+
+
+
+ The developer shall provide composed TOE test documentation.
+
+
+ The developer shall provide base component interface test
+ documentation.
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the base component developer's
+ functional testing of the base component.
+
+
+ The composed TOE and base component interface test
+ documentation shall consist of test plans, expected test
+ results and actual test results.
+
+
+ The test documentation from the developer execution of the
+ composed TOE tests shall demonstrate that the TSF behaves as
+ specified and is complete.
+
+
+ The test documentation from the developer execution of the
+ base component interface tests shall demonstrate that the
+ base component interface relied upon by the dependent
+ component behaves as specified and is complete.
+
+
+ The base component shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the composed TOE test
+ documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the dependent component
+ if the base component was used to satisfy the
+ requirements for IT in the operational environment of
+ the dependent component.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+ The evaluator shall examine the base component interface
+ test documentation to determine that it consists of test
+ plans, expected test results and actual test
+ results.
+
+ This work unit may be satisfied by provision of the test
+ evidence from the evaluation of the base component for
+ those interfaces relied upon in the composed TOE by the
+ dependent component are TSFIs of the successfully
+ evaluated base component. The determination of whether
+ the interfaces of the base component relied upon by the
+ dependent component were in fact TSFIs of the evaluated
+ base component is made during the activity.
+
+ All work units necessary for the satisfaction of will be applied to
+ determine:
+
+
+ that the test documentation consist of test plans
+ expected test results and actual test
+ results;
+
+ that the test documentation contains the information
+ necessary to ensure the tests are repeatable;
+
+ the level of developer effort that was applied to
+ testing of the base component.
+
+
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the composed TOE and the composed TOE
+ SFRs in the composed TOE security target.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and SFRs presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the composed
+ TOE tests shall demonstrate that the TSF behaves as
+ specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the SFRs
+ of the composed TOE, as tested by the developer, behave
+ as expected.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that it provides accurate correspondence
+ between the tests in the test documentation relating to
+ the testing of the base component interfaces relied upon
+ by the dependent component and the interfaces specified
+ in the reliance information.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of correspondence
+ between the tests and interfaces presented in the test
+ documentation has to be unambiguous.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that the developer execution of the base
+ component interface tests shall demonstrate that the
+ base component interfaces relied upon by the dependent
+ component behave as specified.
+
+ Guidance on this work unit can be found in:
+
+
+ Clause .
+
+ Clause .
+
+
+ The outputs from the successful execution of the tests
+ (as assessed for can
+ be compared with the mapping to determine that the
+ interfaces of the base component, as tested by the
+ developer, behave as expected.
+
+
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the TOE provided by the developer for
+ testing.
+
+
+
+
+ The evaluator shall examine the set of resources
+ provided by the developer to determine that they are
+ equivalent to the set of resources used by the base
+ component developer to functionally test the base
+ component.
+
+ To determine that the set of resources provided are
+ equivalent to those used to functionally test the base
+ component as used in the composed TOE, the work unit will be
+ applied.
+
+
+
+ The evaluator shall execute a sample of test in the test
+ documentation to verify the developer test results.
+
+
+ The tests are to be selected and executed in accordance
+ with , to
+ demonstrate the correct behaviour of the SFRs specified
+ in the composed TOE security target.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ associated work units.
+
+
+
+ The evaluator shall test a subset of the TSF interfaces of
+ the composed TOE to confirm that the composed TSF operates
+ as specified.
+
+
+ The evaluator shall perform testing in accordance with , for a subset of the SFRs
+ specified in the composed security target, to confirm that the
+ TSF operates as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the TSF of the composed TOE
+ to test, the evaluator should take into account any
+ modifications to the components from the evaluated
+ version or configuration. Modifications to the component
+ from that evaluated may include patches introduced, a
+ different configuration as a result of modified guidance
+ documentation, reliance an additional portion of the
+ component that was not within the TSF of the
+ component. These modifications will have been identified
+ during the
+ activity.
+
+
+
+ The evaluator shall perform testing, in accordance with
+ , for a subset of the
+ interfaces to the base component to confirm they operate
+ as specified.
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of , reporting in the ETR for the composed TOE
+ all analysis, results and verdicts as dictated by the
+ work units.
+
+ When selecting interfaces of the base component to test,
+ the evaluator should take into account any modifications
+ to the base component from the evaluated version or
+ configuration. In particular, the evaluator should
+ consider the development of tests to demonstrate the
+ correct behaviour of interfaces of the base component
+ that were not considered during the evaluation of the
+ base component. These additional interfaces and other
+ modifications to the base component will have been
+ identified during the
+ activity.
+
+
+
+
+
+
+
+ This family calls for an analysis of vulnerability
+ information available in the public domain and of
+ vulnerabilities that may be introduced as a result of the
+ composition.
+
+
+
+ The vulnerability analysis in includes determination of two different
+ aspects of resistance by the composed TOE, namely:
+
+
+ Residual vulnerabilities in the base and dependent
+ components remain unexploitable in the operational
+ environment of the composed TOE;
+
+ The composed TOE is resistant to attackers with a given
+ level of attack potential.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing scrutiny of vulnerability information from the
+ public domain and independent vulnerability analysis.
+
+
+
+ The developer will provide details of any residual
+ vulnerabilities reported during evaluation of the
+ components. These may be gained from the component
+ developers or evaluation reports for the components. These
+ will be used as inputs into the evaluator's vulnerability
+ analysis of the composed TOE in the operational
+ environment.
+
+
+ The operational environment of the composed TOE is examined
+ to ensure that the assumptions and objectives for the
+ component operational environment (specified in each
+ component ST) are satisfied in the composed TOE. An initial
+ analysis of the consistency of assumptions and objectives
+ between the components and the composed TOE STs will have
+ been performed during the conduct of the activities for the composed TOE. However, this
+ analysis is revisited with the knowledge acquired during the
+ , and the
+ activities to ensure that, for example, assumptions of the
+ dependent component that were addressed by the environment
+ in the dependent component ST are not reintroduced as a
+ result of composition (i.e. that the base component
+ adequately addresses the assumptions of the dependent
+ component ST in the composed TOE).
+
+ A search by the evaluator for issues in each component will
+ identify potential vulnerabilities reported in the public
+ domain since completion of the evaluation of the components.
+ Any potential vulnerabilities will then be subject to
+ testing.
+
+ If the base component used in the composed TOE has been the
+ subject of assurance continuity activities since
+ certification, the evaluator will consider during the
+ composed TOE vulnerability analysis activities the changes
+ made in base component.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ easily exploitable vulnerabilities.
+
+ The developer provides details of any residual
+ vulnerabilities reported from evaluation of the
+ components. The evaluator performs an analysis of the
+ disposition the residual vulnerabilities reported and also
+ performs a search of the public domain, to identify any
+ new potential vulnerabilities in the components
+ (i.e. those issues that have been reported in the public
+ domain since evaluation of the base component). The
+ evaluator then performs penetration testing to demonstrate
+ that the potential vulnerabilities cannot be exploited in
+ the TOE, in its operational environment, by an attacker
+ with basic attack potential.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities;
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes a component from the
+ family, then the
+ evaluator may refer to the result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the base component
+ that have become known since the completion of
+ evaluation of the base component.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the
+ dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (i.e. ), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing basic
+ attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the evaluation
+ of the components). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information publicly
+ available to support the identification of possible security
+ vulnerabilities in the base component that have become known
+ since the completion of the base component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since the completion of
+ the dependent component evaluation.
+
+ The evaluator will use the information in the public domain as
+ described in to search for
+ vulnerabilities in the dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components of the composed TOE
+ in the independent evaluator vulnerability analysis will
+ take a slightly different form to that documented in
+ for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the components, but the evidence may
+ not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the individual
+ components. The focus of the vulnerability analysis
+ during the composed TOE evaluation is to identify any
+ vulnerabilities introduced as a result of the
+ integration of the components or due to any changes in
+ the use of the components between the evaluated
+ component configuration to the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ development information and composition rationale for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact and
+ identify potential vulnerabilities that may be
+ introduced as a result of this interaction.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch(es) in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report) will be the main source of
+ input material of the change. This will be supplemented
+ by any updates to the guidance documentation resulting
+ from the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified vulnerabilities, to demonstrate that the
+ composed TOE is resistant to attacks by an attacker with
+ basic attack potential.
+
+
+ The evaluator shall conduct penetration testing as
+ detailed for .
+
+ The evaluator will apply all work units necessary for
+ the satisfaction of evaluator action , reporting in the ETR
+ for the composed TOE all analysis and verdicts as
+ dictated by the work units.
+
+ The evaluator will also apply the work units for the
+ evaluator action
+ to determine that the composed TOE provided by the
+ developer is suitable for testing.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether the
+ composed TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Enhanced-Basic attack potential.
+
+ The developer provides an analysis of the disposition of
+ any residual vulnerabilities reported for the components
+ and of any vulnerabilities introduced through the
+ combination of the base and dependent components. The
+ evaluator performs a search of the public domain to
+ identify any new potential vulnerabilities in the
+ components (i.e. those issues that have been reported in
+ the public domain since the completion of the component
+ evaluations). The evaluator will also perform an
+ independent vulnerability analysis of the composed TOE and
+ penetration testing.
+
+
+
+ See the application notes for .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the composed TOE suitable for testing;
+
+
+ the composed ST;
+
+
+ the composition rationale;
+
+
+ the reliance information;
+
+
+ the guidance documentation;
+
+
+ information publicly available to support the
+ identification of possible security vulnerabilities.
+
+
+ residual vulnerabilities reported during evaluation of
+ each component.
+
+
+
+
+ The developer shall provide the composed TOE for testing.
+
+
+ The composed TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the composed TOE to
+ determine that it has been installed properly and is in
+ a known state.
+
+ To determine that the composed TOE has been installed
+ properly and is in a known state the and work units will be
+ applied to the composed TOE.
+
+ If the assurance package includes family, then the evaluator may refer to the
+ result of the work unit *-1 to demonstrate this has been
+ satisfied.
+
+
+
+ The evaluator shall examine the composed TOE
+ configuration to determine that any assumptions and
+ objectives in the STs the components relating to IT
+ entities for are fulfilled by the other
+ components.
+
+ The STs for the component may include assumptions about
+ other components that may use the component to which the
+ ST relates, e.g. the ST for an operating system used as
+ a base component may include an assumption that any
+ applications loaded on the operating system do not run
+ in privileged mode. These assumptions and objectives are
+ to be fulfilled by other components in the composed
+ TOE.
+
+
+
+ The evaluator shall perform an analysis to determine that
+ any residual vulnerabilities identified for the base and
+ dependent components are not exploitable in the composed TOE
+ in its operational environment.
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the base component evaluation to determine that
+ they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the base component, which were
+ demonstrated to be non-exploitable in the base
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ base component it was assumed that a particular
+ operating system service was disabled, which is enabled
+ in the composed TOE evaluation, any potential
+ vulnerabilities relating to that service previously
+ scoped out should now be considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ base component should be considered in the light of any
+ known, non-exploitable vulnerabilities for the other
+ components (e.g. dependent component) within the
+ composed TOE. This is to consider the case where a
+ potential vulnerability that is non-exploitable in
+ isolation is exploitable when integrated with an IT
+ entity containing another potential
+ vulnerability.
+
+
+
+ The evaluator shall examine the residual vulnerabilities
+ from the dependent component evaluation to determine
+ that they are not exploitable in the composed TOE in its
+ operational environment.
+
+ The list of vulnerabilities identified in the product
+ during the evaluation of the dependent component, which
+ were demonstrated to be non-exploitable in the dependent
+ component, is to be used as an input into this
+ activity. The evaluator will determine that the
+ premise(s) on which a vulnerability was deemed to be
+ non-exploitable is upheld in the composed TOE, or
+ whether the combination has re-introduced the potential
+ vulnerability. For example, if during evaluation of the
+ dependent component it was assumed that IT meeting the
+ operational environment requirements would not return a
+ certain value in response to a service request, which is
+ provided by the base component in the composed TOE
+ evaluation, any potential vulnerabilities relating to
+ that return value previously scoped out should now be
+ considered.
+
+ Also, this list of known, non-exploitable
+ vulnerabilities resulting from the evaluation of the
+ dependent component should be considered in the light of
+ any known, non-exploitable vulnerabilities for the other
+ components (e.g. base component) within the composed
+ TOE. This is to consider the case where a potential
+ vulnerability that is non-exploitable in isolation is
+ exploitable when integrated with an IT entity containing
+ another potential vulnerability.
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify possible vulnerabilities arising from
+ use of the base and dependent components in the composed TOE
+ operational environment.
+
+
+ The evaluator shall examine the sources of information publicly
+ available to support the identification of possible security
+ vulnerabilities in the base component that have become known
+ since the completion of the base component evaluation.
+
+ The evaluator will use the information in the public
+ domain as described in to search for vulnerabilities in the base
+ component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the base component
+ do not have to be further investigated unless it is
+ apparent to the evaluator that the attack potential
+ required by an attacker to exploit the potential
+ vulnerability has been significantly reduced. This may
+ be through the introduction of some new technology since
+ the base component evaluation that means the
+ exploitation of the potential vulnerability has been
+ simplified.
+
+
+
+ The evaluator shall examine the sources of information
+ publicly available to support the identification of
+ possible security vulnerabilities in the dependent
+ component that have become known since completion of the
+ dependent component evaluation.
+
+ The evaluator will use the information in the public domain as
+ described in to search for
+ vulnerabilities in the dependent component.
+
+ Those potential vulnerabilities that were publicly
+ available prior to the evaluation of the dependent
+ component do not have to be further investigated unless
+ it is apparent to the evaluator that the attack
+ potential required by an attacker to exploit the
+ potential vulnerability has been significantly
+ reduced. This may be through the introduction of some
+ new technology since evaluation of the dependent
+ component that means the exploitation of the potential
+ vulnerability has been simplified.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential security vulnerabilities that are candidates
+ for testing and applicable to the composed TOE in its
+ operational environment.
+
+ The ST, guidance documentation and functional
+ specification are used to determine whether the
+ vulnerabilities are relevant to the composed TOE in its
+ operational environment.
+
+ The evaluator records any reasons for exclusion of
+ vulnerabilities from further consideration if the
+ evaluator determines that the vulnerability is not
+ applicable in the operational environment. Otherwise the
+ evaluator records the potential vulnerability for
+ further consideration.
+
+ A list of potential vulnerabilities applicable to the
+ composed TOE in its operational environment, which can
+ be used as an input into penetration testing activities
+ (), shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the composed TOE, using the guidance
+ documentation, reliance information and composition
+ rationale to identify potential vulnerabilities in the
+ composed TOE.
+
+
+ The evaluator shall conduct a search of the composed TOE
+ ST, guidance documentation, reliance information and
+ composition rationale to identify possible security
+ vulnerabilities in the composed TOE.
+
+ The consideration of the components in the independent
+ evaluator vulnerability analysis will take a slightly
+ different form to that documented in for a component
+ evaluation, as it will not necessarily consider all
+ layers of design abstraction relevant to the assurance
+ package. These will have already been considered during
+ the evaluation of the base component, but the evidence
+ may not be available for the composed TOE
+ evaluation. However, the general approach described in
+ the work units associated with is applicable and should form the basis of
+ the evaluator's search for potential vulnerabilities in
+ the composed TOE.
+
+ A vulnerability analysis of the individual components
+ used in the composed TOE will have already been
+ performed during evaluation of the components. The focus
+ of the vulnerability analysis during the composed TOE
+ evaluation is to identify any vulnerabilities introduced
+ as a result of the integration of the components or due
+ to any changes in the use of the components between the
+ configuration of the component determined during the
+ component evaluation and the composed TOE
+ configuration.
+
+ The evaluator will use the understanding of the
+ component's construction as detailed in the reliance
+ information for the dependent component, and the
+ composition rationale and development information for
+ the base component, together with the dependent
+ component design information. This information will
+ allow the evaluator to gain an understanding of how the
+ base component and dependent component interact.
+
+ The evaluator will consider any new guidance provided
+ for the installation, start-up and operation of the
+ composed TOE to identify any potential vulnerabilities
+ introduced through this revised guidance.
+
+ If any of the individual components have been through
+ assurance continuity activities since the completion of
+ the component evaluation, the evaluator will consider
+ the patch in the independent vulnerability
+ analysis. Information related to the change provided in
+ a public report of the assurance continuity activities
+ (e.g. Maintenance Report). This will be supplemented by
+ any updates to the guidance documentation resulting from
+ the change and any information regarding the change
+ available in the public domain, e.g. vendor
+ website.
+
+ Any risks identified due to the lack of evidence to
+ establish the full impact of any patches or deviations
+ in the configuration of a component from the evaluated
+ configuration are to be documented in the evaluator's
+ vulnerability analysis.
+
+
+
+ The evaluator shall conduct penetration testing, based on the
+ identified vulnerabilities, to demonstrate that the composed TOE
+ is resistant to attacks by an attacker with Enhanced-Basic
+ attack potential.
+
+ The evaluator shall conduct penetration testing as detailed
+ for .
+ The evaluator will apply all work units necessary for the
+ satisfaction of evaluator action , reporting in the ETR for the composed TOE all
+ analysis and verdicts as dictated by the work units.
+ The evaluator will also apply the work units for the
+ evaluator action to
+ determine that the composed TOE provided by the developer is
+ suitable for testing.
+
+
+
+
+
+
+ The requirements of the Development class provide information
+ about the TOE. The knowledge obtained by this information is
+ used as the basis for conducting vulnerability analysis and
+ testing upon the TOE, as described in the and classes.
+
+ The Development class encompasses six families of requirements
+ for structuring and representing the TSF at various levels and
+ varying forms of abstraction. These families include:
+
+ requirements for the description (at the various
+ levels of abstraction) of the design and implementation of
+ the SFRs (, , )
+ requirements for the description of the
+ architecture-oriented features of domain separation, TSF
+ self-protection and non-bypassability of the security
+ functionality ()
+ requirements for a security policy model and for correspondence
+ mappings between security policy model and the functional
+ specification ()
+ requirements on the internal structure of the TSF,
+ which covers aspects such as modularity, layering, and
+ minimisation of complexity ()
+
+ When documenting the security functionality of a TOE, there
+ are two properties that need to be demonstrated. The first
+ property is that the security functionality works correctly;
+ that is, it performs as specified. The second property, and
+ one that is arguably harder to demonstrate, is that the TOE
+ cannot be used in a way such that the security functionality
+ can be corrupted or bypassed. These two properties require
+ somewhat different approaches in analysis, and so the families
+ in are structured to support these
+ different approaches. The families , , , and deal with the first property: the specification
+ of the security functionality. The families and deal with
+ the second property: the specification of the design of the
+ TOE demonstrating the security functionality cannot be
+ corrupted or bypassed. It should be noted that both properties
+ need to be realised: the more confidence one has that the
+ properties are satisfied, the more trustworthy the TOE is. The
+ components in the families are designed so that more assurance
+ can be gained as the components hierarchically
+ increase.
+
+ The paradigm for the families targeted at the first property
+ is one of design decomposition. At the highest level, there is
+ a functional specification of the TSF in terms of its
+ interfaces (describing what the TSF does in
+ terms of requests to the TSF for services and resulting
+ responses), decomposing the TSF into smaller units (dependent
+ on the assurance desired and the complexity of the TOE) and
+ describing how the TSF accomplishes its
+ functions (to a level of detail commensurate with the
+ assurance level), and showing the implementation of the TSF. A
+ formal model of the security behaviour also may be given. All
+ levels of decomposition are used in determining the
+ completeness and accuracy of all other levels, ensuring that
+ the levels are mutually supportive. The requirements for the
+ various TSF representations are separated into different
+ families, to allow the PP/ST author to specify which TSF
+ representations are required. The level chosen will dictate
+ the assurance desired/gained.
+
+ Figure indicates the
+ relationships among the various TSF representations of the
+ class, as well as their
+ relationships with other classes. As the figure indicates, the
+ and
+ classes define the requirements for the correspondence between
+ the SFRs and the security objectives for the TOE. Class also defines requirements for the
+ correspondence between both the security objectives and SFRs,
+ and for the TOE summary specification which explains how the
+ TOE meets its SFRs. The activities of include the verification that the TSF that is
+ tested under the and classes is in fact the one described by all of the
+ decomposition levels.
+
+
+ The requirements for all other correspondence shown in Figure
+ are defined in the
+ class. The family defines the requirements for formally
+ modelling selected SFRs, and providing correspondence between
+ the functional specification and the formal model. Each
+ assurance family specific to a TSF representation (i.e., ,
+ and ) defines requirements
+ relating that TSF representation to the SFRs. All
+ decompositions must accurately reflect all other
+ decompositions (i.e., be mutually supportive); the developer
+ supplies the tracings in the last .C elements of the
+ components. Assurance relating to this factor is obtained
+ during the analysis for each of the levels of decomposition by
+ referring to other levels of decomposition (in a recursive
+ fashion) while the analysis of a particular level of
+ decomposition is being performed; the evaluator verifies the
+ correspondence as part of the second E element. The
+ understanding gained from these levels of decomposition form
+ the basis of the functional and penetration testing
+ efforts.
+
+ The family is not represented
+ in this figure, as it is related to the internal structure of
+ the TSF, and is only indirectly related to the process of
+ refinement of the TSF representations. Similarly, the family is not represented in the
+ figure because it relates to the architectural soundness,
+ rather than representation, of the TSF. Both and
+ relate to the analysis of the property that the TOE cannot be
+ made to circumvent or corrupt its security
+ functionality.
+
+ The TOE security functionality (TSF) consists of all parts of
+ the TOE that have to be relied upon for enforcement of the
+ SFRs. The TSF includes both functionality that directly
+ enforces the SFRs, as well as functionality that, while not
+ directly enforcing the SFRs, contributes to their enforcement
+ in a more indirect manner, including functionality with the
+ capability to cause the SFRs to be violated. This includes
+ portions of the TOE that are invoked on start-up that are
+ responsible for putting the TSF into its initial secure
+ state.
+
+ Several important concepts were used in the development of the
+ components of the families. These
+ concepts, while introduced briefly here, are explained more
+ fully in the application notes for the families.
+
+ One over-riding notion is that, as more information becomes
+ available, greater assurance can be obtained that the security
+ functionality 1) is correctly implemented; 2) cannot be
+ corrupted; and 3) cannot be bypassed. This is done through the
+ verification that the documentation is correct and consistent
+ with other documentation, and by providing information that
+ can be used to ensure that the testing activities (both
+ functional and penetration testing) are comprehensive. This is
+ reflected in the levelling of the components of the
+ families. In general, components are levelled based on the
+ amount of information that is to be provided (and subsequently
+ analysed).
+
+ While not true for all TOEs, it is generally the case that the
+ TSF is sufficiently complex that there are portions of the TSF
+ that deserve more intense examination than other portions of
+ the TSF. Determining those portions is unfortunately somewhat
+ subjective, thus terminology and components have been defined
+ such that as the level of assurance increases, the
+ responsibility for determining what portions of the TSF need
+ to be examined in detail shifts from the developer to the
+ evaluator. To aid in expressing this concept, the following
+ terminology is introduced. It should be noted that in the
+ families of the class, this terminology is used when
+ expressing SFR-related portions of the TOE (that is, elements
+ and work units embodied in the , , and families). While the general
+ concept (that some portions of the TOE are more
+ interesting than others) applies to other
+ families, the criteria are expressed differently in order to
+ obtain the assurance required.
+
+ All portions of the TSF are security
+ relevant, meaning that they must preserve the
+ security of the TOE as expressed by the SFRs and
+ requirements for domain separation and
+ non-bypassability. One aspect of security relevance is the
+ degree to which a portion of the TSF enforces a security
+ requirement. Since different portions of the TOE play
+ different roles (or no apparent role at all) in enforcing
+ security requirements, this creates a continuum of SFR
+ relevance: at one end of this continuum are portions of the
+ TOE that are termed SFR-enforcing. Such
+ portions play a direct role in implementing any SFR on the
+ TOE. Such SFRs refer to any functionality provided by one of
+ the SFRs contained in the ST. It should be noted that the
+ definition of plays a role in for
+ SFR-enforcing functionality is impossible to express
+ quantitatively. For example, in the implementation of a
+ Discretionary Access Control (DAC) mechanism, a very narrow
+ view of SFR-enforcing might be the several
+ lines of code that actually perform the check of a subject's
+ attributes against the object's attributes. A broader view
+ would include the software entity (e.g., C function) that
+ contained the several lines of code. A broader view still
+ would include callers of the C function, since they would be
+ responsible for enforcing the decision returned by the
+ attribute check. A still broader view would include any code
+ in the call tree (or programming equivalent for the
+ implementation language used) for that C function (e.g., a
+ sort function that sorted access control list entries in a
+ first-match algorithm implementation). At some point, the
+ component is not so much enforcing the
+ security policy but rather plays a
+ supporting role; such components are termed
+ SFR supporting.
+
+ One of the characteristics of SFR-supporting functionality is
+ that it is trusted to preserve the correctness of the SFR
+ implementation by operating without error. Such functionality
+ may be depended on by SFR-enforcing functionality, but the
+ dependence is generally at a functional level; for example,
+ memory management, buffer management, etc. Further down on the
+ security relevance continuum is functionality termed
+ SFR non-interfering. Such functionality has
+ no role in implementing the SFRs, and is likely part of the
+ TSF because of its environment; for example, any code running
+ in a privileged hardware mode on an operating system. It needs
+ to be considered part of the TSF because, if compromised (or
+ replaced by malicious code), it could compromise the correct
+ operation of an SFR by virtue of its operating in the
+ privileged hardware mode. An example of SFR non-interfering
+ functionality might be a set of mathematical floating point
+ operations implemented in kernel mode for speed
+ considerations.
+
+ The architecture family ()
+ provides for requirements and analysis of the TOE based on
+ properties of domain separation, self-protection, and
+ non-bypassability. These properties relate to the SFRs in
+ that, if these properties are not present, it will likely lead
+ to the failure of mechanisms implementing SFRs. Functionality
+ and design relating to these properties is
+ not considered a part of the continuum described
+ above, but instead is treated separately due to its
+ fundamentally different nature and analysis
+ requirements.
+
+ The difference in analysis of the implementation of SFRs
+ (SFR-enforcing and SFR-supporting functionality) and the
+ implementation of somewhat fundamental security properties of
+ the TOE, which include the initialisation, self-protection,
+ and non-bypassability concerns, is that the SFR-related
+ functionality is more or less directly visible and relatively
+ easy to test, while the above-mentioned properties require
+ varying degrees of analysis on a much broader set of
+ functionality. Further, the depth of analysis for such
+ properties will vary depending on the design of the TOE. The
+ families are constructed to address
+ this by a separate family ()
+ devoted to analysis of the initialisation, self-protection,
+ and non-bypassability requirements, while the other families
+ are concerned with analysis of the functionality supporting
+ SFRs.
+
+ Even in cases where different descriptions are necessary for
+ the multiple levels of abstraction, it is not absolutely
+ necessary for each and every TSF representation to be in a
+ separate document. Indeed, it may be the case that a single
+ document meets the documentation requirements for more than
+ one TSF representation, since it is the information about each
+ of these TSF representations that is required, rather than the
+ resulting document structure. In cases where multiple TSF
+ representations are combined within a single document, the
+ developer should indicate which portions of the documents meet
+ which requirements.
+
+ Three types of specification style are mandated by this class:
+ informal, semiformal and formal. The functional specification
+ and TOE design documentation are always written in either
+ informal or semiformal style. A semiformal style reduces the
+ ambiguity in these documents over an informal presentation. A
+ formal specification may also be required in addition
+ to the semi-formal presentation; the value is that a
+ description of the TSF in more than one way will add increased
+ assurance that the TSF has been completely and accurately
+ specified.
+
+ An informal specification is written as prose in natural
+ language. Natural language is used here as meaning
+ communication in any commonly spoken tongue (e.g. Spanish,
+ German, French, English, Dutch). An informal specification is
+ not subject to any notational or special restrictions other
+ than those required as ordinary conventions for that language
+ (e.g. grammar and syntax). While no notational restrictions
+ apply, the informal specification is also required to provide
+ defined meanings for terms that are used in a context other
+ than that accepted by normal usage.
+
+ The difference between semiformal and informal documents is
+ only a matter of formatting or presentation: a semiformal
+ notation includes such things as an explicit glossary of
+ terms, a standardised presentation format, etc. A semiformal
+ specification is written to a standard presentation
+ template. The presentation should use terms consistently if
+ written in a natural language. The presentation may also use
+ more structured languages/diagrams (e.g. data-flow diagrams,
+ state transition diagrams, entity-relationship diagrams, data
+ structure diagrams, and process or program structure
+ diagrams). Whether based on diagrams or natural language, a
+ set of conventions must be used in the presentation. The
+ glossary explicitly identifies the words that are being used
+ in a precise and constant manner; similarly, the standardised
+ format implies that extreme care has been taken in
+ methodically preparing the document in a manner that maximises
+ clarity. It should be noted that fundamentally different
+ portions of the TSF may have different semiformal notation
+ conventions and presentation styles (as long as the number of
+ different ``semiformal notations'' is small); this still
+ conforms to the concept of a semiformal
+ presentation.
+
+ A formal specification is written in a notation based upon
+ well-established mathematical concepts, and is typically
+ accompanied by supporting explanatory (informal) prose. These
+ mathematical concepts are used to define the syntax and
+ semantics of the notation and the proof rules that support
+ logical reasoning. The syntactic and semantic rules supporting
+ a formal notation should define how to recognise constructs
+ unambiguously and determine their meaning. There needs to be
+ evidence that it is impossible to derive contradictions, and
+ all rules supporting the notation need to be defined or
+ referenced.
+
+
+
+ The purpose of the Development class is to provide evidence
+ about the TOE. Without the knowledge about the TOE that is
+ gained from this information, there could be no useful
+ vulnerability analysis or testing conducted upon the TOE (as
+ described in the and classes).
+
+
+ The purpose of the development activity is to assess the
+ design documentation in terms of its adequacy to understand
+ how the TSF meets the SFRs and how the implementation of these
+ SFRs cannot be tampered with or bypassed. This understanding
+ is achieved through examination of increasingly refined
+ descriptions of the TSF design documentation. Design
+ documentation consists of a functional specification (which
+ describes the interfaces of the TSF), a TOE design description
+ (which describes the architecture of the TSF in terms of how
+ it works in order to perform the functions related to the SFRs
+ being claimed), and an implementation description (a source
+ code level description). In addition, there is a security
+ architecture description (which describes the architectural
+ properties of the TSF to explain how its security enforcement
+ cannot be compromised or bypassed), an internals description
+ (which describes how the TSF was constructed in a manner that
+ encourages understandability), and a security policy model
+ (which formally describes the security policies enforced by
+ the TSF).
+
+
+
+ The CC requirements for design documentation are levelled by
+ the amount, and detail of information provided, and the degree
+ of formality of the presentation of the information. At lower
+ levels, the most security-critical portions of the TSF are
+ described with the most detail, while less security-critical
+ portions of the TSF are merely summarised; added assurance is
+ gained by increasing the amount of information about the most
+ security-critical portions of the TSF, and increasing the
+ details about the less security-critical portions. The most
+ assurance is achieved when thorough details and information of
+ all portions are provided.
+
+ The CC considers a document's degree of formality (that is,
+ whether it is informal or semiformal) to be hierarchical. An
+ informal document is one that is expressed in a natural
+ language. The methodology does not dictate the specific
+ language that must be used; that issue is left for the
+ scheme. The following paragraphs differentiate the contents of
+ the different informal documents.
+
+ A functional specification provides a description of the
+ purpose and method-of-use of interfaces to the TSF. For
+ example, if an operating system presents the user with a means
+ of self-identification, of creating files, of modifying or
+ deleting files, of setting permissions defining what other
+ users may access files, and of communicating with remote
+ machines, its functional specification would contain
+ descriptions of each of these and how they are realised
+ through interactions with the externally-visible interfaces to
+ the TSF. If there is also audit functionality that detects and
+ record the occurrences of such events, descriptions of this
+ audit functionality would also be expected to be part of the
+ functional specification; while this functionality is
+ technically not directly invoked by the user at the external
+ interface, it certainly is affected by what occurs at the
+ user's external interface.
+
+ A design description is expressed in terms of logical
+ divisions (subsystems or modules) that each provide a
+ comprehensible service or function. For example, a firewall
+ might be composed of subsystems that deal with packet
+ filtering, with remote administration, with auditing, and with
+ connection-level filtering. The design description of the
+ firewall would describe the actions that are taken, in terms
+ of what actions each subsystem takes when an incoming packet
+ arrives at the firewall.
+
+
+
+
+ The objective of this family is for the developer to provide
+ a description of the security architecture of the TSF. This
+ will allow analysis of the information that, when coupled
+ with the other evidence presented for the TSF, will confirm
+ the TSF achieves the desired properties. The security
+ architecture descriptions supports the implicit claim that
+ security analysis of the TOE can be achieved by examining
+ the TSF; without a sound architecture, the entire TOE
+ functionality would have to be examined.
+
+
+
+ The information presented for the security architecture of
+ the TOE is related to the information contained in other
+ decomposition documentation (functional specification and
+ TOE design documentation) provided for the TSF, but presents
+ the design in a manner that supports architectural arguments
+ (e.g., the TSF cannot be compromised; the TSF provides
+ security domains consistent with its SFRs; the TSF cannot be
+ bypassed).
+
+
+
+ This family contains only one component.
+
+
+
+ The properties of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed by Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the TSF
+ that are achieved through the design of the TOE and TSF, and
+ enforced by the correct implementation of that
+ design.
+
+ The approach used in this family is for the developer to
+ design and provide a TSF that exhibits the above-mentioned
+ properties, and to provide evidence (in the form of
+ documentation) that explains these properties of the
+ TSF. This explanation is provided at the same level of
+ detail as the description of the SFR-enforcing elements of
+ the TOE in the TOE design document. The evaluator has the
+ responsibility for looking at the evidence and, coupled with
+ other evidence delivered for the TOE and TSF, determining
+ that the properties are achieved.
+
+ Specification of security functionality implementing the
+ SFRs (in the and ) will not necessarily describe
+ mechanisms employed in implementing self-protection and
+ non-bypassability (e.g. memory management
+ mechanisms). Therefore, the material needed to provide the
+ assurance that these requirements are being achieved is
+ better suited to a presentation separate from the design
+ decomposition of the TSF as embodied in and . This is not
+ to imply that the security architecture description called
+ for by this component cannot reference or make use of the
+ design decomposition material; but it is likely that much of
+ the detail present in the decomposition documentation will
+ not be relevant to the argument being provided for the
+ security architecture description document.
+
+ The description of architectural soundness can be thought of
+ as a developer's vulnerability analysis, in that it provides
+ the justification for why the TSF is sound and enforces all
+ of its SFRs. Where the soundness is achieved through
+ specific security mechanisms, these will be tested as part
+ of the requirements; where
+ the soundness is achieved solely through the architecture,
+ the behaviour will be tested as part of the requirements.
+
+ This family consists of requirements for a security
+ architecture description that describes the self-protection,
+ domain separation, non-bypassability principles, including a
+ description of how these principles are supported by the
+ parts of the TOE that are used for TSF
+ initialisation.
+ Additional information on the security architecture
+ properties of self-protection, domain separation, and
+ non-bypassability can be found in Annex .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is structured such that it cannot be tampered with
+ or bypassed, and whether TSFs that provide security
+ domains isolate those domains from each other.
+
+
+
+ The notions of self-protection, domain separation, and
+ non-bypassability are distinct from security functionality
+ expressed in Part 2 SFRs because self-protection and
+ non-bypassability largely have no directly observable
+ interface at the TSF. Rather, they are properties of the
+ TSF that are achieved through the design of the TOE, and
+ enforced by the correct implementation of that
+ design. Also, the evaluation of these properties is less
+ straight-forward than the evaluation of mechanisms; it is
+ more difficult to check for the absence of functionality
+ than for its presence. However, the determination that
+ these properties are being satisfied is just as critical
+ as the determination that the mechanisms are properly
+ implemented.
+
+ The overall approach used is that the developer provides a
+ TSF that meets the above-mentioned properties, and
+ provides evidence (in the form of documentation) that can
+ be analysed to show that the properties are indeed
+ met. The evaluator has the responsibility for looking at
+ the evidence and, coupled with other evidence delivered
+ for the TOE, determining that the properties are
+ achieved. The work units can be characterised as those
+ detailing with what information has to be provided, and
+ those dealing with the actual analysis the evaluator
+ performs.
+
+ The security architecture description describes how
+ domains are defined and how the TSF keeps them
+ separate. It describes what prevents untrusted processes
+ from getting to the TSF and modifying it. It describes
+ what ensures that all resources under the TSF's control
+ are adequately protected and that all actions related to
+ the SFRs are mediated by the TSF. It explains any role the
+ environment plays in any of these (e.g. presuming it gets
+ correctly invoked by its underlying environment, how is
+ its security functionality invoked?). In short, it
+ explains how the TOE is considered to be providing any
+ kind of security service.
+
+ The analyses the evaluator performs must be done in the
+ context of all of the development evidence provided for
+ the TOE, at the level of detail the evidence is
+ provided. At lower assurance levels there should not be
+ the expectation that, for example, TSF self-protection is
+ completely analysed, because only high-level design
+ representations will be available. The evaluator also
+ needs to be sure to use information gleaned from other
+ portions of their analysis (e.g., analysis of the TOE
+ design) in making their assessments for the properties
+ being examined in the following work units.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation (if available);
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall design and implement the TOE so that the
+ security features of the TSF cannot be bypassed.
+
+
+ The developer shall design and implement the TSF so that it
+ is able to protect itself from tampering by untrusted active
+ entities.
+
+
+ The developer shall provide a security architecture
+ description of the TSF.
+
+
+ The security architecture description shall be at a level of
+ detail commensurate with the description of the
+ SFR-enforcing abstractions described in the TOE design
+ document.
+
+
+ The security architecture description shall describe the
+ security domains maintained by the TSF consistently with the
+ SFRs.
+
+
+ The security architecture description shall describe how the
+ TSF initialisation process is secure.
+
+
+ The security architecture description shall demonstrate that
+ the TSF protects itself from tampering.
+
+
+ The security architecture description shall demonstrate that
+ the TSF prevents bypass of the SFR-enforcing functionality.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the information provided
+ in the evidence is presented at a level of detail
+ commensurate with the descriptions of the SFR-enforcing
+ abstractions contained in the functional specification
+ and TOE design document.
+
+ With respect to the functional specification, the
+ evaluator should ensure that the self-protection
+ functionality described cover those effects that are
+ evident at the TSFI. Such a description might include
+ protection placed upon the executable images of the TSF,
+ and protection placed on objects (e.g., files used by
+ the TSF). The evaluator ensures that the functionality
+ that might be invoked through the TSFI is
+ described.
+
+ If or is included, the evaluator
+ ensures the security architecture description contains
+ information on how any subsystems that contribute to TSF
+ domain separation work.
+
+ If or higher is
+ available, the evaluator ensures that the security
+ architecture description also contains
+ implementation-dependent information. For example, such
+ a description might contain information pertaining to
+ coding conventions for parameter checking that would
+ prevent TSF compromises (e.g. buffer overflows), and
+ information on stack management for call and return
+ operations. The evaluator checks the descriptions of the
+ mechanisms to ensure that the level of detail is such
+ that there is little ambiguity between the description
+ in the security architecture description and the
+ implementation representation.
+
+ The evaluator action related to this work unit is assigned a fail verdict
+ if the security architecture description mentions any module, subsystem, or interface
+ that is not described in the functional specification or TOE design document.
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it describes the security
+ domains maintained by the TSF.
+
+ Security domains refer to environments supplied by the
+ TSF for use by potentially-harmful entities; for
+ example, a typical secure operating system supplies a
+ set of resources (address space, per-process environment
+ variables) for use by processes with limited access
+ rights and security properties. The evaluator determines
+ that the developer's description of the security domains
+ takes into account all of the SFRs claimed by the
+ TOE.
+
+ For some TOEs such domains do not exist because all of
+ the interactions available to users are severely
+ constrained by the TSF. A packet-filter firewall is an
+ example of such a TOE. Users on the LAN or WAN do not
+ interact with the TOE, so there need be no security
+ domains; there are only data structures maintained by
+ the TSF to keep the users' packets separated. The
+ evaluator ensures that any claim that there are no
+ domains is supported by the evidence and that no such
+ domains are, in fact, available.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that the initialisation process
+ preserves security.
+
+ The information provided in the security architecture
+ description relating to TSF initialisation is directed
+ at the TOE components that are involved in bringing the
+ TSF into an initial secure state (i.e. when all parts of
+ the TSF are operational) when power-on or a reset is
+ applied. This discussion in the security architecture
+ description should list the system initialisation
+ components and the processing that occurs in
+ transitioning from the ``down'' state to the initial
+ secure state.
+
+ It is often the case that the components that perform
+ this initialisation function are not accessible after
+ the secure state is achieved; if this is the case then
+ the security architecture description identifies the components and
+ explains how they are not reachable by untrusted
+ entities after the TSF has been established. In this
+ respect, the property that needs to be preserved is that
+ these components either 1) cannot be accessed by
+ untrusted entities after the secure state is achieved,
+ or 2) if they provide interfaces to untrusted entities,
+ these TSFI cannot be used to tamper with the TSF.
+
+ The TOE components related to TSF initialisation, then,
+ are treated themselves as part of the TSF, and analysed
+ from that perspective. It should be noted that even
+ though these are treated as part of the TSF, it is
+ likely that a justification (as allowed by ) can be made that they do not
+ have to meet the internal structuring requirements of
+ .
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it contains information
+ sufficient to support a determination that the TSF is
+ able to protect itself from tampering by untrusted
+ active entities.
+
+ ''Self-protection'' refers to the ability of the TSF to
+ protect itself from manipulation from external entities
+ that may result in changes to the TSF. For TOEs that
+ have dependencies on other IT entities, it is often the
+ case that the TOE uses services supplied by the other IT
+ entities in order to perform its functions. In such
+ cases, the TSF alone does not protect itself because it
+ depends on the other IT entities to provide some of the
+ protection. For the purposes of the security
+ architecture description, the notion of
+ self-protection applies only to the
+ services provided by the TSF through its TSFI, and not
+ to services provided by underlying IT entities that it
+ uses.
+
+ Self-protection is typically achieved by a variety of
+ means, ranging from physical and logical restrictions on
+ access to the TOE; to hardware-based means (e.g.
+ ``execution rings'' and memory management
+ functionality); to software-based means (e.g. boundary
+ checking of inputs on a trusted server). The evaluator
+ determines that all such mechanisms are
+ described.
+
+ The evaluator determines that the design description
+ covers how user input is handled by the TSF in such a
+ way that the TSF does not subject itself to being
+ corrupted by that user input. For example, the TSF might
+ implement the notion of privilege and protect itself by
+ using privileged-mode routines to handle user input. The
+ TSF might make use of processor-based separation
+ mechanisms such as privilege levels or rings. The TSF
+ might implement software protection constructs or coding
+ conventions that contribute to implementing separation of
+ software domains, perhaps by delineating user address
+ space from system address space. And the TSF might have
+ reliance its environment to provide some support to the
+ protection of the TSF.
+
+ All of the mechanisms contributing to the domain
+ separation functions are described. The evaluator should
+ use knowledge gained from other evidence (functional
+ specification, TOE design, TSF internals description,
+ other parts of the security architecture description, or
+ implementation representation, as included in the
+ assurance package for the TOE) in determining if any
+ functionality contributing to self-protection was
+ described that is not present in the security
+ architecture description.
+
+ Accuracy of the description of the self-protection mechanisms is the property that the
+ description faithfully describes what is implemented. The evaluator should use other
+ evidence (functional specification, TOE design, TSF Internals documentation, other parts
+ of the security architecture description, implementation representation, as included in
+ the ST for the TOE) in determining whether there are discrepancies in any descriptions
+ of the self-protection mechanisms. If
+
+ is included in the assurance package for the TOE, the evaluator will choose a sample of
+ the implementation representation; the evaluator should also ensure that the descriptions
+ are accurate for the sample chosen. If an evaluator cannot understand how a certain
+ self-protection mechanism works or could work in the system architecture, it may be the
+ case that the description is not accurate.
+
+
+
+
+ The evaluator shall examine the security architecture
+ description to determine that it presents an analysis
+ that adequately describes how the SFR-enforcing
+ mechanisms cannot be bypassed.
+
+ Non-bypassability is a property that the security
+ functionality of the TSF (as specified by the SFRs) is
+ always invoked. For example, if access control to files
+ is specified as a capability of the TSF via an SFR,
+ there must be no interfaces through which files can be
+ accessed without invoking the TSF's access control
+ mechanism (such as an interface through which a raw disk
+ access takes place).
+
+ Describing how the TSF mechanisms cannot be bypassed
+ generally requires a systematic argument based on the
+ TSF and the TSFIs. The description of how the TSF works
+ (contained in the design decomposition evidence, such as
+ the functional specification, TOE design documentation)
+ - along with the information in the TSS - provides the
+ background necessary for the evaluator to understand
+ what resources are being protected and what security
+ functions are being provided. The functional
+ specification provides descriptions of the TSFIs through
+ which the resources/functions are accessed.
+
+ The evaluator assesses the description provided (and other
+ information provided by the developer, such as the functional
+ specification) to ensure that no available interface can be used
+ to bypass the TSF. This means that every available interface
+ must be either unrelated to the SFRs that are claimed in the ST
+ (and does not interact with anything that is used to satisfy
+ SFRs) or else uses the security functionality that is described
+ in other development evidence in the manner described. For
+ example, a game would likely be unrelated to the SFRs, so there
+ must be an explanation of how it cannot affect security. Access
+ to user data, however, is likely to be related to access control
+ SFRs, so the explanation would describe how the security
+ functionality works when invoked through the data-access
+ interfaces. Such a description is needed for every available
+ interface.
+
+ An example of a description follows. Suppose the TSF
+ provides file protection. Further suppose that although
+ the ``traditional'' system call TSFIs for open, read,
+ and write invoke the file protection mechanism described
+ in the TOE design, there exists a TSFI that allows
+ access to a batch job facility (creating batch jobs,
+ deleting jobs, modifying unprocessed jobs). The
+ evaluator should be able to determine from the
+ vendor-provided description that this TSFI invokes the
+ same protection mechanisms as do the ``traditional''
+ interfaces. This could be done, for example, by
+ referencing the appropriate subclauses of the TOE design
+ that discuss how the batch job facility
+ TSFI achieves its security objectives.
+
+ Using this same example, suppose there is a TSFI whose
+ sole purpose is to display the time of day. The
+ evaluator should determine that the description
+ adequately argues that this TSFI is not capable of
+ manipulating any protected resources and should not
+ invoke any security functionality.
+
+ Another example of bypass is when the TSF is supposed to
+ maintain confidentiality of a cryptographic key (one is
+ allowed to use it for cryptographic operations, but is
+ not allowed to read/write it). If an attacker has direct
+ physical access to the device, he might be able to
+ examine side-channels such as the power usage of the
+ device, the exact timing of the device, or even any
+ electromagnetic emanations of the device and, from this,
+ infer the key.
+
+ If such side-channels may be present, the demonstration
+ should address the mechanisms that prevent these
+ side-channels from occurring, such as random internal
+ clocks, dual-line technology etc. Verification of these
+ mechanisms would be verified by a combination of purely
+ design-based arguments and testing.
+
+ For a final example using security functionality rather
+ than a protected resource, consider an ST that contains
+ , which requires that
+ the TSF provides evidence of origination for information
+ types specified in the ST. Suppose that the
+ ``information types'' included all information that is
+ sent by the TOE via e-mail. In this case the evaluator
+ should examine the description to ensure that all TSFI
+ that can be invoked to send e-mail perform the
+ ``evidence of origination generation'' function are
+ detailed. The description might point to user guidance
+ to show all places where e-mail can originate (e.g.,
+ e-mail program, notification from scripts/batch jobs)
+ and then how each of these places invokes the evidence
+ generation function.
+
+ The evaluator should also ensure that the description is comprehensive, in that each
+ interface is analysed with respect to the entire set of claimed SFRs. This may require the
+ evaluator to examine supporting information (functional specification, TOE design, other
+ parts of the security architecture description, operational user guidance, and perhaps even
+ the implementation representation, as provided for the TOE) to determine that the description
+ has correctly capture all aspects of an interface. The evaluator should consider what SFRs each
+ TSFI might affect (from the description of the TSFI and its implementation in the supporting
+ documentation), and then examine the description to determine whether it covers those aspects.
+
+
+
+
+
+
+
+ This family levies requirements upon the functional specification,
+ which describes the TSF interfaces (TSFIs).
+ The TSFI consists of all means by which external entities (or
+ subjects in the TOE but outside of the TSF) supply data to the TSF,
+ receive data from the TSF and invoke services from the TSF.
+ It does not describe how the TSF processes those service
+ requests, nor does it describe the communication when the TSF invokes services
+ from its operational environment; this information is addressed by the
+ and
+ families, respectively.
+
+ This family provides assurance directly by allowing the
+ evaluator to understand how the TSF meets the claimed SFRs. It
+ also provides assurance indirectly, as input to other assurance
+ families and classes:
+ , where the description of
+ the TSFIs may be used to gain better understanding of how the
+ TSF is protected against corruption (i.e. subversion of
+ self-protection or domain separation) and/or bypass;
+ , where the description of the
+ TSFIs is an important input for both developer and evaluator
+ testing;
+ , where the description of the
+ TSFIs is used to search for vulnerabilities.
+
+
+
+
+ The information presented in the functional specification
+ describes the interfaces through which the TSF services are
+ invoked. At the lower levels of assurance, there is an
+ effort to reduce the amount of information that must be
+ supplied by requiring only the most security-critical
+ information.
+
+
+
+ The components in this family are levelled on the degree of
+ detail required of the description of the TSFIs, and the degree
+ of formalism required of the description of the TSFIs.
+
+
+
+ Once the TSFIs are determined (see for guidance and
+ examples of determining TSFI), they are described. At
+ lower-level components, developers focus their documentation
+ (and evaluators focus their analysis) on the more
+ security-relevant aspects of the TOE. Three categories of
+ TSFIs are defined, based upon the relevance the services
+ available through them have to the SFRs being claimed:
+ If a service available through an interface can be
+ traced to one of the SFRs levied on the TSF, then that
+ interface is termed SFR-enforcing.
+ Note that it is possible that an interface may have
+ various services and results, some of which may be
+ SFR-enforcing and some of which may not.
+ interfaces to (or services available through an
+ interface relating to) services that SFR-enforcing
+ functionality depends upon, but need only to function
+ correctly in order for the security policies of the TOE
+ to be preserved, are termed
+ SFR-supporting.
+ Interfaces to services on which SFR-enforcing
+ functionality has no dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR-supporting or SFR non-interfering it must have
+ no SFR-enforcing services or results. In
+ contrast, an SFR-enforcing interface may have SFR-supporting
+ services (for example, the ability to set the system clock
+ may be an SFR-enforcing service of an interface, but if that
+ same interface is used to display the system date that
+ service may be only SFR-supporting). An example of a purely
+ SFR-supporting interface is a system call interface that is
+ used both by users and by a portion of the TSF that is
+ running on behalf of users.
+
+ As more information about the TSFIs becomes available, the
+ greater the assurance that can be gained that the interfaces are
+ correctly categorised/analysed. The requirements are structured
+ such that, at the lowest level, the information required for SFR
+ non-interfering interfaces is the minimum necessary in order for
+ the evaluator to make this determination in an effective
+ manner. At higher levels, more information becomes available so
+ that the evaluator has greater confidence in the
+ designation.
+
+ The purpose in defining these labels (SFR-enforcing,
+ SFR-supporting, and SFR-non-interfering) and for levying
+ different requirements upon each (at the lower assurance
+ components) is to provide a first approximation of where to
+ focus the analysis and the evidence upon which that analysis
+ is performed. If the developer's documentation of the TSF
+ interfaces describes all of the interfaces to the degree
+ specified in the requirements for the SFR-enforcing
+ interfaces (that is, if the documentation exceeds the
+ requirements), there is no need for the developer to create
+ new evidence to match the requirements. Similarly, because
+ the labels are merely a means of differentiating the
+ interface types within the requirements, there is no need
+ for the developer to update the evidence solely to label the
+ interfaces as SFR-enforcing, SFR-supporting, and
+ SFR-non-interfering. The primary purpose of this labelling
+ is to allow developers with less mature development
+ methodologies (and associated artifacts, such as detailed
+ interface and design documentation) to provide only the
+ necessary evidence without undue cost.
+
+ The last C element of each component within this family provides
+ a direct correspondence between the SFRs and the functional
+ specification; that is, an indication of which interfaces are
+ used to invoke each of the claimed SFRs. In the cases where the
+ ST contains such functional requirements as , whose functionality may not manifest itself at
+ the TSFIs, the functional specification and/or the tracing is
+ expected to identify these SFRs; including them in the functional
+ specification helps to ensure that they are not lost at lower
+ levels of decomposition, where they will be relevant.
+
+
+ The requirements define collections of details about TSFI
+ to be provided. For the purposes of the requirements,
+ interfaces are specified (in varying degrees of detail) in
+ terms of their purpose, method of use, parameters,
+ parameter descriptions, and error messages.
+
+ The purpose of an interface is a
+ high-level description of the general goal of the
+ interface (e.g. process GUI commands, receive network
+ packets, provide printer output, etc.)
+
+ The interface's method of use describes
+ how the interface is supposed to be used. This description
+ should be built around the various interactions available
+ at that interface. For instance, if the interface were a Unix
+ command shell, ls, mv
+ and cp would be interactions for that
+ interface. For each interaction the method of use
+ describes what the interaction does, both for behaviour
+ seen at the interface (e.g. the programmer calling the
+ API, the Windows users changing a setting in the registry,
+ etc.) as well as behaviour at other interfaces
+ (e.g. generating an audit record).
+
+ Parameters are explicit inputs to and
+ outputs from an interface that control the behaviour of
+ that interface. For example, parameters are the arguments
+ supplied to an API; the various fields in a packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; the flags that can be set for the
+ ls, etc. The parameters are
+ ``identified'' with a simple list of what they are.
+
+ A parameter description tells what the
+ parameter is in some meaningful way. For instance, an
+ acceptable parameter description for interface
+ foo(i) would be ``parameter i is an
+ integer that indicates the number of users currently
+ logged in to the system''. A description such as
+ ``parameter i is an integer'' is not an acceptable.
+
+ The description of an interface's actions
+ describes what the interface does. This is more detailed
+ than the purpose in that, while the ``purpose'' reveals
+ why one might want to use it, the ``actions'' reveals
+ everything that it does. These actions might be related to
+ the SFRs or not. In cases where the interface's action is
+ not related to SFRs, its description is said to be
+ summarised, meaning the description
+ merely makes clear that it is indeed not SFR-related.
+
+ The error message description identifies
+ the condition that generated it, what the message is, and
+ the meaning of any error codes. An error message is
+ generated by the TSF to signify that a problem or
+ irregularity of some degree has been encountered. The
+ requirements in this family refer to different kinds of
+ error messages:
+ a ``direct'' error message is a
+ security-relevant response through a specific TSFI
+ invocation.
+ an ``indirect'' error cannot be tied to a
+ specific TSFI invocation because it results from
+ system-wide conditions (e.g. resource exhaustion,
+ connectivity interruptions, etc.). Error messages that
+ are not security-relevant are also considered
+ ``indirect''.
+ ``remaining'' errors are any other errors, such as those
+ that might be referenced within the code. For example, the use of
+ condition-checking code that checks for conditions that would not
+ logically occur (e.g. a final ``else'' after a list of ``case''
+ statements), would provide for generating a catch-all error
+ message; in an operational TOE, these error messages should never
+ be seen.
+
+ An example functional specification is provided in .
+
+
+
+ Increasing assurance through increased completeness and
+ accuracy in the interface specification is reflected in
+ the documentation required from the developer as detailed
+ in the various hierarchical components of this
+ family.
+
+ At , the only
+ documentation required is a characterisation of all TSFIs
+ and a high level description of SFR-enforcing and
+ SFR-supporting TSFIs. To provide some assurance that the
+ ``important'' aspects of the TSF have been correctly
+ characterised at the TSFIs, the developer is required to
+ provide the purpose and method of use, parameters for the
+ SFR-enforcing and SFR-supporting TSFIs.
+
+ At , the developer is
+ required to provide the purpose, method of use,
+ parameters, and parameter descriptions for all
+ TSFIs. Additionally, for the SFR-enforcing TSFIs the
+ developer has to describe the SFR-enforcing actions and
+ direct error messages.
+
+ At , the developer must now,
+ in addition to the information required at , provide enough information about the SFR-supporting
+ and SFR-non-interfering actions to show that they are not
+ SFR-enforcing. Further, the developer must now document all of
+ the direct error messages resulting from the invocation of
+ SFR-enforcing TSFIs.
+
+ At , all TSFIs - whether
+ SFR-enforcing, SFR-supporting, SFR-non-interfering - must
+ be described to the same degree, including all of the
+ direct error messages.
+
+ At , the TSFIs descriptions
+ also include error messages that do not result from an
+ invocation of a TSFI.
+
+ At , in addition to the
+ information required by , all
+ remaining error messages are included. The developer must also
+ provide a formal description of the TSFI. This provides an
+ alternative view of the TSFI that may expose inconsistencies or
+ incomplete specification.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has provided a high-level description of at least the
+ SFR-enforcing and SFR-supporting TSFIs, in terms of descriptions
+ of their parameters. There is no other required evidence that
+ can be expected to be available to measure the accuracy of these
+ descriptions; the evaluator merely ensures the descriptions seem
+ plausible.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall describe the purpose and
+ method of use for each SFR-enforcing and SFR-supporting
+ TSFI.
+
+
+ The functional specification shall identify all parameters
+ associated with each SFR-enforcing and SFR-supporting TSFI.
+
+
+ The functional specification shall provide rationale for the
+ implicit categorisation of interfaces as
+ SFR-non-interfering.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ SFR-supporting and SFR-enforcing TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of the parameters; this can be done in
+ association with other work units for this
+ component.
+
+ If an action available through an interface plays a role in
+ enforcing any security policy on the TOE (that is, if one of the
+ actions of the interface can be traced to one of the SFRs levied
+ on the TSF), then that interface is
+ SFR-enforcing. Such policies are not limited to
+ the access control policies, but also refer to any functionality
+ specified by one of the SFRs contained in the ST. Note that it
+ is possible that an interface may have various actions and
+ results, some of which may be SFR-enforcing and some of which
+ may not.
+
+ Interfaces to (or actions available through an interface
+ relating to) actions that SFR-enforcing functionality
+ depends on, but need only to function correctly in order
+ for the security policies of the TOE to be preserved,
+ are termed SFR supporting. Interfaces
+ to actions on which SFR-enforcing functionality has no
+ dependence are termed SFR
+ non-interfering.
+
+ It should be noted that in order for an interface to be
+ SFR supporting or SFR non-interfering it must have
+ no SFR-enforcing actions or results. In
+ contrast, an SFR-enforcing interface may have
+ SFR-supporting actions (for example, the ability to set
+ the system clock may be an SFR-enforcing action of an
+ interface, but if that same interface is used to display
+ the system date that action may only be SFR
+ supporting). An example of a purely SFR-supporting
+ interface is a system call interface that is used both
+ by untrusted users and by a portion of the TSF that is
+ running in user mode.
+
+ At this level, it is unlikely that a developer will have
+ expended effort to label interfaces as SFR-enforcing and
+ SFR-supporting. In the case that this has been done,
+ the evaluator should verify to the extent that
+ supporting documentation (e.g., operational user
+ guidance) allows that this identification is correct.
+ Note that this identification activity is necessary for
+ several work units for this component.
+
+ In the more likely case that the developer has not
+ labelled the interfaces, the evaluator must perform
+ their own identification of the interfaces first, and
+ then determine whether the required information (for
+ this work unit, the purpose) is present. Again, because
+ of the lack of supporting evidence this identification
+ will be difficult and have low assurance that all
+ appropriate interfaces have been correctly identified,
+ but nonetheless the evaluator examines other evidence
+ available for the TOE to ensure as complete coverage as
+ is possible.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each
+ SFR-supporting and SFR-enforcing TSFI is given.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it identifies all parameters
+ associated with each SFR-enforcing and SFR-supporting
+ TSFI.
+
+ See work unit for a
+ discussion on the identification of SFR-supporting and
+ SFR-enforcing TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for
+ identified TSFI. Parameters are explicit inputs or
+ outputs to an interface that control the behaviour of
+ that interface. For examples, parameters are the
+ arguments supplied to an API; the various fields in
+ packet for a given network protocol; the individual key
+ values in the Windows Registry; the signals across a set
+ of pins on a chip; etc.
+
+ While difficult to obtain much assurance that all
+ parameters for the applicable TSFI have been identified,
+ the evaluator should also check other evidence provided
+ for the evaluation (e.g., operational user guidance) to
+ see if behaviour or additional parameters are described
+ there but not in the functional specification.
+
+
+
+
+ The evaluator shall examine the rationale provided by
+ the developer for the implicit categorisation of
+ interfaces as SFR-non-interfering to determine that it
+ is accurate.
+
+ In the case where the developer has provided adequate
+ documentation to perform the analysis called for by the
+ rest of the work units for this component without
+ explicitly identifying SFR-enforcing and SFR-supporting
+ interfaces, this work unit should be considered
+ satisfied.
+
+ This work unit is intended to apply to cases where the developer
+ has not described a portion of the TSFI, claiming that it is
+ SFR-non-interfering and therefore not subject to other
+ requirements of this component. In such a case, the developer
+ provides a rationale for this characterisation in sufficient
+ detail such that the evaluator understands the rationale, the
+ characteristics of the interfaces affected (e.g., their
+ high-level function with respect to the TOE, such as ``colour
+ palette manipulation''), and that the claim that these are
+ SFR-non-interfering is supported. Given the level of assurance
+ the evaluator should not expect more detail than is provided for
+ the SFR-enforcing or SFR-supporting interfaces, and in fact the
+ detail should be much less. In most cases, individual
+ interfaces should not need to be addressed in the
+ developer-provided rationale subclause.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis, the
+ evaluator may build upon the developer's tracing (see a map between the TOE security
+ functional requirements and the TSFI). Note that this map may
+ have to be at a level of detail below the component or even
+ element level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that have
+ little or no manifestation at the TSF boundary (e.g., ) it is not expected that they
+ completely map those requirements to the TSFI. The analysis for
+ those requirements will be performed in the analysis for the TOE
+ design () when included in the
+ ST. It is also important to note that since the parameters
+ associated with TSFIs must be fully specified, the evaluator
+ should be able to determine if all aspects of an SFR appear to
+ be implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the SFR-enforcing actions, results and error
+ messages of each TSFI that is SFR-enforcing are also
+ described.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe direct error messages resulting from processing
+ associated with the SFR-enforcing actions.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer"; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface can be
+ traced to one of the SFRs levied on the TSF, then that
+ interface is SFR-enforcing. Such
+ policies are not limited to the access control policies,
+ but also refer to any functionality specified by one of
+ the SFRs contained in the ST. Note that it is possible
+ that an interface may have various actions and results,
+ some of which may be SFR-enforcing and some of which may not.
+
+ The developer is not required to ``label'' interfaces as
+ SFR-enforcing, and likewise is not required to identify
+ actions available through an interface as SFR-enforcing.
+ It is the evaluator's responsibility to examine the
+ evidence provided by the developer and determine that
+ the required information is present. In the case where
+ the developer has identified the SFR-enforcing TSFI and
+ SFR-enforcing actions available through those TSFI, the
+ evaluator must judge completeness and accuracy based on
+ other information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and on the other information presented
+ for the interfaces (parameters and parameter
+ descriptions, error messages, etc.).
+
+ In this case (where the developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing.
+
+ In the case where the developer has provided the same
+ level of information on all interfaces, the evaluator
+ performs the same type of analysis mentioned in the
+ previous paragraphs. The evaluator should determine
+ which interfaces are SFR-enforcing and which are not,
+ and subsequently ensure that the SFR-enforcing aspects
+ of the SFR-enforcing actions are appropriately
+ described.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from SFR-enforcing
+ actions associated with each SFR-enforcing TSFI.
+
+ This work unit should be performed in conjunction with,
+ or after, work unit
+ in order to ensure the set of SFR-enforcing TSFI and
+ SFR-enforcing actions is correctly identified. The
+ developer may provide more information than is required
+ (for example, all error messages associated with each
+ interface), in which the case the evaluator should
+ restrict their assessment of completeness and accuracy
+ to only those that they determine to be associated with
+ SFR-enforcing actions of SFR-enforcing TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+ In order to determine that the description of the
+ error messages of a TSFI is accurate and complete, the
+ evaluator measures the interface description against the
+ other evidence provided for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), as well as other evidence available for
+ that TSFI (parameters, analysis from work unit ).
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has provided a description of the TSFIs in
+ terms of their purpose, method of use, and parameters. In
+ addition, the actions, results and error messages of each
+ TSFI are also described sufficiently that it can be
+ determined whether they are SFR-enforcing, with the
+ SFR-enforcing TSFI being described in more detail than
+ other TSFIs.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe the SFR-enforcing actions associated with the TSFI.
+
+
+ For each SFR-enforcing TSFI, the functional specification shall
+ describe direct error messages resulting from SFR-enforcing
+ actions and exceptions associated with invocation of the TSFI.
+
+
+ The functional specification shall summarise the SFR-supporting
+ and SFR-non-interfering actions associated with each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ the SFR-enforcing actions associated with the
+ SFR-enforcing TSFIs.
+
+ If an action available through an interface plays a role
+ in enforcing any security policy on the TOE (that is, if
+ one of the actions of the interface can be traced to one
+ of the SFRs levied on the TSF), then that interface is
+ SFR-enforcing. Such policies are not
+ limited to the access control policies, but also refer
+ to any functionality specified by one of the SFRs
+ contained in the ST. Note that it is possible that an
+ interface may have various actions and results, some of
+ which may be SFR-enforcing and some of which may
+ not.
+ The developer is not required to ``label''
+ interfaces as SFR-enforcing, and likewise is not
+ required to identify actions available through an
+ interface as SFR-enforcing. It is the evaluator's
+ responsibility to examine the evidence provided by the
+ developer and determine that the required information is
+ present. In the case where the developer has identified
+ the SFR-enforcing TSFI and SFR-enforcing actions
+ available through those TSFI, the evaluator must judge
+ completeness and accuracy based on other information
+ supplied for the evaluation (e.g., TOE design, security
+ architecture description, operational user guidance),
+ and on the other information presented for the
+ interfaces (parameters and parameter descriptions, error
+ messages, etc.).
+
+ In this case (developer has provided only the
+ SFR-enforcing information for SFR-enforcing TSFI) the
+ evaluator also ensures that no interfaces have been
+ mis-categorised. This is done by examining other
+ information supplied for the evaluation (e.g., TOE
+ design, security architecture description, operational
+ user guidance), and the other information presented for
+ the interfaces (parameters and parameter descriptions,
+ for example) not labelled as SFR-enforcing. The analysis
+ done for work units
+ and are also used in
+ making this determination.
+ In the case where the developer has provided the
+ same level of information on all interfaces, the
+ evaluator performs the same type of analysis mentioned
+ in the previous paragraphs. The evaluator should
+ determine which interfaces are SFR-enforcing and which
+ are not, and subsequently ensure that the SFR-enforcing
+ aspects of the SFR-enforcing actions are appropriately
+ described. Note that in this case, the evaluator should
+ be able to perform the bulk of the work associated with
+ work unit in the
+ course of performing this SFR-enforcing analysis.
+ The SFR-enforcing actions are those that are
+ visible at any external interface and that provide for
+ the enforcement of the SFRs being claimed. For example,
+ if audit requirements are included in the ST, then
+ audit-related actions would be SFR-enforcing and
+ therefore must be described, even if the result of that
+ action is generally not visible through the invoked
+ interface (as is often the case with audit, where a user
+ action at one interface would produce an audit record
+ visible at another interface).
+
+ The level of description that is required is that
+ sufficient for the reader to understand what role the
+ TSFI actions play with respect to the SFR. The
+ evaluator should keep in mind that the description
+ should be detailed enough to support the generation (and
+ assessment) of test cases against that interface. If
+ the description is unclear or lacking detail such that
+ meaningful testing cannot be conducted against the TSFI,
+ it is likely that the description is inadequate.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ error messages that may result from an invocation of
+ each SFR-enforcing TSFI.
+
+ This work unit should be performed in conjunction with, or
+ after, work unit in order
+ to ensure the set of SFR-enforcing TSFI is correctly identified.
+ The evaluator should note that the requirement and associated
+ work unit is that all direct error messages associated with an
+ SFR-enforcing TSFI must be described, that are associated with
+ SFR-enforcing actions. This is because at this level of
+ assurance, the ``extra'' information provided by the error
+ message descriptions should be used in determining whether all
+ of the SFR-enforcing aspects of an interface have been
+ appropriately described. For instance, if an error message
+ associated with a TSFI (e.g., ``access denied'') indicated that
+ an SFR-enforcing decision or action had taken place, but in the
+ description of the SFR-enforcing actions there was no mention of
+ that particular SFR-enforcing mechanism, then the description
+ may not be complete.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code, set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is
+ accurate.
+
+ In order to determine that the description of the error messages
+ of a TSFI is accurate and complete, the evaluator measures the
+ interface description against the other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance), as well as for other
+ evidence supplied for that TSFI (description of SFR-enforcing
+ actions, summary of SFR-supporting and SFR-non-interfering
+ actions and results).
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to
+ determine that it summarises the SFR-supporting and
+ SFR-non-interfering actions associated with each TSFI.
+
+ The purpose of this work unit is to supplement the details about
+ the SFR-enforcing actions (provided in work unit ) with a summary of the remaining
+ actions (i.e., those that are not SFR-enforcing). This covers
+ all SFR-supporting and SFR-non-interfering
+ actions, whether invokable through SFR-enforcing TSFI or through
+ SFR-supporting or SFR-non-interfering TSFI. Such a summary
+ about all SFR-supporting and SFR-non-interfering actions helps
+ to provide a more complete picture of the functions provided by
+ the TSF, and is to be used by the evaluator in determining
+ whether an action or TSFI may have been mis-categorised.
+
+ The information to be provided is more abstract than that
+ required for SFR-enforcing actions. While it should still be
+ detailed enough so that the reader can understand what the
+ action does, the description does not have to be detailed enough
+ to support writing tests against it, for instance. For the
+ evaluator, the key is that the information must be sufficient to
+ make a positive determination that the action is SFR-supporting
+ or SFR-non-interfering. If that level of information is
+ missing, the summary is insufficient and more information must
+ be obtained.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST.
+
+
+
+ The functional specification describes the interfaces to
+ the TSF (the TSFI) in a structured manner. Because of the
+ dependency on , the
+ evaluator is expected to have identified the TSF prior to
+ beginning work on this sub-activity. Without firm
+ knowledge of what comprises the TSF, it is not possible to
+ assess the completeness of the TSFI.
+
+ In performing the various work units included in this family,
+ the evaluator is asked to make assessments of accuracy and
+ completeness of several factors (the TSFI itself, as well as the
+ individual components (parameters, actions, error messages,
+ etc.) of the TSFI). In doing this analysis, the evaluator is
+ expected to use the documentation provided for the
+ evaluation. This includes the ST, the TOE design, and may
+ include other documentation such as the operational user
+ guidance, security architecture description, and implementation
+ representation. The documentation should be examined in an
+ iterative fashion. The evaluator may read, for example, in the
+ TOE design how a certain function is implemented, but see no way
+ to invoke that function from the interface. This might cause the
+ evaluator to question the completeness of a particular TSFI
+ description, or whether an interface has been left out of the
+ functional specification altogether. Describing analysis
+ activities of this sort in the ETR is a key method in providing
+ rationale that the work units have been performed
+ appropriately.
+
+ It should be recognised that there exist functional
+ requirements whose functionality is manifested wholly or
+ in part architecturally, rather than through a specific
+ mechanism. An example of this is the implementation of
+ mechanisms implementing the requirements. Such mechanisms typically are
+ implemented to ensure a behaviour isn't present, which is
+ difficult to test and typically is verified through
+ analysis. In the cases where such functional requirements
+ are included in the ST, it is expected that the evaluator
+ recognise that there may be SFRs of this type that have no
+ interfaces, and that this should not be considered a
+ deficiency in the functional specification.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+ The evaluator shall examine the functional specification to
+ determine the completeness of the TSFI
+ The evaluator shall use the design documentation to identify the possible types of
+ interfaces. The evaluator shall search the design documentation and the guidance
+ documentation for potential TSFI not contained in the developer's documentation,
+ thus indicating that the set of TSFI defined by the developer is incomplete. The
+ evaluator shall examine the arguments presented by the developer that the TSFI is
+ complete and check down to the lowest level of design or with the
+ implementation representation that no additional TSFI exist.
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system'' is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ Actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to determine
+ that it completely and accurately describes the meaning of all
+ error messages resulting from an invocation of each TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation
+ (e.g. TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has completely described all of the TSFI in
+ a manner such that the evaluator is able to determine
+ whether the TSFI are completely and accurately described,
+ and appears to implement the security functional
+ requirements of the ST. The completeness of the interfaces
+ is judged based upon the implementation
+ representation.
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the implementation representation.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ semi-formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+ The functional specification
+ shall describe all error messages that do not result from an
+ invocation of a TSFI.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation yet
+ does not result from an invocation of a TSFI.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall examine the functional specification
+ to determine that the TSF is fully represented.
+
+ The identification of the TSFI is a necessary
+ prerequisite to all other activities in this
+ sub-activity. The TSF must be identified (done as part
+ of the work units) in
+ order to identify the TSFI. This activity can be done at
+ a high level to ensure that no large groups of
+ interfaces have been missed (network protocols, hardware
+ interfaces, configuration files), or at a low level as
+ the evaluation of the functional specification
+ proceeds.
+
+ In making an assessment for this work unit, the
+ evaluator determines that all portions of the TSF are
+ addressed in terms of the interfaces listed in the
+ functional specification. All portions of the TSF should
+ have a corresponding interface description, or if there
+ are no corresponding interfaces for a portion of the
+ TSF, the evaluator determines that that is
+ acceptable.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is presented using a semiformal
+ style.
+
+ A semi-formal presentation is characterised by a
+ standardised format with a well-defined syntax that
+ reduces ambiguity that may occur in informal
+ presentations. Since the intent of the semi-formal
+ format is to enhance the reader's ability to understand
+ the presentation, use of certain structured presentation
+ methods (pseudo-code, flow charts, block diagrams) are
+ appropriate, though not required.
+
+ For the purposes of this activity, the evaluator should
+ ensure that the interface descriptions are formatted in
+ a structured, consistent manner and use common
+ terminology. A semiformal presentation of the interfaces
+ also implies that the level of detail of the
+ presentation for the interfaces is largely consistent
+ across all TSFI. For the functional specification, it is
+ acceptable to refer to external specifications for
+ portions of the interface as long as those external
+ specifications are themselves semiformal.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it states the purpose of each
+ TSFI.
+
+ The purpose of a TSFI is a general statement summarising
+ the functionality provided by the interface. It is not
+ intended to be a complete statement of the actions and
+ results related to the interface, but rather a statement
+ to help the reader understand in general what the
+ interface is intended to be used for. The evaluator
+ should not only determine that the purpose exists, but
+ also that it accurately reflects the TSFI by taking into
+ account other information about the interface, such as
+ the description of actions and error messages.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that the method of use for each TSFI is
+ given.
+
+ The method of use for a TSFI summarises how the
+ interface is manipulated in order to invoke the actions
+ and obtain the results associated with the TSFI. The
+ evaluator should be able to determine, from reading this
+ material in the functional specification, how to use
+ each interface. This does not necessarily mean that
+ there needs to be a separate method of use for each
+ TSFI, as it may be possible to describe in general how
+ kernel calls are invoked, for instance, and then
+ identify each interface using that general
+ style. Different types of interfaces will require
+ different method of use specifications. APIs, network
+ protocol interfaces, system configuration parameters,
+ and hardware bus interfaces all have very different
+ methods of use, and this should be taken into account by
+ the developer when developing the functional
+ specification, as well as by the evaluator evaluating
+ the functional specification.
+
+ For administrative interfaces whose functionality is documented
+ as being inaccessible to untrusted users, the evaluator ensures
+ that the method of making the functions inaccessible is
+ described in the functional specification. It should be noted
+ that this inaccessibility needs to be tested by the developer in
+ their test suite.
+
+ The evaluator should not only determine that the set of
+ method of use descriptions exist, but also that they
+ accurately cover each TSFI.
+
+ The evaluator shall examine the functional specification to
+ determine the completeness of the TSFI
+ The evaluator shall use the design documentation to identify the possible types of
+ interfaces. The evaluator shall search the design documentation and the guidance
+ documentation for potential TSFI not contained in the developer's documentation,
+ thus indicating that the set of TSFI defined by the developer is incomplete. The
+ evaluator shall examine the arguments presented by the developer that the TSFI is
+ complete and check down to the lowest level of design or with the
+ implementation representation that no additional TSFI exist.
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely identifies all
+ parameters associated with every TSFI.
+
+ The evaluator examines the functional specification to
+ ensure that all of the parameters are described for each
+ TSFI. Parameters are explicit inputs or outputs to an
+ interface that control the behaviour of that
+ interface. For examples, parameters are the arguments
+ supplied to an API; the various fields in packet for a
+ given network protocol; the individual key values in the
+ Windows Registry; the signals across a set of pins on a
+ chip; etc.
+
+ In order to determine that all of the parameters are
+ present in the TSFI, the evaluator should examine the
+ rest of the interface description (actions, error
+ messages, etc.) to determine if the effects of the
+ parameter are accounted for in the description. The
+ evaluator should also check other evidence provided for
+ the evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all parameters associated with every TSFI.
+
+ Once all of the parameters have been identified, the
+ evaluator needs to ensure that they are accurately
+ described, and that the description of the parameters is
+ complete. A parameter description tells what the
+ parameter is in some meaningful way. For instance, the
+ interface foo(i) could be described as
+ having ``parameter i which is an integer''; this is not
+ an acceptable parameter description. A description such
+ as ``parameter i is an integer that indicates the number
+ of users currently logged in to the system''. is much
+ more acceptable.
+
+ In order to determine that the description of the
+ parameters is complete, the evaluator should examine the
+ rest of the interface description (purpose, method of
+ use, actions, error messages, etc.) to determine if the
+ descriptions of the parameter(s) are accounted for in
+ the description. The evaluator should also check other
+ evidence provided (e.g., TOE design, architectural
+ design, operational user guidance, implementation
+ representation) to see if behaviour or additional
+ parameters are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all actions associated with every TSFI.
+
+ The evaluator checks to ensure that all of the actions
+ are described. actions available through an interface
+ describe what the interface does (as opposed to the TOE
+ design, which describes how the actions are provided by
+ the TSF).
+
+ actions of an interface describe functionality that can
+ be invoked through the interface, and can be categorised
+ as regular actions, and
+ SFR-related actions. Regular actions
+ are descriptions of what the interface does. The amount
+ of information provided for this description is
+ dependant on the complexity of the interface. The
+ SFR-related actions are those that are visible at any
+ external interface (for instance, audit activity caused
+ by the invocation of an interface (assuming audit
+ requirements are included in the ST) should be
+ described, even though the result of that action is
+ generally not visible through the invoked
+ interface). Depending on the parameters of an interface,
+ there may be many different actions able to be invoked
+ through the interface (for instance, an API might have
+ the first parameter be a ``subcommand'', and the
+ following parameters be specific to that subcommand. The
+ IOCTL API in some Unix systems is an example of such an
+ interface).
+ In order to determine that the description of the
+ actions of a TSFI is complete, the evaluator should
+ review the rest of the interface description (parameter
+ descriptions, error messages, etc.) to determine if the
+ actions described are accounted for. The evaluator
+ should also analyse other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to see if there is evidence of actions
+ that are described there but not in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI
+ to determine that it completely and accurately describes
+ all errors messages resulting from an invocation of each
+ TSFI.
+
+ Errors can take many forms, depending on the interface
+ being described. For an API, the interface itself may
+ return an error code; set a global error condition, or
+ set a certain parameter with an error code. For a
+ configuration file, an incorrectly configured parameter
+ may cause an error message to be written to a log
+ file. For a hardware PCI card, an error condition may
+ raise a signal on the bus, or trigger an exception
+ condition to the CPU.
+
+ Errors (and the associated error messages) come about
+ through the invocation of an interface. The processing
+ that occurs in response to the interface invocation may
+ encounter error conditions, which trigger (through an
+ implementation-specific mechanism) an error message to
+ be generated. In some instances this may be a return
+ value from the interface itself; in other instances a
+ global value may be set and checked after the invocation
+ of an interface. It is likely that a TOE will have a
+ number of low-level error messages that may result from
+ fundamental resource conditions, such as ``disk full''
+ or ``resource locked''. While these error messages may
+ map to a large number of TSFI, they could be used to
+ detect instances where detail from an interface
+ description has been omitted. For instance, a TSFI that
+ produces a ``disk full'' message, but has no obvious
+ description of why that TSFI should cause an access to
+ the disk in its description of actions, might cause the
+ evaluator to examine other evidence (, ) related
+ that TSFI to determine if the description is complete
+ and accurate.
+
+ The evaluator determines that, for each TSFI, the exact
+ set of error messages that can be returned on invoking
+ that interface can be determined. The evaluator reviews
+ the evidence provided for the interface to determine if
+ the set of errors seems complete. They cross-check this
+ information with other evidence provided for the
+ evaluation (e.g., TOE design, security architecture
+ description, operational user guidance, implementation
+ representation) to ensure that there are no errors
+ steaming from processing mentioned that are not included
+ in the functional specification.
+
+
+
+
+ The evaluator shall examine the presentation of the TSFI to determine
+ that it completely and accurately describes the meaning of all
+ error messages resulting from an invocation of each TSFI.
+
+ In order to determine accuracy, the evaluator must be
+ able to understand meaning of the error. For example, if
+ an interface returns a numeric code of 0, 1, or 2, the
+ evaluator would not be able to understand the error if
+ the functional specification only listed: ``possible
+ errors resulting from invocation of the
+ foo() interface are 0, 1, or
+ 2''. Instead the evaluator checks to ensure that the
+ errors are described such as: ``possible errors
+ resulting from invocation of the foo()
+ interface are 0 (processing successful), 1 (file not
+ found), or 2 (incorrect filename
+ specification)''.
+
+ In order to determine that the description of the errors
+ due to invoking a TSFI is complete, the evaluator
+ examines the rest of the interface description
+ (parameter descriptions, actions, etc.) to determine if
+ potential error conditions that might be caused by using
+ such an interface are accounted for. The evaluator also
+ checks other evidence provided for the evaluation (e.g.,
+ TOE design, security architecture description,
+ operational user guidance, implementation
+ representation) to see if error processing related to
+ the TSFI is described there but is not described in the
+ functional specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it completely and accurately describes
+ all errors messages that do not result from an
+ invocation of any TSFI.
+
+ This work unit complements work unit , which describes those
+ error messages that result from an invocation of the
+ TSFI. Taken together, these work units cover all error
+ messages that might be generated by the TSF.
+
+ The evaluator assesses the completeness and accuracy of
+ the functional specification by comparing its contents
+ to instances of error message generation within the
+ implementation representation. Most of these error
+ messages will have already been covered by work unit
+ .
+
+ The error messages related to this work unit are
+ typically those that are not expected to be generated,
+ but are constructed as a matter of good programming
+ practises. For example, a case statement that defines
+ actions resulting from each of a list of cases may end
+ with a final else statement to apply
+ to anything that might not be expected; this practise
+ ensures the TSF does not get into an undefined state.
+ However, it is not expected that the path of execution
+ would ever get to this else
+ statement; therefore, any error message generation
+ within this else statement would
+ never be generated. Although it would not get
+ generated, it must still be included in the functional
+ specification.
+
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it provides a rationale for each error
+ message contained in the TSF implementation yet does not
+ result from an invocation of a TSFI.
+
+ The evaluator ensures that every error message found
+ under work unit
+ contains a rationale describing why it cannot be invoked
+ from the TSFI.
+
+ As was described in the previous work unit, this
+ rationale might be as straightforward as the fact that
+ the error message in question is provided for
+ completeness of execution logic and that it is never
+ expected to be generated. The evaluator ensures that the
+ rationale for each such error message is logical.
+
+
+
+ The evaluator shall check that the tracing links the
+ SFRs to the corresponding TSFIs.
+
+ The tracing is provided by the developer to serve as a
+ guide to which SFRs are related to which TSFIs. This
+ tracing can be as simple as a table; it is used as input
+ to the evaluator for use in the following work units, in
+ which the evaluator verifies its completeness and
+ accuracy.
+
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is a complete instantiation of the
+ SFRs.
+
+ To ensure that all SFRs are covered by the functional
+ specification, as well as the test coverage analysis,
+ the evaluator may build upon the developer's tracing
+ (see a map between
+ the TOE security functional requirements and the TSFI.
+ Note that this map may have to be at a level of detail
+ below the component or even element level of the
+ requirements, because of operations (assignments,
+ refinements, selections) performed on the functional
+ requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were covered by three different TSFI, it would be
+ inadequate for the evaluator to map to TSFI A, B, and C and claim they had
+ completed the work unit. Instead, the evaluator would
+ map (rule 1) to TSFI A;
+ (rule 2) to TSFI B;
+ etc. It might also be the case that the interface is a
+ wrapper interface (e.g., IOCTL), in which case the
+ mapping would need to be specific to certain set of
+ parameters for a given interface.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that they completely map those requirements to
+ the TSFI. The analysis for those requirements will be
+ performed in the analysis for the TOE design () when included in the ST. It is
+ also important to note that since the parameters,
+ actions, and error messages associated with TSFIs must
+ be fully specified, the evaluator should be able to
+ determine if all aspects of an SFR appear to be
+ implemented at the interface level.
+
+
+
+ The evaluator shall examine the functional specification
+ to determine that it is an accurate instantiation of the
+ SFRs.
+
+ For each functional requirement in the ST that results
+ in effects visible at the TSF boundary, the information
+ in the associated TSFI for that requirement specifies
+ the required functionality described by the
+ requirement. For example, if the ST contains a
+ requirement for access control lists, and the only TSFI
+ that map to that requirement specify functionality for
+ Unix-style protection bits, then the functional
+ specification is not accurate with respect to the
+ requirements.
+
+ The evaluator must recognise that for requirements that
+ have little or no manifestation at the TSF boundary
+ (e.g., ) it is not
+ expected that the evaluator completely map those
+ requirements to the TSFI. The analysis for those
+ requirements will be performed in the analysis for the
+ TOE design () when
+ included in the ST.
+
+
+
+
+
+
+
+
+ (Need Objectives text for FSP.6 methodology)
+
+
+
+ The evaluation evidence for this sub-activity that is
+ required by the work-units is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design.
+
+
+
+ The evaluation evidence for this sub-activity that is used
+ if included in the ST for the TOE is:
+
+
+ the security architecture description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the formal security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a formal presentation of the
+ functional specification of the TSF.
+
+
+ The developer shall provide a tracing from the functional
+ specification to the SFRs.
+
+
+ The functional specification shall completely represent the
+ TSF.
+
+
+ The functional specification shall describe the TSFI using a
+ formal style.
+
+
+ The functional specification shall describe the purpose and
+ method of use for all TSFI.
+
+
+ The functional specification shall identify and describe all
+ parameters associated with each TSFI.
+
+
+ The functional specification shall describe all actions
+ associated with each TSFI.
+
+
+ The functional specification shall describe all direct error
+ messages that may result from an invocation of each TSFI.
+
+
+ The functional specification shall describe all error messages
+ contained in the TSF implementation representation.
+
+
+ The functional specification shall provide a rationale for
+ each error message contained in the TSF implementation that
+ is not otherwise described in the functional specification
+ justifying why it is not associated with a TSFI.
+
+
+ The formal presentation of the functional specification of
+ the TSF shall describe the TSFI using a formal style,
+ supported by informal, explanatory text where appropriate.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs
+ in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the functional
+ specification is an accurate and complete instantiation of
+ the SFRs.
+
+
+
+
+
+
+ The function of the family
+ is for the developer to make available the implementation
+ representation (and, at higher levels, the implementation
+ itself) of the TOE in a form that can be analysed by the
+ evaluator. The implementation representation is used in
+ analysis activities for other families (analysing the TOE
+ design, for instance) to demonstrate that the TOE conforms
+ its design and to provide a basis for analysis in other
+ areas of the evaluation (e.g., the search for
+ vulnerabilities). The implementation representation is
+ expected to be in a form that captures the detailed internal
+ workings of the TSF. This may be software source code,
+ firmware source code, hardware diagrams and/or IC hardware
+ design language code or layout data.
+
+
+
+ The implementation representation of the TOE is made
+ available so that it can be analysed by the evaluator to
+ demonstrate that the TOE conforms its design and to provide
+ a basis for analysis in other areas of the evaluation (e.g.,
+ the search for vulnerabilities). The implementation
+ representation captures the detailed internal workings of
+ the TSF. This may be software source code, firmware source
+ code, hardware diagrams and/or chip specifications.
+
+
+
+ The components in this family are levelled on the amount of
+ implementation that is mapped to the TOE design
+ description.
+
+
+
+ Source code or hardware diagrams and/or IC hardware design
+ language code or layout data that are used to build the
+ actual hardware are examples of parts of an implementation
+ representation. It is important to note that while the
+ implementation representation must be made available to the
+ evaluator, this does not imply that the evaluator needs to
+ possess that representation. For instance, the developer may
+ require that the evaluator review the implementation
+ representation at a site of the developer's choosing.
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due to
+ lack of information. This does not, however, imply that all
+ of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. The implementation representation is made
+ available to allow analysis of other TOE design
+ decompositions (e.g., functional specification, TOE design),
+ and to gain confidence that the security functionality
+ described at a higher level in the design actually appear to
+ be implemented in the TOE. Conventions in some forms of the
+ implementation representation may make it difficult or
+ impossible to determine from just the implementation
+ representation itself what the actual result of the
+ compilation or run-time interpretation will be. For example,
+ compiler directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code. For this reason, it is important that such ``extra''
+ information or related tools (scripts, compilers, etc.) be
+ provided so that the implementation representation can be
+ accurately determined.
+
+ The purpose of the mapping between the implementation
+ representation and the TOE design description is to aid the
+ evaluator's analysis. The internal workings of the TOE may
+ be better understood when the TOE design is analysed with
+ corresponding portions of the implementation representation.
+ The mapping serves as an index into the implementation
+ representation. At the lower component, only a subset of the
+ implementation representation is mapped to the TOE design
+ description. Because of the uncertainty of which portions of
+ the implementation representation will need such a mapping,
+ the developer may choose either to map the entire
+ implementation representation beforehand, or to wait to see
+ which portions of the implementation representation the
+ evaluator requires to be mapped.
+
+ The implementation representation is manipulated by the
+ developer in a form that is suitable for transformation to
+ the actual implementation. For instance, the developer may
+ work with files containing source code, which is eventually
+ compiled to become part of the TSF. The developer makes
+ available the implementation representation in the form used
+ by the developer, so that the evaluator may use automated
+ techniques in the analysis. This also increases the
+ confidence that the implementation representation examined
+ is actually the one used in the production of the TSF (as
+ opposed to the case where it is supplied in an alternate
+ presentation format, such as a word processor document). It
+ should be noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to supply
+ the evaluator with the information that will maximise the
+ effectiveness of the evaluator's analysis efforts.
+
+ Some forms of the implementation representation may require
+ additional information because they introduce significant
+ barriers to understanding and analysis. Examples include
+ ``shrouded'' source code or source code that has been
+ obfuscated in other ways such that it prevents understanding
+ and/or analysis. These forms of implementation
+ representation typically result from the TOE developer
+ taking a version of the implementation representation and
+ running a shrouding or obfuscation program on it. While the
+ shrouded representation is what is compiled and may be
+ closer to the implementation (in terms of structure) than
+ the original, un-shrouded representation, supplying such
+ obfuscated code may cause significantly more time to be
+ spent in analysis tasks involving the representation. When
+ such forms of representation are created, the components
+ require details on the shrouding tools/algorithms used so
+ that the un-shrouded representation can be supplied, and the
+ additional information can be used to gain confidence that
+ the shrouding process does not compromise any security
+ functionality.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer is suitable for use in other analysis
+ activities; suitability is judged by its
+ conformance to the requirements for this component.
+
+
+
+ The entire implementation representation is made available
+ to ensure that analysis activities are not curtailed due
+ to lack of information. This does not, however, imply that
+ all of the representation is examined when the analysis
+ activities are being performed. This is likely impractical
+ in almost all cases, in addition to the fact that it most
+ likely will not result in a higher-assurance TOE
+ vs. targeted sampling of the implementation
+ representation. For this sub-activity, this is even
+ truer. It would not be productive for the evaluator to
+ spend large amounts of time verifying the requirements for
+ one portion of the implementation representation, and then
+ use a different portion of the implementation
+ representation in performing analysis for other work
+ units. Therefore, the evaluator is encouraged to select
+ the sample of the implementation representation from the
+ areas of the TOE that will be of most interest during the
+ analysis performed during work units from other families
+ (e.g. , and ).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the sample of the implementation
+ representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ sample of the implementation representation shall
+ demonstrate their correspondence.
+
+
+ The evaluator shall confirm that, for the selected sample of
+ the implementation representation, the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the implementation
+ representation defines the TSF to a level of detail such
+ that the TSF can be generated without further design
+ decisions.
+
+ Source code or hardware diagrams and/or IC hardware
+ design language code or layout data that are used to
+ build the actual hardware are examples of parts of an
+ implementation representation. The evaluator samples the
+ implementation representation to gain confidence that it
+ is at the appropriate level and not, for instance, a
+ pseudo-code level which requires additional design
+ decisions to be made. The evaluator is encouraged to
+ perform a quick check when first looking at the
+ implementation representation to assure themselves that
+ the developer is on the right track. However, the
+ evaluator is also encourage to perform the bulk of this
+ check while working on other work units that call for
+ examining the implementation; this will ensure the
+ sample examined for this work unit is relevant.
+
+
+
+
+ The evaluator shall check that the implementation
+ representation is in the form used by development
+ personnel.
+
+ The implementation representation is manipulated by the
+ developer in form that it suitable for transformation to
+ the actual implementation. For instance, the developer
+ may work with files containing source code, which is
+ eventually compiled to become part of the TSF. The
+ developer makes available the implementation
+ representation in the form they use, so that the
+ evaluator may use automated techniques in the
+ analysis. This also increases the confidence that the
+ implementation representation examined is actually the
+ one used in the production of the TSF (as opposed to the
+ case where it is supplied in an alternate presentation
+ format, such as a word processor document). It should be
+ noted that other forms of the implementation
+ representation may also be used by the developer; these
+ forms are supplied as well. The overall goal is to
+ supply the evaluator with the information that will
+ maximise the evaluator's analysis efforts.
+
+ The evaluator samples the implementation representation
+ to gain confidence that it is the version that is usable
+ by the developer. The sample is such that the evaluator
+ has assurance that all areas of the implementation
+ representation are in conformance with the requirement;
+ however, a complete examination of the entire
+ implementation representation is unnecessary.
+
+ Conventions in some forms of the implementation
+ representation may make it difficult or impossible to
+ determine from just the implementation representation
+ itself what the actual result of the compilation or
+ run-time interpretation will be. For example, compiler
+ directives for C language compilers will cause the
+ compiler to exclude or include entire portions of the
+ code.
+
+ Some forms of the implementation representation may
+ require additional information because they introduce
+ significant barriers to understanding and
+ analysis. Examples include shrouded source code or
+ source code that has been obfuscated in other ways such
+ that it prevents understanding and/or analysis. These
+ forms of implementation representation typically result
+ from by taking a version of the implementation
+ representation that is used by the TOE developer and
+ running a shrouding or obfuscation program on it. While
+ the shrouded representation is what is compiled and may
+ be closer to the implementation (in terms of structure)
+ than the original, un-shrouded representation, supplying
+ such obfuscated code may cause significantly more time
+ to be spent in analysis tasks involving the
+ representation. When such forms of representation are
+ created, the components require details on the shrouding
+ tools/algorithms used so that the un-shrouded
+ representation can be supplied, and the additional
+ information can be used to gain confidence that the
+ shrouding process does not compromise any security
+ mechanisms.
+
+ The evaluator samples the implementation representation
+ to gain confidence that all of the information needed to
+ interpret the implementation representation has been
+ supplied. Note that the tools are among those referenced
+ by components. The
+ evaluator is encouraged to perform a quick check when
+ first looking at the implementation representation to
+ assure themselves that the developer is on the right
+ track. However, the evaluator is also encouraged to
+ perform the bulk of this check while working on other
+ work units that call for examining the implementation;
+ this will ensure the sample examined for this work unit
+ is relevant.
+
+
+
+
+ The evaluator shall examine the mapping between the TOE
+ design description and the sample of the implementation
+ representation to determine that it is accurate.
+
+ The evaluator augments the determination of existence
+ (specified in work unit ) by verifying the accuracy of a portion of
+ the implementation representation and the TOE design
+ description. For parts of the TOE design description
+ that are interesting, the evaluator would verify the
+ implementation representation accurately reflects the
+ description provided in the TOE design
+ description.
+
+ For example, the TOE design description might identify a
+ login module that is used to identify and authenticate
+ users. If user authentication is sufficiently
+ significant, the evaluator would verify that the
+ corresponding code in fact implements that service as
+ described in the TOE design description. It might also
+ be worthwhile to verify that the code accepts the
+ parameters as described in the functional
+ specification.
+
+ It is worth pointing out the developer must choose
+ whether to perform the mapping for the entire
+ implementation representation, thereby guaranteeing that
+ the chosen sample will be covered, or waiting for the
+ sample to be chosen before performing the mapping. The
+ first option is likely more work, but may be completed
+ before the evaluation begins. The second option is less
+ work, but will produce a suspension of evaluation
+ activity while the necessary evidence is being
+ produced.
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the implementation representation made available by the
+ developer can be transformed into the implementation that
+ is used in the testing activities.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the implementation representation;
+
+
+ the documentation of the development tools, as
+ resulting from ;
+
+
+ TOE design description.
+
+
+
+
+ The developer shall make available the implementation
+ representation for the entire TSF.
+
+
+ The developer shall provide a mapping between the TOE design
+ description and the entire implementation representation.
+
+
+ The implementation representation shall define the TSF to a
+ level of detail such that the TSF can be generated without
+ further design decisions.
+
+
+ The implementation representation shall be in the form used
+ by the development personnel.
+
+
+ The mapping between the TOE design description and the
+ entire implementation representation shall demonstrate their
+ correspondence.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ This family addresses the assessment of the internal
+ structure of the TSF. A TSF whose internals are
+ well-structured is easier to implement and less likely to
+ contain flaws that could lead to vulnerabilities; it is also
+ easier to maintain without the introduction of flaws.
+
+
+
+ The internal structure of the TSF can aid or hamper
+ understandability of the implementation representation.
+ Source code that conforms to coding standards, that exhibit
+ a minimum of interactions, and that is written in modules
+ each with a single purpose, is much easier to understand
+ than poorly-structured code with unnecessary or
+ loosely-defined interactions.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of structure and minimisation of complexity
+ required. places
+ requirements for well-structured internals on only selected
+ parts of the TSF. This component is not included in an EAL
+ because this component is viewed for use in special
+ circumstances (e.g., the sponsor has a specific concern
+ regarding a cryptographic module, which is isolated from the
+ rest of the TSF) and would not be widely applicable.
+
+ At the next level, the requirements for well-structured
+ internals are placed on the entire TSF. Finally,
+ minimisation of complexity is introduced in the highest
+ component.
+
+
+
+ These requirements, when applied to the internal structure
+ of the TSF, typically result in improvements that aid both
+ the developer and the evaluator in understanding the TSF,
+ and also provide the basis for designing and evaluating test
+ suites. Further, improving understandability of the TSF
+ should assist the developer in simplifying its
+ maintainability.
+
+ The requirements in this family are presented at a fairly
+ abstract level. The wide variety of TOEs makes it impossible
+ to codify anything more specific than ``well-structured'' or
+ ``minimum complexity''. Judgements on structure and
+ complexity are expected to be derived from the specific
+ technologies used in the TOE. For example, software is
+ likely to be considered well-structured if it exhibits the
+ characteristics cited in the software engineering
+ disciplines. The components within this family call for
+ identifying the standards for measuring the characteristic
+ of being well-structured and not overly-complex.
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring specific portions of the TSF to be
+ well-structured. The intent is that the entire TSF has
+ been designed and implemented using sound engineering
+ principles, but the analysis is performed upon only a
+ specific subset.
+
+
+
+ This component requires the PP or ST author to fill in an
+ assignment with the subset of the TSF. This subset may be
+ identified in terms of the internals of the TSF at any
+ layer of abstraction. For example:
+
+ the structural elements of the TSF as identified
+ in the TOE design (e.g. ``The developer shall design
+ and implement the audit subsystem
+ such that it has well-structured internals.'')
+ the implementation (e.g. ``The developer shall
+ design and implement the encrypt.c and
+ decrypt.c files such that it has
+ well-structured internals.'' or ``The developer shall
+ design and implement the 6227 IC chip
+ such that it has well-structured
+ internals.'')
+
+ It is likely this would not be readily accomplished by
+ referencing the claimed SFRs (e.g. ``The developer shall
+ design and implement the portion of the TSF that
+ provide anonymity as defined in
+ such that it has well-structured
+ internals.'') because this does not indicate where to
+ focus the analysis.
+
+ This component has limited value and would be suitable in cases
+ where potentially-malicious users/subjects have limited or
+ strictly controlled access to the TSFIs or where there is
+ another means of protection (e.g., domain separation) that
+ ensures the chosen subset of the TSF cannot be adversely
+ affected by the rest of the TSF (e.g., the cryptographic
+ functionality, which is isolated from the rest of the TSF, is
+ well-structured).
+
+
+
+ The objective of this sub-activity is to determine whether
+ the defined subset of the TSF is designed and structured
+ such that the likelihood of flaws is reduced and that
+ maintenance can be more readily performed without the
+ introduction of flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The use of the assignment in this component levies stricter
+ constraints on the subset of the TSF that is explicitly
+ identified in the assignment
+ than on the remainder of the TSF.
+ While the entire TSF is to be designed using good
+ engineering principles and result in a well-structured TSF, only
+ the specified subset is specifically analysed for this
+ characteristic. The evaluator determines that the developer's
+ application of coding standards result in a TSF that is
+ understandable.
+
+ The primary goal of this component is to ensure the TSF
+ subset's implementation representation is understandable
+ to facilitate maintenance and analysis (of both the
+ developer and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance);
+
+
+ the TSF internals description and justification;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement subset
+ of the TSF such that it has well-structured
+ internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall explain the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ assigned subset of the TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF subset:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ subset
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the TSF
+ subset
+
+ For other types of technologies used in the TOE - such as
+ non-procedural software (e.g. object-oriented programming),
+ widespread commodity hardware (e.g. PC microprocessors), and
+ special-purpose hardware (e.g. smart-card processors) - the
+ evaluator should seek guidance from the evaluation authority for
+ determining the adequacy of criteria for being
+ ``well-structured''.
+
+
+
+ The evaluator shall check the TSF internals
+ description to determine that it identifies the Assigned
+ subset of the TSF.
+
+ This subset may be identified in terms of the internals
+ of the TSF at any layer of abstraction. For example, it
+ may be in terms of the structural elements of the TSF as
+ identified in the TOE design (e.g. the audit subsystem),
+ or in terms of the implementation
+ (e.g. encrypt.c and
+ decrypt.c files, or the 6227 IC
+ chip).
+
+ It is insufficient to identify this subset in terms of
+ the claimed SFRs (e.g. the portion of the TSF that
+ provide anonymity as defined in ) because this does not indicate where to
+ focus the analysis.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ assigned TSF subset is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF subset meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF subset meets the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF subset and
+ the modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ assigned subset of the TSF.
+
+
+ The evaluator shall determine that the TOE design for
+ the assigned TSF subset is well-structured.
+
+ The evaluator examines a sample of the TOE design to
+ verify the accuracy of the justification. For example, a
+ sample of the TOE design is analysed to determine its
+ adherence to the design standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the assigned TSF
+ subset is well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF subset to
+ verify the accuracy of the internals description. For
+ example, a sample of the procedural software portions of
+ the TSF subset is analysed to determine its cohesion and
+ coupling, its adherence to the coding standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured. The intent is
+ that the entire TSF has been designed and implemented
+ using sound engineering principles.
+
+
+
+ Judgements on the adequacy of the structure are expected to
+ be derived from the specific technologies used in the TOE.
+ This component calls for identifying the standards for
+ measuring the characteristic of being
+ well-structured.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TSF is designed and structured such that the
+ likelihood of flaws is reduced and that maintenance can be
+ more readily performed without the introduction of
+ flaws.
+
+
+
+ The role of the internals description is to provide
+ evidence of the structure of the design and implementation
+ of the TSF.
+
+ The structure of the design has two aspects: the
+ constituent parts of the TSF and the procedures used to
+ design the TSF. In cases where the TSF is designed in a
+ manner consistent with the design represented by the TOE
+ design (see ), the
+ assessment of the TSF design is obvious. In cases where
+ the design procedures (see )
+ are being followed, the assessment of the TSF design
+ procedures is similarly obvious.
+
+ In cases where the TSF is implemented using
+ procedure-based software, this structure is assessed on
+ the basis of its modularity; the
+ modules identified in the internals description are the
+ same as the modules identified in the TOE design (). A module consists of one or
+ more source code files that cannot be decomposed into
+ smaller compilable units.
+
+ The primary goal of this component is to ensure the TSF's
+ implementation representation is understandable to
+ facilitate maintenance and analysis (of both the developer
+ and evaluator).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation (if is part of the claimed
+ assurance));
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall describe the characteristics used to
+ judge the meaning of ``well-structured''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall examine the justification to
+ determine that it identifies the basis for determining
+ whether the TSF is well-structured.
+
+ The evaluator verifies that the criteria for determining
+ the characteristic of being well-structured are clearly
+ defined in the justification. Acceptable criteria
+ typically originate from industry standards for the
+ technology discipline. For example, procedural software
+ that executes linearly is traditionally viewed as
+ well-structured if it adheres to software engineering
+ programming practises, such as those defined in the IEEE
+ Standard (IEEE Std 610.12-1990). For
+ example, it would identify the criteria for the
+ procedural software portions of the TSF:
+
+ the process used for modular
+ decomposition
+ coding standards used in the development of the
+ implementation
+ a description of the maximum acceptable level of
+ intermodule coupling exhibited by the TSF
+ a description of the minimum acceptable level of
+ cohesion exhibited the modules of the
+ TSF
+
+ For other types of technologies used in the TOE - such
+ as non-procedural software (e.g. object-oriented
+ programming), widespread commodity hardware (e.g. PC
+ microprocessors), and special-purpose hardware
+ (e.g. smart-card processors) - the evaluation authority
+ should be consulted for determining the adequacy of
+ criteria for being ``well-structured''.
+
+
+
+ The evaluator shall examine the TSF internals
+ description to determine that it demonstrates that the
+ TSF is well-structured.
+
+ The evaluator examines the internals description to
+ ensure that it provides a sound explanation of how the
+ TSF meets the criteria from
+
+ For example, it would explain how the procedural
+ software portions of the TSF meet the following:
+
+ that there is a one-to-one correspondence
+ between the modules identified in the TSF and the
+ modules described in the TOE design ()
+ how the TSF design is a reflection of the
+ modular decomposition process
+ a justification for all instances where the
+ coding standards were not used or met
+ a justification for any coupling or cohesion
+ outside the acceptable bounds
+
+
+
+ The evaluator shall perform an internals analysis on the
+ TSF.
+
+
+ The evaluator shall determine that the TOE design is
+ well-structured.
+
+ The evaluator examines the TOE design of a sample of the
+ TSF to verify the accuracy of the justification. For
+ example, a sample of the TOE design is analysed to
+ determine its adherence to the design standards, etc. As
+ with all areas where the evaluator performs activities
+ on a subset the evaluator provides a justification of
+ the sample size and scope
+
+ The description of the TOE's decomposition into
+ subsystems and modules will make the argument that the
+ TSF subset is well-structured self-evident. Verification
+ that the procedures for structuring the TSF (as examined
+ in ) are being followed
+ will make it self-evident that the TSF subset is
+ well-structured.
+
+
+
+ The evaluator shall determine that the TSF is
+ well-structured.
+
+ If is not part of the
+ claimed assurance, then this work unit is not applicable
+ and is therefore considered to be satisfied.
+
+ The evaluator examines a sample of the TSF to verify the
+ accuracy of the internals description. For example, a
+ sample of the procedural software portions of the TSF is
+ analysed to determine its cohesion and coupling, its
+ adherence to the coding standards, etc. As with all
+ areas where the evaluator performs activities on a
+ subset the evaluator provides a justification of the
+ sample size and scope.
+
+
+
+
+
+
+
+
+
+
+ The objective of this component is to provide a means for
+ requiring the TSF to be well-structured and of minimal
+ complexity. The intent is that the entire TSF has been
+ designed and implemented using sound engineering
+ principles.
+
+
+
+ Judgements on the adequacy of the structure and complexity
+ are expected to be derived from the specific technologies
+ used in the TOE. This component calls for identifying the
+ standards for measuring the structure and
+ complexity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the modular design description;
+
+
+ the implementation representation;
+
+
+ the TSF internals description;
+
+
+ the documentation of the coding standards, as
+ resulting from .
+
+
+
+
+ The developer shall design and implement the entire TSF such
+ that it has well-structured internals.
+
+
+ The developer shall provide an internals description and
+ justification.
+
+
+ The justification shall describe the characteristics used to
+ judge the meaning of ``well-structured'' and ``complex''.
+
+
+ The TSF internals description shall demonstrate that the
+ entire TSF is well-structured and is not overly complex.
+
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform an internals analysis on the
+ entire TSF.
+
+
+
+
+
+
+ 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.
+
+
+
+ A formal security model precisely describes important
+ aspects of security and their relationship to the behaviour
+ of the TSF. Formalism helps to prove mathematically the
+ thoroughness of the security.
+
+
+
+ This family contains only one component.
+
+
+
+ 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.
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+ 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.
+
+ 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. contains an assignment for identifying these
+ policies that are formally modelled.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the formal TOE security policy model clearly and
+ consistently describes the rules of operation, states,
+ transition, invariants, and other security properties of
+ the claimed SFRs and whether this description corresponds
+ with the description of the security functionality in the
+ functional specification.
+
+
+
+ This activity applies to cases where the developer has
+ formally modelled all security policies of the TOE that
+ are capable of being modelled formally.
+
+ A formal TOE security policy model is a representation of
+ the rules (synonymously termed ``principles'') and
+ characteristics of security policies in mathematical
+ terms. Their formal counterparts are called security
+ properties and security features, respectively. The
+ representation includes but is not limited to algebraic
+ specifications, finite state machines and logic formalisms
+ strong enough to formally infer the properties from the
+ features. The formal security policy model is accompanied
+ by an informal interpretation explaining how the rules and
+ characteristics are mapped to the respective properties
+ and features.
+
+ It is recognised that not all policies (see work unit
+ ) can be formally
+ modelled for all TOEs. This is because either the state of
+ the art is insufficient to formally model a given policy,
+ or because the nature of the TOE renders impossible the
+ modelling of policies that would otherwise be possible to
+ model. If none of the SFRs can be formally modelled, this
+ component cannot be met.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE security policy model;
+
+
+ the operational user guidance;
+
+
+
+
+ The developer shall provide a formal security policy model for
+ the list of policies that are formally
+ modelled.
+
+ 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.
+
+
+ The developer shall provide a formal proof of correspondence
+ between the model and any formal functional specification.
+
+
+ The developer shall provide a demonstration of
+ correspondence between the model and the functional
+ specification.
+
+
+ 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.
+
+
+ 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.
+
+
+ The correspondence between the model and the functional
+ specification shall be at the correct level of formality.
+
+
+ The correspondence shall show that the functional
+ specification is consistent and complete with respect to the
+ model.
+
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it is written in a formal
+ style.
+
+ The evaluator identifies the formal framework upon which
+ the TOE security policy model is based and ensures that
+ it is founded on well established mathematical concepts,
+ and identifies the security properties and features
+ addressed in the application notes and ensures the
+ formalisation of at least one security policy. If no
+ policy is formally modelled, this component cannot be
+ successfully claimed.
+
+ For additional guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all necessary
+ informal explanatory text.
+
+ Supporting narrative descriptions are necessary for all
+ parts of the model (for example, to make clear the
+ meaning of any formal notation and how they are used)
+ including the security properties and features.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model to determine that it contains all policies that
+ can be formally modelled.
+
+ It is recognised that not all policies can be formally
+ modelled for all TOEs. This is because either the state
+ of the art is insufficient to formally model a given
+ policy, or because the nature of the TOE renders
+ impossible the modelling of policies that would
+ otherwise be possible to model.
+
+ While access control, information flow control, and data
+ integrity policies have all been formally modelled
+ successfully, the possibility of modelling other
+ policies is based on a case by case decision. Abstention
+ from formally modelling security relevant policies
+ requires argumentation and rests the burden of proof
+ entirely on the developer's side.
+
+ For any security policy where formal models are not
+ possible, the policy must be identified in the
+ assignment of .
+
+
+
+
+ The evaluator shall examine the model to determine that
+ the security behaviour of the TOE is clearly
+ articulated.
+
+ The security policy model's properties describe the
+ TOE's behaviour in enforcing the principles of the
+ policy. For example, a policy that is modelled on the
+ basis of state transitions would include principles of
+ its states, identify its initial state, and define what
+ it means to be a secure state.
+
+ The security policy model's features describe the
+ attributes and conditions of the TOE that come into
+ consideration when enforcing its policy's
+ characteristics. For example, a policy that is modelled
+ on the basis of state transitions would describe the
+ necessary conditions to transform the TOE from one state
+ to the next.
+
+ An informal interpretation of all formal concepts
+ (including attributes, predicates and variables, if
+ available) must also be provided in order to make clear
+ their intended meaning.
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the formal functional
+ specification to determine that it is presented in a
+ formal style.
+
+ If no part of the functional specification is formal,
+ this work unit is not applicable and is therefore
+ considered to be satisfied. The corresponding work will
+ be performed under work unit .
+
+ For any part of the functional specification that is
+ formally presented, the correspondence between that part
+ of the functional specification and the security policy
+ model must be formal. Analysis of the content is
+ performed as part of work units through .
+
+ For guidance on formal methods refer to .
+
+
+
+
+ The evaluator shall examine the correspondence between
+ the security policy model and the semiformal functional
+ specification to determine that it is presented in a
+ semiformal style.
+
+ If the entire functional specification is formal, this
+ work unit is not applicable and is therefore considered
+ to be satisfied. The corresponding work will be
+ performed under work unit .
+
+ For formally-modelled policies whose corresponding
+ description in the functional specification is not
+ formally presented, the correspondence between the model
+ and the functional specification must be a semiformal
+ demonstration. Analysis of the content is performed as
+ part of work units
+ through .
+
+ If a security policy model exists, either this work unit
+ or the previous work unit (or both) will be
+ applicable.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it formally proves the
+ correspondence between the security properties and the
+ security features.
+
+ The proof shall show that the security features enforce
+ the security properties. To determine the enforcement,
+ the evaluator considers the security properties and the
+ security features and verifies that the arguments used
+ in the proof are valid. The proof of correspondence
+ between the security properties and the security
+ features shall be formal.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that it proves the internal
+ consistency of the TOE security policy model.
+
+ The proof shall show the absence of contradictions
+ within the TOE security policy model. In determining the
+ absence of contradictions, the evaluator verifies that
+ the arguments used in the proof are valid.
+
+ Since the TOE security policy model is formal, the proof
+ of its internal consistency shall be formal. It is
+ recognised that a complete formal proof of the internal
+ consistency of the TOE security policy model usually is
+ not possible due to the fundamental nature of formal
+ frameworks. Generally, it is sufficient to generate
+ evidence using formal proofs based on the specific TOE
+ security policy model that prove the internal
+ consistency by means of a combination with generic
+ arguments of the formal framework.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is consistent with respect to policies described by the
+ security policies (as articulated by the functional
+ requirements in the ST).
+
+ The examination considers the informal relationships of
+ the model. Hence the meaning of consistency reflects
+ the conventional understanding in contrast to the
+ internal consistency concept of the previous work
+ unit.
+
+ In determining consistency, the evaluator verifies that
+ the rationale shows that each description of properties
+ and features in the security policy model accurately
+ reflects the intent of the security policies. For
+ example, if a policy stated that access control was
+ necessary to the granularity of a single individual,
+ then a security policy model describing the security
+ behaviour of a TOE in the context of controlling groups
+ of users would not be consistent. Likewise, if the
+ policy stated that access control for groups of users
+ was necessary, then a security policy model describing
+ the security behaviour of a TOE in the context of
+ controlling individual users would also not be
+ consistent.
+
+ The evaluator also examines whether the security
+ policies are reflected within their formal counterparts
+ of the security policy model.
+
+
+
+
+ The evaluator shall examine the TOE security policy
+ model rationale to determine that the behaviour modelled
+ is complete with respect to the policies described by
+ the security policies (i.e. as articulated by the
+ functional requirements in the ST).
+
+ In determining completeness of this rationale, the
+ evaluator considers the properties and features of the
+ security policy model and maps those properties and
+ features to explicit policy statements (i.e. functional
+ requirements). The rationale should show that all
+ policies that are required to be modelled have an
+ associated property or feature description in the TOE
+ security policy model.
+
+ Abstention from formally modelling policy statements
+ always calls for justification on the developer's side
+ (also confer the application notes above).
+
+
+
+
+ The evaluator shall examine the demonstration of
+ correspondence to determine that all Assigned policies
+ are mapped to functions within the functional
+ specification.
+
+ If all policies are included within the security policy
+ model (i.e. they are all formally modelled) and the
+ assignment in is
+ therefore empty, this work unit is not applicable and is
+ therefore considered to be satisfied.
+
+ The evaluator verifies that the correspondence
+ demonstrates that the descriptions of the SFR-related
+ functions in the functional specification correspond to
+ the SFRs. This may be done as part of the work units addressing
+ correspondence to the SFRs. However, if the developer
+ provides a well-structured semiformal or informal
+ security policy model to better articulate the notions
+ of security enforced by the TOE, the evaluator will
+ verify that such a model is consistent with the
+ SFRs.
+
+
+
+
+
+
+
+ The design description of a TOE provides both context for a
+ description of the TSF, and a thorough description of the
+ TSF. As assurance needs increase, the level of detail
+ provided in the description also increases. As the size and
+ complexity of the TSF increase, multiple levels of
+ decomposition are appropriate. The design requirements are
+ intended to provide information (commensurate with the given
+ assurance level) so that a determination can be made that
+ the security functional requirements are realised.
+
+
+
+ The design description provides a further-refined
+ description of the TSF from that presented in the functional
+ specification. The functional specification provides a
+ description of what the TSF does at its
+ interface; the design description provides more insight into
+ the TSF by describing how the TSF works in
+ order to perform the functions supporting the SFRs. At lower
+ assurance levels, complete details relating to all portions
+ of the TSF are not required. As the desired assurance
+ increases, more detail is made available so that analysis
+ can be performed that supports the assurance claims being
+ made.
+
+
+
+ The components in this family are levelled on the basis of
+ the amount of information that is required to be presented
+ with respect to the TSF, and on the degree of formalism
+ required of the design description.
+
+
+
+ The goal of design documentation is to provide sufficient
+ information to determine the TSF boundary, and to describe
+ how the TSF implements the Security
+ Functional Requirements. The amount and structure of the
+ design documentation will depend on the complexity of the
+ TOE and the number of SFRs; in general, a very complex TOE
+ with a large number of SFRs will require more design
+ documentation than a very simple TOE implementing only a few
+ SFRs. Very complex TOEs will benefit (in terms of the
+ assurance provided) from the production of differing levels
+ of decomposition in describing the design, while very simple
+ TOEs do not require both high-level and low-level
+ descriptions of its implementation.
+
+ This family uses two levels of decomposition: the
+ subsystem and the module.
+ A module is the most specific description of functionality:
+ it is a description of the implementation. A developer
+ should be able to implement the part of the TOE described by
+ the module with no further design decisions. A subsystem is
+ a description of the design of the TOE; it helps to provide
+ a high-level description of what a portion of the TOE is
+ doing and how. As such, a subsystem may be further divided
+ into lower-level subsystems, or into modules. Very complex
+ TOEs might require several levels of subsystems in order to
+ adequately convey a useful description of how the TOE works.
+ Very simple TOEs, in contrast, might not require a subsystem
+ level of description; the module might clearly describe how
+ the TOE works.
+
+ The general approach adopted for design documentation is
+ that, as the level of assurance increases, the emphasis of
+ description shifts from the general (subsystem level) to
+ more (module level) detail. In cases where a module-level
+ of abstraction is appropriate because the TOE is simple
+ enough to be described at the module level, yet the level of
+ assurance calls for a subsystem level of description, the
+ module-level description alone will suffice. For complex
+ TOEs, however, this is not the case: an enormous amount of
+ (module-level) detail would be incomprehensible without an
+ accompanying subsystem level of description.
+
+ This approach follows the general paradigm that providing
+ additional detail about the implementation of the TSF will
+ result in greater assurance that the SFRs are implemented
+ correctly, and provide information that can be used to
+ demonstrate this in testing ().
+
+ In the requirements for this family, the term
+ interface is used as the means of
+ communication (between two subsystems or modules). It
+ describes how the communication is invoked; this is similar
+ to the details of TSFI (see ). The term interaction is
+ used to identify the purpose for communication; it
+ identifies why two subsystems or modules are
+ communicating.
+
+
+ The requirements define collections of details about
+ subsystems and modules to be provided:
+
+ The subsystems and modules are
+ identified with a simple list of what
+ they are.
+
+ Subsystems and modules may be categorised
+ (either implicitly or explicitly) as ``SFR-enforcing'',
+ ``SFR-supporting'', or ``SFR-non-interfering''; these terms are
+ used the same as they are used in .
+
+ A subsystem's behaviour is what it does. The
+ behaviour may also be categorised as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering. The behaviour of the
+ subsystem is never categorised as more SFR-relevant than the
+ category of the subsystem itself. For example, an SFR-enforcing
+ subsystem can have SFR-enforcing behaviour as well as
+ SFR-supporting or SFR-non-interfering behaviour.
+ A behaviour summary of a
+ subsystem is an overview of the actions it performs
+ (e.g. ``The TCP subsystem assembles IP datagrams into
+ reliable byte streams'').
+ A behaviour description of a
+ subsystem is an explanation of everything it
+ does. This description should be at a level of detail
+ that one can readily determine whether the behaviour
+ has any relevance to the enforcement of the
+ SFRs.
+
+ A description of interactions among or between
+ subsystems or modules identifies the reason that subsystems or
+ modules communicate, and characterises the information that is
+ passed. It need not define the information to the same level of
+ detail as an interface specification. For example, it would be
+ sufficient to say ``subsystem X requests a block of memory from
+ the memory manager, which responds with the location of the
+ allocated memory.
+ A description of interfaces provides the
+ details of how the interactions among modules are achieved.
+ Rather than describing the reason the modules are communicating
+ or the purpose of their communication (that is, the description
+ of interactions), the description of interfaces describes the
+ details of how that communication is accomplished, in terms of
+ the structure and contents of the messages, semaphores, internal
+ process communications, etc.
+
+
+ The purpose describes how a module provides
+ their functionality. It provides sufficient detail that no
+ further design decisions are needed. The correspondence between
+ the implementation representation that implements the module,
+ and the purpose of the module should be readily apparent.
+ A module is otherwise described
+ in terms of whatever is identified in the
+ element. Subsystems and modules, and
+ ``SFR-enforcing'', etc. are all further explained in
+ greater detail in .
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each
+ SFR-supporting or SFR-non-interfering TSF subsystem in
+ sufficient detail to determine that it is not SFR-enforcing.
+
+
+ The design shall summarise the SFR-enforcing behaviour of
+ the SFR-enforcing subsystems.
+
+
+ The design shall provide a description of the interactions
+ among SFR-enforcing subsystems of the TSF, and between the
+ SFR-enforcing subsystems of the TSF and other subsystems of
+ the TSF.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-supporting or SFR-non-interfering subsystem of the TSF
+ is described such that the evaluator can determine that the
+ subsystem is SFR-supporting or SFR-non-interfering.
+
+ SFR-supporting and SFR-non-interfering subsystems do not need to
+ be described in detail as to how they function in the system.
+ However, the evaluator makes a determination, based on the
+ evidence provided by the developer, that the subsystems that do
+ not have high-level descriptions are SFR-supporting or
+ SFR-non-interfering. Note that if the developer provides a
+ uniform level of detailed documentation then this work unit will
+ be largely satisfied, since the point of categorising the
+ subsystems is to allow the developer to provide less information
+ for SFR-supporting and SFR-non-interfering subsystems than for
+ SFR-enforcing subsystems.
+
+ An SFR-supporting subsystem is one that is depended on
+ by an SFR-enforcing subsystem in order to implement an
+ SFR, but does not play as direct a role as an
+ SFR-enforcing subsystem. An SFR-non-interfering
+ subsystem is one that is not depended upon, in either a
+ supporting or enforcing role, to implement an
+ SFR.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and high-level
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. A high-level description need not refer to
+ specific data structures (although it may), but instead
+ talks about more general data flow, message flow, and
+ control relationships within a subsystem. The goal of
+ these descriptions is to give the evaluator enough
+ information to understand how the
+ SFR-enforcing behaviour is achieved. Note that the
+ evaluator should find unacceptable asserts of
+ SFR-enforcement in the TOE design documentation for this
+ work unit. It should be noted that it is the
+ evaluator's determination with respect to what
+ ``high-level'' means for a particular TOE, and the
+ evaluator obtains enough information from the developer
+ to make a sound verdict for this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work
+ unit
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the
+ SFR-enforcing subsystems and other subsystems is to help provide
+ the reader a better understanding of how the TSF performs it
+ functions. These interactions do not need to be characterised at
+ the implementation level (e.g., parameters passed from one
+ routine in a subsystem to a routine in a different subsystem;
+ global variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem), but the
+ data elements identified for a particular subsystem that are
+ going to be used by another subsystem need to be covered in this
+ discussion. Any control relationships between subsystems (e.g.,
+ a subsystem responsible for configuring a rule base for a
+ firewall system and the subsystem that actually implements these
+ rules) should also be described.
+
+ The evaluators need to use their own judgement in assessing the
+ completeness of the description. If the reason for an
+ interaction is unclear, or if there are SFR-related interactions
+ (discovered, for instance, in examining the descriptions of
+ subsystem behaviour) that do not appear to be described, the
+ evaluator ensures that this information is provided by the
+ developer. However, if the evaluator can determine that
+ interactions among a particular set of subsystems, while
+ incompletely described by the developer, will not aid in
+ understanding the overall functionality nor security
+ functionality provided by the TSF, then the evaluator may choose
+ to consider the description sufficient, and not pursue
+ completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall describe the behaviour of each SFR
+ non-interfering subsystem of the TSF in detail sufficient to
+ determine that it is SFR non-interfering.
+
+
+ The design shall describe the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+
+ The design shall summarise the SFR-supporting and
+ SFR-non-interfering behaviour of the SFR-enforcing subsystems.
+
+
+ The design shall summarise the behaviour of the
+ SFR-supporting subsystems.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . At this
+ level of assurance, the decomposition only need be at
+ the ``subsystem'' level.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each SFR-non-interfering subsystem of the TSF is
+ described such that the evaluator can determine that the
+ subsystem is SFR-non-interfering.
+
+ SFR-non-interfering subsystems do not need to be
+ described in detail as to how they function in the
+ system. However, the evaluator makes a determination,
+ based on the evidence provided by the developer, that
+ the subsystems that do not have detailed descriptions
+ are SFR-non-interfering. Note that if the developer
+ provides a uniform level of detailed documentation then
+ this work unit will be largely satisfied, since the
+ point of categorising the subsystems is to allow the
+ developer to provide less information for
+ SFR-non-interfering subsystems than for SFR-enforcing
+ and SFR-supporting subsystems.
+
+ An SFR-non-interfering subsystem is one on which the
+ SFR-enforcing and SFR-supporting subsystems have no
+ dependence; that is, they play no role in implementing
+ SFR functionality.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete, accurate, and detailed
+ description of the SFR-enforcing behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ SFR-enforcing behaviour refers to how a
+ subsystem provides the functionality that implements an
+ SFR. While not at the level of an algorithmic
+ description, a detailed description of behaviour
+ typically discusses how the functionality is provided in
+ terms of what key data and data structures are, what
+ control relationships exist within a subsystem, and how
+ these elements work together to provide the
+ SFR-enforcing behaviour. Such a description also
+ references SFR-supporting behaviour, which the evaluator
+ should consider in performing subsequent work
+ units.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work unit.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that it
+ provides a complete and accurate high-level description of the
+ SFR-supporting and SFR-non-interfering behaviour of the
+ SFR-enforcing subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous work unit, this work unit calls for
+ the evaluator to assess the information provided for
+ SFR-enforcing subsystems that is SFR-supporting or
+ SFR-non-interfering. The goal of this assessment is two-fold.
+ First, it should provide the evaluator greater understanding of
+ the way each subsystem works. Second, the evaluator determines
+ that all SFR-enforcing behaviour exhibited by a subsystem has
+ been described. Unlike the previous work unit, the information
+ provided for the SFR-supporting or SFR-non-interfering behaviour
+ does not have to be as detailed as that provided by the
+ SFR-enforcing behaviour. For example, data structures or data
+ items that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all. It is the
+ evaluator's determination, however, with respect to what
+ ``high-level'' means for a particular TOE, and the evaluator
+ obtains enough information from the developer (even if it turns
+ out to be equivalent to information provided for the parts of
+ the subsystem that are SFR-enforcing) to make a sound verdict
+ for this work unit.
+
+ The evaluator is cautioned, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator examines
+ other information available (e.g., functional specification,
+ security architecture description). Descriptions of functionality in these
+ documents should be consistent with what is provided for
+ evidence for this work unit. In particular, the functional
+ specification should be used to determine that the behaviour
+ required to implement the TSF Interfaces described by the
+ functional specification are completely described by the
+ subsystem, since the behaviour will either be SFR-enforcing,
+ SFR-supporting or SFR-non-interfering.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it provides a complete and accurate high-level
+ description of the behaviour of the SFR-supporting
+ subsystems.
+
+ The developer may designate subsystems as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ subsystems have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ subsystems have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular subsystem.
+
+ In contrast to the previous two work units, this work
+ unit calls for the developer to provide (and the
+ evaluator to assess) information about SFR supporting
+ subsystems. Such subsystems should be referenced by the
+ descriptions of the SFR-enforcing subsystems, as well as
+ by the descriptions of interactions in work unit . The goal of evaluator's
+ assessment, like that for the previous work unit, is
+ two-fold. First, it should provide the evaluator with
+ an understanding of the way each SFR-supporting
+ subsystem works. Second, the evaluator determines that
+ the behaviour is described in enough detail so that the
+ way in which the subsystem supports the SFR-enforcing
+ behaviour is clear, and that the behaviour is not itself
+ SFR-enforcing. The information provided for
+ SFR-supporting subsystem's behaviour does not have to be
+ as detailed as that provided by the SFR-enforcing
+ behaviour. For example, data structures or data items
+ that do not pertain to SFR-enforcing functionality will
+ likely not need to be described in detail, if at all.
+ It is the evaluator's determination, however, with
+ respect to what ``high-level'' means for a particular
+ TOE, and the evaluator obtains enough information from
+ the developer (even if it turns out to be equivalent to
+ information provided for the parts of the subsystem that
+ are SFR-enforcing) to make a sound verdict for this work
+ unit.
+
+ The evaluator is cautions, however, that ``perfect''
+ assurance is not a goal nor required by this work unit,
+ so judgement will have to be exercised in determine the
+ amount and composition of the evidence required to make
+ a verdict on this work unit.
+
+ To determine completeness and accuracy, the evaluator
+ examines other information available (e.g., functional
+ specification, security architecture description,
+ implementation representation). Descriptions of
+ functionality in these documents should be consistent
+ with what is provided for evidence for this work unit.
+ In particular, the functional specification should be
+ used to determine that the behaviour required to
+ implement the TSF Interfaces described by the functional
+ specification are completely described by the
+ subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ The goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs it functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem need to
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be
+ described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the descriptions of subsystem behaviour) that do not
+ appear to be described, the evaluator ensures that this
+ information is provided by the developer. However, if the
+ evaluator can determine that interactions among a particular set
+ of subsystems, while incompletely described by the developer,
+ will not aid in understanding the overall functionality nor
+ security functionality provided by the TSF, then the evaluator
+ may choose to consider the description sufficient, and not
+ pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the subsystems of the TSF described in the TOE
+ design.
+
+ The subsystems described in the TOE design provide a
+ description of how the TSF works at a detailed level for
+ SFR-enforcing portions of the TSF, and at a higher level
+ for other portions of the TSF. The TSFI provide a
+ description of how the implementation is exercised. The
+ evidence from the developer identifies the subsystem
+ that is initially involved when an operation is
+ requested at the TSFI, and identify the various
+ subsystems that are primarily responsible for
+ implementing the functionality. Note that a complete
+ ``call tree'' for each TSFI is not required for this
+ work unit.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ subsystem. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a subsystem at the TSF boundary. This determination
+ can be made by reviewing the subsystem description and
+ interactions, and from this information determining its
+ place in the architecture. The next aspect of accuracy
+ is that the mapping makes sense. For instance, mapping a
+ TSFI dealing with access control to a subsystem that
+ checks passwords is not accurate. The evaluator should
+ again use judgement in making this determination. The
+ goal is that this information aids the evaluator in
+ understanding the system and implementation of the SFRs,
+ and ways in which entities at the TSF boundary can
+ interact with the TSF. The bulk of the assessment of
+ whether the SFRs are described accurately by the
+ subsystems is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A,
+ behaviours x, p, and q; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator ensures that each security requirement
+ listed in the TOE security functional requirements
+ subclause of the ST has a corresponding design description
+ in the TOE design that accurately details how the TSF
+ meets that requirement. This requires that the evaluator
+ identify a collection of subsystems that are responsible
+ for implementing a given functional requirement, and
+ then examine those subsystems to understand how the
+ requirement is implemented. Finally, the evaluator would
+ assess whether the requirement was accurately
+ implemented.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems have been identified, or if
+ adequate detail had been provided for those
+ subsystems.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing
+ modules and enough information about the SFR-supporting
+ and SFR-non-interfering modules for the evaluator to
+ determine that the SFRs are completely and accurately
+ implemented; as such, the TOE design provides an
+ explanation of the implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the evaluator
+ determines that the TSF boundary has been adequately
+ described. Second, the evaluator determines that the developer
+ has provided documentation that conforms to the content and
+ presentation requirements for this subsystem, and that is
+ consistent with other documentation provided for the
+ TOE. Finally, the evaluator must analyse the design information
+ provided for the SFR-enforcing modules (at a detailed level) and
+ the SFR-supporting and SFR-non-interfering modules (at a less detailed level) to
+ understand how the system is implemented, and with that
+ knowledge ensure that the TSFI in the functional specification
+ are adequately described, and that the test information
+ adequately tests the TSF (done in the work units).
+
+ It is important to note that while the developer is obligated to
+ provide a complete description of the TSF (although
+ SFR-enforcing modules will have more detail than the
+ SFR-supporting or SFR-non-interfering modules), the evaluator is
+ expected to use their judgement in performing their
+ analysis. While the evaluator is expected to look at every
+ module, the detail to which they examine each module may
+ vary. The evaluator analyses each module in order to gain enough
+ understanding to determine the effect of the functionality of
+ the module on the security of the system, and the depth to which
+ they need to analyse the module may vary depending on the
+ module's role in the system. An important aspect of this
+ analysis is that the evaluator should use the other
+ documentation provided (TSS, functional specification, security
+ architecture description, and the TSF internal document) in
+ order to determine that the functionality that is described is
+ correct, and that the implicit designation of SFR-supporting or
+ SFR-non-interfering modules (see below) is supported by their
+ role in the system architecture.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a description of each subsystem of
+ the TSF.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing module in terms of
+ its purpose and relationship with other modules.
+
+
+ The design shall describe each SFR-enforcing module in terms of
+ its SFR-related interfaces, return values from those interfaces,
+ interaction with other modules and called
+ SFR-related interfaces to other SFR-enforcing modules.
+
+
+ The design shall describe each SFR-supporting or
+ SFR-non-interfering module in terms of its purpose and
+ interaction with other modules.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules). Depending upon the
+ complexity of the TOE, its design may be described in terms of
+ subsystems and modules, as described in CC Part 3 . For a very simple TOE that can be
+ described solely at the ``module'' level (see ), this work unit is not
+ applicable and therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ security architecture description) in making this
+ determination. For example, if the
+ functional specification contains interfaces to
+ functionality that does not appear to be described in
+ the TOE design description, it may be the case that a
+ portion of the TSF has not been included
+ appropriately. Making this determination will likely be
+ an iterative process, where as more analysis is done on
+ the other evidence, more confidence can be gained with
+ respect to the completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation in a level of detail that can serve
+ as a guide to reviewing the implementation representation. A description of a module should
+ be such that one could create an implementation of the module from the description, and the
+ resulting implementation would be 1) identical to the actual TSF implementation in terms of
+ the interfaces presented, 2) identical in the use of interfaces that are mentioned in the
+ design, and 3) functionally equivalent to the description of the purpose of the TSF module.
+ For instance, RFC 793 provides a high-level description of the TCP protocol. It is
+ necessarily implementation independent. While it provides a wealth of detail, it is
+ not
+ a suitable design description because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC, and implementation choices (for
+ instance, the use of global data vs. local data in various parts of the implementation) may
+ have an impact on the analysis that is performed. The design description of the TCP module would
+ list the interfaces presented by the implementation (rather than just those defined in RFC 793),
+ as well as an algorithm description of the processing associated with the modules implementing
+ TCP (assuming it was part of the TSF).
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-non-interfering subsystem of the TSF is described such that
+ the evaluator can determine that the subsystem is SFR-non-interfering.
+ If the design is presented solely in terms of modules, then this work unit
+ will be considered satisfied by the assessment done in subsequent work units;
+ no explicit action on the part of the evaluator is necessary in this case.
+ An SFR-non-interfering subsystem is one on which the SFR-enforcing and
+ SFR-supporting subsystems have no dependence; that is, they play no role
+ in implementing SFR functionality.
+ The evaluator ensures that all subsystems of the TSF have a description.
+ While the description should focus on the role that the subsystem do not plays
+ in enforcing or supporting the implementation of the SFRs, enough information
+ must be present so that a context for understanding the SFR-non-interfering
+ functionality is provided.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a subsystem-level
+ description of the TSF in addition to the modular description,
+ the goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs its functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem should
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the module-level documentation) that do not appear to
+ be described, the evaluator ensures that this information is
+ provided by the developer. However, if the evaluator can
+ determine that interactions among a particular set of
+ subsystems, while incompletely described by the developer, and a
+ complete description will not aid in understanding the overall
+ functionality nor security functionality provided by the TSF,
+ then the evaluator may choose to consider the description
+ sufficient, and not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing module and relationship with other modules is complete and accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the
+ modules have been categorised by the developer or
+ not, it is the
+ evaluator's responsibility to determine that the
+ modules have the appropriate information for their
+ role (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for component. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the TSF internals, or the security architecture
+ description. However, the evaluator uses the information present
+ in those documents to the extent possible to help ensure that
+ the purpose is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing module contain an accurate and complete
+ description of the SFR-related parameters, the
+ invocation conventions for each interface, and any
+ values returned directly by the interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are fixed)
+ need not be specified or described, since they are not a factor in testing.
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of SFR-related
+ parameters, and descriptions of these parameters. Note
+ that global data would also be considered parameters if
+ used by the module (either as inputs or outputs) when
+ invoked. If a parameter were expected to take on a set
+ of values (e.g., a ``flag'' parameter), the complete set
+ of values the parameter could take on that would have an
+ effect on module processing would be
+ specified. Likewise, parameters representing data
+ structures are described such that each field of the
+ data structure is identified and described. Note that
+ different programming languages may have additional
+ ``interfaces'' that would be non-obvious; an example
+ would be operator/function overloading in C++. This
+ ``implicit interface'' in the class description would
+ also be described as part of the low-level TOE
+ design. Note that although a module could present only
+ one interface, it is more common that a module presents
+ a small set of related interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TOE design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+
+
+
+
+ The evaluator shall examine the TOE design to determine that
+ SFR-supporting and SFR-non-interfering modules are correctly
+ categorised.
+
+ In the cases where the developer has provided different amounts
+ of information for different modules, an implicit categorisation
+ has been done. That is, modules (for instance) with detail
+ presented on their SFR-related interfaces (see ) are candidate SFR-enforcing
+ modules, although examination by the evaluator may lead to a
+ determination that some set of them are SFR-supporting or
+ SFR-non-interfering. Those with only a description of their
+ purpose and interaction with other modules (for instance) are
+ ``implicitly categorised'' as SFR-supporting or
+ SFR-non-interfering.
+
+ In these cases, a key focus of the evaluator for this work unit
+ is attempting to determine from the evidence provided for each
+ module implicitly categorised as SFR-supporting or
+ SFR-non-interfering and the evaluation information about other
+ modules (in the TOE design, the functional specification, the
+ security architecture description, and the operational user
+ guidance), whether the module is indeed SFR-supporting or
+ SFR-non-interfering. At this level of assurance some error
+ should be tolerated; the evaluator does not have to be
+ absolutely sure that a given module is SFR-supporting or
+ SFR-non-interfering, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ SFR-supporting or SFR-non-interfering module is SFR-enforcing,
+ the evaluator requests additional information from the developer
+ in order to resolve the apparent inconsistency. For instance,
+ suppose the documentation for Module A (an SFR-enforcing module)
+ indicates that it calls Module B to perform an access check on a
+ certain type of construct. When the evaluator examines the
+ information associated with Module B, they find that all the
+ developer has provided is a purpose and a set of interactions
+ (thus implicitly categorising Module B as SFR-supporting or
+ SFR-non-interfering). On examining the purpose and interactions
+ from Module A, the evaluator finds no mention of Module B
+ performing any access checks, and Module A is not listed as a
+ module with which Module B interacts. At this point the
+ evaluator should approach the developer to resolve the
+ discrepancies between the information provided in Module A and
+ that in Module B.
+
+ Another example would be where the evaluator examines the
+ mapping of the TSFI to the modules as provided by . This examination shows that
+ Module C is associated with an SFR requiring identification of
+ the user. Again, when the evaluator examines the information
+ associated with Module C, they find that all the developer has
+ provided is a purpose and a set of interactions (thus implicitly
+ categorising Module C as SFR-supporting or
+ SFR-non-interfering). Examining the purpose and interactions
+ presented for Module C, the evaluator is unable to determine why
+ Module C, listed as mapping to a TSFI concerned with user
+ identification, would not be classified as SFR-enforcing. Again,
+ the evaluator should approach the developer to resolve this
+ discrepancy.
+
+
+ A final example is from the opposite point of view. As
+ before, the developer has provided information associated
+ with Module D consisting of a purpose and a set of
+ interactions (thus implicitly categorising Module D as
+ SFR-supporting or SFR-non-interfering). The evaluator
+ examines all of the evidence provided, including the purpose
+ and interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the TOE,
+ the interactions are consistent with that description, and
+ there is nothing to indicate that Module D is
+ SFR-enforcing. In this case, the evaluator should not demand
+ more information about Module D ``just be to sure'' it is
+ correctly categorised. The developer has met their
+ obligations and the resulting assurance the evaluator has in
+ the implicit categorisation of Module D is (by definition)
+ appropriate for this assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that the
+ description of the purpose of each SFR-supporting or
+ SFR-non-interfering module is complete and accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ Because the modules are at such a low level, it may be difficult determine
+ completeness and accuracy impacts from other documentation,
+ such as administrative guidance, the functional specification,
+ the security architecture description, or the TSF internals document.
+ However, the evaluator uses the information present in those documents
+ to the extent possible to help ensure that the function is accurately
+ and completely described. This analysis can be aided by the analysis
+ performed for the work units for the ADV_TDS.3.10C element,
+ which maps the TSFI in the functional specification to the modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine that the
+ description of a SFR-supporting or SFR-non-interfering module's
+ interaction with other modules is complete and accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the function is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a description of
+ the implementation of the TSF. The TSFI provide a description of
+ how the implementation is exercised. The evidence from the
+ developer identifies the module that is initially invoked when
+ an operation is requested at the TSFI, and identifies the chain
+ of modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However, a
+ complete call tree for each TSFI is not required for this work
+ unit. The cases in which more than one module would have to be
+ identified are where there are ``entry point'' modules or
+ wrapper modules that have no functionality other than
+ conditioning inputs or de-multiplexing an input. Mapping to one
+ of these modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped to a module at the TSF boundary.
+ This determination can be made by reviewing the module description and its
+ interfaces/interactions. The next aspect of accuracy is that each TSFI identifies
+ a chain of modules between the initial module identified and a module
+ that is primarily responsible for implementing the function presented at the TSF.
+ Note that this may be the initial module, or there may be several modules,
+ depending on how much pre-conditioning of the inputs is done. It should be noted that
+ one indicator of a pre-conditioning module is that it is invoked for a large number
+ of the TSFI, where the TSFI are all of similar type (e.g., system call).
+ The final aspect of accuracy is that the mapping makes sense. For instance,
+ mapping a TSFI dealing with access control to a module that checks passwords
+ is not accurate. The evaluator should again use judgement in making this determination.
+ The goal is that this information aids the evaluator in understanding the system and
+ implementation of the SFRs, and ways in which entities at the TSF boundary can interact
+ with the TSF. The bulk of the assessment of whether the SFRs are described accurately
+ by the modules is performed in other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems, and later to modules. Note that this map may have to be
+ at a level of detail below the component or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to modules x, y, and z of subsystem A;
+ (rule 2) to modules x, p, and q of subsystem A; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems, and modules that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and modules, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems, and modules implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems and modules have been identified, or if
+ adequate detail had been provided for those subsystems and modules.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of the SFR-enforcing and
+ SFR-supporting modules and enough information about the
+ SFR-non-interfering modules for the evaluator to determine
+ that the SFRs are completely and accurately implemented;
+ as such, the TOE design provides an explanation of the
+ implementation representation.
+
+
+
+ There are three types of activity that the evaluator must
+ undertake with respect to the TOE design. First, the evaluator
+ determines that the TSF boundary has been adequately
+ described. Second, the evaluator determines that the developer
+ has provided documentation that conforms to the content and
+ presentation requirements this subsystem, and that is consistent
+ with other documentation provided for the TOE. Finally, the
+ evaluator must analyse the design information provided for the
+ SFR-enforcing modules (at a detailed level) and the
+ SFR-supporting and SFR-non-interfering modules (at a less detailed level) to
+ understand how the system is implemented, and with that
+ knowledge ensure that the TSFI in the functional specification
+ are adequately described, and that the test information
+ adequately tests the TSF (done in the work units).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each subsystem of
+ the TSF, supported by informal, explanatory text where appropriate.
+
+
+ The design shall provide a description of the interactions
+ among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each SFR-enforcing and SFR-supporting
+ module in terms of its purpose and relationship with other
+ modules.
+
+
+ The design shall describe each SFR-enforcing and SFR-supporting module
+ in terms of its SFR-related interfaces, return values from those interfaces,
+ interaction with other modules and called SFR-related
+ interfaces to other SFR-enforcing or SFR-supporting modules.
+
+
+ The design shall describe each SFR-non-interfering module in
+ terms of its purpose and interaction with other modules.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the structure of the entire TOE is described in
+ terms of subsystems.
+
+ The evaluator ensures that all of the subsystems of the
+ TOE are identified. This description of the TOE will be
+ used as input to work unit , where the parts of the TOE that make up
+ the TSF are identified. That is, this requirement is on
+ the entire TOE rather than on only the TSF.
+
+ The TOE (and TSF) may be described in multiple layers of
+ abstraction (i.e. subsystems and modules) Depending upon
+ the complexity of the TOE, its design may be described
+ in terms of subsystems and modules, as described in CC
+ Part 3 . For a very
+ simple TOE that can be described solely at the
+ ``module'' level (see ), this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ In performing this activity, the evaluator examines
+ other evidence presented for the TOE (e.g., ST, operator
+ user guidance) to determine that the description of the
+ TOE in such evidence is consistent with the description
+ contained in the TOE design.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the entire TSF is described in terms of
+ modules.
+
+ The evaluator will examine the modules for specific
+ properties in other work units; in this work unit the
+ evaluator determines that the modular description covers
+ the entire TSF, and not just a portion of the TSF. The
+ evaluator uses other evidence provided for the
+ evaluation (e.g., functional specification,
+ architectural description) in making this
+ determination. For example, if the functional
+ specification contains interfaces to functionality that
+ does not appear to be described in the TOE design
+ description, it may be the case that a portion of the
+ TSF has not been included appropriately. Making this
+ determination will likely be an iterative process, where
+ as more analysis is done on the other evidence, more
+ confidence can be gained with respect to the
+ completeness of the documentation.
+
+ Unlike subsystems, modules describe the implementation in a level of detail that can serve
+ as a guide to reviewing the implementation representation. A description of a module should
+ be such that one could create an implementation of the module from the description, and the
+ resulting implementation would be 1) identical to the actual TSF implementation in terms of
+ the interfaces presented, 2) identical in the use of interfaces that are mentioned in the
+ design, and 3) functionally equivalent to the description of the purpose of the TSF module.
+ For instance, RFC 793 provides a high-level description of the TCP protocol. It is
+ necessarily implementation independent. While it provides a wealth of detail, it is
+ not
+ a suitable design description because it is not specific to an implementation. An actual
+ implementation can add to the protocol specified in the RFC, and implementation choices (for
+ instance, the use of global data vs. local data in various parts of the implementation) may
+ have an impact on the analysis that is performed. The design description of the TCP module would
+ list the interfaces presented by the implementation (rather than just those defined in RFC 793),
+ as well as an algorithm description of the processing associated with the modules implementing
+ TCP (assuming it was part of the TSF).
+
+
+
+
+ The evaluator shall check the TOE design to determine
+ that the TSF modules are identified as either
+ SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The purpose of designating each module (according to the role a
+ particular module plays in the enforcement of the SFRs) is to
+ allow developers to provide less information about the parts of
+ the TSF that have little role in security. It is always
+ permissible for the developer to provide more information or
+ detail than the requirements demand, as might occur when the
+ information has been gathered outside the evaluation context. In
+ such cases the developer must still designate the modules as
+ either SFR-enforcing, SFR-supporting, or
+ SFR-non-interfering.
+
+ The accuracy of these designations is continuously
+ reviewed as the evaluation progresses. The concern is
+ the mis-designation of modules as being less important
+ (and hence, having less information) than is really the
+ case. While blatant mis-designations may be immediately
+ apparent (e.g., designating an authentication module as
+ anything but SFR-enforcing when is one of the SFRs being claimed), other
+ mis-designations might not be discovered until the TSF
+ is better understood. The evaluator must therefore keep
+ in mind that these designations are the developer's
+ initial best effort, but are subject to change. Further
+ guidance is provided under work unit , which examines the
+ accuracy of these designations.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that all subsystems of the TSF are identified.
+
+ If the design is presented solely in terms of modules,
+ then subsystems in these requirements are equivalent to
+ modules and the activity should be performed at the
+ module level.
+
+ In work unit all of
+ the subsystems of the TOE were identified, and a
+ determination made that the non-TSF subsystems were
+ correctly characterised. Building on that work, the
+ subsystems that were not characterised as non-TSF
+ subsystems should be precisely identified. The evaluator
+ determines that, of the hardware and software installed
+ and configured according to the guidance, each subsystem has been
+ accounted for as either one that is part of the TSF, or
+ one that is not.
+ The evaluator shall examine the TDS documentation to determine
+ that the semiformal notation used for describing the subsystems, modules and
+ their interfaces is defined or referenced.A semiformal notation can be either defined by the sponsor or
+ a corresponding standard be referenced. The evaluator should provide a mapping
+ of security functions and their interfaces outlining in what part of the
+ documentation a function or interface is semiformal described and what notation
+ is used. The evaluator examines all semiformal notations used to make sure that
+ they are of a semiformal style and to justify the appropriateness of the manner
+ how the semiformal notations are used for the TOE.The evaluator is reminded that a semi-formal presentation is
+ characterised by a standardised format with a well-defined syntax that reduces
+ ambiguity that may occur in informal presentations. The syntax of all semiformal
+ notations used in the functional specification shall be defined or a corresponding
+ standard be referenced. The evaluator verifies that the semiformal notations used
+ for expressing the functional specification are capable of expressing features
+ relevant to security. In order to determine this, the evaluator can refer to the
+ SFR and compare the TSF security features stated in the ST and those described
+ in the FSP using the semiformal notations.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that each subsystem of the TSF describes its role in
+ the enforcement of SFRs described in the ST.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the goal of the subsystem-level
+ description is to give the evaluator context for the
+ modular description that follows. Therefore, the
+ evaluator ensures that the subsystem-level description
+ contains a description of how the security functional
+ requirements are achieved in the design, but at a level
+ of abstraction above the modular description. This
+ description should discuss the mechanisms used at a
+ level that is aligned with the module description; this
+ will provide the evaluators the road map needed to
+ intelligently assess the information contained in the
+ module description. A well-written set of subsystem
+ descriptions will help guide the evaluator in
+ determining the modules that are most important to
+ examine, thus focusing the evaluation activity on the
+ portions of the TSF that have the most relevance with
+ respect to the enforcement of the SFRs.
+
+ The evaluator ensures that all subsystems of the TSF
+ have a description. While the description should focus
+ on the role that the subsystem plays in enforcing or
+ supporting the implementation of the SFRs, enough
+ information must be present so that a context for
+ understanding the SFR-related functionality is
+ provided.
+
+ The evaluator shall examine the TOE design to determine that
+ each SFR-non-interfering subsystem of the TSF is described such that
+ the evaluator can determine that the subsystem is SFR-non-interfering.
+ If the design is presented solely in terms of modules, then this work unit
+ will be considered satisfied by the assessment done in subsequent work units;
+ no explicit action on the part of the evaluator is necessary in this case.
+ An SFR-non-interfering subsystem is one on which the SFR-enforcing and
+ SFR-supporting subsystems have no dependence; that is, they play no role
+ in implementing SFR functionality.
+ The evaluator ensures that all subsystems of the TSF have a description.
+ While the description should focus on the role that the subsystem do not plays
+ in enforcing or supporting the implementation of the SFRs, enough information
+ must be present so that a context for understanding the SFR-non-interfering
+ functionality is provided.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that interactions between the subsystems of the TSF are
+ described.
+
+ If the design is presented solely in terms of modules,
+ then this work unit will be considered satisfied by the
+ assessment done in subsequent work units; no explicit
+ action on the part of the evaluator is necessary in this
+ case.
+
+ On systems that are complex enough to warrant a subsystem-level
+ description of the TSF in addition to the modular description,
+ the goal of describing the interactions between the subsystems
+ is to help provide the reader a better understanding of how the
+ TSF performs it functions. These interactions do not need to be
+ characterised at the implementation level (e.g., parameters
+ passed from one routine in a subsystem to a routine in a
+ different subsystem; global variables; hardware signals (e.g.,
+ interrupts) from a hardware subsystem to an interrupt-handling
+ subsystem), but the data elements identified for a particular
+ subsystem that are going to be used by another subsystem need to
+ be covered in this discussion. Any control relationships
+ between subsystems (e.g., a subsystem responsible for
+ configuring a rule base for a firewall system and the subsystem
+ that actually implements these rules) should also be
+ described.
+
+ It should be noted while the developer should characterise all
+ interactions between subsystems, the evaluators need to use
+ their own judgement in assessing the completeness of the
+ description. If the reason for an interaction is unclear, or if
+ there are SFR-related interactions (discovered, for instance, in
+ examining the module-level documentation) that do not appear to
+ be described, the evaluator ensures that this information is
+ provided by the developer. However, if the evaluator can
+ determine that interactions among a particular set of
+ subsystems, while incompletely described by the developer, and a
+ complete description will not aid in understanding the overall
+ functionality nor security functionality provided by the TSF,
+ then the evaluator may choose to consider the description
+ sufficient, and not pursue completeness for its own sake.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF and
+ the modules of the TSF is complete.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. To
+ determine completeness, the evaluator examines each
+ mapping and determines that all subsystems map to at
+ least one module, and that all modules map to exactly
+ one subsystem.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the mapping between the subsystems of the TSF to
+ the modules of the TSF is accurate.
+
+ If the design is presented solely in terms of modules,
+ then this work unit is considered satisfied.
+
+ For TOEs that are complex enough to warrant a
+ subsystem-level description of the TSF in addition to
+ the modular description, the developer provides a simple
+ mapping showing how the modules of the TSF are allocated
+ to the subsystems. This will provide the evaluator a
+ guide in performing their module-level assessment. The
+ evaluator may choose to check the accuracy of the
+ mapping in conjunction with performing other work
+ units. An ``inaccurate'' mapping is one where the module
+ is mistakenly associated with a subsystem where its
+ functions are not used within the subsystem. Because the
+ mapping is intended to be a guide supporting more
+ detailed analysis, the evaluator is cautioned to apply
+ appropriate effort to this work unit. Expending
+ extensive evaluator resources verifying the accuracy of
+ the mapping is not necessary. Inaccuracies that lead to
+ mis-understandings related to the design that are
+ uncovered as part of this or other work units are the
+ ones that should be associated with this work unit and
+ corrected.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-enforcing and SFR-supporting module, and relationship with other modules
+ is complete and accurate.
+
+ The developer may designate modules as SFR-enforcing,
+ SFR-supporting, and SFR non-interfering, but these
+ ``tags'' are used only to describe the amount and type
+ of information the developer must provide, and can be
+ used to limit the amount of information the developer
+ has to develop if their engineering process does not
+ produce the documentation required. Whether the modules
+ have been categorised by the developer or not, it is the
+ evaluator's responsibility to determine that the modules
+ have the appropriate information for their role
+ (SFR-enforcing, etc.) in the TOE, and to obtain the
+ appropriate information from the developer should the
+ developer fail to provide the required information for a
+ particular module.
+
+ The purpose of a module provides a description
+ indicating what function the module is fulfilling. A
+ word of caution to evaluator is in order. The focus of
+ this work unit should be to provide the evaluator an
+ understanding of how the module works so that
+ determinations can be made about the soundness of the
+ implementation of the SFRs, as well as to support
+ architectural analysis performed for subsystems. As long as the evaluator has a
+ sound understanding of the module's operation, and its
+ relationship to other modules and the TOE as a whole,
+ the evaluator should consider the objective of the work
+ achieved and not engage in a documentation exercise for
+ the developer (by requiring, for example, a complete
+ algorithmic description for a self-evident
+ implementation representation).
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the TSF internals, or the security architecture
+ description. However, the evaluator uses the information present
+ in those documents to the extent possible to help ensure that
+ the purpose is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the interfaces presented by each
+ SFR-enforcing and SFR-supporting module contain an
+ accurate and complete description of the SFR-related
+ parameters, the invocation conventions for each
+ interface, and any values returned directly by the
+ interface.
+
+ The SFR-related interfaces of a module are those
+ interfaces used by other modules as a means to invoke
+ the SFR-related operations provided, and to provide
+ inputs to or receive outputs from the module. The
+ purpose in the specification of these interfaces is to
+ permit the exercise of them during testing.
+ Inter-module interfaces that are not SFR-related need
+ not be specified or described, since they are not a
+ factor in testing. Likewise, other internal interfaces
+ that are not a factor in traversing SFR-related paths of
+ execution (such as those internal paths that are
+ fixed).
+ SFR-related interfaces of SFR-supporting modules are all
+ interfaces of SFR-supporting modules that are called directly
+ or indirectly from SFR-enforcing modules. Those interfaces
+ need to be described with all the parameter used in such a
+ call. This allows the evaluator to understand the purpose of
+ the call to the SFR-supporting module in the context of
+ operation of the SFR-enforcing modules.
+
+ SFR-related interfaces are described in terms of how
+ they are invoked, and any values that are returned. This
+ description would include a list of parameters, and
+ descriptions of these parameters. Note that global data
+ would also be considered parameters if used by the
+ module (either as inputs or outputs) when invoked. If a
+ parameter were expected to take on a set of values
+ (e.g., a ``flag'' parameter), the complete set of values
+ the parameter could take on that would have an effect on
+ module processing would be specified. Likewise,
+ parameters representing data structures are described
+ such that each field of the data structure is identified
+ and described. Note that different programming languages
+ may have additional ``interfaces'' that would be
+ non-obvious; an example would be operator/function
+ overloading in C++. This ``implicit interface'' in the
+ class description would also be described as part of the
+ low-level TOE design. Note that although a module could
+ present only one interface, it is more common that a
+ module presents a small set of related
+ interfaces.
+
+ In terms of the assessment of parameters (inputs and
+ outputs) to a module, any use of global data must also
+ be considered. A module ``uses'' global data if it
+ either reads or writes the data. In order to assure the
+ description of such parameters (if used) is complete,
+ the evaluator uses other information provided about the
+ module in the TOE design (interfaces, algorithmic
+ description, etc.), as well as the description of the
+ particular set of global data assessed in work unit
+ . For instance, the
+ evaluator could first determine the processing the
+ module performs by examining its function and interfaces
+ presented (particularly the parameters of the
+ interfaces). They could then check to see if the
+ processing appears to ``touch'' any of the global data
+ areas identified in the TDS design. The evaluator then
+ determines that, for each global data area that appears
+ to be ``touched'', that global data area is listed as a
+ means of input or output by the module the evaluator is
+ examining.
+
+ Invocation conventions are a programming-reference-type
+ description that one could use to correctly invoke a
+ module's interface if one were writing a program to make
+ use of the module's functionality through that
+ interface. This includes necessary inputs and outputs,
+ including any set-up that may need to be performed with
+ respect to global variables.
+
+ Values returned through the interface refer to values
+ that are either passed through parameters or messages;
+ values that the function call itself returns in the
+ style of a ``C'' program function call; or values passed
+ through global means (such as certain error routines in
+ *ix-style operating systems).
+
+ In order to assure the description is complete, the
+ evaluator uses other information provided about the
+ module in the TOE design (e.g., algorithmic description,
+ global data used) to ensure that it appears all data
+ necessary for performing the functions of the module is
+ presented to the module, and that any values that other
+ modules expect the module under examination to provide
+ are identified as being returned by the module. The
+ evaluator determines accuracy by ensuring that the
+ description of the processing matches the information
+ listed as being passed to or from an interface.
+
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that SFR-non-interfering modules are correctly
+ categorised.
+
+ As mentioned in work unit ,
+ less information is required about modules that are
+ SFR-non-interfering. A key focus of the evaluator for this work
+ unit is attempting to determine from the evidence provided for
+ each module implicitly categorised as SFR-non-interfering and
+ the evaluation (information about other modules in the TOE
+ design, the functional specification, the security architecture
+ description, the operational user guidance, the TSF internals
+ document, and perhaps even the implementation representation)
+ whether the module is indeed SFR-non-interfering. At this level
+ of assurance some error should be tolerated; the evaluator does
+ not have to be absolutely sure that a given module is
+ SFR-non-interfering, even though it is labelled as
+ such. However, if the evidence provided indicates that a
+ SFR-non-interfering module is SFR-enforcing or SFR-supporting,
+ the evaluator requests additional information from the developer
+ in order to resolve the apparent inconsistency. For example,
+ suppose the documentation for Module A (an SFR-enforcing module)
+ indicates that it calls Module B to perform an access check on a
+ certain type of construct. When the evaluator examines the
+ information associated with Module B, it is discovered that the
+ only information the developer has provided is a purpose and a
+ set of interactions (thus implicitly categorising Module B as
+ SFR-supporting or SFR-non-interfering). On examining the purpose and interactions
+ from Module A, the evaluator finds no mention of Module B
+ performing any access checks, and Module A is not listed as a
+ module with which Module B interacts. At this point the
+ evaluator should approach the developer to resolve the
+ discrepancies between the information provided in Module A and
+ that in Module B.
+
+ Another example would be where the evaluator examines
+ the mapping of the TSFI to the modules as provided by
+ . This examination
+ shows that Module C is associated with an SFR requiring
+ identification of the user. Again, when the evaluator
+ examines the information associated with Module C, they
+ find that all the developer has provided is a purpose
+ and a set of interactions (thus implicitly categorising
+ Module C as SFR-non-interfering). Examining the purpose
+ and interactions presented for Module C, the evaluator
+ is unable to determine why Module C, listed as mapping
+ to a TSFI concerned with user identification, would not
+ be classified as SFR-enforcing or SFR-supporting. Again,
+ the evaluator should approach the developer to resolve
+ this discrepancy.
+
+ A final example illustrates the opposite situation. As
+ before, the developer has provided information
+ associated with Module D consisting of a purpose and a
+ set of interactions (thus implicitly categorising Module
+ D as SFR-non-interfering). The evaluator examines all of
+ the evidence provided, including the purpose and
+ interactions for Module D. The purpose appears to give a
+ meaningful description of Module D's function in the
+ TOE, the interactions are consistent with that
+ description, and there is nothing to indicate that
+ Module D is SFR-enforcing or SFR-supporting. In this
+ case, the evaluator should not demand more information
+ about Module D ``just be to sure'' it is correctly
+ categorised. The developer has met the obligations and
+ the resulting assurance the evaluator has in the
+ implicit categorisation of Module D is (by definition)
+ appropriate for this assurance level.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of the purpose of each
+ SFR-non-interfering module is complete and
+ accurate.
+
+ The description of the purpose of a module indicates
+ what function the module is fulfilling. From the
+ description, the evaluator should be able to obtain a
+ general idea of the module's role. In order to assure
+ the description is complete, the evaluator uses the
+ information provided about the module's interactions
+ with other modules to assess whether the reasons for the
+ module being called are consistent with the module's
+ purpose. If the interaction description contains
+ functionality that is not apparent from, or in conflict
+ with, the module's purpose, the evaluator needs to
+ determine whether the problem is one of accuracy or of
+ completeness. The evaluator should be wary of purposes
+ that are too short, since meaningful analysis based on a
+ one-sentence purpose is likely to be impossible.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the function is accurately and completely described. This
+ analysis can be aided by the analysis performed for the work
+ units for the element,
+ which maps the TSFI in the functional specification to the
+ modules of the TSF.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that the description of a SFR-non-interfering module's
+ interaction with other modules is complete and
+ accurate.
+
+ It is important to note that, in terms of the Part 3
+ requirement and this work unit, the term
+ interaction is intended to convey less
+ rigour than interface. An interaction
+ does not need to be characterised at the implementation
+ level (e.g., parameters passed from one routine in a
+ module to a routine in a different module; global
+ variables; hardware signals (e.g., interrupts) from a
+ hardware subsystem to an interrupt-handling subsystem),
+ but the data elements identified for a particular module
+ that are going to be used by another module should be
+ covered in this discussion. Any control relationships
+ between modules (e.g., a module responsible for
+ configuring a rule base for a firewall system and the
+ module that actually implements these rules) should also
+ be described.
+
+ A module's interaction with other modules can be captured in
+ many ways. The intent for the TOE design is to allow the
+ evaluator to understand (in part through analysis of module
+ interactions) the role of the SFR-supporting and
+ SFR-non-interfering modules in the overall TOE
+ design. Understanding of this role will aid the evaluator in
+ performing work unit .
+
+ A module's interaction with other modules goes beyond
+ just a call-tree-type document. The interaction is
+ described from a functional perspective of why a module
+ interacts with other modules. The module's purpose
+ describes what functions the module provides to other
+ modules; the interactions should describe what the
+ module depends on from other modules in order to
+ accomplish this function.
+
+ Because the modules are at such a low level, it may be difficult
+ determine completeness and accuracy impacts from other
+ documentation, such as operational user guidance, the functional
+ specification, the security architecture description, or the TSF
+ internals document. However, the evaluator uses the information
+ present in those documents to the extent possible to help ensure
+ that the interactions are accurately and completely
+ described.
+
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it contains a complete and accurate mapping from
+ the TSFI described in the functional specification to
+ the modules of the TSF described in the TOE
+ design.
+
+ The modules described in the TOE design provide a
+ description of the implementation of the TSF. The TSFI
+ provide a description of how the implementation is
+ exercised. The evidence from the developer identifies
+ the module that is initially invoked when an operation
+ is requested at the TSFI, and identify the chain of
+ modules invoked up to the module that is primarily
+ responsible for implementing the functionality. However,
+ a complete call tree for each TSFI is not required for
+ this work unit. The cases in which more than one module
+ would have to be identified are where there are ``entry
+ point'' modules or wrapper modules that have no
+ functionality other than conditioning inputs or
+ de-multiplexing an input. Mapping to one of these
+ modules would not provide any useful information to the
+ evaluator.
+
+ The evaluator assesses the completeness of the mapping
+ by ensuring that all of the TSFI map to at least one
+ module. The verification of accuracy is more
+ complex.
+
+ The first aspect of accuracy is that each TSFI is mapped
+ to a module at the TSF boundary. This determination can
+ be made by reviewing the module description and its
+ interfaces/interactions. The next aspect of accuracy is
+ that each TSFI identifies a chain of modules between the
+ initial module identified and a module that is primarily
+ responsible for implementing the function presented at
+ the TSF. Note that this may be the initial module, or
+ there may be several modules, depending on how much
+ pre-conditioning of the inputs is done. It should be
+ noted that one indicator of a pre-conditioning module is
+ that it is invoked for a large number of the TSFI, where
+ the TSFI are all of similar type (e.g., system
+ call). The final aspect of accuracy is that the mapping
+ makes sense. For instance, mapping a TSFI dealing with
+ access control to a module that checks passwords is not
+ accurate. The evaluator should again use judgement in
+ making this determination. The goal is that this
+ information aids the evaluator in understanding the
+ system and implementation of the SFRs, and ways in which
+ entities at the TSF boundary can interact with the
+ TSF. The bulk of the assessment of whether the SFRs are
+ described accurately by the modules is performed in
+ other work units.
+
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+ The evaluator shall examine the TOE security functional
+ requirements and the TOE design, to determine that all
+ ST security functional requirements are covered by the
+ TOE design.
+
+ The evaluator may construct a map between the TOE
+ security functional requirements and the TOE design.
+ This map will likely be from a functional requirement to
+ a set of subsystems, and later to modules. Note that this map may have to be
+ at a level of detail below the component or even element
+ level of the requirements, because of operations
+ (assignments, refinements, selections) performed on the
+ functional requirement by the ST author.
+
+ For example, the
+ component contains an element with assignments. If the
+ ST contained, for instance, ten rules in the assignment, and these ten
+ rules were implemented in specific places within fifteen
+ modules, it would be inadequate for the evaluator to map
+ to one subsystem and
+ claim the work unit had been completed. Instead, the
+ evaluator would map
+ (rule 1) to modules x, y and z of subsystem A;
+ (rule 2) to x, p, and q of subsystem A; etc.
+
+
+
+ The evaluator shall examine the TOE design to determine
+ that it is an accurate instantiation of all security
+ functional requirements.
+
+ The evaluator may construct a map between the TOE security
+ functional requirements and the TOE design. This map will
+ likely be from a functional requirement to a set of
+ subsystems. Note that this map may have to be at a level of
+ detail below the component or even element level of the
+ requirements, because of operations (assignments, refinements,
+ selections) performed on the functional requirement by the ST
+ author.
+
+ As an example, if the ST requirements specified a
+ role-based access control mechanism, the evaluator would
+ first identify the subsystems, and modules that contribute to this
+ mechanism's implementation. This could be done by
+ in-depth knowledge or understanding of the TOE design or
+ by work done in the previous work unit. Note that this
+ trace is only to identify the subsystems, and modules, and is not the
+ complete analysis.
+
+ The next step would be to understand what mechanism the
+ subsystems, and modules implemented. For instance, if the design
+ described an implementation of access control based on
+ UNIX-style protection bits, the design would not be an
+ accurate instantiation of those access control
+ requirements present in the ST example used above. If
+ the evaluator could not determine that the mechanism was
+ accurately implemented because of a lack of detail, the
+ evaluator would have to assess whether all of the
+ SFR-enforcing subsystems and modules have been identified, or if
+ adequate detail had been provided for those subsystems and modules.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE design provides a description of the TOE in terms
+ of subsystems sufficient to determine the TSF boundary,
+ and provides a description of the TSF internals in terms
+ of modules (and optionally higher-level abstractions). It
+ provides a detailed description of all modules for the
+ evaluator to determine that the SFRs are completely and
+ accurately implemented; as such, the TOE design provides
+ an explanation of the implementation
+ representation.
+
+
+
+ At this level, there is no differentiation of required
+ information according to SFR-relevance.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each
+ subsystem of the TSF, supported by informal, explanatory text where
+ appropriate.
+
+
+ The design shall provide a description of the interactions among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall provide a semiformal description of each module
+ in terms of its purpose, interaction, interfaces, return values
+ from those interfaces, and called interfaces to other modules,
+ supported by informal, explanatory text where appropriate.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ security architecture description;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the implementation representation.
+
+
+
+
+ The developer shall provide the design of the TOE.
+
+
+ The developer shall provide a mapping from the TSFI of the
+ functional specification to the lowest level of
+ decomposition available in the TOE design.
+
+
+ The developer shall provide a formal specification of the
+ TSF subsystems.
+
+
+ The developer shall provide a proof of correspondence
+ between the formal specifications of the TSF subsystems and
+ of the functional specification.
+
+
+ The design shall describe the structure of the TOE in terms
+ of subsystems.
+
+
+ The design shall describe the TSF in terms of modules,
+ designating each module as SFR-enforcing,
+ SFR-supporting, or SFR-non-interfering.
+
+
+ The design shall identify all subsystems of the TSF.
+
+
+ The design shall provide a semiformal description of each
+ subsystem of the TSF, supported by informal, explanatory text where
+ appropriate.
+
+
+ The design shall provide a description of the interactions among all subsystems of the TSF.
+
+
+ The design shall provide a mapping from the subsystems of
+ the TSF to the modules of the TSF.
+
+
+ The design shall describe each module in semiformal style in terms
+ of its purpose, interaction, interfaces, return values from those interfaces,
+ and called interfaces to other modules, supported by informal, explanatory
+ text where appropriate.
+
+
+ The formal specification of the TSF subsystems shall
+ describe the TSF using a formal style, supported by
+ informal, explanatory text where appropriate.
+
+
+ The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
+
+
+ The proof of correspondence between the formal
+ specifications of the TSF subsystems and of the functional
+ specification shall demonstrate that all behaviour described
+ in the TOE design is a correct and complete refinement of
+ the TSFI that invoked it.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+ The evaluator shall determine that the design is an accurate
+ and complete instantiation of all security functional
+ requirements.
+
+
+
+
+
+
+ The guidance documents class provides the requirements for
+ guidance documentation for all user roles. For the secure
+ preparation and operation of the TOE it is necessary to
+ describe all relevant aspects for the secure handling of the
+ TOE. The class also addresses the possibility of unintended
+ incorrect configuration or handling of the TOE.
+
+ In many cases it may be appropriate that guidance is provided
+ in separate documents for preparation and operation of the
+ TOE, or even separate for different user roles as end-users,
+ administrators, application programmers using software or
+ hardware interfaces, etc.
+
+ The guidance documents class is subdivided into two families
+ which are concerned with the preparative user guidance (what
+ has to be done to transform the delivered TOE into its
+ evaluated configuration in the operational environment as
+ described in the ST) and with the operational user guidance
+ (what has to be done during the operation of the TOE in its
+ evaluated configuration).
+
+
+
+ Assurance class defines
+ requirements directed at the understandability, coverage and
+ completeness of the preparative and operational documentation
+ provided by the developer. This documentation, which provides
+ information for all user roles, is an important factor in the
+ secure preparation and operation of the TOE.
+
+
+
+ The purpose of the guidance document activity is to judge the
+ adequacy of the documentation describing how the user can
+ handle the TOE in a secure manner. Such documentation should
+ take into account the various types of users (e.g. those who
+ accept, install, administrate or operate the TOE) whose
+ incorrect actions could adversely affect the security of the
+ TOE or of their own data.
+
+ The guidance documents class is subdivided into two families
+ which are concerned firstly with the preparative procedures
+ (all that has to be done to transform the delivered TOE into
+ its evaluated configuration in the environment as described in
+ the ST, i.e. accepting and installing the TOE) and secondly
+ with the operational user guidance (all that has to be done
+ during the operation of the TOE in its evaluated
+ configuration, i.e. operation and administration).
+
+
+
+ The guidance documents activity applies to those functions and
+ interfaces which are related to the security of the TOE. The
+ secure configuration of the TOE is described in the ST.
+
+
+
+
+ Operational user guidance refers to written material that is
+ intended to be used by all types of users of the TOE in its
+ evaluated configuration: end-users, persons responsible for
+ maintaining and administering the TOE in a correct manner
+ for maximum security, and by others (e.g. programmers) using
+ the TOE's external interfaces. Operational user guidance
+ describes the security functionality provided by the TSF,
+ provides instructions and guidelines (including warnings),
+ helps to understand the TSF and includes the
+ security-critical information, and the security-critical
+ actions required, for its secure use. Misleading and
+ unreasonable guidance should be absent from the guidance
+ documentation, and secure procedures for all modes of
+ operation should be addressed. Insecure states should be
+ easy to detect.
+
+ The operational user guidance provides a measure of
+ confidence that non-malicious users, administrators,
+ application providers and others exercising the external
+ interfaces of the TOE will understand the secure operation
+ of the TOE and will use it as intended. The evaluation of
+ the user guidance includes investigating whether the TOE can
+ be used in a manner that is insecure but that the user of
+ the TOE would reasonably believe to be secure. The objective
+ is to minimise the risk of human or other errors in
+ operation that may deactivate, disable, or fail to activate
+ security functionality, resulting in an undetected insecure
+ state.
+
+
+
+ Requirements for operational user guidance help ensure that
+ all types of users are able to operate the TOE in a secure
+ manner (e.g. the usage constraints assumed by the PP or ST
+ must be clearly explained and illustrated). It should be
+ excluded that the TOE can be used in a manner that is
+ insecure but that the user of the TOE would reasonably
+ believe to be secure. Operational user guidance is the
+ primary vehicle available to the developer for providing the
+ TOE users with the necessary background and specific
+ information on how to correctly use the TOE's protection
+ functions.
+
+ Operational user guidance must do two things. First, it
+ needs to explain what the security functionality accessible
+ by the user does and how it is to be used, so that users are
+ able to consistently and effectively protect their
+ information. Second, it needs to explain the user's role in
+ maintaining the TOE's security.
+
+
+
+ This family contains only one component.
+
+
+
+ There may be different user roles or groups that are
+ recognised by the TOE and that can interact with the
+ TSF. These user roles and groups should be taken into
+ consideration by the operational user guidance. They may be
+ roughly grouped into administrators and non-administrative
+ users, or more specifically grouped into persons responsible
+ for receiving, accepting, installing and maintaining the
+ TOE, application programmers, revisors, auditors,
+ daily-management, end-users. Each role can encompass an
+ extensive set of capabilities, or can be a single
+ one.
+
+ The requirement
+ encompasses the aspect that any warnings to the users during
+ operation of a TOE with regard to the security problem
+ definition and the security objectives for the operational
+ environment described in the PP/ST are appropriately covered
+ in the user guidance.
+
+ The concept of secure values, as employed in , has relevance where a user
+ has control over security parameters. Guidance needs to be
+ provided on secure and insecure settings for such
+ parameters.
+
+ requires that the
+ user guidance describes the appropriate reactions to all
+ security-relevant events. Although many security-relevant
+ events are the result of performing functions, this need not
+ always be the case (e.g. the audit log fills up, an
+ intrusion is detected). Furthermore, a security-relevant
+ event may happen as a result of a specific chain of
+ functions or, conversely, several security-relevant events
+ may be triggered by one function.
+
+ requires that the
+ user guidance is clear and reasonable. Misleading or
+ unreasonable guidance may result in a user of the TOE
+ believing that the TOE is secure when it is not.
+
+ An example of misleading guidance would be the description
+ of a single guidance instruction that could be parsed in
+ more than one way, one of which may result in an insecure
+ state.
+
+ An example of unreasonable guidance would be a
+ recommendation to follow a procedure that is so complicated
+ that it cannot reasonably be expected that users will follow
+ this guidance.
+
+
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the user guidance describes for each user role the
+ security functionality and interfaces provided by the TSF,
+ provides instructions and guidelines for the secure use of
+ the TOE, addresses secure procedures for all modes of
+ operation, facilitates prevention and detection of
+ insecure TOE states, or whether it is misleading or
+ unreasonable.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design, if applicable;
+
+
+ the user guidance;
+
+
+
+
+ The developer shall provide operational user guidance.
+
+
+ The operational user guidance shall describe, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+
+ The operational user guidance shall describe, for each user
+ role, how to use the available interfaces provided by the
+ TOE in a secure manner.
+
+
+ The operational user guidance shall describe, for each user
+ role, the available functions and interfaces, in particular
+ all security parameters under the control of the user,
+ indicating secure values as appropriate.
+
+
+ The operational user guidance shall, for each user role,
+ clearly present each type of security-relevant event
+ relative to the user-accessible functions that need to be
+ performed, including changing the security characteristics
+ of entities under the control of the TSF.
+
+
+ The operational user guidance shall identify all possible
+ modes of operation of the TOE (including operation following
+ failure or operational error), their consequences and
+ implications for maintaining secure operation.
+
+
+ The operational user guidance shall, for each user role,
+ describe the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+
+ The operational user guidance shall be clear and reasonable.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the user-accessible functions and privileges that
+ should be controlled in a secure processing environment,
+ including appropriate warnings.
+
+ The configuration of the TOE may allow different user
+ roles to have dissimilar privileges in making use of the
+ different functions of the TOE. This means that some
+ users are authorised to perform certain functions, while
+ other users may not be so authorised. These functions
+ and privileges should be described, for each user role,
+ by the user guidance.
+
+ The user guidance identifies, for each user role, the
+ functions and privileges that must be controlled, the
+ types of commands required for them, and the reasons for
+ such commands. The user guidance should contain warnings
+ regarding the use of these functions and
+ privileges. Warnings should address expected effects,
+ possible side effects, and possible interactions with
+ other functions and privileges.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the secure use of the available interfaces
+ provided by the TOE.
+
+ The user guidance should provide advice regarding
+ effective use of the TSF (e.g. reviewing password
+ composition practises, suggested frequency of user file
+ backups, discussion on the effects of changing user
+ access privileges).
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the available security functionality and
+ interfaces, in particular all security parameters under
+ the control of the user, indicating secure values as
+ appropriate.
+
+ The user guidance should contain an overview of the
+ security functionality that is visible at the user
+ interfaces.
+
+ The user guidance should identify and describe the
+ purpose, behaviour, and interrelationships of the
+ security interfaces and functionality.
+
+ For each user-accessible interface, the user guidance
+ should:
+
+
+ describe the method(s) by which the interface is
+ invoked (e.g. command-line, programming-language
+ system call, menu selection, command button);
+
+
+ describe the parameters to be set by the user, their
+ particular purposes, valid and default values, and
+ secure and insecure use settings of such parameters,
+ both individually or in combination;
+
+
+ describe the immediate TSF response, message, or
+ code returned.
+
+
+
+ The evaluator should consider the functional
+ specification and the ST to determine that the TSF
+ described in these documents is consistent to the
+ operational user guidance. The evaluator has to ensure
+ that the operational user guidance is complete to allow
+ the secure use through the TSFI available to all types
+ of human users. The evaluator may, as an aid, prepare an
+ informal mapping between the guidance and these
+ documents. Any omissions in this mapping may indicate
+ incompleteness.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, each type of security-relevant event relative to
+ the user functions that need to be performed, including
+ changing the security characteristics of entities under
+ the control of the TSF and operation following failure
+ or operational error.
+
+ All types of security-relevant events are detailed for
+ each user role, such that each user knows what events
+ may occur and what action (if any) he may have to take
+ in order to maintain security. Security-relevant events
+ that may occur during operation of the TOE (e.g. audit
+ trail overflow, system crash, updates to user records,
+ such as when a user account is removed when the user
+ leaves the organisation) are adequately defined to allow
+ user intervention to maintain secure operation.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance and other evaluation evidence to determine that
+ the guidance identifies all possible modes of operation
+ of the TOE (including, if applicable, operation
+ following failure or operational error), their
+ consequences and implications for maintaining secure
+ operation.
+
+ Other evaluation evidence, particularly the functional
+ specification, provide an information source that the
+ evaluator should use to determine that the guidance
+ contains sufficient guidance information.
+
+ If test documentation is included in the assurance
+ package, then the information provided in this evidence
+ can also be used to determine that the guidance contains
+ sufficient guidance documentation. The detail provided
+ in the test steps can be used to confirm that the
+ guidance provided is sufficient for the use and
+ administration of the TOE.
+
+ The evaluator should focus on a single human visible
+ TSFI at a time, comparing the guidance for securely
+ using the TSFI with other evaluation evidence, to
+ determine that the guidance related to the TSFI is
+ sufficient for the secure usage (i.e. consistent with
+ the SFRs) of that TSFI. The evaluator should also
+ consider the relationships between interfaces, searching
+ for potential conflicts.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it describes, for each user
+ role, the security measures to be followed in order to
+ fulfil the security objectives for the operational
+ environment as described in the ST.
+
+ The evaluator analyses the security objectives for the
+ operational environment in the ST and determines that
+ for each user role, the relevant security measures are
+ described appropriately in the user guidance.
+
+ The security measures described in the user guidance
+ should include all relevant external procedural,
+ physical, personnel and connectivity measures.
+
+ Note that those measures relevant for secure
+ installation of the TOE are examined in .
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is clear.
+
+ The guidance is unclear if it can reasonably be
+ misconstrued by an administrator or user, and used in a
+ way detrimental to the TOE, or to the security provided
+ by the TOE.
+
+
+
+
+ The evaluator shall examine the operational user
+ guidance to determine that it is reasonable.
+
+ The guidance is unreasonable if it makes demands on the
+ TOE's usage or operational environment that are
+ inconsistent with the ST or unduly onerous to maintain
+ security.
+
+
+
+
+
+
+
+ Preparative procedures are useful for ensuring that the TOE
+ has been received and installed in a secure manner as
+ intended by the developer. The requirements for preparation
+ call for a secure transition from the delivered TOE to its
+ initial operational environment. This includes investigating
+ whether the TOE can be configured or installed in a manner
+ that is insecure but that the user of the TOE would
+ reasonably believe to be secure.
+
+
+
+ Preparation requires that the delivered copy of the TOE is
+ accepted, configured and activated by the user to exhibit
+ the protection properties as needed during operation of the
+ TOE. The preparative procedures provide confidence that the
+ user will be aware of the TOE configuration parameters and
+ how they can affect the TSF.
+
+
+
+ This family contains only one component.
+
+
+
+ It is recognised that the application of these requirements
+ will vary depending on aspects such as whether the TOE is
+ delivered in an operational state, or whether it has to be
+ installed at the TOE owner's site, etc.
+
+ The first process covered by the preparative procedures is
+ the consumer's secure acceptance of the received TOE in
+ accordance with the developer's delivery procedures. If the
+ developer has not defined delivery procedures, security of
+ the acceptance has to be ensured otherwise.
+
+ Installation of the TOE includes transforming its
+ operational environment into a state that conforms to the
+ security objectives for the operational environment provided
+ in the ST.
+
+ It might also be the case that no installation is necessary,
+ for example a smart card. In this case it may be
+ inappropriate to require and analyse installation
+ procedures.
+
+ The requirements in this assurance family are presented
+ separately from those in the family, due to the infrequent, possibly
+ one-time use of the preparative procedures.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the procedures and steps for the secure preparation of the
+ TOE have been documented and result in a secure
+ configuration.
+
+
+
+ The preparative procedures refer to all acceptance and
+ installation procedures, that are necessary to progress
+ the TOE to the secure configuration as described in the
+ ST.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE including its preparative procedures;
+
+
+ the description of developer's delivery procedures, if
+ applicable;
+
+
+
+
+ The developer shall provide the TOE including its
+ preparative procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure acceptance
+ of the delivered TOE in accordance with the developer's
+ delivery procedures.
+
+ The preparative procedures
+ shall describe all the steps necessary for secure
+ installation of the TOE and for the secure preparation of
+ the operational environment in accordance with the security
+ objectives for the operational environment as described in
+ the ST.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+ The evaluator shall examine the provided acceptance
+ procedures to determine that they describe the steps
+ necessary for secure acceptance of the TOE in accordance
+ with the developer's delivery procedures.
+ If it is not anticipated by the developer's delivery
+ procedures that acceptance procedures will or can be
+ applied, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+ The acceptance procedures should include as a minimum,
+ that the user has to check that all parts of the TOE as
+ indicated in the ST have been delivered in the correct
+ version.
+
+ The acceptance procedures should reflect the steps the
+ user has to perform in order to accept the delivered TOE
+ that are implied by the developer's delivery
+ procedures.
+
+ The acceptance procedures should provide detailed
+ information about the following, if applicable:
+
+
+ making sure that the delivered TOE is the complete
+ evaluated instance;
+
+
+ detecting modification/masquerading of the delivered
+ TOE.
+
+
+
+
+
+
+
+ The evaluator shall examine the provided installation
+ procedures to determine that they describe the steps
+ necessary for secure installation of the TOE and the
+ secure preparation of the operational environment in
+ accordance with the security objectives in the
+ ST.
+
+ If it is not anticipated that installation procedures
+ will or can be applied (e.g. because the TOE may already
+ be delivered in an operational state), this work unit is
+ not applicable, and is therefore considered to be
+ satisfied.
+
+ The installation procedures should provide detailed
+ information about the following, if applicable:
+
+
+ minimum system requirements for secure installation;
+
+
+ requirements for the operational environment in
+ accordance with the security objectives provided by
+ the ST;
+
+ the steps the user has to perform in order to get to an
+ operational TOE being commensurate with its evaluated
+ configuration. Such a description shall include - for each step
+ - a clear scheme for the decision on the next step depended on
+ success, failure or problems at the current step;
+
+
+ changing the installation specific security
+ characteristics of entities under the control of the
+ TSF (for example parameters, settings, passwords);
+
+
+ handling exceptions and problems.
+
+
+
+
+
+ The evaluator shall apply the preparative procedures to
+ confirm that the TOE can be prepared securely for operation.
+
+
+ The evaluator shall perform all user procedures
+ necessary to prepare the TOE to determine that the TOE
+ and its operational environment can be prepared securely
+ using only the supplied preparative procedures.
+ Preparation requires the evaluator to advance the
+ TOE from a deliverable state to the state in which it is
+ operational, including acceptance and installation of
+ the TOE, and enforcing the SFRs consistent with the
+ security objectives for the TOE specified in the
+ ST.
+
+ The evaluator should follow only the developer's
+ procedures and may perform the activities that customers
+ are usually expected to perform to accept and install
+ the TOE, using the supplied preparative procedures only.
+ Any difficulties encountered during such an exercise may
+ be indicative of incomplete, unclear or unreasonable guidance.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+ If it is known that the TOE will be used as a dependent
+ component for a composed TOE evaluation, then the
+ evaluator should ensure that the operational environment
+ is satisfied by the base component used in the composed
+ TOE.
+
+
+
+
+
+
+
+
+ Life-cycle support is an aspect of establishing discipline and
+ control in the processes of refinement of the TOE during its
+ development and maintenance. Confidence in the correspondence
+ between the TOE security requirements and the TOE is greater
+ if security analysis and the production of the evidence are
+ done on a regular basis as an integral part of the development
+ and maintenance activities.
+
+ In the product life-cycle it is distinguished whether the TOE
+ is under the responsibility of the developer or the user
+ rather than whether it is located in the development or user
+ environment. The point of transition is the moment where the
+ TOE is handed over to the user. This is also the point of
+ transition from the to the class.
+
+ The class consists of seven
+ families. is the high-level
+ description of the TOE life-cycle; a more detailed description of the management
+ of the configuration items.
+ requires a minimum set of configuration items to be managed in
+ the defined way. is
+ concerned with the developer's physical, procedural,
+ personnel, and other security measures; with the development tools and implementation
+ standards used by the developer; with the handling of security flaws. defines the procedures used for
+ the delivery of the TOE to the consumer. Delivery processes
+ occurring during the development of the TOE are denoted rather
+ as transportations, and are handled in the context of
+ integration and acceptance procedures in other families of
+ this class.
+
+ Throughout this class, development and related terms
+ (developer, develop) are meant in the more general sense to
+ comprise development and production, whereas
+ production specifically means the process of transforming the
+ implementation representation into the final TOE.
+
+
+
+ Assurance class defines
+ requirements for assurance through the adoption of a well
+ defined life-cycle model for all the steps of the TOE
+ development, including flaw remediation procedures and
+ policies, correct use of tools and techniques and the security
+ measures used to protect the development environment.
+
+ Configuration management (CM) helps to ensure that the
+ integrity of the TOE is preserved, by preventing unauthorised
+ modifications, additions, or deletions to the TOE, thus
+ providing assurance that the TOE and documentation used for
+ evaluation are the ones prepared for distribution.
+
+ The delivery procedures define requirements for the measures,
+ procedures, and standards concerned with secure delivery of
+ the TOE, ensuring that the security protection offered by the
+ TOE is not compromised during the transfer to the user.
+
+
+
+ The purpose of the life-cycle support activity is to determine
+ the adequacy of the security procedures that the developer
+ uses during the development and maintenance of the TOE. These
+ procedures include the life-cycle model used by the developer,
+ the configuration management, the security measures used
+ throughout TOE development, the tools used by the developer
+ throughout the life-cycle of the TOE, the handling of security
+ flaws, and the delivery activity.
+
+ Poorly controlled development and maintenance of the TOE can
+ result in vulnerabilities in the implementation. Conformance
+ to a defined life-cycle model can help to improve controls in
+ this area. A measurable life-cycle model used for the TOE can
+ remove ambiguity in assessing the development progress of the
+ TOE.
+
+ The purpose of the configuration management activity is to
+ assist the consumer in identifying the evaluated TOE, to
+ ensure that configuration items are uniquely identified, and
+ the adequacy of the procedures that are used by the developer
+ to control and track changes that are made to the TOE. This
+ includes details on what changes are tracked, how potential
+ changes are incorporated, and the degree to which automation
+ is used to reduce the scope for error.
+
+ Developer security procedures are intended to protect the TOE
+ and its associated design information from interference or
+ disclosure. Interference in the development process may allow
+ the deliberate introduction of vulnerabilities. Disclosure of
+ design information may allow vulnerabilities to be more easily
+ exploited. The adequacy of the procedures will depend on the
+ nature of the TOE and the development process.
+
+ The use of well-defined development tools and the application
+ of implementation standards by the developer and by third
+ parties involved in the development process help to ensure
+ that vulnerabilities are not inadvertently introduced during
+ refinement.
+
+ The flaw remediation activity is intended to track security
+ flaws, to identify corrective actions, and to distribute the
+ corrective action information to TOE users.
+
+ The purpose of the delivery activity is to judge the adequacy
+ of the documentation of the procedures used to ensure that the
+ TOE is delivered to the consumer without modification.
+
+
+
+
+ Configuration management (CM) is one means for increasing
+ assurance that the TOE meets the SFRs. CM establishes this
+ by requiring discipline and control in the processes of
+ refinement and modification of the TOE and the related
+ information. CM systems are put in place to ensure the
+ integrity of the portions of the TOE that they control, by
+ providing a method of tracking any changes, and by ensuring
+ that all changes are authorised.
+
+ The objective of this family is to require the developer's
+ CM system to have certain capabilities. These are meant to
+ reduce the likelihood that accidental or unauthorised
+ modifications of the configuration items will occur. The CM
+ system should ensure the integrity of the TOE from the early
+ design stages through all subsequent maintenance
+ efforts.
+
+ The objective of introducing automated CM tools is to
+ increase the effectiveness of the CM system. While both
+ automated and manual CM systems can be bypassed, ignored, or
+ proven insufficient to prevent unauthorised modification,
+ automated systems are less susceptible to human error or
+ negligence.
+
+ The objectives of this family include the following:
+
+
+ ensuring that the TOE is correct and complete before it
+ is sent to the consumer;
+
+
+ ensuring that no configuration items are missed during
+ evaluation;
+
+
+ preventing unauthorised modification, addition, or
+ deletion of TOE configuration items.
+
+
+
+
+
+ Configuration management capabilities define the
+ characteristics of the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ the CM system capabilities, the scope of the CM
+ documentation and the evidence provided by the
+ developer.
+
+
+
+ While it is desired that CM be applied from the early design
+ stages and continue into the future, this family requires
+ that CM be in place and in use prior to the end of the
+ evaluation.
+
+ In the case where the TOE is a subset of a product, the
+ requirements of this family apply only to the TOE
+ configuration items, not to the product as a whole.
+
+ For developers that have separate CM systems for different
+ life-cycle phases (for example development, production
+ and/or the final product), it is required to document all of
+ them. For evaluation purposes, the separate CM systems
+ should be regarded as parts of an overall CM system which is
+ addressed in the criteria.
+
+ Similarly, if parts of the TOE are produced by different
+ developers or at different sites, the CM systems being in
+ use at the different places should be regarded as parts of
+ an overall CM system which is addressed in the criteria. In
+ this situation, integration aspects have also to be taken
+ into account.
+
+ Several elements of this family refer to configuration
+ items. These elements identify CM requirements to be imposed
+ on all items identified in the configuration list, but leave
+ the contents of the list to the discretion of the
+ developer. can be used to
+ narrow this discretion by identifying specific items that
+ must be included in the configuration list, and hence
+ covered by CM.
+
+ introduces a
+ requirement that the CM system uniquely identify all
+ configuration items. This also requires that modifications
+ to configuration items result in a new, unique identifier
+ being assigned to the configuration item.
+
+ introduces the
+ requirement that the evidence shall demonstrate that the CM
+ system operates in accordance with the CM plan. Examples of
+ such evidence might be documentation such as screen
+ snapshots or audit trail output from the CM system, or a
+ detailed demonstration of the CM system by the
+ developer. The evaluator is responsible for determining that
+ this evidence is sufficient to show that the CM system
+ operates in accordance with the CM plan.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ support the production of the TOE. This requires that the CM
+ system provide an automated means to assist in determining
+ that the correct configuration items are used in generating
+ the TOE.
+
+ introduces a
+ requirement that the CM system provide an automated means to
+ ascertain the changes between the TOE and its preceding
+ version. If no previous version of the TOE exists, the
+ developer still needs to provide an automated means to
+ ascertain the changes between the TOE and a future version
+ of the TOE.
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the
+ TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items.
+
+
+
+ This component contains an implicit evaluator action to
+ determine that the CM system is being used. As the
+ requirements here are limited to identification of the TOE
+ and provision of a configuration list, this action is
+ already covered by, and limited to, the existing work
+ units. At the
+ requirements are expanded beyond these two items, and more
+ explicit evidence of operation is required.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+ Assurance that the CM system uniquely identifies
+ all configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer uses a CM system that uniquely
+ identifies all configuration items, and whether the
+ ability to modify these items is properly
+ controlled.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide measures such that only
+ authorised changes are made to the configuration items.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan to determine that they
+ are effective in preventing unauthorised access to the
+ configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan.
+ The CM plan needs not to be a connected document, but it is
+ recommended that there is a single document that describes where
+ the various parts of the CM plan can be found. If the CM plan is
+ no single document, the list in the following work unit gives
+ hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the composed TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For configuration
+ items identified under ,
+ the evaluator confirms that each configuration item possesses
+ a unique identifier in a manner consistent with the unique
+ identification method that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that they
+ are automated and effective in preventing unauthorised
+ access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall check that the CM documentation
+ provided includes a CM plan.
+ The CM plan does not need to be contained within a single
+ document, but it is recommended that there is a separate
+ document that describes where the various parts of the CM plan
+ can be found. If the CM plan is provided by a set of documents,
+ the list in the following work unit gives guidance regarding the
+ required content.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+ If this work unit is applied to a dependent component
+ that is going to be integrated in a composed TOE, the CM
+ plan should consider the control of base components
+ obtained by the dependent TOE developer.
+
+ When obtaining the components the evaluators are to
+ verify the following:
+
+
+ Transfer of each base component from the base
+ component developer to the integrator (dependent TOE
+ developer) was performed in accordance with the base
+ component TOE's secure delivery procedures, as
+ reported in the base component TOE certification
+ report.
+
+
+ The component received has the same identifiers as
+ those stated in the ST and Certification Report for
+ the component TOE.
+
+
+ All additional material required by a developer for
+ composition (integration) is provided. This is to
+ include the necessary extract of the component TOE's
+ functional specification.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include change
+ control forms, or configuration item access approval
+ forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+
+
+
+ A unique reference is required to ensure that there is no
+ ambiguity in terms of which instance of the TOE is being
+ evaluated. Labelling the TOE with its reference ensures
+ that users of the TOE can be aware of which instance of
+ the TOE they are using.
+
+ Unique identification of the configuration items leads to
+ a clearer understanding of the composition of the TOE,
+ which in turn helps to determine those items which are
+ subject to the evaluation requirements for the TOE.
+
+ The use of a CM system increases assurance that the
+ configuration items are maintained in a controlled
+ manner.
+
+ Providing controls to ensure that unauthorised
+ modifications are not made to the TOE (``CM access
+ control''), and ensuring proper functionality and use of
+ the CM system, helps to maintain the integrity of the
+ TOE.
+
+ The purpose of the acceptance procedures is to ensure that
+ the parts of the TOE are of adequate quality and to
+ confirm that any creation or modification of configuration
+ items is authorised. Acceptance procedures are an
+ essential element in integration processes and in the
+ life-cycle management of the TOE.
+
+ In development environments where the configuration items
+ are complex, it is difficult to control changes without
+ the support of automated tools. In particular, these
+ automated tools need to be able to support the numerous
+ changes that occur during development and ensure that
+ those changes are authorised. It is an objective of this
+ component to ensure that the configuration items are
+ controlled through automated means. If the TOE is
+ developed by multiple developers, i.e. integration has to
+ take place, the use of automatic tools is adequate.
+
+ Production support procedures help to ensure that the
+ generation of the TOE from a managed set of configuration
+ items is correctly performed in an authorised manner,
+ particularly in the case when different developers are
+ involved and integration processes have to be carried
+ out.
+
+ Requiring that the CM system be able to identify the
+ version of the implementation representation from which
+ the TOE is generated helps to ensure that the integrity of
+ this material is preserved by the appropriate technical,
+ physical and procedural safeguards.
+
+ Providing an automated means of ascertaining changes
+ between versions of the TOE and identifying which
+ configuration items are affected by modifications to other
+ configuration items assists in determining the impact of
+ the changes between successive versions of the TOE. This
+ in turn can provide valuable information in determining
+ whether changes to the TOE result in all configuration
+ items being consistent with one another.
+
+
+
+ The objectives of this sub-activity are to determine
+ whether the developer has clearly identified the TOE and
+ its associated configuration items, and whether the
+ ability to modify these items is properly controlled by
+ automated tools, thus making the CM system less
+ susceptible to human error or negligence.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the TOE suitable for testing;
+
+
+ the configuration management documentation.
+
+
+
+
+ The developer shall provide the TOE and a reference for the
+ TOE.
+
+
+ The developer shall provide the CM documentation.
+
+
+ The developer shall use a CM system.
+
+
+ The TOE shall be labelled with its unique reference.
+
+
+ The CM documentation shall describe the method used to
+ uniquely identify the configuration items.
+
+
+ The CM documentation shall justify that the acceptance
+ procedures provide for an adequate and appropriate review of
+ changes to all configuration items.
+
+
+ The CM system shall uniquely identify all configuration
+ items.
+
+
+ The CM system shall provide automated measures such that
+ only authorised changes are made to the configuration items.
+
+
+ The CM system shall support the production of the TOE by
+ automated means.
+
+
+ The CM system shall ensure that the person responsible for
+ accepting a configuration item into CM is not the person who
+ developed it.
+
+
+ The CM system shall identify the configuration items that
+ comprise the TSF.
+
+
+ The CM system shall support the audit of all changes to the
+ TOE by automated means, including the originator, date, and
+ time in the audit trail.
+
+
+ The CM system shall provide an automated means to identify
+ all other configuration items that are affected by the
+ change of a given configuration item.
+
+
+ The CM system shall be able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+
+ The CM documentation shall include a CM plan.
+
+
+ The CM plan shall describe how the CM system is used for the
+ development of the TOE.
+
+
+ The CM plan shall describe the procedures used to accept
+ modified or newly created configuration items as part of the
+ TOE.
+
+
+ The evidence shall demonstrate that all configuration items
+ are being maintained under the CM system.
+
+
+ The evidence shall demonstrate that the CM system is being
+ operated in accordance with the CM plan.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the TOE provided for
+ evaluation is labelled with its reference.
+
+ The evaluator should ensure that the TOE contains the
+ unique reference which is stated in the ST. This could
+ be achieved through labelled packaging or media, or by a
+ label displayed by the operational TOE. This is to
+ ensure that it would be possible for consumers to
+ identify the TOE (e.g. at the point of purchase or
+ use).
+
+ The TOE may provide a method by which it can be easily
+ identified. For example, a software TOE may display its
+ name and version number during the start up routine, or
+ in response to a command line entry. A hardware or
+ firmware TOE may be identified by a part number
+ physically stamped on the TOE.
+
+ Alternatively, the unique reference provided for the TOE
+ may be the combination of the unique reference of each
+ component from which the TOE is comprised (e.g. in the
+ case of a composed TOE).
+
+
+
+ The evaluator shall check that the TOE references used
+ are consistent.
+
+ If the TOE is labelled more than once then the labels
+ have to be consistent. For example, it should be
+ possible to relate any labelled guidance documentation
+ supplied as part of the TOE to the evaluated operational
+ TOE. This ensures that consumers can be confident that
+ they have purchased the evaluated version of the TOE,
+ that they have installed this version, and that they
+ have the correct version of the guidance to operate the
+ TOE in accordance with its ST.
+
+ The evaluator also verifies that the TOE reference is
+ consistent with the ST.
+
+ If this work unit is applied to a composed TOE, the
+ following will apply. The composed IT TOE will not be
+ labelled with its unique (composite) reference, but only
+ the individual components will be labelled with their
+ appropriate TOE reference. It would require further
+ development for the IT TOE to be labelled, i.e. during
+ start-up and/or operation, with the composite reference.
+ If the composed TOE is delivered as the constituent
+ component TOEs, then the TOE items delivered will not
+ contain the composite reference. However, the composed
+ TOE ST will include the unique reference for the
+ composed TOE and will identify the components comprising
+ the composed TOE through which the consumers will be
+ able to determine whether they have the appropriate
+ items.
+
+
+
+
+ The evaluator shall examine the method of identifying
+ configuration items to determine that it describes how
+ configuration items are uniquely identified.
+
+ Procedures should describe how the status of each
+ configuration item can be tracked throughout the
+ life-cycle of the TOE. The procedures may be detailed in
+ the CM plan or throughout the CM documentation. The
+ information included should describe:
+
+
+ the method how each configuration item is uniquely
+ identified, such that it is possible to track
+ versions of the same configuration item;
+
+ the method how configuration items are assigned
+ unique identifiers and how they are entered into the
+ CM system;
+
+ the method to be used to identify superseded
+ versions of a configuration item.
+
+
+
+
+
+ The evaluator shall examine the CM documentation to
+ determine that it justifies that the acceptance
+ procedures provide for an adequate and appropriate
+ review of changes to all configuration items.
+
+ The CM documentation should make it sufficiently clear
+ that by following the acceptance procedures only parts
+ of adequate quality are incorporated into the
+ TOE.
+
+
+
+
+ The evaluator shall examine the configuration items to
+ determine that they are identified in a way that is
+ consistent with the CM documentation.
+
+ Assurance that the CM system uniquely identifies all
+ configuration items is gained by examining the
+ identifiers for the configuration items. For both
+ configuration items that comprise the TOE, and drafts of
+ configuration items that are submitted by the developer
+ as evaluation evidence, the evaluator confirms that each
+ configuration item possesses a unique identifier in a
+ manner consistent with the unique identification method
+ that is described in the CM documentation.
+
+
+
+
+ The evaluator shall examine the CM access control
+ measures described in the CM plan (cf. ) to determine that
+ they are automated and effective in preventing
+ unauthorised access to the configuration items.
+
+ The evaluator may use a number of methods to determine
+ that the CM access control measures are effective. For
+ example, the evaluator may exercise the access control
+ measures to ensure that the procedures could not be
+ bypassed. The evaluator may use the outputs generated by
+ the CM system procedures required by . The evaluator may also witness a
+ demonstration of the CM system to ensure that the access
+ control measures employed are operating
+ effectively.
+
+
+
+
+ The evaluator shall check the CM plan (cf. ) for automated
+ procedures for supporting the production of the
+ TOE.
+
+ The term ``production'' applies to those processes
+ adopted by the developer to progress the TOE from the
+ implementation representation to a state acceptable for
+ delivery to the end customer.
+
+ The evaluator verifies the existence of automated
+ production support procedures within the CM plan.
+
+ The following are examples for automated means
+ supporting the production of the TOE:
+
+
+ a ``make'' tool (as provided with many software
+ development tools) in the case of a software TOE;
+
+
+ a tool ensuring automatically (for example by means
+ of bar codes) that only parts are combined which
+ indeed belong together in the case of a hardware
+ TOE.
+
+
+
+
+
+
+ The evaluator shall examine the TOE production support
+ procedures to determine that they are effective in
+ ensuring that a TOE is generated that reflects its
+ implementation representation.
+
+ The production support procedures should describe which
+ tools have to be used to produce the final TOE from the
+ implementation representation in a clearly defined
+ way. The conventions, directives, or other necessary
+ constructs are described under .
+
+ The evaluator determines that by following the
+ production support procedures the correct configuration
+ items would be used to generate the TOE. For example, in
+ a software TOE this may include checking that the
+ automated production procedures ensure that all source
+ files and related libraries are included in the compiled
+ object code. Moreover, the procedures should ensure that
+ compiler options and comparable other options are
+ defined uniquely. For a hardware TOE, this work unit may
+ include checking that the automatic production
+ procedures ensure that the belonging parts are built
+ together and no parts are missing.
+
+ The customer can then be confident that the version of
+ the TOE delivered for installation is derived from the
+ implementation representation in an unambiguous way and
+ implements the SFRs as described in the ST.
+
+ The evaluator should bear in mind that the CM system
+ need not necessarily possess the capability to produce
+ the TOE, but should provide support for the process that
+ will help reduce the probability of human error.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it ensures that the person responsible for
+ accepting a configuration item is not the person who
+ developed it.
+
+ The acceptance procedures describe who is responsible
+ for accepting a configuration item. From these
+ descriptions, the evaluator should be able to determine
+ that the person who developed a configuration item is in
+ no case responsible for its acceptance.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it identifies the configuration items that comprise
+ the TSF.
+
+ The CM documentation should describe how the CM system
+ identifies the configuration items that comprise the
+ TSF. The evaluator should select a sample of
+ configuration items covering each type of items,
+ particularly containing TSF and non-TSF items, and check
+ that they are correctly classified by the CM
+ system.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it supports the audit of all changes to the TOE by
+ automated means, including the originator, date, and
+ time in the audit trail.
+
+ The evaluator should inspect a sample of audit trails
+ and check, if they contain the minimum
+ information.
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it provides an automated means to identify all
+ other configuration items that are affected by the
+ change of a given configuration item.
+
+ The CM documentation should describe how the CM system
+ identifies all other configuration items that are
+ affected by the change of a given configuration
+ item. The evaluator should select a sample of
+ configuration items, covering all types of items, and
+ exercise the automated means to determine that it
+ identifies all items that are affected by the change of
+ the selected item.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall examine the CM system to determine
+ that it is able to identify the version of the
+ implementation representation from which the TOE is
+ generated.
+
+ The CM documentation should describe how the CM system
+ identifies the version of the implementation
+ representation from which the TOE is generated. The
+ evaluator should select a sample of the parts used to
+ produce the TOE and should apply the CM system to verify
+ that it identifies the corresponding implementation
+ representation in the correct version.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check that the CM documentation provided
+ includes a CM plan.
+ The CM plan needs not to be a connected document, but it is
+ recommended that there is a single document that describes where
+ the various parts of the CM plan can be found. If the CM plan is
+ no single document, the list in the following work unit gives
+ hints regarding which context is expected.
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes how the CM system is used for the
+ development of the TOE.
+
+ The descriptions contained in a CM plan include, if
+ applicable:
+
+
+ all activities performed in the TOE development that
+ are subject to configuration management procedures
+ (e.g. creation, modification or deletion of a
+ configuration item, data-backup, archiving);
+
+
+ which means (e.g. CM tools, forms) have to be made
+ available;
+
+
+ the usage of the CM tools: the necessary details for
+ a user of the CM system to be able to operate the CM
+ tools correctly in order to maintain the integrity
+ of the TOE;
+
+
+ the production support procedures;
+
+
+ which other objects (development components, tools,
+ assessment environments, etc) are taken under CM
+ control;
+
+
+ the roles and responsibilities of individuals
+ required to perform operations on individual
+ configuration items (different roles may be
+ identified for different types of configuration
+ items (e.g. design documentation or source code));
+
+
+ how CM instances (e.g. change control boards,
+ interface control working groups) are introduced and
+ staffed;
+
+
+ the description of the change management;
+
+
+ the procedures that are used to ensure that only
+ authorised individuals can make changes to
+ configuration items;
+
+
+ the procedures that are used to ensure that
+ concurrency problems do not occur as a result of
+ simultaneous changes to configuration items;
+
+
+ the evidence that is generated as a result of
+ application of the procedures. For example, for a
+ change to a configuration item, the CM system might
+ record a description of the change, accountability
+ for the change, identification of all configuration
+ items affected, status (e.g. pending or completed),
+ and date and time of the change. This might be
+ recorded in an audit trail of changes made or change
+ control records;
+
+
+ the approach to version control and unique
+ referencing of TOE versions (e.g. covering the
+ release of patches in operating systems, and the
+ subsequent detection of their application).
+
+
+
+
+
+
+ The evaluator shall examine the CM plan to determine
+ that it describes the procedures used to accept modified
+ or newly created configuration items as parts of the
+ TOE.
+
+ The descriptions of the acceptance procedures in the CM
+ plan should include the developer roles or individuals
+ responsible for the acceptance and the criteria to be
+ used for acceptance. They should take into account all
+ acceptance situations that may occur, in particular:
+
+
+ accepting an item into the CM system for the first
+ time, in particular inclusion of software, firmware
+ and hardware components from other manufacturers
+ into the TOE (``integration'');
+
+
+ moving configuration items to the next life-cycle
+ phase at each stage of the construction of the TOE
+ (e.g. module, subsystem, system);
+
+
+ subsequent to transports between different
+ development sites.
+
+
+
+
+
+
+ The evaluator shall check that the configuration items
+ identified in the configuration list are being
+ maintained by the CM system.
+
+ The CM system employed by the developer should maintain the
+ integrity of the TOE. The evaluator should check that for each
+ type of configuration item (e.g. design documents or source code
+ modules) contained in the configuration list there are examples
+ of the evidence generated by the procedures described in the CM
+ plan. In this case, the approach to sampling will depend upon
+ the level of granularity used in the CM system to control CM
+ items. Where, for example, 10,000 source code modules are
+ identified in the configuration list, a different sampling
+ strategy needs to be applied compared to the case in which there
+ are only 5, or even 1. The emphasis of this activity should be
+ on ensuring that the CM system is being operated correctly,
+ rather than on the detection of any minor error.
+
+ For guidance on sampling see .
+
+
+
+
+ The evaluator shall check the CM documentation to
+ ascertain that it includes the CM system records
+ identified by the CM plan.
+
+ The output produced by the CM system should provide the
+ evidence that the evaluator needs to be confident that
+ the CM plan is being applied, and also that all
+ configuration items are being maintained by the CM
+ system as required by . Example output could include
+ change control forms, or configuration item access
+ approval forms.
+
+
+
+
+ The evaluator shall examine the evidence to determine
+ that the CM system is being operated in accordance with
+ the CM plan.
+
+ The evaluator should select and examine a sample of
+ evidence covering each type of CM-relevant operation
+ that has been performed on a configuration item
+ (e.g. creation, modification, deletion, reversion to an
+ earlier version) to confirm that all operations of the
+ CM system have been carried out in line with documented
+ procedures. The evaluator confirms that the evidence
+ includes all the information identified for that
+ operation in the CM plan. Examination of the evidence
+ may require access to a CM tool that is used. The
+ evaluator may choose to sample the evidence.
+
+ For guidance on sampling see .
+
+ Further confidence in the correct operation of the CM system and
+ the effective maintenance of configuration items may be
+ established by means of interviews with selected development
+ staff. In conducting such interviews, the evaluator aims
+ to gain a deeper understanding of how the CM system is used in
+ practise as well as to confirm that the CM procedures are being
+ applied as described in the CM documentation. Note that such
+ interviews should complement rather than replace the examination
+ of documentary evidence, and may not be necessary if the
+ documentary evidence alone satisfies the requirement. However,
+ given the wide scope of the CM plan it is possible that some
+ aspects (e.g. roles and responsibilities) may not be clear from
+ the CM plan and records alone. This is one case where
+ clarification may be necessary through interviews.
+
+ It is expected that the evaluator will visit the
+ development site in support of this activity.
+
+ For guidance on site visits see .
+
+
+
+ The evaluator shall determine that the application of the
+ production support procedures results in a TOE as provided
+ by the developer for testing activities.
+
+
+ The evaluator shall examine the production support
+ procedures to determine that by following these
+ procedures a TOE would be produced like that one
+ provided by the developer for testing activities.
+
+ If the TOE is a small software TOE and production
+ consists of compiling and linking, the evaluator might
+ confirm the adequacy of the production support
+ procedures by reapplying them himself.
+
+ If the production process of the TOE is more complicated
+ (as for example in the case of a smart card), but has
+ already started, the evaluator should inspect the
+ application of the production support procedures during
+ a visit of the development site. He might compare a copy
+ of the TOE produced in his presence with the samples
+ used for his testing activities.
+
+ For guidance on site visits see .
+
+ Otherwise the evaluator's determination should be based
+ on the documentary evidence provided by the
+ developer.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+ The objective of this family is to identify items to be
+ included as configuration items and hence placed under the
+ CM requirements of .
+ Applying configuration management to these additional items
+ provides additional assurance that the integrity of TOE is
+ maintained.
+
+
+
+ Configuration management scope indicates the TOE items that
+ need to be controlled by the configuration management
+ system.
+
+
+
+ The components in this family are levelled on the basis of
+ which of the following are required to be included as
+ configuration items: the TOE and the evaluation evidence
+ required by the SARs; the parts of the TOE; the
+ implementation representation; security flaws; and
+ development tools and related information.
+
+
+
+ While mandates a list of
+ configuration items and that each item on this list be under
+ CM, leaves the contents of
+ the configuration list to the discretion of the
+ developer. narrows this
+ discretion by identifying items that must be included in the
+ configuration list, and hence come under the CM requirements
+ of .
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself and the evaluation evidence required by the other
+ SARs in the ST under CM provides assurance that they have
+ been modified in a controlled manner with proper
+ authorisations.
+
+
+
+ introduces the
+ requirement that the TOE itself and the evaluation
+ evidence required by the other SARs in the ST be included
+ in the configuration list and hence be subject to the CM
+ requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer performs configuration management on the TOE
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; and the evaluation evidence required by the SARs.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, and the
+ evaluation evidence required by the other SARs under CM
+ provides assurance that they have been modified in a
+ controlled manner with proper authorisations.
+
+
+
+ introduces the
+ requirement that the parts that comprise the TOE (all
+ parts that are delivered to the consumer, for example
+ hardware parts or executable files) be included in the
+ configuration list and hence be subject to the CM
+ requirements of .
+
+ introduces the
+ requirement that the configuration list indicate the
+ developer of each TSF relevant configuration
+ item. ``Developer'' here does not refer to a person, but
+ to the organisation responsible for the development of the
+ item.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; and
+ the parts that comprise the TOE.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+ the TOE itself;
+
+ the parts that comprise the TOE;
+
+ the evaluation evidence required by the SARs.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+
+
+ introduces the
+ requirement that the TOE implementation representation be
+ included in the list of configuration items and hence be
+ subject to the CM requirements of .
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; and the implementation
+ representation.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST.
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+
+
+ introduces the
+ requirement that security flaws be included in the
+ configuration list and hence be subject to the CM
+ requirements of . This
+ requires that information regarding previous security
+ flaws and their resolution be maintained, as well as
+ details regarding current security flaws.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; and security flaw reports and resolution
+ status.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database).
+
+
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ A CM system can control changes only to those items that
+ have been placed under CM (i.e., the configuration items
+ identified in the configuration list). Placing the TOE
+ itself, the parts that comprise the TOE, the TOE
+ implementation representation and the evaluation evidence
+ required by the other SARs under CM provides assurance
+ that they have been modified in a controlled manner with
+ proper authorisations.
+
+ Placing security flaws under CM ensures that security flaw
+ reports are not lost or forgotten, and allows a developer
+ to track security flaws to their resolution.
+
+ Development tools play an important role in ensuring the
+ production of a quality version of the TOE. Therefore, it
+ is important to control modifications to these
+ tools.
+
+
+
+ introduces the
+ requirement that development tools and other related
+ information be included in the list of configuration items
+ and hence be subject to the CM requirements of . Examples of development tools
+ are programming languages and compilers. Information
+ pertaining to TOE generation items (such as compiler
+ options, generation options, and build options) is an
+ example of information relating to development
+ tools.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the configuration list includes the TOE, the parts that
+ comprise the TOE, the TOE implementation representation,
+ security flaws, development tools and related information,
+ and the evaluation evidence. These configuration items are
+ controlled in accordance with .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the configuration list.
+
+
+
+
+ The developer shall provide a configuration list for the
+ TOE.
+
+
+ The configuration list shall include the following: the TOE
+ itself; the evaluation evidence required by the SARs; the
+ parts that comprise the TOE; the implementation
+ representation; security flaw reports and resolution status;
+ and development tools and related information.
+
+
+ The configuration list shall uniquely identify the
+ configuration items.
+
+
+ For each TSF relevant configuration item, the configuration
+ list shall indicate the developer of the item.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the configuration list
+ includes the following set of items:
+
+
+ the TOE itself;
+
+
+ the parts that comprise the TOE;
+
+
+ the TOE implementation representation;
+
+
+ the evaluation evidence required by the SARs in the
+ ST;
+
+
+ the documentation used to record details of reported
+ security flaws associated with the implementation
+ (e.g., problem status reports derived from a
+ developer's problem database);
+
+
+ all tools (incl. test software, if applicable)
+ involved in the development and production of the
+ TOE including the names, versions, configurations
+ and roles of each development tool, and related
+ documentation.
+
+
+ For a software TOE, ``development tools'' are usually
+ programming languages and compiler and ``related documentation''
+ comprises compiler and linker options. For a hardware TOE,
+ ``development tools'' might be hardware design languages,
+ simulation and synthesis tools, compilers, and ``related
+ documentation'' might comprise compiler options again.
+
+
+
+
+ The evaluator shall examine the configuration list to
+ determine that it uniquely identifies each configuration
+ item.
+
+ The configuration list contains sufficient information
+ to uniquely identify which version of each item has been
+ used (typically a version number). Use of this list will
+ enable the evaluator to check that the correct
+ configuration items, and the correct version of each
+ item, have been used during the evaluation.
+
+
+
+
+ The evaluator shall check that the configuration list
+ indicates the developer of each TSF relevant
+ configuration item.
+
+ If only one developer is involved in the development of
+ the TOE, this work unit is not applicable, and is
+ therefore considered to be satisfied.
+
+
+
+
+
+
+
+ The concern of this family is the secure transfer of the
+ finished TOE from the development environment into the
+ responsibility of the user.
+
+ The requirements for delivery call for system control and
+ distribution facilities and procedures that detail the
+ measures necessary to provide assurance that the security of
+ the TOE is maintained during distribution of the TOE to the
+ user. For a valid distribution of the TOE, the procedures
+ used for the distribution of the TOE address the objectives
+ identified in the PP/ST relating to the security of the TOE
+ during delivery.
+
+
+
+ Delivery covers the procedures used to maintain security
+ during transfer of the TOE to the user, both on initial
+ delivery and as part of subsequent modification. It includes
+ special procedures or operations required to demonstrate the
+ authenticity of the delivered TOE. Such procedures and
+ measures are the basis for ensuring that the security
+ protection offered by the TOE is not compromised during
+ transfer. While compliance with the delivery requirements
+ cannot always be determined when a TOE is evaluated, it is
+ possible to evaluate the procedures that a developer has
+ developed to distribute the TOE to users.
+
+
+
+ This family contains only one component. An increasing level
+ of protection is established by requiring commensurability
+ of the delivery procedures with the assumed attack potential
+ in the family .
+
+
+
+ Transportations from subcontractors to the developer or
+ between different development sites are not considered here,
+ but in the family .
+
+ The end of the delivery phase is marked by the transfer of
+ the TOE into the responsibility of the user. This does not
+ necessarily coincide with the arrival of the TOE at the
+ user's location.
+
+ The delivery procedures should consider, if applicable,
+ issues such as:
+
+
+ ensuring that the TOE received by the consumer
+ corresponds precisely to the evaluated version of the
+ TOE;
+
+
+ avoiding or detecting any tampering with the actual
+ version of the TOE;
+
+
+ preventing submission of a false version of the TOE;
+
+
+ avoiding unwanted knowledge of distribution of the TOE
+ to the consumer: there might be cases where potential
+ attackers should not know when and how it is delivered;
+
+
+ avoiding or detecting the TOE being intercepted during
+ delivery; and
+
+
+ avoiding the TOE being delayed or stopped during
+ distribution.
+
+
+
+ The delivery procedures should include the recipient's
+ actions implied by these issues. The consistent description
+ of these implied actions is examined in the family, if present.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the delivery documentation describes all procedures used
+ to maintain security of the TOE when distributing the TOE
+ to the user.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the delivery documentation.
+
+
+
+
+ The developer shall document and provide procedures for delivery of the
+ TOE or parts of it to the consumer.
+
+
+ The developer shall use the delivery procedures.
+
+
+ The evaluator shall examine aspects of the delivery
+ process to determine that the delivery procedures are
+ used.
+
+ The approach taken by the evaluator to check the
+ application of delivery procedures will depend on the
+ nature of the TOE, and the delivery process itself. In
+ addition to examination of the procedures themselves,
+ the evaluator seeks some assurance that they are applied
+ in practise. Some possible approaches are:
+
+
+ a visit to the distribution site(s) where practical
+ application of the procedures may be observed;
+
+
+ examination of the TOE at some stage during
+ delivery, or after the user has received it
+ (e.g. checking for tamper proof seals);
+
+
+ observing that the process is applied in practise
+ when the evaluator obtains the TOE through regular
+ channels;
+
+
+ questioning end users as to how the TOE was
+ delivered.
+
+
+
+ For guidance on site visits see .
+
+ It may be the case of a newly developed TOE that the
+ delivery procedures have yet to be exercised. In these
+ cases, the evaluator has to be satisfied that
+ appropriate procedures and facilities are in place for
+ future deliveries and that all personnel involved are
+ aware of their responsibilities. The evaluator may
+ request a ``dry run'' of a delivery if this is
+ practical. If the developer has produced other similar
+ products, then an examination of procedures in their use
+ may be useful in providing assurance.
+
+
+
+ The delivery documentation shall describe all procedures
+ that are necessary to maintain security when distributing
+ versions of the TOE to the consumer.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the delivery documentation
+ to determine that it describes all procedures that are
+ necessary to maintain security when distributing
+ versions of the TOE or parts of it to the
+ consumer.
+
+ The delivery documentation describes proper procedures
+ to maintain security of the TOE during transfer of the
+ TOE or its component parts and to determine the
+ identification of the TOE.
+
+ The delivery documentation should cover the entire TOE,
+ but may contain different procedures for different parts
+ of the TOE. The evaluation should consider the totality
+ of procedures.
+
+ The delivery procedures should be applicable across all
+ phases of delivery from the production environment to
+ the installation environment (e.g. packaging, storage
+ and distribution). Standard commercial practise for
+ packaging and delivery may be acceptable. This includes
+ shrink wrapped packaging, a security tape or a sealed
+ envelope. For the distribution, physical (e.g. public
+ mail or a private distribution service) or electronic
+ (e.g. electronic mail or downloading off the Internet)
+ procedures may be used.
+
+ Cryptographic checksums or a software signature may be
+ used by the developer to ensure that tampering or
+ masquerading can be detected. Tamper proof seals
+ additionally indicate if the confidentiality has been
+ broken. For software TOEs, confidentiality might be
+ assured by using encryption. If availability is of
+ concern, a secure transportation might be
+ required.
+
+ Interpretation of the term ``necessary to maintain
+ security'' will need to consider:
+
+
+ The nature of the TOE (e.g. whether it is software
+ or hardware).
+
+
+ The overall security level stated for the TOE by the
+ chosen level of the Vulnerability Assessment. If the
+ TOE is required to be resistant against attackers of
+ a certain potential in its intended environment,
+ this should also apply to the delivery of the
+ TOE. The evaluator should determine that a balanced
+ approach has been taken, such that delivery does not
+ present a weak point in an otherwise secure
+ development process.
+
+
+ The security objectives provided by the ST. The emphasis in the
+ delivery documentation is likely to be on measures related to
+ integrity, as integrity of the TOE is always important. However,
+ confidentiality and availability of the delivery will be of
+ concern in the delivery of some TOEs; procedures relating to
+ these aspects of the secure delivery should also be discussed in
+ the procedures.
+
+
+
+
+
+
+
+
+
+ Development security is concerned with physical, procedural,
+ personnel, and other security measures that may be used in
+ the development environment to protect the TOE and its
+ parts. It includes the physical security of the development
+ location and any procedures used to select development
+ staff.
+
+
+
+ Development security covers the physical, procedural,
+ personnel, and other security measures used in the
+ development environment. It includes physical security of
+ the development location(s) and controls on the selection
+ and hiring of development staff.
+
+
+
+ The components in this family are levelled on the basis of
+ whether justification of the sufficiency of the security
+ measures is required.
+
+
+
+ This family deals with measures to remove or reduce threats
+ existing at the developer's site.
+
+ The evaluator should visit the site(s) in order to assess
+ evidence for development security. This may include sites of
+ subcontractors involved in the TOE development and
+ production. Any decision not to visit shall be agreed with
+ the evaluation authority.
+
+ Although development security deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, the requirements specify only that the
+ development security measures be in place at the time of
+ evaluation. Furthermore,
+ does not contain any requirements related to the sponsor's
+ intention to apply the development security measures in the
+ future, after completion of the evaluation.
+
+ It is recognised that confidentiality may not always be an
+ issue for the protection of the TOE in its development
+ environment. The use of the word ``necessary'' allows for
+ the selection of appropriate safeguards.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce and provide development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first referring to
+ the ST for any information that may assist in the determination
+ of necessary protection.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material within and out of
+ the development environment and between
+ different development sites in accordance with
+ defined acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ The evaluator should examine whether the following is included
+ in the policies:
+
+ what information relating to the TOE development needs to be
+ kept confidential, and which members of the development
+ staff are allowed to access such material;
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the ,
+ mandating only necessary measures, are dependent on the nature of the TOE,
+ and on information that may be provided in the ST. The evaluators would
+ then determine that such a policy had been applied under this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer's security controls on the development
+ environment are adequate to provide the confidentiality
+ and integrity of the TOE design and implementation that is
+ necessary to ensure that secure operation of the TOE is
+ not compromised. Additionally, sufficiency of the measures
+ as applied is intended be justified.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the development security documentation.
+
+
+
+ In addition, the evaluator may need to examine other
+ deliverables to determine that the security controls are
+ well-defined and followed. Specifically, the evaluator may
+ need to examine the developer's configuration management
+ documentation (the input for the ``Production support and acceptance
+ procedures'' and the
+ ``Problem tracking CM coverage''). Evidence that the
+ procedures are being applied is also required.
+
+
+ The developer shall produce and provide development security
+ documentation.
+
+
+ The development security documentation shall describe all
+ the physical, procedural, personnel, and other security
+ measures that are necessary to protect the confidentiality
+ and integrity of the TOE design and implementation in its
+ development environment.
+
+
+ The development security documentation shall justify that
+ the security measures provide the necessary level of
+ protection to maintain the confidentiality and integrity of
+ the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that it details all security
+ measures used in the development environment that are
+ necessary to protect the confidentiality and integrity
+ of the TOE design and implementation.
+
+ The evaluator determines what is necessary by first referring to
+ the ST for any information that may assist in the determination
+ of necessary protection.
+
+ If no explicit information is available from the ST the
+ evaluator will need to make a determination of the
+ necessary measures. In cases where the developer's
+ measures are considered less than what is necessary, a
+ clear justification should be provided for the
+ assessment, based on a potential exploitable
+ vulnerability.
+
+ The following types of security measures are considered
+ by the evaluator when examining the documentation:
+
+
+ physical, for example physical access controls used
+ to prevent unauthorised access to the TOE
+ development environment (during normal working hours
+ and at other times);
+
+
+ procedural, for example covering:
+
+
+ granting of access to the development
+ environment or to specific parts of the
+ environment such as development machines
+
+
+ revocation of access rights when a person leaves
+ the development team
+
+
+ transfer of protected material out of the
+ development environment and between different
+ development sites in accordance with defined
+ acceptance procedures
+
+
+ admitting and escorting visitors to the
+ development environment
+
+
+ roles and responsibilities in ensuring the
+ continued application of security measures, and
+ the detection of security breaches.
+
+
+
+
+ personnel, for example any controls or checks made
+ to establish the trustworthiness of new development
+ staff;
+
+
+ other security measures, for example the logical
+ protections on any development machines.
+
+
+
+ The development security documentation should identify
+ the locations at which development occurs, and describe
+ the aspects of development performed, along with the
+ security measures applied at each location and for
+ transports between different locations. For example,
+ development could occur at multiple facilities within a
+ single building, multiple buildings at the same site, or
+ at multiple sites. Transports of parts of the TOE or the
+ unfinished TOE between different development sites are
+ to be covered by the ,
+ whereas the transport of the finished TOE to the
+ consumer is dealt with in the .
+
+ Development includes the production of the TOE.
+
+
+
+
+ The evaluator shall examine the development security
+ documentation to determine that an appropriate
+ justification is given why the security measures provide
+ the necessary level of protection to maintain the
+ confidentiality and integrity of the TOE.
+
+ Since attacks on the TOE or its related information are
+ assumed in different design and production stages,
+ measures and procedures need to have an appropriate
+ level necessary to prevent those attacks or to make them
+ more difficult.
+
+ Since this level depends on the overall attack potential
+ claimed for the TOE (cf. the component chosen), the development
+ security documentation should justify the necessary
+ level of protection to maintain the confidentiality and
+ integrity of the TOE. This level has to be achieved by
+ the security measures applied.
+
+ The concept of protection measures should be consistent,
+ and the justification should include an analysis of how
+ the measures are mutually supportive. All aspects of
+ development and production on all the different sites
+ with all roles involved up to delivery of the TOE should
+ be analysed.
+
+ Justification may include an analysis of potential
+ vulnerabilities taking the applied security measures
+ into account.
+
+ There may be a convincing argument showing that e.g.
+
+
+ The technical measures and mechanisms of the
+ developer's infrastructure are sufficient for
+ keeping the appropriate security level
+ (e.g. cryptographic mechanisms as well as physical
+ protection mechanisms, properties of the CM system
+ (cf. ));
+
+ The system containing the implementation
+ representation of the TOE (including concerning
+ guidance documents) provides effective protection
+ against logical attacks e.g. by ``Trojan'' code or
+ viruses. It might be adequate, if the implementation
+ representation is kept on an isolated system where
+ only the software necessary to maintain it is
+ installed and where no additional software is
+ installed afterwards.
+
+ Data brought into this system need to be carefully considered to
+ prevent the installation of hidden functionality onto the
+ system. The effectiveness of these measures need to be tested,
+ e.g. by independently trying to get access to the machine,
+ install some additional executable (program, macro etc.) or get
+ some information out of the machine using logical
+ attacks.
+
+ The appropriate organisational (procedural and
+ personal) measures are unconditionally
+ enforced.
+
+
+
+
+ The evaluator shall examine the development
+ confidentiality and integrity policies in order to
+ determine the sufficiency of the security measures
+ employed.
+
+ The evaluator should examine whether the following is included
+ in the policies:
+
+ what information relating to the TOE development needs to be
+ kept confidential, and which members of the development
+ staff are allowed to access such material;
+
+ what material must be protected from unauthorised
+ modification in order to preserve the integrity of
+ the TOE, and which members of the development staff
+ are allowed to modify such material.
+
+
+ The evaluator should determine that these policies are
+ described in the development security documentation,
+ that the security measures employed are consistent with
+ the policies, and that they are complete.
+
+ It should be noted that configuration management
+ procedures will help protect the integrity of the TOE
+ and the evaluator should avoid overlap with the
+ work-units conducted for the . For example, the CM documentation may
+ describe the security procedures necessary for
+ controlling the roles or individuals who should have
+ access to the development environment and who may modify
+ the TOE.
+
+ Whereas the
+ requirements are fixed, those for the , mandating only necessary measures, are
+ dependent on the nature of the TOE, and on information
+ that may be provided in the ST. For example, the ST may
+ identify a security objective for the development
+ environment that requires the TOE to be developed by
+ staff that has security clearance. The evaluators would
+ then determine that such a policy had been applied under
+ this sub-activity.
+
+
+
+ The evaluator shall confirm that the security measures are
+ being applied.
+
+
+ The evaluator shall examine the development security
+ documentation and associated evidence to determine that
+ the security measures are being applied.
+
+ This work unit requires the evaluator to determine that
+ the security measures described in the development
+ security documentation are being followed, such that the
+ integrity of the TOE and the confidentiality of
+ associated documentation is being adequately
+ protected. For example, this could be determined by
+ examination of the documentary evidence
+ provided. Documentary evidence should be supplemented by
+ visiting the development environment. A visit to the
+ development environment will allow the evaluator to:
+
+
+ observe the application of security measures
+ (e.g. physical measures);
+
+
+ examine documentary evidence of application of
+ procedures;
+
+
+ interview development staff to check awareness of
+ the development security policies and procedures,
+ and their responsibilities.
+
+
+
+ A development site visit is a useful means of gaining
+ confidence in the measures being used. Any decision not
+ to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ For guidance on site visits see .
+
+
+
+
+
+
+
+ Flaw remediation requires that discovered security flaws be
+ tracked and corrected by the developer. Although future
+ compliance with flaw remediation procedures cannot be
+ determined at the time of the TOE evaluation, it is possible
+ to evaluate the policies and procedures that a developer has
+ in place to track and correct flaws, and to distribute the
+ flaw information and corrections.
+
+
+
+ Flaw remediation ensures that flaws discovered by the TOE
+ consumers will be tracked and corrected while the TOE is
+ supported by the developer. While future compliance with the
+ flaw remediation requirements cannot be determined when a
+ TOE is evaluated, it is possible to evaluate the procedures
+ and policies that a developer has in place to track and
+ repair flaws, and to distribute the repairs to
+ consumers.
+
+
+
+ The components in this family are levelled on the basis of
+ the increasing extent in scope of the flaw remediation
+ procedures and the rigour of the flaw remediation
+ policies.
+
+
+
+ This family provides assurance that the TOE will be
+ maintained and supported in the future, requiring the TOE
+ developer to track and correct flaws in the
+ TOE. Additionally, requirements are included for the
+ distribution of flaw corrections. However, this family does
+ not impose evaluation requirements beyond the current
+ evaluation.
+
+ The TOE user is considered to be the focal point in the user
+ organisation that is responsible for receiving and
+ implementing fixes to security flaws. This is not
+ necessarily an individual user, but may be an organisational
+ representative who is responsible for the handling of
+ security flaws. The use of the term TOE user recognises that
+ different organisations have different procedures for
+ handling flaw reporting, which may be done either by an
+ individual user, or by a central administrative body.
+
+ The flaw remediation procedures should describe the methods
+ for dealing with all types of flaws encountered. These flaws
+ may be reported by the developer, by users of the TOE, or by
+ other parties with familiarity with the TOE. Some flaws may
+ not be reparable immediately. There may be some occasions
+ where a flaw cannot be fixed and other (e.g. procedural)
+ measures must be taken. The documentation provided should
+ cover the procedures for providing the operational sites
+ with fixes, and providing information on flaws where fixes
+ are delayed (and what to do in the interim) or when fixes
+ are not possible.
+
+ Changes applied to a TOE after its release render it
+ unevaluated; although some information from the original
+ evaluation may still apply. The phrase ``release of the
+ TOE'' used in this family therefore refers to a version of a
+ product that is a release of a certified TOE, to which
+ changes have been applied.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE users.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation.
+
+
+
+
+ The developer shall document and provide flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+ While these requirements do not mandate that there be a
+ publicised means for TOE users to report security flaws,
+ they do mandate that all security flaws that are
+ reported be tracked. That is, a reported security flaw
+ cannot be ignored simply because it comes from outside
+ the developer's organisation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACK DOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer. Flaw remediation guidance from the developer to
+ the TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, and for assurance that the corrections introduce no
+ new security flaws.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document and provide flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that they describe procedures
+ for the developer to accept reports of security flaws or
+ requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure every reported flaw is
+ corrected.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is corrected. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+
+ The procedures describe the process that is taken from
+ the point at which a security flaw is resolved to the
+ point at which the remediation procedures are
+ provided. The procedures for delivering corrective
+ actions should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+
+
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, and to know to
+ whom to send corrective fixes, TOE users need to
+ understand how to submit security flaw reports to the
+ developer, and how to register themselves with the
+ developer so that they may receive these corrective
+ fixes. Flaw remediation guidance from the developer to the
+ TOE user ensures that TOE users are aware of this
+ important information.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has established flaw remediation procedures
+ that describe the tracking of security flaws, the
+ identification of corrective actions, and the distribution
+ of corrective action information to TOE
+ users. Additionally, this sub-activity determines whether
+ the developer's procedures provide for the corrections of
+ security flaws, for the receipt of flaw reports from TOE
+ users, for assurance that the corrections introduce no new
+ security flaws, for the establishment of a point of
+ contact for each TOE user, and for the timely issue of
+ corrective actions to TOE users.
+
+ In order for the developer to be able to act appropriately
+ upon security flaw reports from TOE users, TOE users need
+ to understand how to submit security flaw reports to the
+ developer, and developers need to know how to receive
+ these reports. Flaw remediation guidance addressed to the
+ TOE user ensures that TOE users are aware of how to
+ communicate with the developer; flaw remediation
+ procedures describe the developer's role is such
+ communication.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the flaw remediation procedures documentation;
+
+
+ flaw remediation guidance documentation.
+
+
+
+
+ The developer shall document and provide flaw remediation procedures
+ addressed to TOE developers.
+
+
+ The developer shall establish a procedure for accepting and
+ acting upon all reports of security flaws and requests for
+ corrections to those flaws.
+
+
+ The developer shall provide flaw remediation guidance
+ addressed to TOE users.
+
+
+ The flaw remediation procedures documentation shall describe
+ the procedures used to track all reported security flaws in
+ each release of the TOE.
+
+
+ The flaw remediation procedures shall require that a
+ description of the nature and effect of each security flaw
+ be provided, as well as the status of finding a correction
+ to that flaw.
+
+
+ The flaw remediation procedures shall require that
+ corrective actions be identified for each of the security
+ flaws.
+
+
+ The flaw remediation procedures documentation shall describe
+ the methods used to provide flaw information, corrections
+ and guidance on corrective actions to TOE users.
+
+
+ The flaw remediation procedures shall describe a means by
+ which the developer receives from TOE users reports and
+ enquiries of suspected security flaws in the TOE.
+
+
+ The flaw remediation procedures shall include a procedure
+ requiring timely response and the automatic distribution of
+ security flaw reports and the associated corrections to
+ registered users who might be affected by the security flaw.
+
+
+ The procedures for processing reported security flaws shall
+ ensure that any reported flaws are remediated and the
+ remediation procedures issued to TOE users.
+
+
+ The procedures for processing reported security flaws shall
+ provide safeguards that any corrections to these security
+ flaws do not introduce any new flaws.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users report to the developer any suspected
+ security flaws in the TOE.
+
+
+ The flaw remediation guidance shall describe a means by
+ which TOE users may register with the developer, to be
+ eligible to receive security flaw reports and corrections.
+
+
+ The flaw remediation guidance shall identify the specific
+ points of contact for all reports and enquiries about
+ security issues involving the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ the procedures used to track all reported security flaws
+ in each release of the TOE.
+
+ The procedures describe the actions that are taken by
+ the developer from the time each suspected security flaw
+ is reported to the time that it is resolved. This
+ includes the flaw's entire time frame, from initial
+ detection through ascertaining that the flaw is a
+ security flaw, to resolution of the security
+ flaw.
+
+ If a flaw is discovered not to be security-relevant,
+ there is no need (for the purposes of the requirements) for the flaw
+ remediation procedures to track it further; only that
+ there be an explanation of why the flaw is not
+ security-relevant.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would produce a description of each security
+ flaw in terms of its nature and effects.
+
+ The procedures identify the actions that are taken by
+ the developer to describe the nature and effects of each
+ security flaw in sufficient detail to be able to
+ reproduce it. The description of the nature of a
+ security flaw addresses whether it is an error in the
+ documentation, a flaw in the design of the TSF, a flaw
+ in the implementation of the TSF, etc. The description
+ of the security flaw's effects identifies the portions
+ of the TSF that are affected and how those portions are
+ affected. For example, a security flaw in the
+ implementation might be found that affects the
+ identification and authentication enforced by the TSF by
+ permitting authentication with the password
+ ``BACKDOOR''.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the status of finding a
+ correction to each security flaw.
+
+ The flaw remediation procedures identify the different
+ stages of security flaws. This differentiation includes
+ at least: suspected security flaws that have been
+ reported, suspected security flaws that have been
+ confirmed to be security flaws, and security flaws whose
+ solutions have been implemented. It is permissible that
+ additional stages (e.g. flaws that have been reported
+ but not yet investigated, flaws that are under
+ investigation, security flaws for which a solution has
+ been found but not yet implemented) be included.
+
+
+
+
+ The evaluator shall check the flaw remediation
+ procedures to determine that the application of these
+ procedures would identify the corrective action for each
+ security flaw.
+
+ Corrective action may consist of a
+ repair to the hardware, firmware, or software portions
+ of the TOE, a modification of TOE guidance, or
+ both. Corrective action that constitutes modifications
+ to TOE guidance (e.g. details of procedural measures to
+ be taken to obviate the security flaw) includes both
+ those measures serving as only an interim solution
+ (until the repair is issued) as well as those serving as
+ a permanent solution (where it is determined that the
+ procedural measure is the best solution).
+
+ If the source of the security flaw is a documentation
+ error, the corrective action consists of an update of
+ the affected TOE guidance. If the corrective action is a
+ procedural measure, this measure will include an update
+ made to the affected TOE guidance to reflect these
+ corrective procedures.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures documentation to determine that it describes
+ a means of providing the TOE users with the necessary
+ information on each security flaw.
+
+ The necessary information about each
+ security flaw consists of its description (not
+ necessarily at the same level of detail as that provided
+ as part of work unit ), the prescribed corrective action,
+ and any associated guidance on implementing the
+ correction.
+
+ TOE users may be provided with such information,
+ correction, and documentation updates in any of several
+ ways, such as their posting to a website, their being
+ sent to TOE users, or arrangements made for the
+ developer to install the correction. In cases where the
+ means of providing this information requires action to
+ be initiated by the TOE user, the evaluator examines any
+ TOE guidance to ensure that it contains instructions for
+ retrieving the information.
+
+ The only metric for assessing the adequacy of the method
+ used for providing the information, corrections and
+ guidance is that there be a reasonable expectation that
+ TOE users can obtain or receive it. For example,
+ consider the method of dissemination where the requisite
+ data is posted to a website for one month, and the TOE
+ users know that this will happen and when this will
+ happen. This may not be especially reasonable or
+ effective (as, say, a permanent posting to the website),
+ yet it is feasible that the TOE user could obtain the
+ necessary information. On the other hand, if the
+ information were posted to the website for only one
+ hour, yet TOE users had no way of knowing this or when
+ it would be posted, it is infeasible that they would
+ ever get the necessary information.
+
+ For TOE users who register with the developer (see work
+ unit ), the
+ passive availability of this information is not
+ sufficient. Developers must actively send the
+ information (or a notification of its availability) to
+ registered TOE users.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a means for the developer to
+ receive from TOE user reports of suspected security
+ flaws or requests for corrections to such flaws.
+
+ The procedures ensure that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws. This
+ means of contact may be part of a more general contact
+ facility for reporting non-security related
+ problems.
+
+ The use of these procedures is not restricted to TOE
+ users; however, only the TOE users are actively supplied
+ with the details of these procedures. Others who might
+ have access to or familiarity with the TOE can use the
+ same procedures to submit reports to the developer, who
+ is then expected to process them. Any means of
+ submitting reports to the developer, other than those
+ identified by the developer, are beyond the scope of
+ this work unit; reports generated by other means need
+ not be addressed.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in a timely means of providing
+ the registered TOE users who might be affected with
+ reports about, and associated corrections to, each
+ security flaw.
+
+ The issue of timeliness applies to the issuance of both
+ security flaw reports and the associated
+ corrections. However, these need not be issued at the
+ same time. It is recognised that flaw reports should be
+ generated and issued as soon as an interim solution is
+ found, even if that solution is as drastic as turn off
+ the TOE. Likewise, when a more permanent (and less
+ drastic) solution is found, it should be issued without
+ undue delay.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done in a timely manner.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in automatic distribution of the
+ reports and associated corrections to the registered TOE
+ users who might be affected.
+
+ Automatic distribution does not mean
+ that human interaction with the distribution method is
+ not permitted. In fact, the distribution method could
+ consist entirely of manual procedures, perhaps through a
+ closely monitored procedure with prescribed escalation
+ upon the lack of issue of reports or corrections.
+
+ It is unnecessary to restrict the recipients of the
+ reports and associated corrections to only those TOE
+ users who might be affected by the security flaw; it is
+ permissible that all TOE users be given such reports and
+ corrections for all security flaws, provided such is
+ done automatically.
+
+
+
+
+ The evaluator shall examine the flaw remediation procedures to
+ determine that the application of these procedures would help to
+ ensure that every reported flaw is corrected.
+
+ The flaw remediation procedures cover not only those
+ security flaws discovered and reported by developer
+ personnel, but also those reported by TOE users. The
+ procedures are sufficiently detailed so that they
+ describe how it is ensured that each reported security
+ flaw is remediated. The procedures contain reasonable
+ steps that show progress leading to the eventual,
+ inevitable resolution.
+
+ The procedures describe the process that is taken from
+ the point at which the suspected security flaw is
+ determined to be a security flaw to the point at which
+ it is resolved.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would help to ensure that the TOE users are
+ issued remediation procedures for each security
+ flaw.
+ The procedures describe the process that is taken
+ from the point at which a security flaw is resolved to
+ the point at which the remediation procedures are
+ provided. The procedures for delivering remediation
+ procedures should be consistent with the security
+ objectives; they need not necessarily be identical to
+ the procedures used for delivering the TOE, as
+ documented to meet , if
+ included in the assurance requirements. For example, if
+ the hardware portion of a TOE were originally delivered
+ by bonded courier, updates to hardware resulting from
+ flaw remediation would likewise be expected to be
+ distributed by bonded courier. Updates unrelated to flaw
+ remediation would follow the procedures set forth in the
+ documentation meeting the requirements.
+
+
+
+ The evaluator shall examine the flaw remediation
+ procedures to determine that the application of these
+ procedures would result in safeguards that the potential
+ correction contains no adverse effects.
+
+ Through analysis, testing, or a combination of the two,
+ the developer may reduce the likelihood that adverse
+ effects will be introduced when a security flaw is
+ corrected. The evaluator assesses whether the procedures
+ provide detail in how the necessary mix of analysis and
+ testing actions is to be determined for a given
+ correction.
+
+ The evaluator also determines that, for instances where
+ the source of the security flaw is a documentation
+ problem, the procedures include the means of
+ safeguarding against the introduction of contradictions
+ with other documentation.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that the application of these
+ procedures would result in a means for the TOE user to
+ provide reports of suspected security flaws or requests
+ for corrections to such flaws.
+
+ The guidance ensures that TOE users have a means by
+ which they can communicate with the TOE developer. By
+ having a means of contact with the developer, the user
+ can report security flaws, enquire about the status of
+ security flaws, or request corrections to flaws.
+
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it describes a means of
+ enabling the TOE users to register with the
+ developer.
+
+ Enabling the TOE users to register with the
+ developer simply means having a way for each
+ TOE user to provide the developer with a point of
+ contact; this point of contact is to be used to
+ provide the TOE user with information related to
+ security flaws that might affect that TOE user, along
+ with any corrections to the security flaw. Registering
+ the TOE user may be accomplished as part of the
+ standard procedures that TOE users undergo to identify
+ themselves to the developer, for the purposes of
+ registering a software licence, or for obtaining
+ update and other useful information.
+
+ There need not be one registered TOE user per
+ installation of the TOE; it would be sufficient if there
+ were one registered TOE user for an organisation. For
+ example, a corporate TOE user might have a centralised
+ acquisition office for all of its sites. In this case,
+ the acquisition office would be a sufficient point of
+ contact for all of that TOE user's sites, so that all of
+ the TOE user's installations of the TOE have a
+ registered point of contact.
+
+ In either case, it must be possible to associate each
+ TOE that is delivered with an organisation in order to
+ ensure that there is a registered user for each TOE. For
+ organisations that have many different addresses, this
+ assures that there will be no user who is erroneously
+ presumed to be covered by a registered TOE user.
+ It should be noted that TOE users need not
+ register; they must only be provided with a means of
+ doing so. However, users who choose to register must be
+ directly sent the information (or a notification of its
+ availability).
+
+
+
+ The evaluator shall examine the flaw remediation
+ guidance to determine that it identifies specific points
+ of contact for user reports and enquiries about security
+ issues involving the TOE.
+
+ The guidance includes a means whereby registered TOE
+ users can interact with the developer to report
+ discovered security flaws in the TOE or to make
+ enquiries regarding discovered security flaws in the
+ TOE.
+
+
+
+
+
+
+
+ Poorly controlled development and maintenance of the TOE can
+ result in a TOE that does not meet all of its
+ SFRs. Therefore, it is important that a model for the
+ development and maintenance of a TOE be established as early
+ as possible in the TOE's life-cycle.
+
+ Using a model for the development and maintenance of a TOE
+ does not guarantee that the TOE meets all of its SFRs. It is
+ possible that the model chosen will be insufficient or
+ inadequate and therefore no benefits in the quality of the
+ TOE can be observed. Using a life-cycle model that has been
+ approved by a group of experts (e.g. academic experts,
+ standards bodies) improves the chances that the development
+ and maintenance models will contribute to the TOE meeting
+ its SFRs. The use of a life-cycle model including some
+ quantitative valuation adds further assurance in the overall
+ quality of the TOE development process.
+
+
+
+ Life-cycle definition establishes that the engineering
+ practises used by a developer to produce the TOE include the
+ considerations and activities identified in the development
+ process and operational support requirements. Confidence in
+ the correspondence between the requirements and the TOE is
+ greater when quality control and the production of evidence
+ are done on a regular basis as an integral part of the
+ development process and operational support activities. It
+ is not the intent of this component to dictate any specific
+ development process.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements for measurability of the life-cycle
+ model, and for compliance with that model.
+
+
+
+ A life-cycle model encompasses the procedures, tools and
+ techniques used to develop and maintain the TOE. Aspects of
+ the process that may be covered by such a model include
+ design methods, review procedures, project management
+ controls, change control procedures, test methods and
+ acceptance procedures. An effective life-cycle model will
+ address these aspects of the development and maintenance
+ process within an overall management structure that assigns
+ responsibilities and monitors progress.
+
+ There are different types of acceptance situations that are
+ dealt with at different locations in the criteria:
+ acceptance of parts delivered by subcontractors
+ (``integration'') should be treated in this family , acceptance subsequent to
+ internal transportations in , acceptance of parts into the CM system in
+ , and acceptance of the
+ delivered TOE by the consumer in . The first three types may overlap.
+
+ Although life-cycle definition deals with the maintenance of
+ the TOE and hence with aspects becoming relevant after the
+ completion of the evaluation, its evaluation adds assurance
+ through an analysis of the life-cycle information for the
+ TOE provided at the time of the evaluation.
+
+ A life-cycle model provides for the necessary control over
+ the development and maintenance of the TOE, if the model
+ enables sufficient minimisation of the danger that the TOE
+ will not meet its security requirement.
+
+ A measurable life-cycle model is a model using some
+ quantitative valuation (arithmetic parameters and/or
+ metrics) of the managed product in order to measure
+ development properties of the product. Typical metrics are
+ source code complexity metrics, defect density (errors per
+ size of code) or mean time to failure. For the security
+ evaluation all those metrics are of relevance, which are
+ used to increase quality by decreasing the probability of
+ faults and thereby in turn increasing assurance in the
+ security of the TOE.
+
+ One should take into account that there exist standardised
+ life cycle models on the one hand (like the waterfall model)
+ and standardised metrics on the other hand (like error
+ density), which may be combined. The CC does not require the
+ life cycle to follow exactly one standard defining both
+ aspects.
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented model of the
+ TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process.
+
+ The description of the life-cycle model should include:
+
+
+ information on the life-cycle phases of the TOE and
+ the boundaries between the subsequent phases;
+
+
+ information on the procedures, tools and techniques
+ used by the developer (e.g. for design, coding,
+ testing, bug-fixing);
+
+
+ overall management structure governing the
+ application of the procedures (e.g. an
+ identification and description of the individual
+ responsibilities for each of the procedures required
+ by the development and maintenance process covered
+ by the life-cycle model);
+
+
+ information on which parts of the TOE are delivered
+ by subcontractors, if subcontractors are involved.
+
+
+
+ does not require the
+ model used to conform to any standard life-cycle
+ model.
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine
+ whether the developer has used a documented and measurable
+ model of the TOE life-cycle.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the life-cycle definition documentation;
+
+
+ information about the standard used;
+
+
+ the life-cycle output documentation.
+
+
+
+
+ The developer shall establish a life-cycle model to be used
+ in the development and maintenance of the TOE, that is based
+ on a measurable life-cycle model.
+
+
+ The developer shall provide life-cycle definition
+ documentation.
+
+
+ The developer shall measure the TOE development using the
+ measurable life-cycle model.
+
+
+ The developer shall provide life-cycle output documentation.
+
+
+ The life-cycle definition documentation shall describe the
+ model used to develop and maintain the TOE, including the
+ details of its arithmetic parameters and/or metrics used to
+ measure the quality of the TOE and/or its development.
+
+
+ The life-cycle model shall provide for the necessary control
+ over the development and maintenance of the TOE.
+
+
+ The life-cycle output documentation shall provide the
+ results of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the documented description
+ of the life-cycle model used to determine that it covers
+ the development and maintenance process, including the
+ details of its arithmetic parameters and/or metrics used
+ to measure the TOE development.
+
+ The description of the life-cycle model includes:
+
+ information on the life-cycle phases of the TOE and the
+ boundaries between the subsequent phases;
+
+ information on the procedures, tools and techniques used by
+ the developer (e.g. for design, coding, testing,
+ bug-fixing);
+
+ overall management structure governing the application of
+ the procedures (e.g. an identification and description of
+ the individual responsibilities for each of the procedures
+ required by the development and maintenance process covered
+ by the life-cycle model);
+
+ information on which parts of the TOE are delivered by
+ subcontractors, if subcontractors are involved;
+
+ information on the parameters/metrics that are used to
+ measure the TOE development. Metrics standards typically
+ include guides for measuring and producing reliable products
+ and cover the aspects reliability, quality, performance,
+ complexity and cost. For the evaluation all those metrics
+ are of relevance, which are used to increase quality by
+ decreasing the probability of faults and thereby in turn
+ increase assurance in the security of the TOE.
+
+
+
+
+
+ The evaluator shall examine the life-cycle model to
+ determine that use of the procedures, tools and
+ techniques described by the life-cycle model will make
+ the necessary positive contribution to the development
+ and maintenance of the TOE.
+
+ The information provided in the life-cycle model gives
+ the evaluator assurance that the development and
+ maintenance procedures adopted would minimise the
+ likelihood of security flaws. For example, if the
+ life-cycle model described the review process, but did
+ not make provision for recording changes to components,
+ then the evaluator may be less confident that errors
+ will not be introduced into the TOE. The evaluator may
+ gain further assurance by comparing the description of
+ the model against an understanding of the development
+ process gleaned from performing other evaluator actions
+ relating to the TOE development (e.g. those covered
+ under the ).
+ Identified deficiencies in the life-cycle model will be
+ of concern if they might reasonably be expected to give
+ rise to the introduction of flaws into the TOE, either
+ accidentally or deliberately.
+
+ The CC does not mandate any particular development
+ approach, and each should be judged on merit. For
+ example, spiral, rapid-prototyping and waterfall
+ approaches to design can all be used to produce a
+ quality TOE if applied in a controlled
+ environment.
+
+ For the metrics/measurements used in the life-cycle
+ model, evidence has to be provided that shows how those
+ metrics/measurements usefully contribute to the
+ minimisation of the likelihood of flaws. This can be
+ viewed as the overall goal for measurement in an context. As a consequence the
+ metrics/measurements have to be selected based on their
+ capability to achieve that overall goal or contribute to
+ that. In the first place a metric/measure is suitable
+ with respect to if a
+ correlation between the metric/measure and the number of
+ flaws can be stated with a certain degree of
+ reliability. But also a metric/measure useful for
+ management purposes as for planning and monitoring the
+ TOE development are helpful since badly managed projects
+ are endangered to produce bad quality and to introduce
+ flaws.
+
+ It may be possible to use metrics for quality
+ improvement, for which this use is not obvious. For
+ example a metric to estimate the expected cost of a
+ product development may help quality, if the developer
+ can show that this is used to provide an adequate budget
+ for development projects and that this helps to avoid
+ quality problems arising from resource shortages.
+
+ It is not required that every single step in the life
+ cycle of the TOE is measurable. However the evaluator
+ should see from the description of the measures and
+ procedures that the metrics are appropriate to control
+ the overall quality of the TOE and to minimise possible
+ security flaws by this.
+
+
+
+
+ The evaluator shall examine the life-cycle output
+ documentation to determine that it provides the results
+ of the measurements of the TOE development using the
+ measurable life-cycle model.
+
+ The results of the measurements and the life-cycle
+ progress of the TOE should be in accordance with the
+ life-cycle model.
+
+ The output documentation not only includes numeric values of the
+ metrics but also documents actions taken as a result of the
+ measurements and in accordance with the model. For example there
+ may be a requirement that a certain design phase needs to be
+ repeated, if some error rates measured during testing are
+ outside of a defined threshold. In this case the documentation
+ should show that such action was taken, if indeed the thresholds
+ were not met.
+
+ If the evaluation is conducted in parallel with the
+ development of the TOE it may be possible that quality
+ measurements have not been used in the past. In this
+ case the evaluator should use the documentation of the
+ planned procedures in order to gain confidence that
+ corrective actions are defined if results of quality
+ measurements deviate from some threshold.
+
+
+
+
+
+
+
+ Tools and techniques is an aspect of selecting tools that
+ are used to develop, analyse and implement the TOE. It
+ includes requirements to prevent ill-defined, inconsistent
+ or incorrect development tools from being used to develop
+ the TOE. This includes, but is not limited to, programming
+ languages, documentation, implementation standards, and
+ other parts of the TOE such as supporting runtime
+ libraries.
+
+
+
+ Tools and techniques addresses the need to define the
+ development tools being used to analyse and implement the
+ TOE. It includes requirements concerning the development
+ tools and implementation dependent options of those
+ tools.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing requirements on the description and scope of the
+ implementation standards and the documentation of
+ implementation-dependent options.
+
+
+
+ There is a requirement for well-defined development
+ tools. These are tools that are clearly and completely
+ described. For example, programming languages and computer
+ aided design (CAD) systems that are based on a standard
+ published by standards bodies are considered to be
+ well-defined. Self-made tools would need further
+ investigation to clarify whether they are
+ well-defined.
+
+ The requirement in is
+ especially applicable to programming languages so as to
+ ensure that all statements in the source code have an
+ unambiguous meaning.
+
+ In and , implementation guidelines may be accepted
+ as an implementation standard if they have been approved by
+ some group of experts (e.g. academic experts, standards
+ bodies). Implementation standards are normally public, well
+ accepted and common practise in a specific industry, but
+ developer-specific implementation guidelines may also be
+ accepted as a standard; the emphasis is on the
+ expertise.
+ Tools and techniques distinguishes between the
+ implementation standards applied by the developer () and the implementation
+ standards for ``all parts of the TOE'' () which include third party software,
+ hardware, or firmware. The configuration list introduced in
+ requires that for each TSF
+ relevant configuration item to indicate if it has been
+ generated by the TOE developer or by third party
+ developers.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable
+ results.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the subset of the implementation representation.
+
+
+
+
+ The developer shall provide the documentation identifying each development tool being
+ used for the TOE.
+
+
+ The developer shall document and provide the selected
+ implementation-dependent options of each development tool.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tools is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has used well-defined development tools
+ (e.g. programming languages or computer-aided design (CAD)
+ systems) that yield consistent and predictable results,
+ and whether implementation standards have been
+ applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall provide the documentation identifying each development tool being
+ used for the TOE.
+
+
+ The developer shall document and provide the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe and provide the implementation standards
+ that are being applied by the developer.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is not required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, but only those parts
+ that are developed by the TOE developer himself. The
+ evaluator may consult the configuration list required by
+ the to get the
+ information which parts are developed by the TOE
+ developer, and which by third party developers.
+
+ If the referenced implementation standards are not
+ applied for at least parts of the provided implementation representation,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer and his subcontractors have used
+ well-defined development tools (e.g. programming languages
+ or computer-aided design (CAD) systems) that yield
+ consistent and predictable results, and whether
+ implementation standards have been applied.
+
+
+
+ This work may be performed in parallel with the evaluation
+ activities under ,
+ specifically with regard to determining the use of
+ features in the tools that will affect the object code
+ (e.g. compilation options).
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the development tool documentation;
+
+
+ the implementation standards description;
+
+
+ the provided implementation representation of the TSF.
+
+
+
+
+ The developer shall provide the documentation identifying each development tool being
+ used for the TOE.
+
+
+ The developer shall document and provide the selected
+ implementation-dependent options of each development tool.
+
+
+ The developer shall describe and provide the implementation standards
+ that are being applied by the developer and by any
+ third-party providers for all parts of the TOE.
+
+
+ Each development tool used for implementation shall be
+ well-defined.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all statements as well
+ as all conventions and directives used in the
+ implementation.
+
+
+ The documentation of each development tool shall
+ unambiguously define the meaning of all
+ implementation-dependent options.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the development tool
+ documentation provided to determine that each
+ development tool is well-defined.
+
+ For example, a well-defined language, compiler or CAD
+ system may be considered to be one that conforms to a
+ recognised standard, such as the ISO standards. A
+ well-defined language is one that has a clear and
+ complete description of its syntax, and a detailed
+ description of the semantics of each construct.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the documentation of each
+ development tool to determine that it unambiguously
+ defines the meaning of all statements as well as all
+ conventions and directives used in the
+ implementation.
+
+ The development tool documentation (e.g. programming
+ language specifications and user manuals) should cover
+ all statements used in the implementation representation
+ of the TOE, and for each such statement should provide a
+ clear and unambiguous definition of the purpose and
+ effect of that statement. This work may be performed in
+ parallel with the evaluator's examination of the
+ implementation representation performed during the sub-activity. The key test the
+ evaluator should apply is whether or not the
+ documentation is sufficiently clear for the evaluator to
+ be able to understand the implementation
+ representation. The documentation should not assume (for
+ example) that the reader is an expert in the programming
+ language used.
+
+ Reference to the use of a documented standard is an
+ acceptable approach to meet this requirement, provided
+ that the standard is available to the evaluator. Any
+ differences from the standard should be
+ documented.
+
+ The critical test is whether the evaluator can
+ understand the TOE source code when performing source
+ code analysis covered in the sub-activity. However, the following
+ checklist can additionally be used in searching for
+ problem areas:
+
+
+ In the language definition, phrases such as ``the
+ effect of this construct is undefined'' and terms
+ such as ``implementation dependent'' or
+ ``erroneous'' may indicate ill-defined areas.
+
+
+ Aliasing (allowing the same piece of memory to be
+ referenced in different ways) is a common source of
+ ambiguity problems.
+
+
+ Exception handling (e.g. what happens after memory
+ exhaustion or stack overflow) is often poorly
+ defined.
+
+
+
+ Most languages in common use, however well designed,
+ will have some problematic constructs. If the
+ implementation language is mostly well defined, but some
+ problematic constructs exist, then an inconclusive
+ verdict should be assigned, pending examination of the
+ source code.
+
+ The evaluator should verify, during the examination of
+ source code, that any use of the problematic constructs
+ does not introduce vulnerabilities. The evaluator should
+ also ensure that constructs precluded by the documented
+ standard are not used.
+
+ The development tool documentation should define all
+ conventions and directives used in the
+ implementation.
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+
+ The evaluator shall examine the development tool
+ documentation to determine that it unambiguously defines
+ the meaning of all implementation-dependent
+ options.
+
+ The documentation of software development tools should
+ include definitions of implementation-dependent options
+ that may affect the meaning of the executable code, and
+ those that are different from the standard language as
+ documented. Where source code is provided to the
+ evaluator, information should also be provided on
+ compilation and linking options used.
+
+ The documentation for hardware design and development
+ tools should describe the use of all options that affect
+ the output from the tools (e.g. detailed hardware
+ specifications, or actual hardware).
+
+ At this level, the documentation of development tools
+ used by third party contributors to the TOE has to be
+ included in the evaluator's examination.
+
+
+
+ The evaluator shall confirm that the implementation
+ standards have been applied.
+
+
+ The evaluator shall examine aspects of the
+ implementation process to determine that documented
+ implementation standards have been applied.
+
+ This work unit requires the evaluator to analyse the
+ provided implementation representation of the TOE to
+ determine whether the documented implementation
+ standards have been applied.
+
+ The evaluator should verify that constructs excluded by
+ the documented standard are not used.
+
+ Additionally, the evaluator should verify the
+ developer's procedures which ensure the application of
+ the defined standards within the design and
+ implementation process of the TOE. Therefore,
+ documentary evidence should be supplemented by visiting
+ the development environment. A visit to the development
+ environment will allow the evaluator to:
+
+
+ observe the application of defined standards;
+
+ examine documentary evidence of application of
+ procedures describing the use of defined
+ standards;
+
+ interview development staff to check awareness of
+ the application of defined standards and
+ procedures.
+
+ A development site visit is a useful means of gaining
+ confidence in the procedures being used. Any decision
+ not to make such a visit should be determined in
+ consultation with the evaluation authority.
+
+ The evaluator compares the provided implementation
+ representation with the description of the applied
+ implementation standards and verifies their use.
+ At this level it is required that the complete
+ provided implementation representation of the TSF is
+ based on implementation standards, including third party
+ contributions. This may require the evaluator to visit
+ the sites of contributors. The evaluator may consult the
+ configuration list required by the to see who has developed which part of
+ the TOE.
+
+ Note that parts of the TOE which are not TSF relevant do
+ not need to be examined.
+
+ This work unit may be performed in conjunction with the
+ evaluation activities under .
+
+
+
+
+
+
+
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more other PPs or on packages, that the PP is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ writing an ST or another PP.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+ This standard defines two assurance packages for PP evaluation as follows:
+ Low assurance PP evaluation package;(Standard) PP evaluation package.
+ The assurance components for these packages are defined by table
+ .
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an PP to demonstrate that
+ the PP is sound and internally consistent, and, if the PP is
+ based on one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of a PP. The
+ requirements and methodology for PP evaluation are identical
+ for each PP evaluation, regardless of the EAL (or other set of
+ assurance requirements) that is claimed in the PP. The
+ evaluation methodology in this Clause is based on the
+ requirements on the PP as specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The PP is the description of a TOE type. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating a PP is required to demonstrate that the PP is
+ sound and internally consistent, and, if the PP is based on
+ one or more PPs or packages, that the PP is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the PP to be suitable for use as the basis for
+ an ST or another PP.
+
+
+
+
+ While evaluating a PP that is based on one or more certified
+ PPs, it may be possible to re-use the fact that these PPs were
+ certified. The potential for re-use of the result of a certified
+ PP is greater if the PP under evaluation does not add threats,
+ OSPs, security objectives and/or security requirements to those
+ of the PP that conformance is being claimed to. If the PP under
+ evaluation contains much more than the certified PP, re-use may
+ not be useful at all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP that conformance is being
+ claimed to contains a set of security requirements, and these
+ were determined to be internally consistent during its
+ evaluation. If the PP under evaluation uses the exact same
+ requirements, the consistency analysis does not have to be
+ repeated during the PP evaluation. If the PP under evaluation
+ adds one or more requirements, or performs operations on these
+ requirements, the analysis will have to be repeated. However, it
+ may be possible to save work in this consistency analysis by
+ using the fact that the original requirements are internally
+ consistent. If the original requirements are internally
+ consistent, the evaluator only has to determine that:
+
+ the set of all new and/or changed requirements is internally
+ consistent, and
+
+ the set of all new and/or changed requirements is consistent
+ with the original requirements.
+
+ The evaluator notes in the ETR each case where analyses
+ are not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way.
+
+ Evaluation of the PP introduction is required to demonstrate
+ that the PP is correctly identified, and that the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The PP introduction describes the TOE in a narrative
+ way.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the PP is correctly identified, and whether the PP
+ reference and TOE overview are consistent with each
+ other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a PP introduction.
+
+
+ The PP introduction shall contain a PP reference and a TOE
+ overview.
+
+
+ The PP reference shall uniquely identify the PP.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware available to the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the PP introduction
+ contains a PP reference and a TOE overview.
+
+
+
+
+ The evaluator shall examine the PP reference to
+ determine that it uniquely identifies the PP.
+
+ The evaluator determines that the PP reference
+ identifies the PP itself, so that it may be easily
+ distinguished from other PPs, and that it also uniquely
+ identifies each version of the PP, e.g. by including a
+ version number and/or a date of publication.
+
+ The PP should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features expected of the TOE. The TOE overview should
+ enable consumers and potential TOE developers to quickly
+ determine whether the PP is of interest to them.
+
+ The evaluator determines that the overview is clear
+ enough for TOE developers and consumers, and sufficient
+ to give them a general understanding of the intended
+ usage and major security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware available to the TOE.
+
+ While some TOEs may run stand-alone, other TOEs (notably
+ software TOEs) need additional hardware, software or
+ firmware to operate. In this subclause of the PP, the PP
+ author lists all hardware, software, and/or firmware
+ that will be available for the TOE to run on.
+
+ This identification should be detailed enough for
+ potential consumers and TOE developers to determine
+ whether their TOE may operate with the listed hardware,
+ software and firmware.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs and other PPs are to claim conformance with the
+ PP.
+
+
+
+ Conformance claims describes how the Protection Profile
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the PP conforms to the CC, other PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP;
+
+
+ the PP(s) that the PP claims conformance to;
+
+
+ the package(s) that the PP claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The developer shall provide a conformance statement.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the PP claims
+ conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the PP to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the PP claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ PP to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance statement shall describe the conformance
+ required of any PPs/STs to the PP as strict-PP or
+ demonstrable-PP conformance.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the PP claims
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this PP. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the PP.
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the PP.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the PP claims conformance.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+ The evaluator determines that any referenced PPs
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the PP claims conformance.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the PP does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package, then the PP
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the PP
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The relation between the types may be simple: a firewall
+ PP claiming conformance to another firewall PP, or more
+ complex: a smart card PP claiming conformance to a number
+ of other PPs at the same time: a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the PP under evaluation does not claim conformance
+ with another PP, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If the PP to which conformance is being claimed does not
+ have a statement of security problem definition, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether
+
+
+ the threats in the PP under evaluation are a
+ superset of or identical to the threats in the PP to
+ which conformance is being claimed;
+
+
+ the OSPs in the PP under evaluation are a superset
+ of or identical to the OSPs in the PP to which
+ conformance is being claimed;
+
+
+ the assumptions in the PP claiming conformance are identical to the assumptions in the PP
+ to which conformance is being claimed, with two possible exceptions described
+ in the following two bullet points;
+
+ an assumption (or part of an assumption) from the PP to which conformance is claimed, can be omitted,
+ if all security objectives for the operational environment addressing this assumption (or part of an
+ assumption) are replaced by security objectives for the TOE;
+ an assumption can be added to the assumptions defined in the PP to which conformance is claimed,
+ if a justification is given, why the new assumption neither mitigates a threat (or a part of a threat)
+ meant to be addressed by security objectives for the TOE in the PP to which conformance is claimed,
+ nor fulfills an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the PP
+ to which conformance is claimed.
+ When examining a PP, which omits assumptions
+ from another PP to which conformance is claimed, or adds new assumptions, the evaluator shall carefully determine,
+ if the conditions given above are fulfilled.
+ The following discussion gives some motivation and examples for these cases:
+
+ Example for omitting an assumption: A PP to which conformance is claimed, may contain an assumption
+ stating that the operational environment prevents unauthorized modification or interception of data sent
+ to an external interface of the TOE. This may be the case if the TOE accepts data in clear text and without
+ integrity protection at this interface and is assumed to be located in a secure operational environment,
+ which will prevent attackers from accessing these data. The assumption will then be mapped in the PP,
+ to which conformance is claimed, to some objective for the operational environment stating that the data
+ interchanged at this interface are protected by adequate measures in the operational environment.
+ If a PP claiming this PP, defines a more secure TOE,
+ which has an additional security objective stating that the TOE itself protects these data, for example by
+ providing a secure channel for encryption and integrity protection of all data transferred via this interface,
+ the corresponding objective and assumption for the operational environment can be omitted from the PP claiming
+ conformance. This is also called re-assigning of the objective, since the objective is re-assigned
+ from the operational environment to the TOE. Note, that this TOE is still secure in an operational
+ environment fulfilling the omitted assumption and therefore still fulfills the PP to which conformance
+ is claimed.
+ Example for adding an assumption: In this example the PP to which conformance is claimed, is designed
+ to specify requirements for a TOE of type "Firewall" and the author of another PP wishes to claim conformance
+ to this PP for a TOE, which implements a firewall, but additionally provides
+ the functionality of a virtual private network (VPN) component. For the VPN functionality the TOE needs
+ cryptographic keys and these keys may also have to be handled securely by the operational environment
+ (e. g. if symmetric keys are used to secure the network connection and therefore need to be provided
+ in some secure way to other components in the network). In this case it is acceptable to add an assumption
+ that the cryptographic keys used by the VPN are handled securely by the operational environment.
+ This assumption does not address threats or OSPs of the PP to which conformance is claimed, and therefore
+ fulfills the conditions stated above.
+ Counterexample for adding an assumption: In a variant of the first example a PP to which conformance is
+ claimed, may already contain an objective for the TOE to provide a secure channel for one of its interfaces,
+ and this objective is mapped to a threat of unauthorized modification or reading of the data on this interface.
+ In this case it is clearly not allowed for another PP claiming this PP, to add an assumption for the operational
+ environment, which assumes that the operational
+ environment protects data on this interface against modification or unauthorized reading of the data.
+ This assumption would reduce a threat, which is meant to be addressed by the TOE. Therefore a TOE
+ fulfilling a PP with this added assumption would not automatically fulfill the PP
+ to which conformance is claimed, anymore and this addition is therefore not allowed.
+ Second counterexample for adding an assumption: In the example above of a TOE implementing a firewall it would
+ not be admissible to add a general assumption that the TOE is only connected to trusted devices, because this
+ would obviously remove essential threats relevant for a firewall (namely that there is untrusted IP traffic,
+ which needs to be filtered). Therefore this addition would not be allowed.
+
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ problem definition of the PP under evaluation is
+ equivalent or more restrictive than the statement of
+ security problem definition in the PP to which
+ conformance is being claimed.
+ For this, the conformance claim rationale needs to demonstrate
+ that the security problem definition in the PP claiming conformance is equivalent (or more restrictive) than the security
+ problem definition in the PP to which conformance is claimed. This means that:
+
+ all TOEs that would meet the security problem definition in the PP claiming conformance also meet the security problem
+ definition in the PP to which conformance is claimed. This can also be shown indirectly by demonstrating that every
+ event, which realizes a threat defined in the PP to which conformance is claimed, or violates an OSP defined in the PP
+ to which conformance is claimed, would also realize a threat stated in the PP claiming conformance or violate an OSP
+ defined in the PP claiming conformance.
+ Note that fulfilling an OSP stated in the PP claiming conformance may avert a threat stated in the PP to which
+ conformance is claimed, or that averting a threat stated in the PP claiming conformance may fulfill an OSP
+ stated in the PP to which conformance is claimed, so threats and OSPs can substitute each other;
+ all operational environments that would meet the security problem definition in the PP to which conformance
+ is claimed, would also meet the security problem definition in the PP claiming conformance (with one exception
+ in the next bullet);
+ besides a set of assumptions in the PP claiming conformance needed to demonstrate conformance to the SPD of the PP
+ to which conformance is claimed, an PP claiming conformance may specify further assumptions, but only if these
+ additional assumptions are independent of and do not affect the security problem definition as defined in the PP
+ to which conformance is claimed. More detailed, there are no assumptions in the PP claiming conformance that exclude
+ threats to the TOE that need to be countered by the TOE according to the PP to which conformance is claimed.
+ Similarly, there are no assumptions in the PP claiming conformance that realize aspects of an OSP stated in the PP
+ to which conformance is claimed, which are meant to be fulfilled by the TOE according to the PP to which conformance
+ is claimed.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PPs, with the statement of security
+ objectives in the PPs.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which conformance is being claimed, no
+ conformance claim rationale is required. Instead, the
+ evaluator determines whether:
+ The PP under evaluation contains all security
+ objectives for the TOE of the PP to which
+ conformance is being claimed. Note that it is
+ allowed for the PP under evaluation to have
+ additional security objectives for the TOE;
+ The security objectives for the operational environment in the PP claiming conformance are identical to the security objectives
+ for the operational environment in the PP to which conformance is being claimed, with two possible
+ exceptions described in the following two bullet points;
+
+ a security objective for the operational environment (or part of such security objective) from the PP
+ to which conformance is claimed, can be replaced by the same (part of the) security objective stated for the TOE;
+
+ a security objective for the operational environment can be added to the objectives defined in the PP
+ to which conformance is claimed, if a justification is given, why the new objective neither mitigates a threat
+ (or a part of a threat) meant to be addressed by security objectives for the TOE in the PP to which conformance
+ is claimed, nor fulfills an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in
+ the PP to which conformance is claimed.
+
+ When examining a PP claiming another PP which omits security objectives for the
+ operational environment from the PP to which conformance is claimed, or adds new security objectives for the
+ operational environment, the evaluator shall carefully determine, if the conditions given above are fulfilled.
+ The examples given for the case of assumptions in the preceding work unit are also valid here.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ objectives in the PP to which conformance is being
+ claimed.
+ For this the conformance claim rationale needs to demonstrate
+ that the security objectives in the PP claiming conformance are equivalent (or more restrictive) than the security
+ objectives in the PP to which conformance is claimed. This means that:
+
+ all TOEs that would meet the security objectives for the TOE in the PP claiming conformance also meet the
+ security objectives for the TOE in the PP to which conformance is claimed;
+ all operational environments that would meet the security objectives for the operational environment in the PP
+ to which conformance is claimed, would also meet the security objectives for the operational environment in the
+ PP claiming conformance (with one exception in the next bullet);
+ besides a set of security objectives for the operational environment in the PP claiming conformance, which
+ are used to demonstrate conformance to the set of security objectives defined in the PP to which conformance
+ is claimed, an PP claiming conformance may specify further security objectives for the operational environment,
+ but only if these security objectives neither affect the original set of security objectives for the TOE nor the
+ security objectives for the operational environment as defined in the PP to which conformance is claimed.
+
+
+
+
+ The evaluator shall examine the PP to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the PP does not claim conformance to another PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the PP
+ under evaluation is a superset of or identical to the
+ statement of security requirements in the PP to which
+ conformance is being claimed (for strict
+ conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the PP under evaluation is equivalent or
+ more restrictive than the statement of security
+ requirements in the PP to which conformance is being
+ claimed.
+ For:
+
+ SFRs: The conformance rationale in the PP claiming conformance shall demonstrate that the overall
+ set of requirements defined by the SFRs in the PP claiming conformance is equivalent (or more restrictive)
+ than the overall set of requirements defined by the SFRs in the PP to which conformance is claimed. This means
+ that all TOEs that would meet the requirements defined by the set of all SFRs in the PP claiming conformance
+ would also meet the requirements defined by the set of all SFRs in the PP to which conformance is claimed;
+ SARs: The PP claiming conformance shall contain all SARs in the PP to which conformance is claimed,
+ but may claim additional SARs or replace SARs by hierarchically stronger SARs. The completion of operations
+ in the PP claiming conformance must be consistent with that in the PP to which conformance is claimed; either
+ the same completion will be used in the PP claiming conformance as that in the PP to which conformance is
+ claimed or a completion that makes the SAR more restrictive (the rules of refinement apply).
+
+
+
+
+
+ The evaluator shall check that the PP conformance
+ statement states a claim of strict-PP or demonstrable-PP
+ conformance.
+
+
+
+
+
+
+
+ This part of the PP defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or its operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and OSPs only, the statement of threats need not be
+ present in the PP. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall examine that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and/or threats only, OSPs need not be present in the
+ PP. In this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition and that
+ the division of this problem between the TOE and its
+ operational environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat, the evaluator action
+ related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP, the evaluator action
+ related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ If no security objectives for the operational environment trace back to the assumption,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the PP
+ author. This family is used to determine that these extended
+ components are defined similarly to the existing CC Part 2
+ or CC Part 3 components.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the PP.
+
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the PP, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the PP defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+
+ a member of a new class defined in the PP.
+
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ PP, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the PP author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the PP does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations, the
+ evaluator determines that the extended functional component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the PP does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the PP does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the PP does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the PP does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the PP does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance to
+ this requirement.
+
+
+
+ The evaluator shall confirm that no extended component may
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component may
+ not be clearly expressed using existing
+ components.
+
+ If the PP does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the PP, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is, or whether the SFRs are derived from
+ security objectives for the TOE.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to a PP that the PP claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the PP claims to be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the PP.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the PP;
+
+
+ by reference to an individual component in a PP that
+ the PP claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the PP claims to
+ be conformant with;
+
+
+ by reproduction in the PP.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the PP to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the PP defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the PP writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ PP.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. This includes both completed operations and
+ uncompleted operations. Identification may be achieved
+ by typographical distinctions, or by explicit
+ identification in the surrounding text, or by any other
+ distinctive means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it justifies that the SFRs are suitable to
+ meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the TOE,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ If the SFRs that trace back to a security objective for
+ the TOE have any uncompleted assignments, or uncompleted
+ or restricted selections, the evaluator determines that
+ for every conceivable completion or combination of
+ completions of these operations, the security objective
+ is still met.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+ The evaluator is reminded that any explanation is
+ correct, as long as it is coherent and neither the SARs
+ nor the explanation have obvious inconsistencies with
+ the remainder of the PP.
+ An example of an obvious inconsistency between the
+ SARs and the remainder of the PP would be to have threat
+ agents that are very capable, but an SAR that does not protect against these
+ threat agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+ Evaluating a PP-Configuration is required to demonstrate that the PP-Configuration is
+ sound and consistent. These properties are necessary for the PP-Configuration to be
+ suitable for use as the basis for writing an ST or another PP or PP-Configuration.
+
+
+ The class ACE is defined for the evaluation of a PP-Configuration composed of one or
+ more PPs and one PP-Module.
+
+
+ This Clause should be used in conjunction with Annexes and
+ in CC Part 1, as these Annexes clarify the concepts here and provide many examples.
+
+
+ This standard does not define low assurance PP-Configuration evaluation package.
+ There is only one assurance package for PP-Configuration evaluation, equivalent to
+ Standard PP evaluation package.
+
+
+ Figure shows the families within this class, and the hierarchy of components within
+ the families.
+
+
+
+ The ACE class is based on APE.
+
+
+
+
+ All Base-PP(s) referenced in the PP-Module must be evaluated before the evaluation of a PP-Configuration.
+
+
+ One possibility for evaluating a PP-Configuration is to flatten all the components of the PP(s) and PP-Modules composing the PP-Configuration and evaluating the resulting PP as a standard PP.
+
+
+ Another possibility for evaluation of a PP-Configuration composed of several PP-Modules proceeds PP-Module by PP-Module. Considering a PP-Configuration composed of the Protection Profiles Pi and the PP-Modules Mj, evaluation of the PP-Configuration proceeds with the following steps, illustrated in Figure :
+
+ first evaluating independently all Protection Profiles Pi;
+ evaluating the PP-Configuration C1 composed of the PP-Module M1 with the Protection Profiles Pi;
+ evaluating the PP-Configuration Ci+1 composed of the PP-Module Mi+1 with the PP-Configuration Ci considered as a standard PP (cf. Section B.13 in CC Part 1);
+ iterating the step 3 for all the PP-Modules.
+
+
+
+ Steps 2 and 3 are themselves performed in two steps:
+
+ Evaluation of the PP-Module with its Base-PP(s) ()
+ Extension of the evaluation (consistency assessment) to the other elements of the PP-Configuration ()
+
+
+
+
+ The ACE evaluation methodology is based on APE's. The common parts are not duplicated in this document but referred to.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a narrative way.
+
+
+ The objective of this sub-activity is to determine whether the PP-Module is correctly identified, and whether the PP-Module reference and TOE overview are consistent with each other.
+
+
+
+
+
+ All content and presentation elements of APE_INT.1 hold with PP-Module instead of PP.
+
+
+
+
+ The objective of this sub-activity is to determine whether the PP-Module is correctly identified, and whether the Base-PP(s) and TOE overview are consistent with each other.
+
+
+
+ All actions of APE_INT.1.1E hold.
+
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+ the PP-Module;
+ its Base-PP(s)
+
+
+
+
+ The developer shall provide a PP-Module introduction.
+
+
+ The PP-Module introduction shall uniquely identify all the Base-PPs on which the PP-Module relies, including their logical structuring and relationship to the PP-Module according to CC Part 1, section B.14.3.2. The TOE overview shall identify the differences introduced by the PP-Module with respect to the TOE overview of its Base-PP(s).
+ The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
+
+ The evaluator shall check that the PP-Module introduction identifies the Base-PP(s) on which the PP-Module relies.
+ The evaluator shall check that the TOE overview identifies the differences introduced by the PP-Module with respect to the TOE overview of its Base-PP(s).
+ The objective of this family is to determine the validity of the conformance claim. Unlike standard Protection Profiles, a PP-Module cannot claim conformance to another PP or PP-Module, nor to CC part 3 or any SAR package.
+ The objective of this sub-activity is to determine the validity of various conformance claims. These describe how the PP-Module conforms to the CC Part 2 and SFR packages.
+ The evaluation evidence for this sub-activity is:
+ the PP-Module; the SFR package(s) that the PP claims conformance to. The developer shall provide a conformance claim. The conformance claim shall contain a CC conformance claim that identifies the version of the CC to which the PP-Module claims conformance. The CC conformance claim shall describe the conformance of the PP-Module to CC Part 2 as either CC Part 2 conformant or CC Part 2 extended. The conformance claim shall identify all security functional requirement packages to which the PP-Module claims conformance The CC conformance claim shall be consistent with the extended components definition.
+ The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
+
+ The evaluator shall check that the conformance claim contains a CC conformance claim that identifies the version of the CC to which the PP-Module claims conformance.
+ The evaluator determines that the CC conformance claim identifies the version of the CC that was used to develop this PP-Module. This should include the version number of the CC and, unless the International English version of the CC was used, the language of the version of the CC that was used.
+ The evaluator shall check that the CC conformance claim states a claim of either CC Part 2 conformant or CC Part 2 extended for the PP-Module.
+ The evaluator shall check that the conformance claim contains a package claim that identifies all security functional requirement packages to which the PP-Module claims conformance.
+ If the PP-Module does not claim conformance to a security functional requirement package, this work unit is not applicable and therefore considered to be satisfied.
+ The evaluator determines that any referenced security functional requirement packages are unambiguously identified (e.g. by title and version number, or by the identification included in the introduction of that security functional requirement package).
+ The evaluator is reminded that claims of partial conformance to a security functional requirement package are not permitted.
+ The evaluator shall examine the CC conformance claim for CC Part 2 to determine that it is consistent with the extended components definition.
+ If the CC conformance claim contains CC Part 2 conformant, the evaluator determines that the extended components definition does not define functional components.
+ If the CC conformance claim contains CC Part 2 extended, the evaluator determines that the extended components definition defines at least one extended functional component.All content and presentation elements of APE_SPD.1 hold.All actions of APE_SPD.1.1E hold.All content and presentation elements of APE_OBJ.2 hold.All actions of APE_OBJ.2.1E hold.
+ Extended security functional requirements are requirements that are not based on components from CC Part 2, but are based on extended components: components defined by the PP-Module author.
+ Evaluation of the definition of extended functional components is necessary to determine that they are clear and unambiguous, and that they are necessary, i.e. they may not be clearly expressed using existing CC Part 2 components.All actions of APE_ECD.1.1E hold. The developer shall provide a statement of security functional requirements. The developer shall provide an extended functional components definition. The statement of security functional requirements shall identify all extended security functional requirements. The extended functional components definition shall define an extended functional component for each extended security functional requirement. The extended functional components definition shall describe how each extended functional component is related to the existing CC Part 2 components, families, and classes. The extended functional components definition shall use the existing CC Part 2 components, families, classes, and methodology as a model for presentation. The extended functional components shall consist of measurable and objective elements such that conformance or nonconformance to these elements can be demonstrated.
+ The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
+
+ The evaluator shall confirm that no extended functional component may be clearly expressed using existing components.
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined description of the expected security behaviour of the TOE.
+
+
+ Evaluation of the security functional requirements is required to ensure that they are clear, unambiguous and well-defined.
+
+
+
+
+
+
+
+ All actions of APE_REQ.2.1E hold without considering the SAR part which is empty in PP-Modules.
+
+
+ The developer shall provide a statement of security functional requirements.The developer shall provide a security requirements rationale.The statement of security requirements shall describe the SFRs that hold on the TOE.All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs shall be defined.The statement of security functional requirements shall identify all operations on the security functional requirements.All operations shall be performed correctly.Each dependency of the security functional requirements shall either be satisfied, or the security functional requirements rationale shall justify the dependency not being satisfied.The security functional requirements rationale shall trace each SFR back to the security objectives for the TOE.The security functional requirements rationale shall demonstrate that the SFRs meet all security objectives for the TOE.
+ The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
+
+ The objective of this family is to determine the validity of the PP-Module.
+ The objective of this sub-activity is to determine the consistency of the PP-Module regarding its Base-PP(s).
+ The evaluation evidence for this sub-activity is:
+ the PP-Module; its Base-PP(s).The developer shall provide a consistency rationale of the PP-Module with respect to its Base-PP(s) identified in the PP-Module introduction. If the PP-Module specifies alternate sets of Base-PPs, the developer shall provide as many consistency rationales as the number of alternate set of Base-PPs.The consistency rationale shall demonstrate that the TOE type of the PP-Module is consistent with the TOE type(s) in the Base-PPs identified in the PP-Module introduction.The consistency rationale shall demonstrate that the statement of the security problem definition is consistent with the statement of the security problem definition in the Base-PPs identified in the PP-Module introduction.The consistency rationale shall demonstrate that the statement of security objectives is consistent with the statement of security objectives in the Base-PPs identified in the PP-Module introduction.The consistency rationale shall demonstrate that the statement of security requirements is consistent with the statement of security requirements in the Base-PPs identified in the PP-Module introduction.
+ The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. If the PP-Module specifies alternate sets of Base-PPs, the evaluator shall perform this action for each consistency rationale with its related Base-PPs in the alternate set of Base-PPs of the PP-Module.
+
+ The evaluator shall examine the consistency rationale to determine that the TOE type of the PP-Module is consistent with all the TOE types of the Base-PP(s).
+ The relation between the types may be simple: a PP-Module may consider a TOE that provides additional security functionality regarding, or more complex: a TOE that provides a given security functionality in a specific way.
+ The evaluator shall examine the PP-Module consistency rationale to determine that it demonstrates that the statement of security problem definition of the PP-Module is consistent with the statements of security problem definition stated in its Base-PPs.
+ In particular, the evaluator examines the consistency rationale to determine that:
+ the statements of threats, assumptions and OSPs in the PP-Module do not contradict those from the Base-PP(s). the statement of assumptions in the PP-Module addresses aspects out of scope of the Base-PP, in which case, the addition of elements is allowed.
+ The evaluator shall examine the consistency rationale to determine that the statement of security objectives of the PP-Module is consistent with the statement of security objectives of its Base-PP(s).
+ In particular, the evaluator examines the consistency rationale to determine that:
+ the statements of the security objectives for the TOE and the security objectives for the operational environment in the PP-Module do not contradict those from the Base-PPs. the statement of the security objectives for the operational environment in the PP-Module addresses aspects out of scope of the Base-PP, in which case, the addition of elements is allowed.
+ The evaluator shall examine the consistency rationale to determine that the statement of security requirements of the PP-Module is consistent with the statement of security requirements of its Base-PPs, that is, the SFRs of the PP-Module either complete or refine the SFRs of the Base-PP(s) and that no contradiction arises from the whole set of SFRs of the PP-Module and the Base-PP(s).
+ The objective of this family is to determine the well-formedness and the consistency of the PP-Configuration.
+ The objective of this sub-activity is to determine whether the PP-Configuration and its components are correctly identified.
+ The objective of this sub-activity is also to determine the consistency of the PP-Configuration regarding the whole set of Protection Profiles and PP-Modules.
+ For the consistency analysis required by this activity, the application notes of the CEM, Section (), is applicable to determine which parts of the Base-PPs are to be re-evaluated during the evaluation of PP-Configuration
+ The evaluation evidence for this sub-activity is:
+ the PP-Configuration reference; the PP-Configuration components statement; the PP(s) and PP-Modules identified in the components statement.The developer shall provide the reference of the PP-Configuration.The developer shall provide a components statement.The developer shall provide a conformance statement and a conformance claim.The developer shall provide a SAR statement.The PP-Configuration reference shall uniquely identify the PP-Configuration.The components statements shall uniquely identify the Protection Profiles and the PP-Modules that compose the PP-Configuration.The conformance statement shall specify the kind of conformity of the PP-Configuration, either strict or demonstrable. The conformance claim shall contain a CC conformance claim that identifies the version of the CC to which the PP-Configuration and its underlying Base-PP(s) and PP-Module claim conformance.The SAR statement shall specify the set of SAR or predefined EAL that applies to this PP-Configuration.The Base-PP(s) on which the PP-Modules relies shall belong the Protection Profiles identified in the components statement of the PP-Configuration.
+ The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
+
+ The evaluator shall examine the PP-Configuration reference to determine that it uniquely identifies the PP-Configuration.
+ The evaluator determines that the PP-Configuration reference identifies the PP-Configuration itself, so that it may be easily distinguished from other PPs, PP-Configurations and PP-Modules, and that it also uniquely identifies each version of the PP-Configuration, e.g. by including a version number and/or a date of publication.
+ The PP-Configuration should have some referencing system that is capable of supporting unique references (e.g. use of numbers, letters or dates).
+ The evaluator shall examine the PP-Configuration components statement to determine that it uniquely identifies the Protection Profiles and PP-Modules contained in the PP-Configuration.
+ The Protection Profiles should have been certified and available for use in security targets.
+ The evaluator shall examine the PP-Configuration conformance statement to determine that it specifies the kind of conformity required: strict or demonstrable.
+ The evaluator shall check that the conformance claim contains a CC conformance claim that identifies the version of the CC to which the PP-Configuration and its underlying Base-PP(s) and PP-Module claim conformance.
+ The evaluator shall examine the PP-Configuration conformance claim to determine the compatibility between all CC versions that are related to the PP-Configuration and its underlying Base-PP(s) and PP-Module.
+ If at least one of the Protection Profiles identified in the PP-Configuration components statement claims strict conformance, then the PP-Configuration conformance claim has to state strict conformance also. CC versions used in a PP-Configuration and its underlying Base-PP(s) and PP-Module have to be compatible. If compatibility is not obvious, guidance from the certification scheme should be asked.
+ The evaluator shall examine the PP-Configuration SAR statement to determine that it specifies a well-formed package of SAR. The SAR package can be build in with components from CC Part 3 or can refer to a specific SAR package stated in one of the Protection Profiles composing the PP-Configuration.
+ If the set of SAR comes from CC Part 3 then the evaluator shall check that it is well-formed: it is closed by dependencies or the SAR statements provide a sound discarding rationale.
+ The evaluator shall check that the set of SAR of the PP-Configuration is consistent with respect to the SARs of each of the Protection Profiles contained in the PP-Configuration: for any SAR component in each of the Protection Profile, the PP-Configuration provides either the same component or a higher component in the family hierarchy. If the SAR component in the Protection Profile is a refinement of a standard component, then the correspondent SAR component in the PP-Configuration has to include these refinements. If two Protection Profiles refine the same SAR component, the evaluator shall check that the refinements are not contradictory and that the corresponding SAR component in the PP-Configuration meets both.
+ The evaluator shall check that the Base-PP(s) of the PP-Module are included in the set of PP(s) selected for the PP-Configuration.
+ The evaluator shall check that the PP-Configuration made up of all the Protection Profiles and PP-Modules identified in the components statement of the PP-Configuration is consistent.
+
+ The evaluator shall check that the PP-Configuration made up of all the Protection Profiles and PP-Modules identified in the components statement of the PP-Configuration is consistent. That is, the evaluator shall check that no contradiction arises from the whole set of Protection Profiles and PP-Modules included in the PP-Configuration.
+ The evaluator can organise this work in many ways; the actual organisation may depend on the will to derive evaluation results for more than one PP-Configuration at a time.
+ For instance, the evaluator can process in two steps as follows:
+ Assess the consistency of the set of Protection Profiles composing the PP-Configuration, Then proceed with the assessment of the PP-Configuration consistency incrementally, by adding one PP-Module at a time.
+ An alternative is to proceed incrementally but mixing PPs and PP-Modules or to flatten the definition of the PP-Configuration
+ (cf. Annex in CC Part 1) and to assess the consistency of the whole set of elements.
+ Any incremental consistency analysis step where C is a subset of the PP-Configuration and X is a PP or a PP-Module that has to be added to C consists in:
+ assessing that the SPD, the objectives and the SFRs of X do not contradict the statements in C; the assumptions and objectives for the environment in X either are the same as in C or address security aspects that are out of the scope of C.
+ Note that if X is a PP-Module, C contains all its Base-PP(s) and has succeed for X, then the consistency analysis step has to be performed with respect to the components of C different from these Base-PP(s) only.
+
+
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ Assurance class defines
+ requirements for the evaluation of an ST, to demonstrate that
+ the ST is sound and internally consistent, and, if the ST is
+ based on one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs and packages.
+
+
+
+ This Clause describes the evaluation of an ST. The ST
+ evaluation should be started prior to any TOE evaluation
+ sub-activities since the ST provides the basis and context to
+ perform these sub-activities. The evaluation methodology in
+ this subclause is based on the requirements on the ST as
+ specified in CC Part 3 class .
+
+ This Clause should be used in conjunction with Annexes , and
+ in CC
+ Part 1, as these Annexes clarify the concepts here and provide
+ many examples.
+
+
+
+ The ST describes the security features of a TOE. As such it is
+ expected to identify the security requirements that enforce
+ the defined OSPs and counter the defined threats under the
+ defined assumptions.
+
+ Evaluating an ST is required to demonstrate that the ST is
+ sound and internally consistent, and, if the ST is based on
+ one or more PPs or packages, that the ST is a correct
+ instantiation of these PPs or packages. These properties are
+ necessary for the ST to be suitable for use as the basis for a
+ TOE evaluation.
+
+
+
+
+ While evaluating an ST that is based on one or more
+ certified PPs, it may be possible to re-use the fact that
+ these PPs were certified. The potential for re-use of the
+ result of a certified PP is greater if the ST does not add
+ threats, OSPs, assumptions, security objectives and/or
+ security requirements to those of the PP. If the ST
+ contains much more than the certified PP, re-use may not be
+ useful at all.
+
+ The evaluator is allowed to re-use the PP evaluation results
+ by doing certain analyses only partially or not at all if
+ these analyses or parts thereof were already done as part of
+ the PP evaluation. While doing this, the evaluator should
+ assume that the analyses in the PP were performed
+ correctly.
+
+ An example would be where the PP contains a set of security
+ requirements, and these were determined to be internally
+ consistent during the PP evaluation. If the ST uses the
+ exact same requirements, the consistency analysis does not
+ have to be repeated during the ST evaluation. If the ST adds
+ one or more requirements, or performs operations on these
+ requirements, the analysis will have to be
+ repeated. However, it may be possible to save work in this
+ consistency analysis by using the fact that the original
+ requirements are internally consistent. If the original
+ requirements are internally consistent, the evaluator only
+ has to determine that:
+
+
+ the set of all new and/or changed requirements is
+ internally consistent, and
+
+
+ the set of all new and/or changed requirements is
+ consistent with the original requirements.
+
+
+ The evaluator notes in the ETR each case where analyses are
+ not done or only partially done for this reason.
+
+
+
+
+
+ The objective of this family is to describe the TOE in a
+ narrative way on three levels of abstraction: TOE reference,
+ TOE overview and TOE description.
+
+ Evaluation of the ST introduction is required to demonstrate
+ that the ST and the TOE are correctly identified, that the
+ TOE is correctly described at three levels of abstraction
+ and that these three descriptions are consistent with each
+ other.
+
+
+
+ The ST introduction describes the TOE in a narrative way on
+ three levels of abstraction: TOE reference, TOE overview and
+ TOE description.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the ST and the TOE are correctly identified, whether the
+ TOE is correctly described in a narrative way at three
+ levels of abstraction (TOE reference, TOE overview and TOE
+ description), and whether these three descriptions are
+ consistent with each other.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide an ST introduction.
+
+
+ The ST introduction shall contain an ST reference, a TOE
+ reference, a TOE overview and a TOE description.
+
+
+ The ST reference shall uniquely identify the ST.
+
+
+ The TOE reference shall identify the TOE.
+
+
+ The TOE overview shall summarise the usage and major
+ security features of the TOE.
+
+
+ The TOE overview shall identify the TOE type.
+
+
+ The TOE overview shall identify any non-TOE
+ hardware/software/firmware required by the TOE.
+
+
+ The TOE description shall describe the physical scope of the
+ TOE.
+
+
+ The TOE description shall describe the logical scope of the
+ TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the ST introduction
+ contains an ST reference, a TOE reference, a TOE
+ overview and a TOE description.
+
+
+
+
+ The evaluator shall examine the ST reference to
+ determine that it uniquely identifies the ST.
+
+ The evaluator determines that the ST reference
+ identifies the ST itself, so that it may be easily
+ distinguished from other STs, and that it also uniquely
+ identifies each version of the ST, e.g. by including a
+ version number and/or a date of publication.
+
+ In evaluations where a CM system is provided, the
+ evaluator may validate the uniqueness of the reference
+ by checking the configuration list. In the other cases,
+ the ST should have some referencing system that is
+ capable of supporting unique references (e.g. use of
+ numbers, letters or dates).
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it identifies the TOE.
+
+ The evaluator determines that the TOE reference
+ identifies the TOE, so that it is clear to which TOE the
+ ST refers, and that it also identifies the version of
+ the TOE, e.g. by including a version/release/build
+ number, or a date of release.
+
+
+
+
+ The evaluator shall examine the TOE reference to
+ determine that it is not misleading.
+
+ If the TOE is related to one or more well-known
+ products, it is allowed to reflect this in the TOE
+ reference. However, this should not be used to mislead
+ consumers: situations where only a small part of a
+ product is evaluated, yet the TOE reference does not
+ reflect this, are not allowed.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it describes the usage and major security
+ features of the TOE.
+
+ The TOE overview should briefly (i.e. several
+ paragraphs) describe the usage and major security
+ features of the TOE. The TOE overview should enable
+ potential consumers to quickly determine whether the TOE
+ may be suitable for their security needs.
+
+ The TOE overview in an ST for a composed TOE should
+ describe the usage and major security feature of the
+ composed TOE, rather than those of the individual
+ component TOEs.
+
+ The evaluator determines that the overview is clear
+ enough for consumers, and sufficient to give them a
+ general understanding of the intended usage and major
+ security features of the TOE.
+
+
+
+
+ The evaluator shall check that the TOE overview
+ identifies the TOE type.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that the TOE type is not misleading.
+
+ There are situations where the general consumer would
+ expect certain functionality of the TOE because of its
+ TOE type. If this functionality is absent in the TOE,
+ the evaluator determines that the TOE overview
+ adequately discusses this absence.
+
+ There are also TOEs where the general consumer would
+ expect that the TOE should be able to operate in a
+ certain operational environment because of its TOE
+ type. If the TOE is unable to operate in such an
+ operational environment, the evaluator determines that
+ the TOE overview adequately discusses this.
+
+
+
+
+ The evaluator shall examine the TOE overview to
+ determine that it identifies any non-TOE
+ hardware/software/firmware required by the TOE.
+
+ While some TOEs are able to run stand-alone, other TOEs
+ (notably software TOEs) need additional hardware,
+ software or firmware to operate. If the TOE does not
+ require any hardware, software or firmware, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the TOE overview
+ identifies any additional hardware, software and
+ firmware needed by the TOE to operate. This
+ identification does not have to be exhaustive, but
+ detailed enough for potential consumers of the TOE to
+ determine whether their current hardware, software and
+ firmware support use of the TOE, and, if this is not the
+ case, which additional hardware, software and/or
+ firmware is needed.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the physical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description lists
+ the hardware, firmware, software and guidance parts that
+ constitute the TOE and describes them at a level of
+ detail that is sufficient to give the reader a general
+ understanding of those parts.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any hardware, firmware,
+ software or guidance part is part of the TOE or
+ not.
+
+
+
+
+ The evaluator shall examine the TOE description to
+ determine that it describes the logical scope of the
+ TOE.
+
+ The evaluator determines that the TOE description
+ discusses the logical security features offered by the
+ TOE at a level of detail that is sufficient to give the
+ reader a general understanding of those features.
+
+ The evaluator also determines that there is no possible
+ misunderstanding as to whether any logical security
+ feature is offered by the TOE or not.
+
+ An ST for a composed TOE may refer out to the
+ description of the logical scope of the component TOEs,
+ provided in the component TOE STs to provide the
+ majority of this description for the composed TOE.
+ However, the evaluator determines that the composed TOE
+ ST clearly discusses which features of the individual
+ components are not within the composed TOE, and
+ therefore not a feature of the composed TOE.
+
+
+
+ The evaluator shall confirm that the TOE reference, the TOE
+ overview, and the TOE description are consistent with each
+ other.
+
+
+ The evaluator shall examine the TOE reference, TOE
+ overview and TOE description to determine that they are
+ consistent with each other.
+
+
+
+
+
+
+
+ The objective of this family is to determine the validity of
+ the conformance claim. In addition, this family specifies
+ how STs are to claim conformance with the PP.
+
+
+
+ Conformance claims describes how the Security Target
+ conforms to CC Part 2 and CC Part 3, to Protection Profiles
+ and to packages.
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine the
+ validity of various conformance claims. These describe how
+ the ST and the TOE conform to the CC and how the ST
+ conforms to PPs and packages.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the PP(s) that the ST claims conformance to;
+
+
+ the package(s) that the ST claims conformance to.
+
+
+
+
+ The developer shall provide a conformance claim.
+
+
+ The developer shall provide a conformance claim rationale.
+
+
+ The conformance claim shall contain a CC conformance claim
+ that identifies the version of the CC to which the ST and
+ the TOE claim conformance.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 2 as either CC Part 2 conformant or CC
+ Part 2 extended.
+
+
+ The CC conformance claim shall describe the conformance of
+ the ST to CC Part 3 as either CC Part 3 conformant or CC
+ Part 3 extended.
+
+
+ The CC conformance claim shall be consistent with the
+ extended components definition.
+
+
+ The conformance claim shall identify all PPs and security
+ requirement packages to which the ST claims conformance.
+
+
+ The conformance claim shall describe any conformance of the
+ ST to a package as either package-conformant or
+ package-augmented.
+
+
+ The conformance claim rationale shall demonstrate that the
+ TOE type is consistent with the TOE type in the PPs for
+ which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of the security problem definition is consistent
+ with the statement of the security problem definition in the
+ PPs for which conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security objectives is consistent with the
+ statement of security objectives in the PPs for which
+ conformance is being claimed.
+
+
+ The conformance claim rationale shall demonstrate that the
+ statement of security requirements is consistent with the
+ statement of security requirements in the PPs for which
+ conformance is being claimed.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a CC conformance claim that identifies the
+ version of the CC to which the ST and the TOE claim
+ conformance.
+
+ The evaluator determines that the CC conformance claim
+ identifies the version of the CC that was used to
+ develop this ST. This should include the version number
+ of the CC and, unless the International English version
+ of the CC was used, the language of the version of the
+ CC that was used.
+
+ For a composed TOE, the evaluator will consider any
+ differences between the version of the CC claimed for a
+ component and the version of the CC claimed for the
+ composed TOE. If the versions differ the evaluator will
+ assess whether the differences between the versions will
+ lead to conflicting claims.
+
+ For instances where the CC conformance claims for the
+ base TOE and dependent TOE are for different major
+ releases of the CC (e.g. one component TOE conformance
+ claim is CC v2.x and the other component TOE conformance
+ claim is CC v3.x), the conformance claim for the
+ composed TOE will be the earlier release of the CC, as
+ the CC is developed with an aim to provide backwards
+ compatibility (although this may not be achieved in the
+ strictest sense, it is understood to be achieved in
+ principle).
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 2 conformant or CC Part
+ 2 extended for the ST.
+
+ For a composed TOE, the evaluator will consider whether
+ this claim is consistent not only with the CC Part 2,
+ but also with the claims of conformance to CC Part 2 by
+ each of the component TOEs. I.e. if one or more
+ component TOEs claims to be CC Part 2 extended, then the
+ composed TOE should also claim to be CC Part 2
+ extended.
+
+ The CC conformance claim for the composed TOE may be CC
+ Part 2 extended, even though the component TOEs are Part
+ 2 conformant, in the event that additional SFRs are
+ claimed for the base TOE (see composed TOE guidance for
+ )
+
+
+
+
+ The evaluator shall check that the CC conformance claim
+ states a claim of either CC Part 3 conformant or CC Part
+ 3 extended for the ST.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 2 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 2
+ conformant, the evaluator determines that the extended
+ components definition does not define functional
+ components.
+
+ If the CC conformance claim contains CC Part 2 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended functional
+ component.
+
+
+
+
+ The evaluator shall examine the CC conformance claim for
+ CC Part 3 to determine that it is consistent with the
+ extended components definition.
+
+ If the CC conformance claim contains CC Part 3
+ conformant, the evaluator determines that the extended
+ components definition does not define assurance
+ components.
+
+ If the CC conformance claim contains CC Part 3 extended,
+ the evaluator determines that the extended components
+ definition defines at least one extended assurance
+ component.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a PP claim that identifies all PPs for which
+ the ST claims conformance.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that any referenced PPs are
+ unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that PP).
+
+ The evaluator is reminded that claims of partial
+ conformance to a PP are not permitted. Therefore,
+ conformance to a PP requiring a composite solution may
+ be claimed in an ST for a composed TOE. Conformance to
+ such a PP would not have been possible during the
+ evaluation of the component TOEs, as these components
+ would not have satisfied the composed solution. This is
+ only possible in the instances where the ``composite'' PP
+ permits use of the composition evaluation approach (use
+ of components).
+
+ The ST for a composed TOE will identify the STs of the
+ component TOEs from which the composed ST is comprised.
+ The composed TOE is essentially claiming conformance to
+ the STs of the component TOEs.
+
+
+
+
+ The evaluator shall check that the conformance claim
+ contains a package claim that identifies all packages to
+ which the ST claims conformance.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that any referenced packages
+ are unambiguously identified (e.g. by title and version
+ number, or by the identification included in the
+ introduction of that package).
+
+ The evaluator determines that the component TOE STs from
+ which the composed TOE is derived are also unambiguously
+ identified.
+
+ The evaluator is reminded that claims of partial
+ conformance to a package are not permitted.
+
+
+
+
+ The evaluator shall check that, for each identified
+ package, the conformance claim states a claim of either
+ package-name conformant or package-name
+ augmented.
+
+ If the ST does not claim conformance to a package, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the package conformance claim contains package-name
+ conformant, the evaluator determines that:
+
+
+ If the package is an assurance package, then the ST
+ contains all SARs included in the package, but no
+ additional SARs.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, but no
+ additional SFRs.
+
+
+
+ If the package conformance claim contains package-name
+ augmented, the evaluator determines that:
+
+
+ If the package is an assurance package then the ST
+ contains all SARs included in the package, and at
+ least one additional SAR or at least one SAR that is
+ hierarchical to a SAR in the package.
+
+
+ If the package is a functional package, then the ST
+ contains all SFRs included in the package, and at
+ least one additional SFR or at least one SFR that is
+ hierarchical to a SFR in the package.
+
+
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the TOE type of the TOE is
+ consistent with all TOE types of the PPs.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ The relation between the types may be simple: a firewall
+ ST claiming conformance to a firewall PP, or more
+ complex: a smart card ST claiming conformance to a number
+ of PPs at the same time (a PP for the integrated
+ circuit, a PP for the smart card OS, and two PPs for two
+ applications on the smart card).
+
+ For a composed TOE, the evaluator will determine whether
+ the conformance claim rationale demonstrates that the
+ TOE types of the component TOEs are consistent with the
+ composed TOE type. This does not mean that both the
+ component and the composed TOE types have to be the
+ same, but rather that the component TOEs are suitable
+ for integration to provide the composed TOE. It should be made clear in the composed TOE ST which SFRs are only included as a result of composition, and were not examined as SFRs in the base and dependent TOE (e.g. EALx) evaluation.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that it demonstrates that the
+ statement of security problem definition is consistent,
+ as defined by the conformance statement of the PP, with
+ the statements of security problem definition stated in
+ the PPs to which conformance is being claimed.
+
+ If the ST does not claim conformance with a PP, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ If the PP does not have a statement of security problem
+ definition, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether:
+
+
+ the threats in the ST are a superset of or identical
+ to the threats in the PP to which conformance is
+ being claimed;
+
+
+ the OSPs in the ST are a superset of or identical to
+ the OSPs in the PP to which conformance is being
+ claimed;
+
+
+ the assumptions in the ST are identical to the assumptions in the PP to which conformance is being
+ claimed, with two possible exceptions described in the following two bullet points;
+
+ an assumption (or part of an assumption) from the PP can be omitted, if all security objectives for the
+ operational environment addressing this assumption (or part of an assumption) are replaced by
+ security objectives for the TOE;
+ an assumption can be added to the assumptions defined in the PP, if a rationale is given, why the new
+ assumption neither mitigates a threat (or a part of a threat) meant to be addressed by
+ security objectives for the TOE in the PP, nor fulfils an OSP (or part of an OSP) meant to be
+ addressed by security objectives for the TOE in the PP.
+ When examining an ST claiming a PP, which omits assumptions from the PP or adds new assumptions, the
+ evaluator shall carefully determine, if the conditions given above are fulfilled.
+ The following discussion gives some motivation and examples for these cases:
+
+ Example for omitting an assumption: A PP may contain an assumption stating that the operational
+ environment prevents unauthorised modification or interception of data sent to an external interface of
+ the TOE. This may be the case if the TOE accepts data in clear text and without integrity protection at
+ this interface and is assumed to be located in a secure operational environment, which will prevent
+ attackers from accessing these data. The assumption will then be mapped in the PP to some objective
+ for the operational environment stating that the data interchanged at this interface are protected by
+ adequate measures in the operational environment. If an ST claiming this PP defines a more secure
+ TOE, which has an additional security objective stating that the TOE itself protects these data, for
+ example by providing a secure channel for encryption and integrity protection of all data transferred via
+ this interface, the corresponding objective and assumption for the operational environment can be
+ omitted from the ST. This is also called re-assigning of the objective, since the objective is re-assigned
+ from the operational environment to the TOE. Note, that this TOE is still secure in an operational
+ environment fulfilling the omitted assumption and therefore still fulfils the PP.
+ Example for adding an assumption: In this example the PP is designed to specify requirements for a
+ TOE of type "Firewall" and an ST author wishes to claim this PP for a TOE, which implements a
+ firewall, but additionally provides the functionality of a virtual private network (VPN) component. For
+ the VPN functionality the TOE needs cryptographic keys and these keys may also have to be handled
+ securely by the operational environment (e. g. if symmetric keys are used to secure the network
+ connection and therefore need to be provided in some secure way to other components in the
+ network). In this case it is acceptable to add an assumption that the cryptographic keys used by the
+ VPN are handled securely by the operational environment. This assumption does not address threats or OSPs of the PP and
+ therefore fulfils the conditions stated above.
+ Counterexample for adding an assumption: In a variant of the first example a PP may already contain
+ an objective for the TOE to provide a secure channel for one of its interfaces, and this objective is
+ mapped to a threat of unauthorised modification or reading of the data on this interface. In this case it
+ is clearly not allowed for an ST claiming this PP to add an assumption for the operational environment,
+ which assumes that the operational environment protects data on this interface against modification or
+ unauthorised reading of the data. This assumption would reduce a threat, which is meant to be
+ addressed by the TOE. Therefore a TOE fulfilling an ST with this added assumption would not
+ automatically fulfil the PP any more and this addition is therefore not allowed.
+ Second counterexample for adding an assumption: In the example above of a TOE implementing a
+ firewall it would not be admissible to add a general assumption that the TOE is only connected to
+ trusted devices, because this would obviously remove essential threats relevant for a firewall (namely
+ that there is untrusted IP traffic, which needs to be filtered). Therefore this addition would not be
+ allowed.
+
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security problem definition of the ST is equivalent or
+ more restrictive than the statement of security problem
+ definition in the PP to which conformance is being
+ claimed.
+ For this, the conformance claim rationale needs to demonstrate that the security problem definition in
+ the ST is equivalent (or more restrictive) than the security problem definition in the PP. This means that:
+
+ all TOEs that would meet the security problem definition in the ST also meet the security problem
+ definition in the PP. This can also be shown indirectly by demonstrating that every event, which
+ realises a threat defined in the PP or violates an OSP defined in the PP, would also realise a threat
+ stated in the ST or violate an OSP defined in the ST.
+ Note that fulfilling an OSP stated in the ST may avert a threat stated in the PP or that averting a
+ threat stated in the ST may fulfil an OSP stated in the PP, so threats and OSPs can substitute
+ each other;
+ all operational environments that would meet the security problem definition in the PP would also
+ meet the security problem definition in the ST (with one exception in the next bullet);
+ besides a set of assumptions in the ST needed to demonstrate conformance to the SPD of the PP,
+ an ST may specify further assumptions, but only if these additional assumptions are independent
+ of and do not affect the security problem definition as defined in the PP. More detailed, there are
+ no assumptions in the ST that exclude threats to the TOE that need to be countered by the TOE
+ according to the PP. Similarly, there are no assumptions in the ST that realise aspects of an OSP
+ stated in the PP, which are meant to be fulfilled by the TOE according to the PP."
+
+ For a composed TOE, the evaluator will consider whether
+ the security problem definition of the composed TOE is
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ Threat statements and OSPs in the composed TOE ST do
+ not contradict those from the component STs.
+
+ Any assumptions made in the component STs are upheld
+ in the composed TOE ST. That is, either the
+ assumption should also be present in the composed
+ ST, or the assumption should be positively addressed
+ in the composed ST. The assumption may be
+ positively addressed through specification of
+ requirements in the composed TOE to provide
+ functionality fulfilling the concern captured in the
+ assumption.
+
+
+
+
+ The evaluator shall examine the conformance claim
+ rationale to determine that the statement of security
+ objectives is consistent, as defined by the conformance
+ statement of the PP, with the statement of security
+ objectives in the PPs to which conformance is being claimed.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP to which conformance is being claimed, no
+ conformance claim rationale is required. Instead, the
+ evaluator determines whether:
+ The ST contains all security objectives for the
+ TOE of the PP to which conformance is being
+ claimed. Note that it is allowed for the ST under
+ evaluation to have additional security objectives
+ for the TOE;
+ The security objectives for the operational environment in the ST are identical to the security
+ objectives for the operational environment in the PP to which conformance is being claimed, with two
+ possible exceptions described in the following two bullet points;
+
+ a security objective for the operational environment (or part of such security objective) from the PP can
+ be replaced by the same (part of the) security objective stated for the TOE;
+
+ a security objective for the operational environment can be added to the objectives defined in the PP,
+ if a justification is given, why the new objective neither mitigates a threat (or a part of a threat) meant to
+ be addressed by security objectives for the TOE in the PP, nor fulfils an OSP (or part of
+ an OSP) meant to be addressed by security objectives for the TOE in the PP.
+
+ When examining an ST claiming a PP, which omits security objectives for the operational environment from
+ the PP or adds new security objectives for the operational environment, the evaluator shall carefully
+ determine, if the conditions given above are fulfilled. The examples given for the case of assumptions in the
+ preceding work unit are also valid here.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ objectives of the ST is equivalent or more restrictive
+ than the statement of security objectives in the PP to
+ which conformance is being claimed.
+ For this the conformance claim rationale needs to demonstrate that the security objectives in the ST are
+ equivalent (or more restrictive) than the security objectives in the PP. This means that:
+
+ all TOEs that would meet the security objectives for the TOE in the ST also meet the security
+ objectives for the TOE in the PP;
+ all operational environments that would meet the security objectives for the operational
+ environment in the PP would also meet the security objectives for the operational environment in
+ the ST (with one exception in the next bullet);
+ besides a set of security objectives for the operational environment in the ST, which are used to
+ demonstrate conformance to the set of security objectives defined in the PP, an ST may specify
+ further security objectives for the operational environment, but only if these security objectives
+ neither affect the original set of security objectives for the TOE nor the security objectives for the
+ operational environment as defined in the PP to which conformance is claimed."
+
+ For a composed TOE, the evaluator will consider whether
+ the security objectives of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance claim rationale to determine
+ that:
+
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment are consistent with the
+ statement of security objectives for the TOE in the
+ base TOE ST. It is not expected that the statement
+ of security objectives for the environment within in
+ the dependent TOE ST will cover all aspects of the
+ statement of security objectives for the TOE in the
+ base TOE ST.
+
+ The statement of security objectives in the composed
+ ST is consistent with the statements of security
+ objectives in the STs for the component TOEs.
+
+
+ If demonstrable conformance is required by the PP, the
+ evaluator examines the conformance claim rationale to
+ determine that it demonstrates that the statement of
+ security objectives of the ST is at least equivalent to
+ the statement of security objectives in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+ The evaluator shall examine the ST to determine that it
+ is consistent, as defined by the conformance statement
+ of the PP, with all security requirements in the PPs for
+ which conformance is being claimed.
+
+ If the ST does not claim conformance to a PP, this work
+ unit is not applicable and therefore considered to be
+ satisfied.
+
+ If strict conformance is required by the PP to which
+ conformance is being claimed, no conformance claim
+ rationale is required. Instead, the evaluator determines
+ whether the statement of security requirements in the ST
+ is a superset of or identical to the statement of
+ security requirements in the PP to which conformance is
+ being claimed (for strict conformance).
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is equivalent or more restrictive
+ than the statement of security requirements in the PP to
+ which conformance is being claimed.
+ For:
+
+ SFRs: The conformance rationale in the ST shall demonstrate that the overall set of requirements
+ defined by the SFRs in the ST is equivalent (or more restrictive) than the overall set of
+ requirements defined by the SFRs in the PP. This means that all TOEs that would meet the
+ requirements defined by the set of all SFRs in the ST would also meet the requirements defined by
+ the set of all SFRs in the PP;
+ SARs: The ST shall contain all SARs in the PP, but may claim additional SARs or replace SARs by
+ hierarchically stronger SARs. The completion of operations in the ST must be consistent with that
+ in the PP; either the same completion will be used in the ST as that in the PP or a completion that
+ makes the SAR more restrictive (the rules of refinement apply).
+
+
+ For a composed TOE, the evaluator will consider whether
+ the security requirements of the composed TOE are
+ consistent with that specified in the STs for the
+ component TOEs. This is determined in terms of
+ demonstrable conformance. In particular, the evaluator
+ examines the conformance rationale to determine that:
+
+
+ The statement of security requirements in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security requirements for the
+ environment within in the dependent TOE ST will
+ cover all aspects of the statement of security
+ requirements for the TOE in the base TOE ST, as
+ some SFRs may need to be added to the statement of
+ security requirements in the composed TOE ST.
+ However, the statement of security requirements in
+ the base should support the operation of the dependent
+ component.
+
+ The statement of security objectives in the
+ dependent TOE ST relevant to any IT in the
+ operational environment is consistent with the
+ statement of security requirements for the TOE in
+ the base TOE ST. It is not expected that the
+ statement of security objectives for the environment
+ within in the dependent TOE ST will cover all
+ aspects of the statement of security requirements
+ for the TOE in the base TOE ST.
+
+ The statement of security requirements in the
+ composed is consistent with the statements of
+ security requirements in the STs for the component
+ TOEs.
+
+ If demonstrable conformance is required by the PP to
+ which conformance is being claimed, the evaluator
+ examines the conformance claim rationale to determine
+ that it demonstrates that the statement of security
+ requirements of the ST is at least equivalent to the
+ statement of security requirements in the PP, or
+ component TOE ST in the case of a composed TOE
+ ST.
+
+
+
+
+
+
+
+ This part of the ST defines the security problem to be
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+ Evaluation of the security problem definition is required to
+ demonstrate that the security problem intended to be
+ addressed by the TOE and its operational environment, is
+ clearly defined.
+
+
+
+ The security problem definition defines the problem
+ addressed by the TOE and the operational environment of the
+ TOE.
+
+
+
+
+ The objective of this sub-activity is to determine that
+ the security problem intended to be addressed by the TOE
+ and its operational environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a security problem definition.
+
+
+ The security problem definition shall describe the threats.
+
+
+ All threats shall be described in terms of a threat agent,
+ an asset, and an adverse action.
+
+
+ The security problem definition shall describe the OSPs.
+
+
+ The security problem definition shall describe the
+ assumptions about the operational environment of the TOE.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the security problem
+ definition describes the threats.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the security problem
+ definition describes the threats that must be countered
+ by the TOE and/or operational environment.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that all threats are described
+ in terms of a threat agent, an asset, and an adverse
+ action.
+
+ If all security objectives are derived from assumptions
+ and/or OSPs only, the statement of threats need not be
+ present in the ST. In this case, this work unit is not
+ applicable and therefore considered to be
+ satisfied.
+
+ Threat agents may be further described by aspects such
+ as expertise, resource, opportunity, and
+ motivation.
+
+
+
+
+ The evaluator shall examine that the security problem
+ definition describes the OSPs.
+
+ If all security objectives are derived from assumptions
+ and threats only, OSPs need not be present in the ST. In
+ this case, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that OSP statements are made in
+ terms of rules or guidelines that must be followed by
+ the TOE and/or its operational environment.
+
+ The evaluator determines that each OSP is explained
+ and/or interpreted in sufficient detail to make it
+ clearly understandable; a clear presentation of policy
+ statements is necessary to permit tracing security
+ objectives to them.
+
+
+
+
+ The evaluator shall examine the security problem
+ definition to determine that it describes the
+ assumptions about the operational environment of the
+ TOE.
+
+ If there are no assumptions, this work unit is not
+ applicable and is therefore considered to be
+ satisfied.
+
+ The evaluator determines that each assumption about the
+ operational environment of the TOE is explained in
+ sufficient detail to enable consumers to determine that
+ their operational environment matches the assumption. If
+ the assumptions are not clearly understood, the end
+ result may be that the TOE is used in an operational
+ environment in which it will not function in a secure
+ manner.
+
+
+
+
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem defined through
+ the family.
+
+ Evaluation of the security objectives is required to
+ demonstrate that the security objectives adequately and
+ completely address the security problem definition, that the
+ division of this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The security objectives are a concise statement of the
+ intended response to the security problem.
+
+
+
+ The components in this family are levelled on whether they
+ prescribe only security objectives for the operational
+ environment, or also security objectives for the TOE.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives for the operational environment
+ are clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the operational environment.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the
+ operational environment.
+
+ The evaluator checks that the security objectives for
+ the operational environment are identified.
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the security objectives adequately and completely address
+ the security problem definition and that the division of
+ this problem between the TOE and its operational
+ environment is clearly defined.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ objectives.
+
+
+ The developer shall provide a security objectives rationale.
+
+
+ The statement of security objectives shall describe the
+ security objectives for the TOE and the security objectives
+ for the operational environment.
+
+
+ The security objectives rationale shall trace each security
+ objective for the TOE back to threats countered by that
+ security objective and OSPs enforced by that security
+ objective.
+
+
+ The security objectives rationale shall trace each security
+ objective for the operational environment back to threats
+ countered by that security objective, OSPs enforced by that
+ security objective, and assumptions upheld by that security
+ objective.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives counter all threats.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives enforce all OSPs.
+
+
+ The security objectives rationale shall demonstrate that the
+ security objectives for the operational environment uphold
+ all assumptions.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ objectives defines the security objectives for the TOE
+ and the security objectives for the operational
+ environment.
+
+ The evaluator checks that both categories of security
+ objectives are clearly identified and separated from the
+ other category.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces all security objectives for the TOE
+ back to threats countered by the objectives and/or OSPs
+ enforced by the objectives.
+
+ Each security objective for the TOE may trace back to
+ threats or OSPs, or a combination of threats and OSPs,
+ but it must trace back to at least one threat or
+ OSP.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the TOE has no useful purpose.
+
+
+
+
+ The evaluator shall check that the security objectives
+ rationale traces the security objectives for the
+ operational environment back to threats countered by
+ that security objective, to OSPs enforced by that
+ security objective, and to assumptions upheld by that
+ security objective.
+
+ Each security objective for the operational environment
+ may trace back to threats, OSPs, assumptions, or a
+ combination of threats, OSPs and/or assumptions, but it
+ must trace back to at least one threat, OSP or
+ assumption.
+
+ Failure to trace implies that either the security
+ objectives rationale is incomplete, the security problem
+ definition is incomplete, or the security objective for
+ the operational environment has no useful
+ purpose.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that it justifies for each threat
+ that the security objectives are suitable to counter
+ that threat.
+
+ If no security objectives trace back to the threat,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ threat shows whether the threat is removed, diminished
+ or mitigated.
+
+ The evaluator determines that the justification for a
+ threat demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to the threat are achieved, the threat is removed,
+ sufficiently diminished, or the effects of the threat
+ are sufficiently mitigated.
+
+ Note that the tracings from security objectives to
+ threats provided in the security objectives rationale
+ may be part of a justification, but do not constitute a
+ justification by themselves. Even in the case that a
+ security objective is merely a statement reflecting the
+ intent to prevent a particular threat from being
+ realised, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly counters Threat Y''.
+
+ The evaluator also determines that each security
+ objective that traces back to a threat is necessary:
+ when the security objective is achieved it actually
+ contributes to the removal, diminishing or mitigation of
+ that threat.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each OSP it justifies
+ that the security objectives are suitable to enforce
+ that OSP.
+
+ If no security objectives trace back to the OSP,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ OSP demonstrates that the security objectives are
+ sufficient: if all security objectives that trace back
+ to that OSP are achieved, the OSP is enforced.
+
+ The evaluator also determines that each security
+ objective that traces back to an OSP is necessary: when
+ the security objective is achieved it actually
+ contributes to the enforcement of the OSP.
+
+ Note that the tracings from security objectives to OSPs
+ provided in the security objectives rationale may be
+ part of a justification, but do not constitute a
+ justification by themselves. In the case that a security
+ objective is merely a statement reflecting the intent to
+ enforce a particular OSP, a justification is required,
+ but this justification may be as minimal as ``Security
+ Objective X directly enforces OSP Y''.
+
+
+
+
+ The evaluator shall examine the security objectives
+ rationale to determine that for each assumption for the
+ operational environment it contains an appropriate
+ justification that the security objectives for the
+ operational environment are suitable to uphold that
+ assumption.
+
+ If no security objectives for the operational environment trace back to the assumption,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for an
+ assumption about the operational environment of the TOE
+ demonstrates that the security objectives are
+ sufficient: if all security objectives for the
+ operational environment that trace back to that
+ assumption are achieved, the operational environment
+ upholds the assumption.
+
+ The evaluator also determines that each security
+ objective for the operational environment that traces
+ back to an assumption about the operational environment
+ of the TOE is necessary: when the security objective is
+ achieved it actually contributes to the operational
+ environment upholding the assumption.
+
+ Note that the tracings from security objectives for the
+ operational environment to assumptions provided in the
+ security objectives rationale may be a part of a
+ justification, but do not constitute a justification by
+ themselves. Even in the case that a security objective
+ of the operational environment is merely a restatement
+ of an assumption, a justification is required, but this
+ justification may be as minimal as ``Security Objective
+ X directly upholds Assumption Y''.
+
+
+
+
+
+
+
+ Extended security requirements are requirements that are not
+ based on components from CC Part 2 or CC Part 3, but are
+ based on extended components: components defined by the ST
+ author.
+
+ Evaluation of the definition of extended components is
+ necessary to determine that they are clear and unambiguous,
+ and that they are necessary, i.e. they may not be clearly
+ expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ Extended components are defined wherever it is impossible to
+ clearly express requirements using only components from CC
+ Part 2 and/or CC Part 3.
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ extended components have been clearly and unambiguously
+ defined, and whether they are necessary, i.e. they may not
+ be clearly expressed using existing CC Part 2 or CC Part 3
+ components.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security
+ requirements.
+
+
+ The developer shall provide an extended components
+ definition.
+
+
+ The statement of security requirements shall identify all
+ extended security requirements.
+
+
+ The extended components definition shall define an extended
+ component for each extended security requirement.
+
+
+ The extended components definition shall describe how each
+ extended component is related to the existing CC components,
+ families, and classes.
+
+
+ The extended components definition shall use the existing CC
+ components, families, classes, and methodology as a model
+ for presentation.
+
+
+ The extended components shall consist of measurable and
+ objective elements such that conformance or nonconformance
+ to these elements can be demonstrated.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that all security requirements
+ in the statement of security requirements that are not
+ identified as extended requirements are present in CC
+ Part 2 or in CC Part 3.
+
+
+
+
+ The evaluator shall check that the extended components
+ definition defines an extended component for each
+ extended security requirement.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ A single extended component may be used to define
+ multiple iterations of an extended security requirement,
+ it is not necessary to repeat this definition for each
+ iteration.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that it describes how each
+ extended component fits into the existing CC components,
+ families, and classes.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that each extended component is
+ either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ family, or
+
+ a member of a new family defined in the ST.
+
+
+ If the extended component is a member of an existing CC
+ Part 2 or CC Part 3 family, the evaluator determines
+ that the extended components definition adequately
+ describes why the extended component should be a member
+ of that family and how it relates to other components of
+ that family.
+
+ If the extended component is a member of a new family
+ defined in the ST, the evaluator confirms that the
+ extended component is not appropriate for an existing
+ family.
+
+ If the ST defines new families, the evaluator determines
+ that each new family is either:
+
+
+ a member of an existing CC Part 2 or CC Part 3
+ class, or
+
+ a member of a new class defined in the ST.
+
+
+ If the family is a member of an existing CC Part 2 or CC
+ Part 3 class, the evaluator determines that the extended
+ components definition adequately describes why the
+ family should be a member of that class and how it
+ relates to other families in that class.
+
+ If the family is a member of a new class defined in the
+ ST, the evaluator confirms that the family is not
+ appropriate for an existing class.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended component identifies all applicable
+ dependencies of that component.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator confirms that no applicable dependencies
+ have been overlooked by the ST author.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended functional
+ component uses the existing CC Part 2 components as a
+ model for presentation.
+
+ If the ST does not contain extended SFRs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended functional
+ component is consistent with CC Part 2 Subclause .
+
+ If the extended functional component uses operations, the
+ evaluator determines that the extended functional component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended functional component is hierarchical to
+ an existing functional component, the evaluator
+ determines that the extended functional component is
+ consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional family uses the existing CC functional
+ families as a model for presentation.
+
+ If the ST does not define new functional families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional
+ families are defined consistent with CC Part 2 Subclause
+ .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ functional class uses the existing CC functional classes
+ as a model for presentation.
+
+ If the ST does not define new functional classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new functional classes
+ are defined consistent with CC Part 2 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of an
+ extended assurance component uses the existing CC Part 3
+ components as a model for presentation.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that the extended assurance
+ component definition is consistent with CC Part 3
+ Subclause .
+
+ If the extended assurance component uses operations, the
+ evaluator determines that the extended assurance component is
+ consistent with CC Part 1 Subclause .
+
+ If the extended assurance component is hierarchical to
+ an existing assurance component, the evaluator
+ determines that the extended assurance component is
+ consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that, for each defined extended
+ assurance component, applicable methodology has been
+ provided.
+
+ If the ST does not contain extended SARs, this work unit
+ is not applicable and therefore considered to be
+ satisfied.
+
+ The evaluator determines that, for each evaluator action
+ element of each extended SAR, one or more work units are
+ provided and that successfully performing all work units
+ for a given evaluator action element will demonstrate
+ that the element has been achieved.
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance family uses the existing CC assurance families
+ as a model for presentation.
+
+ If the ST does not define new assurance families, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance families
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each definition of a new
+ assurance class uses the existing CC assurance classes
+ as a model for presentation.
+
+ If the ST does not define new assurance classes, this
+ work unit is not applicable and therefore considered to
+ be satisfied.
+
+ The evaluator determines that all new assurance classes
+ are defined consistent with CC Part 3 Subclause .
+
+
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each element in each
+ extended component is measurable and states objective
+ evaluation requirements, such that conformance or
+ nonconformance can be demonstrated.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator determines that elements of extended
+ functional components are stated in such a way that they
+ are testable, and traceable through the appropriate TSF
+ representations.
+
+ The evaluator also determines that elements of extended
+ assurance components avoid the need for subjective
+ evaluator judgement.
+
+ The evaluator is reminded that whilst being measurable
+ and objective is appropriate for all evaluation
+ criteria, it is acknowledged that no formal method
+ exists to prove such properties. Therefore the existing
+ CC functional and assurance components are to be used as
+ a model for determining what constitutes conformance
+ with this requirement.
+
+
+
+ The evaluator shall confirm that no extended component can
+ be clearly expressed using existing components.
+
+
+ The evaluator shall examine the extended components
+ definition to determine that each extended component can
+ not be clearly expressed using existing
+ components.
+
+ If the ST does not contain extended security
+ requirements, this work unit is not applicable and
+ therefore considered to be satisfied.
+
+ The evaluator should take components from CC Part 2 and
+ CC Part 3, other extended components that have been
+ defined in the ST, combinations of these components, and
+ possible operations on these components into account
+ when making this determination.
+
+ The evaluator is reminded that the role of this work
+ unit is to preclude unnecessary duplication of
+ components, that is, components that may be clearly
+ expressed by using other components. The evaluator
+ should not undertake an exhaustive search of all
+ possible combinations of components including operations
+ in an attempt to find a way to express the extended
+ component by using existing components.
+
+
+
+
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and canonical
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+ Evaluation of the security requirements is required to
+ ensure that they are clear, unambiguous and
+ well-defined.
+
+
+
+ The SFRs form a clear, unambiguous and well-defined
+ description of the expected security behaviour of the
+ TOE. The SARs form a clear, unambiguous and well-defined
+ description of the expected activities that will be
+ undertaken to gain assurance in the TOE.
+
+
+
+ The components in this family are levelled on whether they
+ are stated as is.
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined
+ and whether they are internally consistent.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+
+ All subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the SFRs
+ and the SARs shall be defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that each SAR is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to a PP that the ST claims to be
+ conformant with;
+
+
+ by reference to a security requirements package that
+ the ST claims to be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that a
+ security requirements rationale is provided which justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended SAR specifying an open
+ source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the SFRs and SARs are clear, unambiguous and well-defined,
+ whether they are internally consistent, and whether the
+ SFRs meet the security objectives of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a statement of security requirements.
+
+
+ The developer shall provide a security requirements
+ rationale.
+
+
+ The statement of security requirements shall describe the
+ SFRs and the SARs.
+
+ All subjects, objects,
+ operations, security attributes, external entities and other
+ terms that are used in the SFRs and the SARs shall be
+ defined.
+
+
+ The statement of security requirements shall identify all
+ operations on the security requirements.
+
+
+ All operations shall be performed correctly.
+
+
+ Each dependency of the security requirements shall either be
+ satisfied, or the security requirements rationale shall
+ justify the dependency not being satisfied.
+
+
+ The security requirements rationale shall trace each SFR
+ back to the security objectives for the TOE.
+
+
+ The security requirements rationale shall demonstrate that
+ the SFRs meet all security objectives for the TOE.
+
+
+ The security requirements rationale shall explain why the
+ SARs were chosen.
+
+
+ The statement of security requirements shall be internally
+ consistent.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SFRs.
+
+ The evaluator determines that each SFRs is identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 2;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SFRs.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements describes the SARs.
+
+ The evaluator determines that all SARs are identified by
+ one of the following means:
+
+
+ by reference to an individual component in CC Part
+ 3;
+
+
+ by reference to an extended component in the
+ extended components definition of the ST;
+
+
+ by reference to an individual component in a PP that
+ the ST claims to be conformant with;
+
+
+ by reference to an individual component in a
+ security requirements package that the ST claims to
+ be conformant with;
+
+
+ by reproduction in the ST.
+
+ It is not required to use the same means of
+ identification for all SARs.
+
+
+
+
+ The evaluator shall examine the ST to determine that all
+ subjects, objects, operations, security attributes,
+ external entities and other terms that are used in the
+ SFRs and the SARs are defined.
+
+ The evaluator determines that the ST defines all:
+
+ (types of) subjects and objects that are used in
+ the SFRs;
+ (types of) security attributes of subjects, users,
+ objects, information, sessions and/or resources, possible
+ values that these attributes may take and any relations
+ between these values (e.g. top_secret is ``higher'' than secret);
+ (types of) operations that are used in the SFRs,
+ including the effects of these operations;
+ (types of) external entities in the SFRs;
+ other terms that are introduced in the SFRs
+ and/or SARs by completing operations, if these terms
+ are not immediately clear, or are used outside their
+ dictionary definition.
+
+ The goal of this work unit is to ensure that the SFRs
+ and SARs are well-defined and that no misunderstanding
+ may occur due to the introduction of vague terms. This
+ work unit should not be taken into extremes, by forcing
+ the ST writer to define every single word. The general
+ audience of a set of security requirements should be
+ assumed to have a reasonable knowledge of IT, security
+ and Common Criteria.
+
+ All of the above may be presented in groups, classes,
+ roles, types or other groupings or characterisations
+ that allow easy understanding.
+
+ The evaluator is reminded that these lists and
+ definitions do not have to be part of the statement of
+ security requirements, but may be placed (in part or in
+ whole) in different subclauses. This may be especially
+ applicable if the same terms are used in the rest of the
+ ST.
+
+
+
+
+ The evaluator shall check that the statement of security
+ requirements identifies all operations on the security
+ requirements.
+
+ The evaluator determines that all operations are
+ identified in each SFR or SAR where such an operation is
+ used. Identification may be achieved by typographical
+ distinctions, or by explicit identification in the
+ surrounding text, or by any other distinctive
+ means.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all assignment operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all iteration operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all selection operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that all refinement operations
+ are performed correctly.
+
+ Guidance on the correct performance of operations may be found
+ in CC Part 1 Annex .
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that each dependency of the
+ security requirements is either satisfied, or that the
+ security requirements rationale justifies the dependency
+ not being satisfied.
+
+ A dependency is satisfied by the inclusion of the
+ relevant component (or one that is hierarchical to it)
+ within the statement of security requirements. The
+ component used to satisfy the dependency should, if
+ necessary, be modified by operations to ensure that it
+ actually satisfies that dependency.
+
+ A justification that a dependency is not met should
+ address either:
+
+
+ why the dependency is not necessary or useful, in
+ which case no further information is required; or
+
+
+ that the dependency has been addressed by the
+ operational environment of the TOE, in which case
+ the justification should describe how the security
+ objectives for the operational environment address
+ this dependency.
+
+
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale traces each SFR back to the security
+ objectives for the TOE.
+
+ The evaluator determines that each SFR is traced back to
+ at least one security objective for the TOE.
+
+ Failure to trace implies that either the security
+ requirements rationale is incomplete, the security
+ objectives for the TOE are incomplete, or the SFR has no
+ useful purpose.
+
+
+
+
+ The evaluator shall examine the security requirements
+ rationale to determine that for each security objective
+ for the TOE it demonstrates that the SFRs are suitable
+ to meet that security objective for the TOE.
+
+ If no SFRs trace back to the security objective for the TOE,
+ the evaluator action related to this work unit is assigned a fail verdict.
+
+ The evaluator determines that the justification for a
+ security objective for the TOE demonstrates that the
+ SFRs are sufficient: if all SFRs that trace back to the
+ objective are satisfied, the security objective for the
+ TOE is achieved.
+
+ The evaluator also determines that each SFR that traces
+ back to a security objective for the TOE is necessary:
+ when the SFR is satisfied, it actually contributes to
+ achieving the security objective.
+
+ Note that the tracings from SFRs to security objectives
+ for the TOE provided in the security requirements
+ rationale may be a part of the justification, but do not
+ constitute a justification by themselves.
+
+
+
+
+ The evaluator shall check that the security requirements
+ rationale explains why the SARs were chosen.
+
+ The evaluator is reminded that any explanation is correct, as
+ long as it is coherent and neither the SARs nor the explanation
+ have obvious inconsistencies with the remainder of the ST.
+
+ An example of an obvious inconsistency between the SARs and the
+ remainder of the ST would be to have threat agents that are very
+ capable, but an SAR that does not
+ protect against these threat agents.
+
+
+
+
+ The evaluator shall examine the statement of security
+ requirements to determine that it is internally
+ consistent.
+
+ The evaluator determines that the combined set of all
+ SFRs and SARs is internally consistent.
+
+ The evaluator determines that on all occasions where
+ different security requirements apply to the same types
+ of developer evidence, events, operations, data, tests
+ to be performed etc. or to ``all objects'', ``all
+ subjects'' etc., that these requirements do not
+ conflict.
+
+ Some possible conflicts are:
+
+
+ an extended SAR specifying that the design of a
+ certain cryptographic algorithm is to be kept
+ secret, and another extended assurance requirement
+ specifying an open source review;
+
+ specifying
+ that subject identity is to be logged, specifying who has
+ access to these logs, and specifying that some actions of
+ subjects should be unobservable to other
+ subjects. If the subject that should not be able to
+ see an activity may access logs of this activity,
+ these SFRs conflict;
+
+ specifying
+ deletion of information no longer needed, and specifying that a TOE
+ may return to a previous state. If the information
+ that is needed for the rollback to the previous
+ state has been deleted, these requirements conflict;
+
+
+ Multiple iterations of especially where some iterations cover
+ the same subjects, objects, or operations. If one
+ access control SFR allows a subject to perform an
+ operation on an object, while another access control
+ SFR does not allow this, these requirements
+ conflict.
+
+
+
+
+
+
+
+
+
+ The TOE summary specification enables evaluators and
+ potential consumers to gain a general understanding of how
+ the TOE is implemented.
+
+ Evaluation of the TOE summary specification is necessary to
+ determine whether it is adequately described how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass. and whether the TOE
+ summary specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The TOE Summary specification allows evaluators and
+ potential consumers of the TOE to gain a general
+ understanding of how the TOE:
+
+ meets its SFRs;
+ protects itself against interference, logical
+ tampering and bypass.
+
+
+
+ The components in this family are levelled on whether the
+ TOE summary specification only needs to describe how the TOE
+ meets the SFRs, or whether the TOE summary specification
+ also needs to describe how the TOE protects itself against
+ logical tampering and bypass. This additional description
+ may be used in special circumstances where there might be a
+ specific concern regarding the TOE security architecture.
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, and
+ whether the TOE summary specification is consistent with
+ other narrative descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each description is to provide
+ potential consumers of the TOE with a high-level view of how the developer intends
+ to satisfy each SFR and that the descriptions therefore should not be overly detailed.
+ Often several SFRs will be implemented in one context; for instance a password
+ authentication mechanism may implement ,
+ and .
+ Therefore usually the TSS will not consist of a long list with texts for each single
+ SFR, but complete groups of SFRs may be covered by one text passage.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE summary specification addresses all SFRs, whether
+ the TOE summary specification addresses interference,
+ logical tampering and bypass, and whether the TOE summary
+ specification is consistent with other narrative
+ descriptions of the TOE.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST.
+
+
+
+
+ The developer shall provide a TOE summary specification.
+
+
+ The TOE summary specification shall describe how the TOE
+ meets each SFR.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against interference and logical tampering.
+
+
+ The TOE summary specification shall describe how the TOE
+ protects itself against bypass.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ meets each SFR.
+
+ The evaluator determines that the TOE summary
+ specification provides, for each SFR from the statement
+ of security requirements, a description on how that SFR
+ is met.
+
+ The evaluator is reminded that the objective of each description is to provide
+ potential consumers of the TOE with a high-level view of how the developer intends
+ to satisfy each SFR and that the descriptions therefore should not be overly detailed.
+ Often several SFRs will be implemented in one context; for instance a password
+ authentication mechanism may implement ,
+ and .
+ Therefore usually the TSS will not consist of a long list with texts for each single
+ SFR, but complete groups of SFRs may be covered by one text passage.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides each SFR or how the
+ components combine to meet each SFR.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against interference and logical
+ tampering.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against interference and logical
+ tampering and that the descriptions therefore should not
+ be overly detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it describes how the TOE
+ protects itself against bypass.
+
+ The evaluator is reminded that the objective of each
+ description is to provide potential consumers of the TOE
+ with a high-level view of how the developer intends to
+ provide protection against bypass and that the
+ descriptions therefore should not be overly
+ detailed.
+
+ For a composed TOE, the evaluator also determines that
+ it is clear which component provides the protection or
+ how the components combine to provide protection.
+
+
+
+ The evaluator shall confirm that the TOE summary
+ specification is consistent with the TOE overview and the
+ TOE description.
+
+
+ The evaluator shall examine the TOE summary
+ specification to determine that it is consistent with
+ the TOE overview and the TOE description.
+
+ The TOE overview, TOE description, and TOE summary
+ specification describe the TOE in a narrative form at
+ increasing levels of detail. These descriptions
+ therefore need to be consistent.
+
+
+
+
+
+
+
+
+ The class ``Tests'' encompasses four families: , ,
+ (i.e. functional testing
+ performed by evaluators), and . Testing provides assurance that the TSF
+ behaves as described (in the functional specification, TOE
+ design, and implementation representation).
+
+ The emphasis in this class is on confirmation that the TSF
+ operates according to its design descriptions. This class does
+ not address penetration testing, which is based upon an
+ analysis of the TSF that specifically seeks to identify
+ vulnerabilities in the design and implementation of the
+ TSF. Penetration testing is addressed separately as an aspect
+ of vulnerability assessment in the class.
+
+ The class separates testing into
+ developer testing and evaluator testing. The and families address the completeness of developer
+ testing. addresses the rigour
+ with which the functional specification is tested; addresses whether testing against
+ other design descriptions (security architecture, TOE design,
+ implementation representation) is required.
+
+ addresses the performing of
+ the tests by the developer and how this testing should be
+ documented. Finally, then
+ addresses evaluator testing: whether the evaluator should
+ repeat part or all of the developer testing and how much
+ independent testing the evaluator should do.
+
+
+
+ Assurance class states testing
+ requirements that demonstrate that the TOE matches its design
+ descriptions as provided in the
+ class.
+
+
+
+ The goal of this activity is to determine whether the TOE
+ behaves as described in the ST and as specified in the
+ evaluation evidence (described in the class). This determination is achieved through
+ some combination of the developer's own functional testing of
+ the TSF () and independent
+ testing the TSF by the evaluator (). At the lowest level of assurance, there is no
+ requirement for developer involvement, so the only testing is
+ conducted by the evaluator, using the limited available
+ information about the TOE. Additional assurance is gained as
+ the developer becomes increasingly involved both in testing
+ and in providing additional information about the TOE, and as
+ the evaluator increases the independent testing
+ activities.
+
+
+
+ Testing of the TSF is conducted by the evaluator and, in most
+ cases, by the developer. The evaluator's testing efforts
+ consist not only of creating and running original tests, but
+ also of assessing the adequacy of the developer's tests and
+ re-running a subset of them.
+
+ The evaluator analyses the developer's tests to determine the
+ extent to which they are sufficient to demonstrate that TSFI
+ (see ) perform as specified,
+ and to understand the developer's approach to
+ testing. Similarly, the evaluator analyses the developer's
+ tests to determine the extent to which they are sufficient to
+ demonstrate the internal behaviour and properties of the
+ TSF.
+ The evaluator also executes a subset of the developer's
+ tests as documented to gain confidence in the developer's test
+ results: the evaluator will use the results of this analysis
+ as an input to independently testing a subset of the TSF. With
+ respect to this subset, the evaluator takes a testing approach
+ that is different from that of the developer, particularly if
+ the developer's tests have shortcomings.
+
+ To determine the adequacy of developer's test documentation or
+ to create new tests, the evaluator needs to understand the
+ desired expected behaviour of the TSF, both internally and as
+ seen at the TSFI, in the context of the SFRs it is to
+ satisfy. The evaluator may choose to divide the TSF and TSFI
+ into subsets according to functional areas of the ST (audit
+ subsystem, audit-related TSFI, authentication module,
+ authentication-related TSFI, etc.) if they were not already
+ divided in the ST, and focus on one subset of the TSF and TSFI
+ at a time, examining the ST requirement and the relevant parts
+ of the development and guidance documentation to gain an
+ understanding of the way the TOE is expected to behave. This
+ reliance upon the development documentation underscores the need
+ for the dependencies on by and .
+
+ The CC has separated coverage and depth from functional tests
+ to increase the flexibility when applying the components of
+ the families. However, the requirements of the families are
+ intended to be applied together to confirm that the TSF
+ operates according to its specification. This tight coupling
+ of families has led to some duplication of evaluator work
+ units across sub-activities. These application notes are used
+ to minimise duplication of text between sub-activities.
+
+
+ Before the adequacy of test documentation can be accurately
+ evaluated, or before new tests can be created, the evaluator
+ has to understand the desired expected behaviour of a
+ security function in the context of the requirements it is
+ to satisfy.
+
+ As mentioned earlier, the evaluator may choose to subset the
+ TSF and TSFI according to SFRs (audit, authentication, etc.)
+ in the ST and focus on one subset at a time. The evaluator
+ examines each ST requirement and the relevant parts of the
+ functional specification and guidance documentation to gain
+ an understanding of the way the related TSFI is expected to
+ behave. Similarly, the evaluator examines the relevant parts
+ of the TOE design and security architecture documentation to
+ gain an understanding of the way the related modules or
+ subsystems of the TSF are expected to behave.
+
+ With an understanding of the expected behaviour, the
+ evaluator examines the test plan to gain an understanding of
+ the testing approach. In most cases, the testing approach
+ will entail a TSFI being stimulated and its responses
+ observed. Externally-visible functionality can be tested
+ directly; however, in cases where functionality is not
+ visible external to the TOE (for example, testing the
+ residual information protection functionality), other means
+ will need to be employed.
+
+
+
+ In cases where it is impractical or inadequate to test
+ specific functionality (where it provides no
+ externally-visible TSFI), the test plan should identify the
+ alternate approach to verify expected behaviour. It is the
+ evaluator's responsibility to determine the suitability of
+ the alternate approach. However, the following should be
+ considered when assessing the suitability of alternate
+ approaches:
+
+
+ an analysis of the implementation representation to
+ determine that the required behaviour should be
+ exhibited by the TOE is an acceptable alternate
+ approach. This could mean a code inspection for a
+ software TOE or perhaps a chip mask inspection for a
+ hardware TOE.
+
+
+ it is acceptable to use evidence of developer
+ integration or module testing, even if the claimed
+ assurance requirements do not include availability of
+ lower level descriptions of the TOE modules (e.g. ) or implementation (). If evidence of developer
+ integration or module testing is used in verifying the
+ expected behaviour of a security functionality, care
+ should be given to confirm that the testing evidence
+ reflects the current implementation of the TOE. If the
+ subsystems or modules have been changed since testing
+ occurred, evidence that the changes were tracked and
+ addressed by analysis or further testing will usually be
+ required.
+
+
+
+ It should be emphasised that supplementing the testing
+ effort with alternate approaches should only be undertaken
+ when both the developer and evaluator determine that there
+ exists no other practical means to test the expected
+ behaviour.
+
+
+
+ Test pre-requisites are necessary to establish the required
+ initial conditions for the test. They may be expressed in
+ terms of parameters that must be set or in terms of test
+ ordering in cases where the completion of one test
+ establishes the necessary pre-requisites for another
+ test. The evaluator must determine that the pre-requisites
+ are complete and appropriate in that they will not bias the
+ observed test results towards the expected test
+ results.
+
+ The test steps and expected results specify the actions and
+ parameters to be applied to the TSFI as well as how the
+ expected results should be verified and what they are. The
+ evaluator must determine that the test steps and expected
+ results are consistent with the descriptions of the TSFI in
+ the functional specification. This means that each
+ characteristic of the TSFI behaviour explicitly described in
+ the functional specification should have tests and expected
+ results to verify that behaviour.
+
+ The overall aim of this testing activity is to determine
+ that each subsystem, module, and TSFI has been sufficiently
+ tested against the behavioural claims in the functional
+ specification, TOE design, and architecture description. At
+ the higher assurance levels, testing also includes bounds
+ testing and negative testing. The test procedures will
+ provide insight as to how the TSFIs, modules, and subsystems
+ have been exercised by the developer during testing. The
+ evaluator uses this information when developing additional
+ tests to independently test the TSF.
+
+
+
+
+
+ This family establishes that the TSF has been tested against
+ its functional specification. This is achieved through an
+ examination of developer evidence of correspondence.
+
+
+
+ Coverage deals with the completeness of the functional tests
+ performed by the developer on the TOE. It addresses the
+ extent to which the TSF is tested.
+
+
+
+ The components in this family are levelled on the basis of
+ specification.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to establish that some
+ of the TSFIs have been tested.
+
+
+
+ In this component the developer shows how tests in the
+ test documentation correspond to TSFIs in the functional
+ specification. This can be achieved by a statement of
+ correspondence, perhaps using a table.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+ The coverage analysis provided by the developer is
+ required to show the correspondence between the tests
+ provided as evaluation evidence and the functional
+ specification. However, the coverage analysis need not
+ demonstrate that all TSFI have been tested, or that all
+ externally-visible interfaces to the TOE have been
+ tested. Such shortcomings are considered by the evaluator
+ during the independent testing () sub-activity.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage evidence.
+
+
+
+
+ The developer shall provide evidence of the test coverage.
+
+
+ The evidence of the test coverage shall show the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage evidence
+ to determine that the correspondence between the tests
+ identified in the test documentation and the TSFIs
+ described in the functional specification is
+ accurate.
+
+ Correspondence may take the form of a table or
+ matrix. The coverage evidence required for this
+ component will reveal the extent of coverage, rather
+ than to show complete coverage. In cases where coverage
+ is shown to be poor the evaluator should increase the
+ level of independent testing to compensate.
+
+
+
+
+
+
+
+
+
+ The objective of this component is to confirm that all of
+ the TSFIs have been tested.
+
+
+
+ In this component the developer confirms that tests in the
+ test documentation correspond to all of the TSFIs in the
+ functional specification. This can be achieved by a
+ statement of correspondence, perhaps using a table, but
+ the developer also provides an analysis of the test
+ coverage.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested all of the TSFIs, and that the
+ developer's test coverage evidence shows correspondence
+ between the tests identified in the test documentation and
+ the TSFIs described in the functional
+ specification.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation;
+
+
+ the test coverage analysis.
+
+
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the tests
+ in the test documentation and the interfaces in the
+ functional specification is accurate.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ interfaces presented in the test coverage analysis has
+ to be unambiguous.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the testing approach for each interface
+ demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that the test prerequisites, test steps and
+ expected result(s) adequately test each
+ interface.
+
+ Guidance on this work units, as it pertains to the
+ functional specification, can be found in:
+
+
+
+
+
+
+
+
+
+ The evaluator shall examine the test coverage analysis
+ to determine that the correspondence between the
+ interfaces in the functional specification and the tests
+ in the test documentation is complete.
+
+ All TSFIs that are described in the functional
+ specification have to be present in the test coverage
+ analysis and mapped to tests in order for completeness
+ to be claimed, although exhaustive specification testing
+ of interfaces is not required. Incomplete coverage would
+ be evident if an interface was identified in the
+ functional specification and no test was mapped to
+ it.
+
+ The evaluator is reminded that this does not imply that
+ all tests in the test documentation must map to
+ interfaces in the functional specification.
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to confirm that the
+ developer performed exhaustive tests of all interfaces in
+ the functional specification.
+
+ The objective of this component is to confirm that all
+ parameters of all of the TSFIs have been tested.
+
+
+
+ In this component the developer is required to show how
+ tests in the test documentation correspond to all of the
+ TSFIs in the functional specification. This can be
+ achieved by a statement of correspondence, perhaps using a
+ table, but in addition the developer is required to
+ demonstrate that the tests exercise all of the parameters
+ of all TSFIs. This additional requirement includes bounds
+ testing (i.e. verifying that errors are generated when
+ stated limits are exceeded) and negative testing
+ (e.g. when access is given to User A, verifying not only
+ that User A now has access, but also that User B did not
+ suddenly gain access). This kind of testing is not,
+ strictly speaking, exhaustive because not
+ every possible value of the parameters is expected to be
+ checked.
+
+
+ The developer shall provide an analysis of the test
+ coverage.
+
+
+ The analysis of the test coverage shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSFIs in the functional specification.
+
+
+ The analysis of the test coverage shall demonstrate that all
+ TSFIs in the functional specification have been completely
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The components in this family deal with the level of detail
+ to which the TSF is tested by the developer. Testing of the
+ TSF is based upon increasing depth of information derived
+ from additional design representations and descriptions (TOE
+ design, implementation representation, and security
+ architecture description).
+
+ The objective is to counter the risk of missing an error in
+ the development of the TOE. Testing that exercises specific
+ internal interfaces can provide assurance not only that the
+ TSF exhibits the desired external security behaviour, but
+ also that this behaviour stems from correctly operating
+ internal functionality.
+
+
+
+ Depth deals with the level of detail to which the developer
+ tests the TSF. Testing is based upon increasing depth of
+ information derived from analysis of the TSF
+ representations.
+
+
+
+ The components in this family are levelled on the basis of
+ increasing detail provided in the TSF representations, from
+ the TOE design to the implementation representation. This
+ levelling reflects the TSF representations presented in the
+ class.
+
+
+
+ The TOE design describes the internal components
+ (e.g. subsystems) and, perhaps, modules of the TSF, together
+ with a description of the interfaces among these components and
+ modules. Evidence of testing of this TOE design must show that
+ the internal interfaces have been exercised and seen to behave
+ as described. This may be achieved through testing via the
+ external interfaces of the TSF, or by testing of the TOE
+ subsystem or module interfaces in isolation, perhaps employing a
+ test harness. In cases where some aspects of an internal
+ interface cannot be tested via the external interfaces, there
+ should either be justification that these aspects need not be
+ tested, or the internal interface needs to be tested
+ directly. In the latter case the TOE design needs to be
+ sufficiently detailed in order to facilitate direct
+ testing.
+
+ In cases where the description of the TSF's architectural
+ soundness (in ) cites
+ specific mechanisms, the tests performed by the developer
+ must show that the mechanisms have been exercised and seen
+ to behave as described.
+
+ At the highest component of this family, the testing is
+ performed not only against the TOE design, but also against
+ the implementation representation.
+
+
+
+
+
+
+
+ The subsystem descriptions of the TSF provide a high-level
+ description of the internal workings of the TSF. Testing
+ at the level of the TOE subsystems provides assurance that
+ the TSF subsystems behave and interact as described in the
+ TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer has tested the TSF subsystems against the
+ TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the descriptions of the
+ behaviour of TSF subsystems and of their interactions is
+ included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ When is combined with a component of , which includes descriptions at the module level
+ (e.g. ), the level of detail needed to map
+ the test cases to the behaviour of the subsystems may require
+ information from the module description to be used. This is
+ because allows the description of details
+ to be shifted from the subsystem level to the module level, or
+ even to omit the subsystems altogether.
+ In any case, the required level of detail in the provided
+ reference to the tested behaviour can be defined as ``the level
+ of detail required for the description of subsystem behaviour as
+ defined by (in particular work unit )''. It states that a detailed description of
+ the behaviour typically discusses how the functionality is
+ provided, in terms of what key data and data structures re
+ present; what control relationships exist within a subsytem and
+ how these elements work together to provide the SFR-enforcing
+ behaviour.
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ When is combined with a component of , which includes descriptions at the module level
+ (e.g. ), the level of detail needed to map
+ the test cases to the behaviour of the subsystems may require
+ information from the module description to be used. This is
+ because allows the description of details
+ to be shifted from the subsystem level to the module level, or
+ even to omit the subsystems altogether.
+ In any case, the required level of detail in the provided
+ reference to the tested behaviour can be defined as ``the level
+ of detail required for the description of subsystem behaviour as
+ defined by (in particular work unit )''. It states that a detailed description of
+ the behaviour typically discusses how the functionality is
+ provided, in terms of what key data and data structures re
+ present; what control relationships exist within a subsytem and
+ how these elements work together to provide the SFR-enforcing
+ behaviour.
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ When is combined with a component of , which includes descriptions at the module level
+ (e.g. ), the level of detail needed to map
+ the test cases to the behaviour of the subsystems may require
+ information from the module description to be used. This is
+ because allows the description of details
+ to be shifted from the subsystem level to the module level, or
+ even to omit the subsystems altogether.
+ In any case, the required level of detail in the provided
+ reference to the tested behaviour can be defined as ``the level
+ of detail required for the description of subsystem behaviour as
+ defined by (in particular work unit )''. It states that a detailed description of
+ the behaviour typically discusses how the functionality is
+ provided, in terms of what key data and data structures re
+ present; what control relationships exist within a subsytem and
+ how these elements work together to provide the SFR-enforcing
+ behaviour.
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to the subsystem behaviour
+ or interaction description in the TOE design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the SFR-enforcing
+ modules, of the TSF. Testing at this level of TOE
+ description provides assurance that the TSF subsystems and
+ SFR-enforcing modules behave and interact as described in
+ the TOE design and the security architecture
+ description.
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has tested all the TSF subsystems and SFR-enforcing
+ modules against the TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation and
+ the TSF subsystems and SFR-enforcing modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the SFR-enforcing modules in the TOE design have been
+ tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms, this work
+ unit also verifies the correspondence between the tests
+ and the descriptions of the behaviour of such
+ mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ behaviour/interaction presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the behaviour
+ of those subsystems may be tested directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are described, the
+ interactions with other subsystems may be tested
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of
+ SFR-enforcing modules are included within the test
+ documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. In cases where the description of the
+ TSF's architectural soundness (in ) cites specific mechanisms at the modular
+ level, this work unit also verifies the correspondence
+ between the tests and the descriptions of the behaviour
+ of such mechanisms.
+
+ A simple cross-table may be sufficient to show test
+ correspondence. The identification of the tests and the
+ SFR-enforcing modules presented in the depth-of coverage
+ analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to the interfaces of SFR-enforcing modules.
+
+
+
+
+ The evaluator shall examine the test plan, test prerequisites,
+ test steps and expected result(s) to determine that the testing
+ approach for each SFR-enforcing module interface demonstrates
+ the expected behaviour of that interface.
+
+ While work unit addresses
+ expected behaviour of subsystems, this work unit addresses
+ expected behaviour of the SFR-enforcing module interfaces that
+ are covered by .
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to the subsystem behaviour
+ or interaction description in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all interfaces of SFR-enforcing modules
+ are tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of SFR-enforcing modules that are provided in the TOE
+ design have to be tested. Incomplete depth of testing
+ would be evident if any interface of any SFR-enforcing
+ modules was identified in the TOE design and no tests
+ could be attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of an SFR-enforcing module in the TOE
+ design.
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description.
+
+
+
+ The objective of this sub-activity is to determine whether the
+ developer has tested the all the TSF subsystems and modules
+ against the TOE design and the security architecture
+ description.
+
+
+
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design;
+
+
+ the security architecture description;
+
+
+ the test documentation;
+
+
+ the depth of testing analysis.
+
+
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that all
+ TSF modules in the TOE design have been tested.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that descriptions of the behaviour
+ of TSF subsystems and of their interactions are included
+ within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the behaviour of that subsystem
+ as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+
+ If TSF subsystem interfaces are provided, the behaviour
+ of those subsystems may be performed directly from those
+ interfaces. Otherwise, the behaviour of those subsystems
+ is tested from the TSFI interfaces. Or a combination of
+ the two may be employed. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the behaviour that is described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for the behaviour
+ description demonstrates the interactions among
+ subsystems as described in the TOE design.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ While the previous work unit addresses behaviour of subsystems,
+ this work unit addresses the interactions among
+ subsystems.
+
+ If TSF subsystem interfaces are provided, the
+ interactions with other subsystems may be performed
+ directly from those interfaces. Otherwise, the
+ interactions among subsystems must be inferred from the
+ TSFI interfaces. Whatever strategy is used the evaluator
+ will consider its appropriateness for adequately testing
+ the interactions among subsystems that are described in
+ the TOE design.
+
+
+
+
+ The evaluator shall examine the depth of testing
+ analysis to determine that the interfaces of TSF modules
+ are included within the test documentation.
+
+ This work unit verifies the content of the
+ correspondence between the tests and the descriptions in
+ the TOE design. A simple cross-table may be sufficient
+ to show test correspondence. The identification of the
+ tests and the behaviour/interaction presented in the
+ depth-of coverage analysis has to be unambiguous.
+
+ The evaluator is reminded that not all tests in the test
+ documentation must map to a subsystem behaviour or
+ interaction description.
+
+
+
+
+ The evaluator shall examine the test plan, test
+ prerequisites, test steps and expected result(s) to
+ determine that the testing approach for each TSF module
+ interface demonstrates the expected behaviour of that
+ interface.
+
+ Guidance on this work unit can be found in:
+
+
+
+
+
+
+
+
+ Testing of an interface may be performed directly
+ at that interface, or at the external interfaces, or a
+ combination of both. Whatever strategy is used the
+ evaluator will consider its appropriateness for
+ adequately testing the interfaces. Specifically the
+ evaluator determines whether testing at the internal
+ interfaces is necessary or whether these internal
+ interfaces can be adequately tested (albeit implicitly)
+ by exercising the external interfaces. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+
+
+ The evaluator shall examine the test procedures to
+ determine that all descriptions of TSF subsystem
+ behaviour and interaction are tested.
+
+ This work unit verifies the completeness of work unit
+ . All descriptions
+ of TSF subsystem behaviour and of interactions among TSF
+ subsystems that are provided in the TOE design have to
+ be tested. Incomplete depth of testing would be evident
+ if a description of TSF subsystem behaviour or of
+ interactions among TSF subsystems was identified in the
+ TOE design and no tests could be attributed to
+ it.
+
+ The evaluator is reminded that this does not imply that all
+ tests in the test documentation must map to the subsystem behaviour
+ or interaction description in the TOE design.
+
+
+
+
+ The evaluator shall examine the test procedures to determine
+ that all interfaces of all TSF modules are tested.
+
+ This work unit verifies the completeness of work unit
+ . All interfaces
+ of TSF modules that are provided in the TOE design have
+ to be tested. Incomplete depth of testing would be
+ evident if any interface of any TSF module was
+ identified in the TOE design and no tests could be
+ attributed to it.
+ The evaluator is reminded that this does not imply
+ that all tests in the test documentation must map to an
+ interface of a TSF module in the TOE design.
+
+
+
+
+
+
+
+
+
+
+
+ The subsystem and module descriptions of the TSF provide a
+ high-level description of the internal workings, and a
+ description of the interfaces of the modules, of the
+ TSF. Testing at this level of TOE description provides
+ assurance that the TSF subsystems and modules behave and
+ interact as described in the TOE design and the security
+ architecture description, and in accordance with the
+ implementation representation.
+
+
+ The developer shall provide the analysis of the depth of
+ testing.
+
+
+ The analysis of the depth of testing shall demonstrate the
+ correspondence between the tests in the test documentation
+ and the TSF subsystems and modules in the TOE design.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all TSF subsystems in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ all modules in the TOE design have been tested.
+
+
+ The analysis of the depth of testing shall demonstrate that
+ the TSF operates in accordance with its implementation
+ representation.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ Functional testing performed by the developer provides
+ assurance that the tests in the test documentation are
+ performed and documented correctly. The correspondence of
+ these tests to the design descriptions of the TSF is
+ achieved through the and
+ families.
+
+ This family contributes to providing assurance that the
+ likelihood of undiscovered flaws is relatively small.
+
+ The families , and are used in combination to define the evidence
+ of testing to be supplied by a developer. Independent
+ functional testing by the evaluator is specified by .
+
+
+
+ Functional testing establishes that the tests performed by
+ the developer are performed and documented correctly.
+
+
+
+ This family contains two components, the higher requiring
+ that ordering dependencies are analysed.
+
+
+
+ Procedures for performing tests are expected to provide
+ instructions for using test programs and test suites,
+ including the test environment, test conditions, test data
+ parameters and values. The test procedures should also show
+ how the test results are derived from the test
+ inputs.
+
+ Ordering dependencies are relevant when the successful
+ execution of a particular test depends upon the existence of
+ a particular state. For example, this might require that
+ test A be executed immediately before test B, since the
+ state resulting from the successful execution of test A is a
+ prerequisite for the successful execution of test B. Thus,
+ failure of test B could be related to a problem with the
+ ordering dependencies. In the above example, test B could
+ fail because test C (rather than test A) was executed
+ immediately before it, or the failure of test B could be
+ related to a failure of test A.
+
+
+
+
+
+ The objective is for the developer to demonstrate that the
+ tests in the test documentation are performed and
+ documented correctly.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the developer correctly performed and documented the tests
+ in the test documentation.
+
+
+
+ The extent to which the test documentation is required to
+ cover the TSF is dependent upon the coverage assurance
+ component.
+
+ For the developer tests provided, the evaluator determines
+ whether the tests are repeatable, and the extent to which
+ the developer's tests can be used for the evaluator's
+ independent testing effort. Any TSFI for which the
+ developer's test results indicate that it might not
+ perform as specified should be tested independently by the
+ evaluator to determine whether or not it does.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the test documentation.
+
+
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall check that the test documentation
+ includes test plans, expected test results and actual
+ test results.
+
+ The evaluator checks that test plans, expected tests
+ results and actual test results are included in the test
+ documentation.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that it describes the scenarios for performing each
+ test.
+
+ The evaluator determines that the test plan provides
+ information about the test configuration being used:
+ both on the configuration of the TOE and on any test
+ equipment being used. This information should be
+ detailed enough to ensure that the test configuration is
+ reproducible.
+
+ The evaluator also determines that the test plan
+ provides information about how to execute the test: any
+ necessary automated set-up procedures (and whether they
+ require privilege to run), inputs to be applied, how
+ these inputs are applied, how output is obtained, any
+ automated clean-up procedures (and whether they require
+ privilege to run), etc. This information should be
+ detailed enough to ensure that the test is
+ reproducible.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test plan to determine
+ that the TOE test configuration is consistent with the
+ ST.
+
+ The TOE referred to in the developer's test plan should
+ have the same unique reference as established by the
+ sub-activities and
+ identified in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The evaluator verifies
+ that all test configurations identified in the developer
+ test documentation are consistent with the ST. For
+ example, the ST might define configuration options that
+ must be set, which could have an impact upon what
+ constitutes the TOE by including or excluding additional
+ portions. The evaluator verifies that all such
+ variations of the TOE are considered.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+ If this work unit is applied to a component TOE that
+ might be used/integrated in a composed TOE (see ), the following will apply. In
+ the instances that the component TOE under evaluation
+ depends on other components in the operational
+ environment to support their operation, the developer
+ may wish to consider using the other component(s) that
+ will be used in the composed TOE to fulfil the
+ requirements of the operational environment as one of
+ the test configurations. This will reduce the amount an
+ additional testing that will be required for the
+ composed TOE evaluation.
+
+
+
+
+ The evaluator shall examine the test plans to determine
+ that sufficient instructions are provided for any
+ ordering dependencies.
+
+ Some steps may have to be performed to establish initial
+ conditions. For example, user accounts need to be added
+ before they can be deleted. An example of ordering
+ dependencies on the results of other tests is the need
+ to perform actions in a test that will result in the
+ generation of audit records, before performing a test to
+ consider the searching and sorting of those audit
+ records. Another example of an ordering dependency
+ would be where one test case generates a file of data to
+ be used as input for another test case.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall examine the test documentation to
+ determine that all expected tests results are
+ included.
+
+ The expected test results are needed to determine
+ whether or not a test has been successfully
+ performed. Expected test results are sufficient if they
+ are unambiguous and consistent with expected behaviour
+ given the testing approach.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall check that the actual test results
+ in the test documentation are consistent with the
+ expected test results in the test documentation.
+
+ A comparison of the actual and expected test results
+ provided by the developer will reveal any
+ inconsistencies between the results. It may be that a
+ direct comparison of actual results cannot be made until
+ some data reduction or synthesis has been first
+ performed. In such cases, the developer's test
+ documentation should describe the process to reduce or
+ synthesise the actual data.
+
+ For example, the developer may need to test the contents
+ of a message buffer after a network connection has
+ occurred to determine the contents of the buffer. The
+ message buffer will contain a binary number. This binary
+ number would have to be converted to another form of
+ data representation in order to make the test more
+ meaningful. The conversion of this binary representation
+ of data into a higher-level representation will have to
+ be described by the developer in enough detail to allow
+ an evaluator to perform the conversion process
+ (i.e. synchronous or asynchronous transmission, number
+ of stop bits, parity, etc.).
+
+ It should be noted that the description of the process
+ used to reduce or synthesise the actual data is used by
+ the evaluator not to actually perform the necessary
+ modification but to assess whether this process is
+ correct. It is up to the developer to transform the
+ expected test results into a format that allows an easy
+ comparison with the actual test results.
+
+ The evaluator may wish to employ a sampling strategy
+ when performing this work unit.
+
+
+
+
+ The evaluator shall report the developer testing effort,
+ outlining the testing approach, configuration, depth and
+ results.
+
+ The developer testing information recorded in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing of the TOE by the developer. The intent
+ of providing this information is to give a meaningful overview
+ of the developer testing effort. It is not intended that the
+ information regarding developer testing in the ETR be an exact
+ reproduction of specific test steps or results of individual
+ tests. The intention is to provide enough detail to allow other
+ evaluators and evaluation authorities to gain some insight about the
+ developer's testing approach, amount of testing performed, TOE
+ test configurations, and the overall results of the developer
+ testing.
+
+ Information that would typically be found in the ETR
+ subclause regarding the developer testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested,
+ including whether any privileged code was required
+ to set up the test or clean up afterwards;
+
+
+ testing approach. An account of the overall
+ developer testing strategy employed;
+
+
+ testing results. A description of the overall
+ developer testing results.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ developer testing effort.
+
+
+
+
+
+
+
+
+ The objectives are for the developer to demonstrate that
+ the tests in the test documentation are performed and
+ documented correctly, and to ensure that testing is
+ structured such as to avoid circular arguments about the
+ correctness of the interfaces being tested.
+
+
+
+ Although the test procedures may state pre-requisite
+ initial test conditions in terms of ordering of tests,
+ they may not provide a rationale for the ordering. An
+ analysis of test ordering is an important factor in
+ determining the adequacy of testing, as there is a
+ possibility of faults being concealed by the ordering of
+ tests.
+
+
+ The developer shall test the TSF and document the results.
+
+
+ The developer shall provide test documentation.
+
+
+ The test documentation shall consist of test plans, expected
+ test results and actual test results.
+
+
+ The test plans shall identify the tests to be performed and
+ describe the scenarios for performing each test. These
+ scenarios shall include any ordering dependencies on the
+ results of other tests.
+
+
+ The expected test results shall show the anticipated outputs
+ from a successful execution of the tests.
+
+
+ The actual test results shall be consistent with the
+ expected test results.
+
+
+ The test documentation shall include an analysis of the test
+ procedure ordering dependencies.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+
+
+
+ The objectives of this family are built upon the assurances
+ achieved in the , , and
+ families by verifying the developer testing and performing
+ additional tests by the evaluator.
+
+
+
+ Independent testing specifies the degree to which the
+ testing of the TSF must be performed by a party other than
+ the developer (e.g. a third party). This family adds value
+ by the introduction of tests that are not part of the
+ developer's tests.
+
+
+
+ Levelling is based upon the amount of developer test
+ documentation and test support and the amount of evaluator
+ testing.
+
+
+
+ This family deals with the degree to which there is
+ independent functional testing of the TSF. Independent
+ functional testing may take the form of repeating the
+ developer's functional tests (in whole or in part) or of
+ extending the scope or the depth of the developer's
+ tests. These activities are complementary, and an
+ appropriate mix must be planned for each TOE, which takes
+ into account the availability and coverage of test results,
+ and the functional complexity of the TSF.
+
+ Sampling of developer tests is intended to provide
+ confirmation that the developer has carried out his planned
+ test programme on the TSF, and has correctly recorded the
+ results. The size of sample selected will be influenced by
+ the detail and quality of the developer's functional test
+ results. The evaluator will also need to consider the scope
+ for devising additional tests, and the relative benefit that
+ may be gained from effort in these two areas. It is
+ recognised that repetition of all developer tests may be
+ feasible and desirable in some cases, but may be very
+ arduous and less productive in others. The highest component
+ in this family should therefore be used with
+ caution. Sampling will address the whole range of test
+ results available, including those supplied to meet the
+ requirements of both and
+ .
+
+ There is also a need to consider the different
+ configurations of the TOE that are included within the
+ evaluation. The evaluator will need to assess the
+ applicability of the results provided, and to plan his own
+ testing accordingly.
+
+ The suitability of the TOE for testing is based on the
+ access to the TOE, and the supporting documentation and
+ information required (including any test software or tools)
+ to run tests. The need for such support is addressed by the
+ dependencies to other assurance families.
+
+ Additionally, suitability of the TOE for testing may be
+ based on other considerations. For example, the version of
+ the TOE submitted by the developer may not be the final
+ version.
+
+ The term interfaces refers to interfaces
+ described in the functional specification and TOE design,
+ and parameters passed through invocations identified in the
+ implementation representation. The exact set of interfaces
+ to be used is selected through and the
+ components.
+
+ References to a subset of the interfaces are intended to
+ allow the evaluator to design an appropriate set of tests
+ which is consistent with the objectives of the evaluation
+ being conducted.
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents.
+
+
+
+ This component does not address the use of developer test
+ results. It is applicable where such results are not
+ available, and also in cases where the developer's testing
+ is accepted without validation. The evaluator is required
+ to devise and conduct tests with the objective of
+ confirming that the TOE operates in accordance with its
+ design representations, including but not limited to the
+ functional specification. The approach is to gain
+ confidence in correct operation through representative
+ testing, rather than to conduct every possible test. The
+ extent of testing to be planned for this purpose is a
+ methodology issue, and needs to be considered in the
+ context of a particular TOE and the balance of other
+ evaluation activities.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSFI, whether the
+ TOE behaves as specified in the functional specification
+ and guidance documentation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer should have the same
+ unique reference as established by the sub-activities and identified
+ in the ST introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state.
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall test a subset of the TSF to confirm that
+ the TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of the
+ interfaces. In other cases this may not be
+ cost-effective, and sampling is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of the interface. Complex interfaces may
+ require complex tests that impose onerous
+ requirements on the developer or evaluator, which
+ may not be conducive to cost-effective
+ evaluations. Conversely, they are a likely area to
+ find errors and are good candidates for the
+ subset. The evaluator will need to strike a balance
+ between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST and the functional specification, the
+ evaluator has to determine the most feasible way to test
+ the interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection, if the
+ implementation representation is available);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the behaviour of the
+ interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing activity during the evaluation. The
+ intent of providing this information is to give a meaningful
+ overview of the testing effort. It is not intended that the
+ information regarding testing in the ETR be an exact
+ reproduction of specific test instructions or results of
+ individual tests. The intention is to provide enough detail to
+ allow other evaluators and evaluation authorities to gain some insight about
+ the testing approach chosen, amount of testing performed, TOE
+ test configurations, and the overall results of the testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested;
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size;
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset;
+
+
+ interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset;
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate that
+ the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ confirms that the developer performed some tests of some
+ interfaces in the functional specification.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ This component contains a requirement that the evaluator
+ has available test results from the developer to
+ supplement the programme of testing. The evaluator will
+ repeat a sample of the developer's tests to gain
+ confidence in the results obtained. Having established
+ such confidence the evaluator will build upon the
+ developer's testing by conducting additional tests that
+ exercise the TOE in a different manner. By using a
+ platform of validated developer test results the evaluator
+ is able to gain confidence that the TOE operates correctly
+ in a wider range of conditions than would be possible
+ purely using the developer's own efforts, given a fixed
+ level of resource. Having gained confidence that the
+ developer has tested the TOE, the evaluator will also have
+ more freedom, where appropriate, to concentrate testing in
+ areas where examination of documentation or specialist
+ knowledge has raised particular concerns.
+
+
+
+ The goal of this activity is to determine, by
+ independently testing a subset of the TSF, whether the TOE
+ behaves as specified in the design documentation, and to
+ gain confidence in the developer's test results by
+ performing a sample of the developer's tests.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the functional specification;
+
+
+ the TOE design description;
+
+
+ the operational user guidance;
+
+
+ the preparative user guidance;
+
+
+ the configuration management documentation;
+
+
+ the test documentation;
+
+
+ the TOE suitable for testing.
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state.
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+
+ The evaluator shall examine the set of resources provided by the developer
+ to determine that they are equivalent to the set of resources used by the
+ developer to functionally test the TSF.
+
+ The set of resource used by the developer is documented
+ in the developer test plan, as considered in the family. The resource set may
+ include laboratory access and special test equipment,
+ among others. Resources that are not identical to those
+ used by the developer need to be equivalent in terms of
+ any impact they may have on test results.
+
+
+
+ The evaluator shall execute a sample of tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall conduct testing using a sample of
+ tests found in the developer test plan and
+ procedures.
+
+ The overall aim of this work unit is to perform a
+ sufficient number of the developer tests to confirm the
+ validity of the developer's test results. The evaluator
+ has to decide on the size of the sample, and the
+ developer tests that will compose the sample (see ).
+
+ All the developer tests can be traced back to specific
+ interfaces. Therefore, the factors to consider in the
+ selection of the tests to compose the sample are similar
+ to those listed for subset selection in work-unit . Additionally, the
+ evaluator may wish to employ a random sampling method to
+ select developer tests to include in the sample.
+
+
+
+ The evaluator shall check that all the actual test
+ results are consistent with the expected test
+ results.
+
+ Inconsistencies between the developer's expected test
+ results and actual test results will compel the
+ evaluator to resolve the discrepancies. Inconsistencies
+ encountered by the evaluator could be resolved by a
+ valid explanation and resolution of the inconsistencies
+ by the developer.
+
+ If a satisfactory explanation or resolution can not be reached,
+ the evaluator's confidence in the developer's test results may be
+ lessened and it may be necessary for the evaluator to increase
+ the sample size to the extent that the subset identified in work unit
+ is adequately tested:
+ deficiencies with the developer's tests need to result in either
+ corrective action to the TOE by the developer (e.g., if the inconsistency
+ is caused by incorrect behaviour) or to the developer's tests (e.g., if the
+ inconsistency is caused by an incorrect test), or in the production of new
+ tests by the evaluator.
+
+
+
+ The evaluator shall test a subset of the TSF to confirm that the
+ TSF operates as specified.
+
+
+ The evaluator shall devise a test subset.
+
+ The evaluator selects a test subset and testing strategy
+ that is appropriate for the TOE. One extreme testing
+ strategy would be to have the test subset contain as
+ many interfaces as possible tested with little
+ rigour. Another testing strategy would be to have the
+ test subset contain a few interfaces based on their
+ perceived relevance and rigorously test these
+ interfaces.
+
+ Typically the testing approach taken by the evaluator
+ should fall somewhere between these two extremes. The
+ evaluator should exercise most of the interfaces using
+ at least one test, but testing need not demonstrate
+ exhaustive specification testing.
+
+ The evaluator, when selecting the subset of the
+ interfaces to be tested, should consider the following
+ factors:
+
+
+ The developer test evidence. The developer test
+ evidence consists of: the test documentation, the
+ available test coverage analysis, and the available
+ depth of testing analysis. The developer test
+ evidence will provide insight as to how the TSF has
+ been exercised by the developer during testing. The
+ evaluator applies this information when developing
+ new tests to independently test the
+ TOE. Specifically the evaluator should consider:
+
+
+ augmentation of developer testing for
+ interfaces. The evaluator may wish to perform
+ more of the same type of tests by varying
+ parameters to more rigorously test the
+ interface.
+
+
+ supplementation of developer testing strategy
+ for interfaces. The evaluator may wish to vary
+ the testing approach of a specific interface by
+ testing it using another test strategy.
+
+
+
+
+ The number of interfaces from which to draw upon for
+ the test subset. Where the TSF includes only a small
+ number of relatively simple interfaces, it may be
+ practical to rigorously test all of them. In other
+ cases this may not be cost-effective, and sampling
+ is required.
+
+
+ Maintaining a balance of evaluation activities. The
+ evaluator effort expended on the test activity
+ should be commensurate with that expended on any
+ other evaluation activity.
+
+
+
+ The evaluator selects the interfaces to compose the
+ subset. This selection will depend on a number of
+ factors, and consideration of these factors may also
+ influence the choice of test subset size:
+
+
+ Rigour of developer testing of the interfaces. Those
+ interfaces that the evaluator determines require
+ additional testing should be included in the test
+ subset.
+
+
+ Developer test results. If the results of developer
+ tests cause the evaluator to doubt that an interface
+ is not properly implemented, then the evaluator
+ should include such interfaces in the test subset.
+
+
+ Significance of interfaces. Those interfaces more
+ significant than others should be included in the
+ test subset. One major factor of ``significance'' is
+ the security-relevance (SFR-enforcing interfaces
+ would be more significant than SFR-supporting
+ interfaces, which are more significant than
+ SFR-non-interfering interfaces; see CC Part 3
+ Subclause ). The other
+ major factor of ``significance'' is the number of
+ SFRs mapping to this interface (as determined when
+ identifying the correspondence between levels of
+ abstraction in ).
+
+
+ Complexity of interfaces. Interfaces that require
+ complex implementation may require complex tests
+ that impose onerous requirements on the developer or
+ evaluator, which may not be conducive to
+ cost-effective evaluations. Conversely, they are a
+ likely area to find errors and are good candidates
+ for the subset. The evaluator will need to strike a
+ balance between these considerations.
+
+
+ Implicit testing. Testing some interfaces may often
+ implicitly test other interfaces, and their
+ inclusion in the subset may maximise the number of
+ interfaces tested (albeit implicitly). Certain
+ interfaces will typically be used to provide a
+ variety of security functionality, and will tend to
+ be the target of an effective testing approach.
+
+
+ Types of interfaces (e.g. programmatic,
+ command-line, protocol). The evaluator should
+ consider including tests for all different types of
+ interfaces that the TOE supports.
+
+
+ Interfaces that give rise to features that are
+ innovative or unusual. Where the TOE contains
+ innovative or unusual features, which may feature
+ strongly in marketing literature and guidance
+ documents, the corresponding interfaces should be
+ strong candidates for testing.
+
+
+
+ This guidance articulates factors to consider during the
+ selection process of an appropriate test subset, but
+ these are by no means exhaustive.
+
+
+ The evaluator shall produce test documentation for the
+ test subset that is sufficiently detailed to enable the
+ tests to be reproducible.
+
+ With an understanding of the expected behaviour of the
+ TSF, from the ST, the functional specification, and the
+ TOE design description, the evaluator has to determine
+ the most feasible way to test the
+ interface. Specifically the evaluator considers:
+
+
+ the approach that will be used, for instance,
+ whether an external interface will be tested, or an
+ internal interface using a test harness, or will an
+ alternate test approach be employed (e.g. in
+ exceptional circumstances, a code inspection);
+
+
+ the interface(s) that will be used to test and
+ observe responses;
+
+
+ the initial conditions that will need to exist for
+ the test (i.e. any particular objects or subjects
+ that will need to exist and security attributes they
+ will need to have);
+
+
+ special test equipment that will be required to
+ either stimulate an interface (e.g. packet
+ generators) or make observations of an interface
+ (e.g. network analysers).
+
+
+
+ The evaluator may find it practical to test each
+ interface using a series of test cases, where each test
+ case will test a very specific aspect of expected
+ behaviour of that interface.
+
+ The evaluator's test documentation should specify the
+ derivation of each test, tracing it back to the relevant
+ interface(s).
+
+
+ The evaluator shall conduct testing.
+
+ The evaluator uses the test documentation developed as a
+ basis for executing tests on the TOE. The test
+ documentation is used as a basis for testing but this
+ does not preclude the evaluator from performing
+ additional ad hoc tests. The evaluator may devise new
+ tests based on behaviour of the TOE discovered during
+ testing. These new tests are recorded in the test
+ documentation.
+
+
+ The evaluator shall record the following information
+ about the tests that compose the test subset:
+
+
+ identification of the interface behaviour to be
+ tested;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the test;
+
+
+ instructions to establish all prerequisite test
+ conditions;
+
+
+ instructions to stimulate the interface;
+
+
+ instructions for observing the interface;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE;
+
+
+ actual test results.
+
+
+
+ The level of detail should be such that another
+ evaluator could repeat the tests and obtain an
+ equivalent result. While some specific details of the
+ test results may be different (e.g. time and date fields
+ in an audit record) the overall result should be
+ identical.
+
+ There may be instances when it is unnecessary to provide
+ all the information presented in this work unit
+ (e.g. the actual test results of a test may not require
+ any analysis before a comparison between the expected
+ results can be made). The determination to omit this
+ information is left to the evaluator, as is the
+ justification.
+
+
+ The evaluator shall check that all actual test results
+ are consistent with the expected test results.
+
+ Any differences in the actual and expected test results
+ may indicate that the TOE does not perform as specified
+ or that the evaluator test documentation may be
+ incorrect. Unexpected actual results may require
+ corrective maintenance to the TOE or test documentation
+ and perhaps require re-running of impacted tests and
+ modifying the test sample size and composition. This
+ determination is left to the evaluator, as is its
+ justification.
+
+
+ The evaluator shall report in the ETR the evaluator
+ testing effort, outlining the testing approach,
+ configuration, depth and results.
+
+ The evaluator testing information reported in the ETR allows the
+ evaluator to convey the overall testing approach and effort
+ expended on the testing activity during the evaluation. The
+ intent of providing this information is to give a meaningful
+ overview of the testing effort. It is not intended that the
+ information regarding testing in the ETR be an exact
+ reproduction of specific test instructions or results of
+ individual tests. The intention is to provide enough detail to
+ allow other evaluators and evaluation authorities to gain some insight about
+ the testing approach chosen, amount of evaluator testing
+ performed, amount of developer tests performed, TOE test
+ configurations, and the overall results of the testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding the evaluator testing effort is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were tested.
+
+
+ subset size chosen. The amount of interfaces that
+ were tested during the evaluation and a
+ justification for the size.
+
+
+ selection criteria for the interfaces that compose
+ the subset. Brief statements about the factors
+ considered when selecting interfaces for inclusion
+ in the subset.
+
+
+ Interfaces tested. A brief listing of the interfaces
+ that merited inclusion in the subset.
+
+
+ developer tests performed. The amount of developer
+ tests performed and a brief description of the
+ criteria used to select the tests.
+
+
+ verdict for the activity. The overall judgement on
+ the results of testing during the evaluation.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the testing
+ the evaluator performed during the evaluation.
+
+
+
+
+
+
+
+
+
+
+ In this component, the objective is to demonstrate
+ that the TOE operates in accordance with its design
+ representations and guidance documents. Evaluator testing
+ includes repeating all of the developer tests.
+
+
+
+ The intent is that the developer should provide the
+ evaluator with materials necessary for the efficient
+ reproduction of developer tests. This may include such
+ things as machine-readable test documentation, test
+ programs, etc.
+
+ In this component the evaluator must repeat all of the
+ developer's tests as part of the programme of testing. As
+ in the previous component the evaluator will also conduct
+ tests that aim to exercise the TSF in a different manner
+ from that achieved by the developer. In cases where
+ developer testing has been exhaustive, there may remain
+ little scope for this.
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The developer shall provide an equivalent set of resources
+ to those that were used in the developer's functional
+ testing of the TSF.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall execute all tests in the test
+ documentation to verify the developer test results.
+
+
+ The evaluator shall test the TSF to confirm that the entire
+ TSF operates as specified.
+
+
+
+
+
+
+
+ The class addresses the
+ possibility of exploitable vulnerabilities introduced in the
+ development or the operation of the TOE.
+
+
+
+ Assurance class defines
+ requirements directed at the identification of exploitable
+ vulnerabilities. Specifically, it addresses those
+ vulnerabilities introduced in the development, operation,
+ misuse, or incorrect configuration of the TOE.
+
+
+
+ Generally, the vulnerability assessment activity covers various
+ vulnerabilities in the development and operation of the
+ TOE. Development vulnerabilities take advantage of some property
+ of the TOE which was introduced during its development,
+ e.g. defeating the TSF self protection through tampering, direct
+ attack or monitoring of the TSF, defeating the TSF domain
+ separation through monitoring or direct attack the TSF, or
+ defeating non-bypassability through circumventing (bypassing)
+ the TSF. Operational vulnerabilities take advantage of
+ weaknesses in non-technical countermeasures to violate the TOE
+ SFRs, e.g. misuse or incorrect configuration. Misuse
+ investigates whether the TOE can be configured or used in a
+ manner that is insecure, but that an administrator or user of
+ the TOE would reasonably believe to be secure.
+
+ Assessment of development vulnerabilities is covered by the
+ assurance family . Basically,
+ all development vulnerabilities can be considered in the
+ context of due to the fact,
+ that this family allows application of a wide range of
+ assessment methodologies being unspecific to the kind of an
+ attack scenario. These unspecific assessment methodologies
+ comprise, among other, also the specific methodologies for
+ those TSF where covert channels are to be considered (a
+ channel capacity estimation can be done using informal
+ engineering measurements, as well as actual test measurements)
+ or can be overcome by the use of sufficient resources in the
+ form of a direct attack (underlying technical concept of those
+ TSF is based on probabilistic or permutational mechanisms; a
+ qualification of their security behaviour and the effort
+ required to overcome them can be made using a quantitative or
+ statistical analysis).
+
+ If there are security objectives specified in the ST to either
+ to prevent one user of the TOE from observing activity
+ associated with another user of the TOE, or to ensure that
+ information flows cannot be used to achieve enforced illicit
+ data signals, covert channel analysis should be considered
+ during the conduct of the vulnerability analysis. This is often
+ reflected by the inclusion of
+ and multilevel access control policies specified through and/or requirements in the ST.
+
+
+
+ The purpose of the vulnerability assessment activity is to
+ determine the exploitability of flaws or weaknesses in the TOE
+ in the operational environment. This determination is based
+ upon analysis of the evaluation evidence and a search of
+ publicly available material by the evaluator and is supported
+ by evaluator penetration testing.
+
+
+
+
+ Vulnerability analysis is an assessment to determine whether
+ potential vulnerabilities identified, during the evaluation
+ of the development and anticipated operation of the TOE or
+ by other methods (e.g. by flaw hypotheses or quantitative or
+ statistical analysis of the security behaviour of the
+ underlying security mechanisms), could allow attackers to
+ violate the SFRs.
+
+ Vulnerability analysis deals with the threats that an
+ attacker will be able to discover flaws that will allow
+ unauthorised access to data and functionality, allow the
+ ability to interfere with or alter the TSF, or interfere
+ with the authorised capabilities of other users.
+
+
+
+ Vulnerability analysis consists of the identification of
+ flaws potentially introduced in the different refinement
+ steps of the development (development vulnerabilities) or
+ through the application of the guidance in operation of the
+ TOE (operational vulnerabilities). It results in the
+ definition of penetration tests through the collection of
+ the necessary information concerning: (1) the completeness
+ of the TSF (does the TSF counter all the postulated
+ threats?), (2) the dependencies between all SFRs and (3)
+ whether any of the SFRs can be undermined through unexpected
+ behaviour of the TOE. These potential vulnerabilities are
+ assessed through penetration testing to determine whether
+ they could, in practise, be exploitable to compromise the
+ security of the TOE.
+
+ The characteristics of different levels of attack potential
+ are discussed in CEM .
+
+
+
+ Levelling is based on an increasing rigour of vulnerability
+ analysis by the evaluator and increased levels of attack
+ potential required by an attacker to identify and exploit
+ the potential vulnerabilities.
+
+
+
+
+
+
+
+ A vulnerability survey of information available in the
+ public domain is performed by the evaluator to ascertain
+ potential vulnerabilities that may be easily found by an
+ attacker.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has easily
+ identifiable exploitable vulnerabilities.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during the conduct of other parts of the
+ evaluation.
+
+ The use of the term guidance in this sub-activity refers
+ to the operational guidance and the preparative
+ guidance.
+
+ Potential vulnerabilities may be in information that is
+ publicly available, or not, and may require skill to
+ exploit, or not. These two aspects are related, but are
+ distinct. It should not be assumed that, simply because a
+ potential vulnerability is identifiable from information
+ that is publicly available, it can be easily
+ exploited.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+
+ the guidance documentation;
+
+
+ the TOE suitable for testing;
+
+
+ information publicly available to support the
+ identification of potential vulnerabilities.
+
+
+
+ Other input for this sub-activity is:
+
+
+ current information regarding potential
+ vulnerabilities (e.g. from an evaluation authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information, which
+ should be considered, e.g. mailing lists and security
+ forums on the world wide web that report known
+ vulnerabilities in specified technologies.
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks effectively operates to substantially
+ enhance the attack potential of a given attacker. The
+ accessibility of vulnerability information and
+ sophisticated attack tools on the Internet makes it more
+ likely that this information will be used in attempts to
+ identify potential vulnerabilities in the TOE and
+ exploit them. Modern search tools make such information
+ easily available to the evaluator, and the determination
+ of resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the information
+ publicly available. However, in this type of search, the
+ evaluator may not be able to describe the steps in
+ identifying potential vulnerabilities before the outset
+ of the examination, as the approach may evolve as a
+ result of findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses;
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers a potential vulnerability that is beyond Basic
+ attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing Basic
+ attack potential.
+
+
+
+ The evaluator should consider performing additional tests
+ as a result of potential vulnerabilities encountered
+ during other parts of the evaluation.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer specifically to
+ the product from which the TOE is derived. The
+ extensiveness of this search should consider the
+ following factors: TOE type, evaluator experience in
+ this TOE type, expected attack potential and the level
+ of evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent vulnerability
+ analysis of the TOE using the guidance documentation,
+ functional specification, TOE design and security
+ architecture description to identify potential
+ vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a search of ST, guidance
+ documentation, functional specification, TOE design and
+ security architecture description evidence to identify
+ possible potential vulnerabilities in the TOE.
+
+ A search of the evidence should be completed whereby
+ specifications and documentation for the TOE are
+ analysed and then potential vulnerabilities in the TOE
+ are hypothesised, or speculated. The list of
+ hypothesised potential vulnerabilities is then
+ prioritised on the basis of the estimated probability
+ that a potential vulnerability exists and, assuming an
+ exploitable vulnerability does exist the attack
+ potential required to exploit it, and on the extent of
+ control or compromise it would provide. The prioritised
+ list of potential vulnerabilities is used to direct
+ penetration testing against the TOE.
+
+ The security architecture description provides the
+ developer vulnerability analysis, as it documents how
+ the TSF protects itself from interference from untrusted
+ subjects and prevents the bypass of security enforcement
+ functionality. Therefore, the evaluator should use this
+ description of the protection of the TSF as a basis for
+ the search for possible ways to undermine the
+ TSF.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the security
+ architecture description in the search for vulnerabilities (as
+ detailed in ), testing should
+ be performed to confirm the architectural properties. This is
+ likely to require negative tests attempting to disprove the
+ properties of the security architecture. In developing the
+ strategy for penetration testing, the evaluator will ensure that
+ each of the major characteristics of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ Basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Enhanced-Basic, Moderate or
+ High attack potential do not result in a failure of this
+ evaluator action. Where analysis supports the
+ hypothesis, these need not be considered further as an
+ input to penetration testing. However, such
+ vulnerabilities are reported in the ETR as residual
+ vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic attack potential and
+ resulting in a violation of the security objectives
+ should be the highest priority potential vulnerabilities
+ comprising the list used to direct penetration testing
+ against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Basic attack potential is required to
+ effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Basic attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming a Basic attack potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Basic attack potential. In
+ some cases, however, it will be necessary to carry out a
+ test before the exploitability can be determined. Where,
+ as a result of evaluation expertise, the evaluator
+ discovers an exploitable vulnerability that is beyond
+ basic attack potential, this is reported in the ETR as a
+ residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than an Enhanced-Basic attack
+ potential, then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Enhanced-Basic.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A vulnerability analysis is performed by the evaluator to
+ ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Enhanced-Basic.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Enhanced-Basic attack potential.
+
+
+
+ During the conduct of evaluation activities the evaluator
+ may also identify areas of concern. These are specific
+ portions of the TOE evidence that the evaluator has some
+ reservation about, although the evidence meets the
+ requirements for the activity with which the evidence is
+ associated. For example, a particular interface
+ specification looks particularly complex, and therefore
+ may be prone to error either in the development of the TOE
+ or in the operation of the TOE. There is no potential
+ vulnerability apparent at this stage, further
+ investigation is required. This is beyond the bounds of
+ encountered, as further investigation is required.
+
+ The focused approach to the identification of potential
+ vulnerabilities is an analysis of the evidence with the
+ aim of identifying any potential vulnerabilities evident
+ through the contained information. It is an unstructured
+ analysis, as the approach is not predetermined. Further
+ guidance on focused vulnerability analysis can be found in
+ Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation subset selected;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the identification of possible potential vulnerabilities;
+
+ the results of the testing of the basic design.
+
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examined in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+
+
+ The evaluator shall perform an independent, focused vulnerability analysis of the
+ TOE using the guidance documentation, functional specification, TOE design, security
+ architecture description and implementation representation to identify potential
+ vulnerabilities in the TOE.
+
+
+ The evaluator shall conduct a focused search of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ A flaw hypothesis methodology needs to be used whereby
+ specifications and development and guidance evidence are
+ analysed and then potential vulnerabilities in the TOE are
+ hypothesised, or speculated.
+
+ The evaluator uses the knowledge of the TOE design and operation
+ gained from the TOE deliverables to conduct a flaw hypothesis to
+ identify potential flaws in the development of the TOE and
+ potential errors in the specified method of operation of the
+ TOE.
+
+ The security architecture description provides the developer
+ vulnerability analysis, as it documents how the TSF protects
+ itself from interference from untrusted subjects and prevents
+ the bypass of security enforcement functionality. Therefore, the
+ evaluator should build upon the understanding of the TSF
+ protection gained from the analysis of this evidence and then
+ develop this in the knowledge gained from other development
+ evidence.
+
+
+ The approach taken is directed by areas of concern
+ identified during examination of the evidence during the
+ conduct of evaluation activities and ensuring a
+ representative sample of the development and guidance
+ evidence provided for the evaluation is searched.
+
+ For guidance on sampling see Annex . This guidance
+ should be considered when selecting the subset, giving
+ reasons for:
+
+
+ the approach used in selection;
+
+
+ qualification that the evidence to be examined
+ supports that approach.
+
+
+
+ The areas of concern may relate to the sufficiency of
+ specific protection features detailed in the security
+ architecture description.
+
+ The evidence to be considered during the vulnerability analysis
+ may be linked to the evidence the attacker is assumed to be able
+ to obtain. For example, the developer may protect the TOE design
+ and implementation representations, so the only information
+ assumed to be available to an attacker is the functional
+ specification and guidance (publicly available). So, although
+ the objectives for assurance in the TOE ensure the TOE design
+ and implementation representation requirements are met, these
+ design representations may only be searched to further
+ investigate areas of concerns.
+
+ On the other hand, if the source is publicly available it would
+ be reasonable to assume that the attacker has access to the
+ source and can use this in attempts to attack the
+ TOE. Therefore, the source should be considered in the focused
+ examination approach.
+
+ The following indicates examples for the selection of
+ the subset of evidence to be considered:
+
+
+ For an evaluation where all levels of design
+ abstraction from functional specification to
+ implementation representation are provided,
+ examination of information in the functional
+ specification and the implementation representation
+ may be selected, as the functional specification
+ provides detail of interfaces available to an
+ attacker, and the implementation representation
+ incorporates the design decisions made at all other
+ design abstractions. Therefore, the TOE design
+ information will be considered as part of the
+ implementation representation.
+
+
+ Examination of a particular subset of information in
+ each of the design representations provided for the
+ evaluation.
+
+
+ Coverage of particular SFRs through each of the
+ design representations provided for the evaluation.
+
+
+ Examination of each of the design representations
+ provided for the evaluation, considering different
+ SFRs within each design representations.
+
+
+ Examination of aspects of the evidence provided for
+ the evaluation relating to current potential
+ vulnerability information the evaluator has received
+ (e.g. from a scheme).
+
+
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach; applying a system to the examination. The
+ evaluator is to describe the method to be used in terms
+ of what evidence will be considered, the information
+ within the evidence that is to be examined, the manner
+ in which this information is to be considered and the
+ hypothesis that is to be created.
+
+ The following provide some examples that a hypothesis
+ may take:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that ``all interface
+ specifications provided in the functional specification
+ and TOE design will be searched to hypothesise potential
+ vulnerabilities'' and go on to explain the methods used
+ in the hypothesis.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will report what actions were taken to
+ identify potential vulnerabilities in the
+ evidence. However, in this type of search, the evaluator
+ may not be able to describe the steps in identifying
+ potential vulnerabilities before the outset of the
+ examination, as the approach may evolve as a result of
+ findings during the search.
+
+ The evaluator will report the evidence examine in
+ completing the search for potential
+ vulnerabilities. This selection of evidence may be
+ derived from those areas of concern identified by the
+ evaluator, linked to the evidence the attacker is
+ assumed to be able to obtain, or according to another
+ rationale provided by the evaluator.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+ The evaluator shall conduct penetration testing, based on
+ the identified potential vulnerabilities, to determine that
+ the TOE is resistant to attacks performed by an attacker
+ possessing Enhanced-Basic attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the security
+ architecture description in the search for vulnerabilities (as
+ detailed in ), testing should
+ be performed to confirm the architectural properties. If
+ requirements from are included in
+ the SARs, the developer testing evidence will include testing
+ performed to confirm the correct implementation of any specific
+ mechanisms detailed in the security architecture
+ description. However, the developer testing will not necessarily
+ include testing of all aspects of the architectural properties
+ that protect the TSF, as much of this testing will be negative
+ testing in nature, attempting to disprove the properties. In
+ developing the strategy for penetration testing, the evaluator
+ will ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ It will probably be practical to carry out penetration
+ test using a series of test cases, where each test case
+ will test for a specific potential vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable
+ only by attackers possessing Moderate or High attack
+ potential do not result in a failure of this evaluator
+ action. Where analysis supports the hypothesis, these
+ need not be considered further as an input to
+ penetration testing. However, such vulnerabilities are
+ reported in the ETR as residual vulnerabilities.
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Basic or Enhanced-Basic attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which an Enhanced-Basic attack potential is
+ required to effect an attack. However, as a result of
+ evaluation expertise, the evaluator may discover a
+ potential vulnerability that is exploitable only by an
+ attacker with greater than Enhanced-Basic attack
+ potential. Such vulnerabilities are to be reported in
+ the ETR as residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI (although it is unlikely that specialist
+ equipment would be required to exploit a potential
+ vulnerability assuming an Enhanced-Basic attack
+ potential);
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required an Enhanced-Basic attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Enhanced-Basic attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing an Enhanced-Basic attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than Moderate attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than Moderate.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of Moderate.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing
+ Moderate attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the identification of possible potential vulnerabilities;
+
+ the results of the testing of the basic design.
+
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+
+ The evaluator shall examine the TOE to determine that
+ the test configuration is consistent with the
+ configuration under evaluation as specified in the
+ ST.
+
+ The TOE provided by the developer and identified in the
+ test plan should have the same unique reference as
+ established by the
+ sub-activities and identified in the ST
+ introduction.
+
+ It is possible for the ST to specify more than one
+ configuration for evaluation. The TOE may comprise a
+ number of distinct hardware and software entities that
+ need to be tested in accordance with the ST. The
+ evaluator verifies that all test configurations are
+ consistent with the ST.
+
+ The evaluator should consider the security objectives
+ for the operational environment described in the ST that
+ may apply to the test environment and ensure they are
+ met in the testing environment. There may be some
+ objectives for the operational environment that do not
+ apply to the test environment. For example, an objective
+ about user clearances may not apply; however, an
+ objective about a single point of connection to a
+ network would apply.
+
+ If any test resources are used (e.g. meters, analysers)
+ it will be the evaluator's responsibility to ensure that
+ these resources are calibrated correctly.
+
+
+
+
+ The evaluator shall examine the TOE to determine that it
+ has been installed properly and is in a known
+ state
+
+ It is possible for the evaluator to determine the state
+ of the TOE in a number of ways. For example, previous
+ successful completion of the sub-activity will satisfy this work unit
+ if the evaluator still has confidence that the TOE being
+ used for testing was installed properly and is in a
+ known state. If this is not the case, then the evaluator
+ should follow the developer's procedures to install and
+ start up the TOE, using the supplied guidance
+ only.
+
+ If the evaluator has to perform the installation
+ procedures because the TOE is in an unknown state, this
+ work unit when successfully completed could satisfy work
+ unit .
+
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall examine sources of information
+ publicly available to identify potential vulnerabilities
+ in the TOE.
+
+ The evaluator examines the sources of information
+ publicly available to support the identification of
+ possible potential vulnerabilities in the TOE. There are
+ many sources of publicly available information which the
+ evaluator should consider using items such as those
+ available on the world wide web, including:
+
+
+ specialist publications (magazines, books);
+
+
+ research papers;
+
+
+ conference proceedings.
+
+
+
+ The evaluator should not constrain their consideration
+ of publicly available information to the above, but
+ should consider any other relevant information
+ available.
+
+ While examining the evidence provided the evaluator will
+ use the information in the public domain to further
+ search for potential vulnerabilities. Where the
+ evaluators have identified areas of concern, the
+ evaluator should consider information publicly available
+ that relate to those areas of concern.
+
+ The availability of information that may be readily
+ available to an attacker that helps to identify and
+ facilitate attacks may substantially enhance the attack
+ potential of a given attacker. The accessibility of
+ vulnerability information and sophisticated attack tools
+ on the Internet makes it more likely that this
+ information will be used in attempts to identify
+ potential vulnerabilities in the TOE and exploit
+ them. Modern search tools make such information easily
+ available to the evaluator, and the determination of
+ resistance to published potential vulnerabilities and
+ well known generic attacks can be achieved in a
+ cost-effective manner.
+
+ The search of the information publicly available should
+ be focused on those sources that refer to the
+ technologies used in the development of the product from
+ which the TOE is derived. The extensiveness of this
+ search should consider the following factors: TOE type,
+ evaluator experience in this TOE type, expected attack
+ potential and the level of
+ evidence available.
+
+ The identification process is iterative, where the
+ identification of one potential vulnerability may lead
+ to identifying another area of concern that requires
+ further investigation.
+
+ The evaluator will describe the approach to be taken to
+ identify potential vulnerabilities in the publicly
+ available material, detailing the search to be
+ performed. This may be driven by factors such as areas
+ of concern identified by the evaluator, linked to the
+ evidence the attacker is assumed to be able to obtain.
+ However, it is recognised that in this type of search
+ the approach may further evolve as a result of findings
+ during the search. Therefore, the evaluator will also
+ report any actions taken in addition to those described
+ in the approach to further investigate issues thought to
+ lead to potential vulnerabilities, and will report the
+ evidence examined in completing the search for potential
+ vulnerabilities.
+
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct a methodical analysis of ST,
+ guidance documentation, functional specification, TOE
+ design, security architecture description and
+ implementation representation to identify possible
+ potential vulnerabilities in the TOE.
+
+ Guidance on methodical vulnerability analysis is
+ provided in Annex .
+
+ This approach to identification of potential
+ vulnerabilities is to take an ordered and planned
+ approach. A system is to be applied in the
+ examination. The evaluator is to describe the method to
+ be used in terms of the manner in which this information
+ is to be considered and the hypothesis that is to be
+ created.
+
+ A flaw hypothesis methodology needs to be used whereby the ST,
+ development (functional specification, TOE design and
+ implementation representation) and guidance evidence are
+ analysed and then vulnerabilities in the TOE are hypothesised,
+ or speculated.
+
+ The evaluator uses the knowledge of the TOE design and operation
+ gained from the TOE deliverables to conduct a flaw hypothesis to
+ identify potential flaws in the development of the TOE and
+ potential errors in the specified method of operation of the
+ TOE.
+
+ The security architecture description provides the developer
+ vulnerability analysis, as it documents how the TSF protects
+ itself from interference from untrusted subjects and prevents
+ the bypass of security enforcement functionality. Therefore, the
+ evaluator should build upon the understanding of the TSF
+ protection gained from the analysis of this evidence and then
+ develop this in the knowledge gained from other development
+ evidence.
+
+ The approach taken to the methodical search for vulnerabilities
+ is to consider any areas of concern identified in the results of
+ the evaluator's assessment of the development and guidance
+ evidence. However, the evaluator should also consider each
+ aspect of the security architecture analysis to search for any
+ ways in which the protection of the TSF can be undermined. It
+ may be helpful to structure the methodical analysis on the basis
+ of the material presented in the security architecture
+ description, introducing concerns from other evidence as appropriate. The analysis can then be
+ further developed to ensure all other material from the evidence is considered.
+
+ The following provide some examples of hypotheses that
+ may be created when examining the evidence:
+
+
+ consideration of malformed input for interfaces
+ available to an attacker at the external interfaces;
+
+
+ examination of a key security mechanism cited in the
+ security architecture description, such as process
+ separation, hypothesising internal buffer overflows
+ that may lead to degradation of separation;
+
+
+ search to identify any objects created in the TOE
+ implementation representation that are then not
+ fully controlled by the TSF, and could be used by an
+ attacker to undermine SFRs.
+
+
+
+ For example, the evaluator may identify that interfaces
+ are a potential area of weakness in the TOE and specify
+ an approach to the search that 'all interface
+ specifications in the evidence provided will be searched
+ to hypothesise potential vulnerabilities' and go on to
+ explain the methods used in the hypothesis.
+
+ In addition, areas of concern the evaluator has identified
+ during examination of the evidence during the conduct of
+ evaluation activities. Areas of concern may also be identified
+ during the conduct of other work units associated with this
+ component, in particular ,
+ and where the development and conduct of penetration
+ tests may identify further areas of concerns for investigation,
+ or potential vulnerabilities.
+
+ However, examination of only a subset of the development
+ and guidance evidence or their contents is not permitted
+ in this level of rigour. The approach description should
+ provide a demonstration that the methodical approach
+ used is complete, providing confidence that the approach
+ used to search the deliverables has considered all of
+ the information provided in those deliverables.
+
+ This approach to identification of potential vulnerabilities is
+ to take an ordered and planned approach; applying a system to
+ the examination. The evaluator is to describe the method to be
+ used in terms of how the evidence will be considered; the manner
+ in which this information is to be considered and the hypothesis
+ that is to be created. This approach should be agreed with the
+ evaluation authority, and the evaluation authority may
+ provide detail of any additional approaches the evaluator should
+ take to the vulnerability analysis and identify any additional
+ information that should be considered by the evaluator.
+
+ Although a system to identifying potential
+ vulnerabilities is predefined, the identification
+ process may still be iterative, where the identification
+ of one potential vulnerability may lead to identifying
+ another area of concern that requires further
+ investigation.
+
+ Subject to the SFRs the TOE is to meet in the
+ operational environment, the evaluator's independent
+ vulnerability analysis should consider generic potential
+ vulnerabilities under each of the following headings:
+
+
+ generic potential vulnerabilities relevant for the
+ type of TOE being evaluated, as may be supplied by
+ the evaluation authority;
+
+ bypassing;
+
+ tampering;
+
+ direct attacks;
+
+ monitoring;
+
+ misuse.
+
+ Items b) - f) are explained in greater detail in .
+
+ The security architecture description should be
+ considered in light of each of the above generic
+ potential vulnerabilities. Each potential vulnerability
+ should be considered to search for possible ways in
+ which to defeat the TSF protection and undermine the
+ TSF.
+
+
+
+ The evaluator shall record in the ETR the identified
+ potential vulnerabilities that are candidates for
+ testing and applicable to the TOE in its operational
+ environment.
+
+ It may be identified that no further consideration of
+ the potential vulnerability is required if for example
+ the evaluator identifies that measures in the
+ operational environment, either IT or non-IT, prevent
+ exploitation of the potential vulnerability in that
+ operational environment. For instance, restricting
+ physical access to the TOE to authorised users only may
+ effectively render a potential vulnerability to
+ tampering unexploitable.
+
+ The evaluator records any reasons for exclusion of
+ potential vulnerabilities from further consideration if
+ the evaluator determines that the potential
+ vulnerability is not applicable in the operational
+ environment. Otherwise the evaluator records the
+ potential vulnerability for further
+ consideration.
+
+ A list of potential vulnerabilities applicable to the
+ TOE in its operational environment, which can be used as
+ an input into penetration testing activities, shall be
+ reported in the ETR by the evaluators.
+
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing Moderate attack potential.
+
+
+ The evaluator shall devise penetration tests, based on
+ the independent search for potential
+ vulnerabilities.
+
+ The evaluator prepares for penetration testing as necessary to
+ determine the susceptibility of the TOE, in its operational
+ environment, to the potential vulnerabilities identified during
+ the search of the sources of information publicly available.
+ Any current information provided to the evaluator by a third
+ party (e.g. evaluation authority) regarding known potential
+ vulnerabilities will be considered by the evaluator, together
+ with any encountered potential vulnerabilities resulting from
+ the performance of other evaluation activities.
+
+ The evaluator is reminded that, as for considering the
+ security architecture description in the search for
+ vulnerabilities (as detailed in ), testing should be performed to confirm the
+ architectural properties. If requirements from are included in the SARs, the
+ developer testing evidence will include testing
+ performed to confirm the correct implementation of any
+ specific mechanisms detailed in the security
+ architecture description. However, the developer testing
+ will not necessarily include testing of all aspects of
+ the architectural properties that protect the TSF, as
+ much of this testing will be negative testing in nature,
+ attempting to disprove the properties. In developing the
+ strategy for penetration testing, the evaluator will
+ ensure that all aspects of the security architecture
+ description are tested, either in functional testing (as
+ considered in ) or evaluator
+ penetration testing.
+
+ The evaluator will probably find it practical to carry
+ out penetration test using a series of test cases, where
+ each test case will test for a specific potential
+ vulnerability.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+ Guidance on determining the necessary attack potential
+ to exploit a potential vulnerability can be found in
+ Annex .
+
+ Potential vulnerabilities hypothesised as exploitable by
+ an attacker possessing a Moderate (or less) attack
+ potential and resulting in a violation of the security
+ objectives should be the highest priority potential
+ vulnerabilities comprising the list used to direct
+ penetration testing against the TOE.
+
+
+
+ The evaluator shall produce penetration test
+ documentation for the tests based on the list of
+ potential vulnerabilities in sufficient detail to enable
+ the tests to be repeatable. The test documentation shall
+ include:
+
+
+ identification of the potential vulnerability the
+ TOE is being tested for;
+
+
+ instructions to connect and setup all required test
+ equipment as required to conduct the penetration
+ test;
+
+
+ instructions to establish all penetration test
+ prerequisite initial conditions;
+
+
+ instructions to stimulate the TSF;
+
+
+ instructions for observing the behaviour of the TSF;
+
+
+ descriptions of all expected results and the
+ necessary analysis to be performed on the observed
+ behaviour for comparison against expected results;
+
+
+ instructions to conclude the test and establish the
+ necessary post-test state for the TOE.
+
+
+
+ The evaluator prepares for penetration testing based on
+ the list of potential vulnerabilities identified during
+ the search of the public domain and the analysis of the
+ evaluation evidence.
+
+ The evaluator is not expected to determine the
+ exploitability for potential vulnerabilities beyond
+ those for which a Moderate attack potential is required
+ to effect an attack. However, as a result of evaluation
+ expertise, the evaluator may discover a potential
+ vulnerability that is exploitable only by an attacker
+ with greater than Moderate attack potential. Such
+ vulnerabilities are to be reported in the ETR as
+ residual vulnerabilities.
+
+ With an understanding of the potential vulnerability,
+ the evaluator determines the most feasible way to test
+ for the TOE's susceptibility. Specifically the evaluator
+ considers:
+
+
+ the TSFI or other TOE interface that will be used to
+ stimulate the TSF and observe responses (It is
+ possible that the evaluator will need to use an
+ interface to the TOE other than the TSFI to
+ demonstrate properties of the TSF such as those
+ described in the security architecture description
+ (as required by ). It
+ should the noted, that although these TOE interfaces
+ provide a means of testing the TSF properties, they
+ are not the subject of the test.);
+
+
+ initial conditions that will need to exist for the
+ test (i.e. any particular objects or subjects that
+ will need to exist and security attributes they will
+ need to have);
+
+
+ special test equipment that will be required to
+ either stimulate a TSFI or make observations of a
+ TSFI;
+
+
+ whether theoretical analysis should replace physical
+ testing, particularly relevant where the results of
+ an initial test can be extrapolated to demonstrate
+ that repeated attempts of an attack are likely to
+ succeed after a given number of attempts.
+
+
+
+ The evaluator will probably find it practical to carry
+ out penetration testing using a series of test cases,
+ where each test case will test for a specific potential
+ vulnerability.
+
+ The intent of specifying this level of detail in the
+ test documentation is to allow another evaluator to
+ repeat the tests and obtain an equivalent result.
+
+
+
+ The evaluator shall conduct penetration testing.
+
+ The evaluator uses the penetration test documentation
+ resulting from work unit as a basis for executing penetration tests
+ on the TOE, but this does not preclude the evaluator
+ from performing additional ad hoc penetration tests. If
+ required, the evaluator may devise ad hoc tests as a
+ result of information learnt during penetration testing
+ that, if performed by the evaluator, are to be recorded
+ in the penetration test documentation. Such tests may be
+ required to follow up unexpected results or
+ observations, or to investigate potential
+ vulnerabilities suggested to the evaluator during the
+ pre-planned testing.
+
+ Should penetration testing show that a hypothesised
+ potential vulnerability does not exist, then the
+ evaluator should determine whether or not the
+ evaluator's own analysis was incorrect, or if evaluation
+ deliverables are incorrect or incomplete.
+
+ The evaluator is not expected to test for potential
+ vulnerabilities (including those in the public domain)
+ beyond those which required a Moderate attack
+ potential. In some cases, however, it will be necessary
+ to carry out a test before the exploitability can be
+ determined. Where, as a result of evaluation expertise,
+ the evaluator discovers an exploitable vulnerability
+ that is beyond Moderate attack potential, this is
+ reported in the ETR as a residual vulnerability.
+
+
+
+ The evaluator shall record the actual results of the
+ penetration tests.
+
+ While some specific details of the actual test results
+ may be different from those expected (e.g. time and date
+ fields in an audit record) the overall result should be
+ identical. Any unexpected test results should be
+ investigated. The impact on the evaluation should be
+ stated and justified.
+
+
+
+ The evaluator shall report in the ETR the evaluator
+ penetration testing effort, outlining the testing
+ approach, configuration, depth and results.
+
+ The penetration testing information reported in the ETR
+ allows the evaluator to convey the overall penetration
+ testing approach and effort expended on this
+ sub-activity. The intent of providing this information
+ is to give a meaningful overview of the evaluator's
+ penetration testing effort. It is not intended that the
+ information regarding penetration testing in the ETR be
+ an exact reproduction of specific test steps or results
+ of individual penetration tests. The intention is to
+ provide enough detail to allow other evaluators and
+ evaluation authorities to gain some insight about the
+ penetration testing approach chosen, amount of
+ penetration testing performed, TOE test configurations,
+ and the overall results of the penetration testing
+ activity.
+
+ Information that would typically be found in the ETR
+ subclause regarding evaluator penetration testing efforts
+ is:
+
+
+ TOE test configurations. The particular
+ configurations of the TOE that were penetration
+ tested;
+
+
+ TSFI penetration tested. A brief listing of the TSFI
+ and other TOE interfaces that were the focus of the
+ penetration testing;
+
+
+ Verdict for the sub-activity. The overall judgement
+ on the results of penetration testing.
+
+
+
+ This list is by no means exhaustive and is only intended
+ to provide some context as to the type of information
+ that should be present in the ETR concerning the
+ penetration testing the evaluator performed during the
+ evaluation.
+
+
+
+ The evaluator shall examine the results of all
+ penetration testing to determine that the TOE, in its
+ operational environment, is resistant to an attacker
+ possessing a Moderate attack potential.
+
+ If the results reveal that the TOE, in its operational
+ environment, has vulnerabilities exploitable by an
+ attacker possessing less than a High attack potential,
+ then this evaluator action fails.
+
+ The guidance in should be used to determine the attack
+ potential required to exploit a particular vulnerability
+ and whether it can therefore be exploited in the
+ intended environment. It may not be necessary for the
+ attack potential to be calculated in every instance,
+ only if there is some doubt as to whether or not the
+ vulnerability can be exploited by an attacker possessing
+ an attack potential less than High.
+
+
+
+ The evaluator shall report in the ETR all exploitable
+ vulnerabilities and residual vulnerabilities, detailing
+ for each:
+
+
+ its source (e.g. CEM activity being undertaken when
+ it was conceived, known to the evaluator, read in a
+ publication);
+
+
+ the SFR(s) not met;
+
+
+ a description;
+
+
+ whether it is exploitable in its operational
+ environment or not (i.e. exploitable or residual).
+
+
+ the amount of time, level of expertise, level of
+ knowledge of the TOE, level of opportunity and the
+ equipment required to perform the identified
+ vulnerabilities, and the corresponding values using
+ the tables and
+ of Annex .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A methodical vulnerability analysis is performed by the
+ evaluator to ascertain the presence of potential
+ vulnerabilities.
+
+ The evaluator performs penetration testing, to confirm
+ that the potential vulnerabilities cannot be exploited in
+ the operational environment for the TOE. Penetration
+ testing is performed by the evaluator assuming an attack
+ potential of High.
+
+
+
+ The objective of this sub-activity is to determine whether
+ the TOE, in its operational environment, has
+ vulnerabilities exploitable by attackers possessing High
+ attack potential.
+
+
+
+ The methodical analysis approach takes the form of a
+ structured examination of the evidence. This method
+ requires the evaluator to specify the structure and form
+ the analysis will take (i.e. the manner in which the
+ analysis is performed is predetermined, unlike the focused
+ analysis). The method is specified in terms of the
+ information that will be considered and how/why it will be
+ considered. Further guidance on methodical vulnerability
+ analysis can be found in Annex .
+
+ If the TOE SFRs include and
+ requirements such that
+ actions and data of one subject cannot be observed and
+ linked with another subject, the evaluator should consider
+ performing a covert channel analysis. This will build
+ upon the design evidence provided by the developer in
+ satisfaction of and requirements. The design evidence
+ will include details of how the TOE architecture prevents
+ observation by subjects of actions performed by other
+ subjects. the evaluator should seek guidance from the
+ evaluation authority on the conduct of such a covert
+ channel analysis.
+
+ The analysis of the guidance documentation is to include
+ consideration of whether it is possible to unknowingly
+ configure the TOE insecurely. Therefore, the analysis will
+ consider warning prompts provided by the TOE when
+ configuration options are selected by the user that may
+ render the TOE in an insecure state, not just in the
+ guidance but also in the use of the TOE. An example may be
+ when access control rules are amended from a remote
+ administration console, which will not take effect until
+ the TOE has been restarted. The evaluator will determine
+ whether the TOE issues a suitable warning when the changes
+ are made to ensure the user is aware that a restart must
+ be completed before the changes take effect.
+
+
+
+ The evaluation evidence for this sub-activity is:
+
+
+ the ST;
+
+ the functional specification;
+
+ the TOE design;
+
+ the security architecture description;
+
+ the implementation representation;
+
+ the guidance documentation;
+
+ the TOE suitable for testing;
+
+ information publicly available to support the
+ identification of possible potential
+ vulnerabilities.
+
+ The remaining implicit evaluation evidence for this
+ sub-activity depends on the components that have been
+ included in the assurance package. The evidence provided
+ for each component is to be used as input in this
+ sub-activity.
+
+ Other input for this sub-activity is:
+
+
+ current information regarding public domain potential
+ vulnerabilities and attacks (e.g. from an evaluation
+ authority).
+
+
+
+
+ The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+ The evaluator shall confirm that the information provided
+ meets all requirements for content and presentation of
+ evidence.
+
+
+ The evaluator shall perform a search of public domain
+ sources to identify potential vulnerabilities in the TOE.
+
+
+ The evaluator shall perform an independent, methodical
+ vulnerability analysis of the TOE using the guidance
+ documentation, functional specification, TOE design,
+ security architecture description and implementation
+ representation to identify potential vulnerabilities in the
+ TOE.
+
+
+ The evaluator shall conduct penetration testing based on the
+ identified potential vulnerabilities to determine that the
+ TOE is resistant to attacks performed by an attacker
+ possessing High attack potential.
+
+
+
+
+
+
+
+ EAL1 is applicable where some confidence in correct operation
+ is required, but the threats to security are not viewed as
+ serious. It will be of value where independent assurance is
+ required to support the contention that due care has been
+ exercised with respect to the protection of personal or
+ similar information.
+
+ EAL1 requires only a limited security target. It is sufficient
+ to simply state the SFRs that the TOE must meet, rather than
+ deriving them from threats, OSPs and assumptions through
+ security objectives.
+
+ EAL1 provides an evaluation of the TOE as made available to
+ the customer, including independent testing against a
+ specification, and an examination of the guidance
+ documentation provided. It is intended that an EAL1 evaluation
+ could be successfully conducted without assistance from the
+ developer of the TOE, and for minimal outlay.
+
+ An evaluation at this level should provide evidence that the
+ TOE functions in a manner consistent with its
+ documentation.
+
+
+
+ EAL1 provides a basic level of assurance by a limited security
+ target and an analysis of the SFRs in that ST using a
+ functional and interface specification and guidance
+ documentation, to understand the security behaviour.
+
+ The analysis is supported by a search for potential
+ vulnerabilities in the public domain and independent testing
+ (functional and penetration) of the TSF.
+
+ EAL1 also provides assurance through unique identification of
+ the TOE and of the relevant evaluation documents.
+
+ This EAL provides a meaningful increase in assurance over
+ unevaluated IT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL2 requires the co-operation of the developer in terms of
+ the delivery of design information and test results, but
+ should not demand more effort on the part of the developer
+ than is consistent with good commercial practise. As such it
+ should not require a substantially increased investment of
+ cost or time.
+
+ EAL2 is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record. Such a
+ situation may arise when securing legacy systems, or where
+ access to the developer may be limited.
+
+
+
+ EAL2 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation and a basic
+ description of the architecture of the TOE, to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, selective independent confirmation of the
+ developer test results, and a vulnerability analysis (based
+ upon the functional specification, TOE design, security architecture
+ description and guidance evidence provided) demonstrating
+ resistance to penetration attackers with a basic attack
+ potential.
+
+ EAL2 also provides assurance through use of a configuration
+ management system and evidence of secure delivery
+ procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL1 by requiring developer testing, a vulnerability analysis
+ (in addition to the search of the public domain), and
+ independent testing based upon more detailed TOE
+ specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL3 permits a conscientious developer to gain maximum
+ assurance from positive security engineering at the design
+ stage without substantial alteration of existing sound
+ development practises.
+
+ EAL3 is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the TOE and
+ its development without substantial re-engineering.
+
+
+
+ EAL3 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation, and an
+ architectural description of the design of the TOE, to
+ understand the security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent
+ confirmation of the developer test results, and a
+ vulnerability analysis (based upon the functional
+ specification, TOE design, security architecture description and guidance
+ evidence provided) demonstrating resistance to penetration
+ attackers with a basic attack potential.
+
+ EAL3 also provides assurance through the use of development
+ environment controls, TOE configuration management, and
+ evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL2 by requiring more complete testing coverage of the
+ security functionality and mechanisms and/or procedures that
+ provide some confidence that the TOE will not be tampered with
+ during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL4 permits a developer to gain maximum assurance from
+ positive security engineering based on good commercial
+ development practises which, though rigorous, do not require
+ substantial specialist knowledge, skills, and other
+ resources. EAL4 is the highest level at which it is likely to
+ be economically feasible to retrofit to an existing product
+ line.
+
+ EAL4 is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity TOEs
+ and are prepared to incur additional security-specific
+ engineering costs.
+
+
+
+ EAL4 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the basic modular design of the TOE, and a
+ subset of the implementation, to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification and TOE design, selective independent confirmation
+ of the developer test results, and a vulnerability analysis (based upon
+ the functional specification, TOE design, implementation
+ representation, security architecture description and guidance
+ evidence provided) demonstrating resistance to penetration
+ attackers with an Enhanced-Basic attack potential.
+
+ EAL4 also provides assurance through the use of development
+ environment controls and additional TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from EAL3
+ by requiring more design description, the implementation
+ representation for the entire TSF, and improved mechanisms
+ and/or procedures that provide confidence that the TOE will not
+ be tampered with during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL5 permits a developer to gain maximum assurance from
+ security engineering based upon rigorous commercial
+ development practises supported by moderate application of
+ specialist security engineering techniques. Such a TOE will
+ probably be designed and developed with the intent of
+ achieving EAL5 assurance. It is likely that the additional
+ costs attributable to the EAL5 requirements, relative to
+ rigorous development without the application of specialised
+ techniques, will not be large.
+
+ EAL5 is therefore applicable in those circumstances where
+ developers or users require a high level of independently
+ assured security in a planned development and require a
+ rigorous development approach without incurring unreasonable
+ costs attributable to specialist security engineering
+ techniques.
+
+
+
+ EAL5 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, a
+ description of the design of the TOE, and the implementation,
+ to understand the security behaviour. A modular TSF design is
+ also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a moderate attack potential.
+
+ EAL5 also provides assurance through the use of a development
+ environment controls, and comprehensive TOE configuration
+ management including automation, and evidence of secure
+ delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from EAL4
+ by requiring semiformal design descriptions, a more structured
+ (and hence analysable) architecture, and improved mechanisms
+ and/or procedures that provide confidence that the TOE will not
+ be tampered with during development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL6 permits developers to gain high assurance from
+ application of security engineering techniques to a rigorous
+ development environment in order to produce a premium TOE for
+ protecting high value assets against significant risks.
+
+ EAL6 is therefore applicable to the development of security
+ TOEs for application in high risk situations where the value
+ of the protected assets justifies the additional costs.
+
+
+
+ EAL6 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and the implementation to understand the
+ security behaviour. Assurance is additionally gained through a
+ formal model of select TOE security policies and a semiformal
+ presentation of the functional specification and TOE design. A
+ modular, layered and simple TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design, selective independent confirmation
+ of the developer test results, and an independent
+ vulnerability analysis demonstrating resistance to penetration
+ attackers with a high attack potential.
+
+ EAL6 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL5 by requiring more comprehensive analysis, a structured
+ representation of the implementation, more architectural
+ structure (e.g. layering), more comprehensive independent
+ vulnerability analysis, and improved configuration management
+ and development environment controls.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EAL7 is applicable to the development of security TOEs for
+ application in extremely high risk situations and/or where the
+ high value of the assets justifies the higher costs. Practical
+ application of EAL7 is currently limited to TOEs with tightly
+ focused security functionality that is amenable to extensive
+ formal analysis.
+
+
+
+ EAL7 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ complete interface specification, guidance documentation, the
+ design of the TOE, and a structured presentation of the
+ implementation to understand the security behaviour. Assurance
+ is additionally gained through a formal model of select TOE
+ security policies and a semiformal presentation of the
+ functional specification and TOE design. A modular, layered
+ and simple TSF design is also required.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, TOE design and implementation representation,
+ complete independent confirmation of the developer test
+ results, and an independent vulnerability analysis
+ demonstrating resistance to penetration attackers with a high
+ attack potential.
+
+ EAL7 also provides assurance through the use of a structured
+ development process, development environment controls, and
+ comprehensive TOE configuration management including complete
+ automation, and evidence of secure delivery procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL6 by requiring more comprehensive analysis using formal
+ representations and formal correspondence, and comprehensive
+ testing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-A is applicable when a composed TOE is integrated and
+ confidence in the correct security operation of the resulting
+ composite is required. This requires the cooperation of the
+ developer of the dependent component in terms of delivery of
+ design information and test results from the dependent
+ component certification, without requiring the involvement of
+ the base component developer.
+
+ CAP-A is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record.
+
+
+
+ CAP-A provides assurance by analysis of a security target for
+ the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation) and a
+ specification for the interfaces between the component TOEs in
+ the composed TOE to understand the security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information,
+ evidence of developer testing based on the reliance
+ information, development information and composition
+ rationale, and selective independent confirmation of the
+ developer test results. The analysis is also supported by a
+ vulnerability review of the composed TOE by the
+ evaluator.
+
+ CAP-A also provides assurance through unique identification of
+ the composed TOE (i.e. IT TOE and guidance
+ documentation).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-B permits a conscientious developer to gain maximum
+ assurance from understanding, at a subsystem level, the
+ affects of interactions between component TOEs integrated in
+ the composed TOE, whilst minimising the demand of involvement
+ of the base component developer.
+
+ CAP-B is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the composed
+ TOE and its development without substantial
+ re-engineering.
+
+
+
+ CAP-B provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF subsystems) contained in
+ the composed development information to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now also including TOE design), evidence of developer testing
+ based on the reliance information, development information and
+ composition rationale, and selective independent confirmation
+ of the developer test results. The analysis is also supported
+ by a vulnerability analysis of the composed TOE by the
+ evaluator demonstrating resistance to attackers with basic
+ attack potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-A by requiring more complete testing coverage of the
+ security functionality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CAP-C permits a developer to gain maximum assurance from
+ positive analysis of the interactions between the components
+ of the composed TOE, which, though rigorous, do not require
+ full access to all evaluation evidence of the base
+ component.
+
+ CAP-C is therefore applicable in those circumstances where
+ developers or users require a moderate to high level of
+ independently assured security in conventional commodity
+ composed TOEs and are prepared to incur additional
+ security-specific engineering costs.
+
+
+
+ CAP-C provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF modules) contained in the
+ composed development information to understand the security
+ behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now including TOE design), evidence of developer testing based
+ on the reliance information, development information and
+ composition rationale, and selective independent confirmation of
+ the developer test results. The analysis is also supported by a
+ vulnerability analysis of the composed TOE by the evaluator
+ demonstrating resistance to attackers with Enhanced-Basic attack
+ potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-B by requiring more design description and demonstration
+ of resistance to a higher attack potential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/c5dec/assets/scripts/doorstop_mock.sh b/c5dec/assets/scripts/doorstop_mock.sh
new file mode 100644
index 0000000..785ea5a
--- /dev/null
+++ b/c5dec/assets/scripts/doorstop_mock.sh
@@ -0,0 +1,49 @@
+#!/bin/bash
+
+# don't judge me for this script.
+
+# Find the project root by looking for the .git directory
+function find_project_root() {
+ local current_dir="$1"
+ while [[ "$current_dir" != "" && ! -d "$current_dir/.git" ]]; do
+ current_dir=$(dirname "$current_dir")
+ done
+ echo "$current_dir"
+}
+
+# Get the directory of the running script
+SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )"
+
+# Find the project root
+PROJECT_ROOT=$(find_project_root "$SCRIPT_DIR")
+
+# Validate that the project root was found
+if [[ -z "$PROJECT_ROOT" ]]; then
+ echo "Error: Unable to find the project root."
+ exit 1
+fi
+
+# Define relative paths to Doorstop repositories
+PATH_TO_DB="c5dec/assets/database/SecurityControls"
+PATH_TO_REQ="docs/reqs"
+
+# Convert relative paths to absolute paths
+REPO1_ABS_PATH="$PROJECT_ROOT/$PATH_TO_DB"
+REPO2_ABS_PATH="$PROJECT_ROOT/$PATH_TO_REQ"
+
+user_input="$1"
+
+if [ "$user_input" == "db" ]; then
+ cd "$REPO1_ABS_PATH"
+ echo "$(pwd)"
+ mkdir .git
+ doorstop "${@:2}"
+ rm -rf .git
+elif [ "$user_input" == "req" ]; then
+ cd "$REPO2_ABS_PATH"
+ echo "$(pwd)"
+ mkdir .git
+ doorstop "${@:2}"
+ rm -rf .git
+fi
+
diff --git a/c5dec/assets/translations/translations.de.json b/c5dec/assets/translations/translations.de.json
new file mode 100644
index 0000000..3d9b22e
--- /dev/null
+++ b/c5dec/assets/translations/translations.de.json
@@ -0,0 +1,97 @@
+{
+ "_comment1": "template",
+ "Back": "Zurück",
+ "Quit": "Verlassen",
+ "Template": "Vorlage",
+
+ "_comment2": "Builder",
+ "filepath": "Dateipfad",
+ "copy to clipboard": "in Zwischenablage kopieren",
+ "Result": "Ergebnis",
+ "no entries found": "keine Einträge gefunden",
+ "Status bar": "Statusleiste",
+
+ "_comment3": "Generate hash",
+ "Hash Generator": "Hash Generator",
+ "Algorithms": "Algorithmen",
+ "Shake length": "Shake Länge",
+ "Save to file?": "In Datei speichern?",
+ "Calculate": "Berechnen",
+ "The path to F_0 is invalid": "Der Dateipfad zu F_0 ist ungültig",
+ "The path to F_1 is invalid": "Der Dateipfad zu F_0 ist ungültig",
+ "An algorithm has to be chosen": "Ein Algorithmus muss ausgewählt werden",
+ "invalid shake length": "Ungültige Shake Länge",
+ "Hash successfully saved": "Hash erfolgreich gespeichert",
+
+ "_comment4": "Compare hash",
+ "Compare": "Vergleichen",
+ "The hash values are matching": "Die Hashwerte stimmen überein",
+ "The hash values are different": "Die Hashwerte sind unterschiedlich",
+ "The path to H_0 is invalid": "Der Dateipfad zu H_0 ist ungültig",
+ "The path to H_1 is invalid": "Der Dateipfad zu H_1 ist ungültig",
+ "file": "Datei",
+ "hash value": "Hashwert",
+
+
+ "_comment5": "Digital signatures",
+ "Digital signatures": "Digitale Signaturen",
+ "sign": "signieren",
+ "verify": "verifizieren",
+ "Secret key": "Privater Schlüssel",
+ "Public key": "Öffen. Schlüssel",
+ "generate keys": "Schlüssel generieren",
+ "The computation started, please wait": "Die Berechnung ist gestartet, bitten warten",
+ "Signed": "Signiert",
+ "The key is invalid": "Der Schlüssel ist ungültig",
+ "The file could not be found": "Die Datei konnte nicht gefunden werden",
+ "Signature is correct": "Die Signatur ist korrekt",
+ "Signature was forged or corrupt": "Die Signatur wurde bearbeitet oder beschädigt",
+
+ "_comment6": "Filename validator",
+ "folder/ file": "Ordner/ Datei",
+ "Validate": "Validieren",
+ "Number of files:": "Anzahl der Dateien",
+ "Number of invalid names:": "Anzahl ungültiger Namen",
+
+ "_comment7": "Filename generator",
+ "other document": "anderes Dokument",
+ "Add a date?": "Ein Datum hinzufügen?",
+ "Add an author?": "Einen Autor hinzufügen?",
+ "year": "Jahr",
+ "month": "Monat",
+ "day": "Tag",
+ "Documenttype": "Dokumententyp",
+ "Document title Acronym": "Dokumentnamenacronym",
+ "Invalid entries: ": "Ungültige Eingaben: ",
+ "Subdomaincode (number)": "Subdomaincode (Zahl)",
+ "Addition": "Addition (Buchstabe)",
+ "Entity acronym (capitalized)": "Entity Acronym (kapitalisiert)",
+ "Title acronym (capitalized)": "Title acronym (kapitalisiert)",
+ "Date": "Datum",
+
+ "_comment8": "activity report",
+ "The path to the folder is invalid": "Der Ordnerpfad ist ungültig",
+ "User": "Benutzer",
+ "File": "Datei",
+ "Event": "Aktivität",
+ "Save as csv?": "Als CSV speichern?",
+ "months": "Monate",
+ "days": "Tage",
+ "hours": "Stunden",
+ "Author": "Autor",
+ "Save to": "Speichern in",
+ "Folder": "Ordner",
+ "List": "Auflisten",
+ "all": "alle",
+ "The path to the CSV file is invalid": "Der Pfad zur CSV Datei ist ungültig",
+ "file successfully saved": "Datei erfolgreich gespeichert",
+
+ "_comment9": "main",
+ "Cryptography": "Kryptographie",
+ "Compare hashes": "Hashes vergleichen",
+ "Generate hash": "Hash generieren",
+ "Document Management": "Dokumentverwaltung",
+ "Filename Validation": "Dateinamenvalidierung",
+ "Filename Generator": "Dateinamen generieren",
+ "Activity Report": "Aktivitätenbericht"
+}
\ No newline at end of file
diff --git a/c5dec/assets/translations/translations.en.json b/c5dec/assets/translations/translations.en.json
new file mode 100644
index 0000000..0e0dcd2
--- /dev/null
+++ b/c5dec/assets/translations/translations.en.json
@@ -0,0 +1,3 @@
+{
+
+}
\ No newline at end of file
diff --git a/c5dec/assets/translations/translations.fr.json b/c5dec/assets/translations/translations.fr.json
new file mode 100644
index 0000000..cf7b342
--- /dev/null
+++ b/c5dec/assets/translations/translations.fr.json
@@ -0,0 +1,54 @@
+{
+ "_comment1": "template",
+ "Back": "Retour",
+ "Quit": "Fermer",
+ "Template": "",
+
+ "_comment2": "Builder",
+ "filepath": "Chemin du fichier",
+ "copy to clipboard": "Copier dans le presse-papiers",
+ "Result": "résultat",
+ "no entries found": "Aucune entrée trouvée",
+ "Status bar": "Barre d'état",
+
+ "_comment3": "Generate hash",
+ "Hash Generator": "",
+ "Algorithms": "algorithmes",
+ "Shake length": "longueur du shake",
+ "Save to file?": "Enregistrer dans un fichier?",
+ "Calculate": "Calculer",
+ "The path to F_0 is invalid": "Le chemin vers F_0 n'est pas valide",
+ "The path to F_1 is invalid": "Le chemin vers F_1 n'est pas valide",
+ "An algorithm has to be chosen": "Un algorithme doit être choisi",
+ "invalid shake length": "longueur de shake non valide",
+ "Hash successfully saved": "Hachage enregistré avec succès",
+
+ "_comment4": "Compare hash",
+ "Compare": "Comparer",
+ "The hash values are matching": "Les valeurs de hachage correspondent",
+ "The hash values are different": "Les valeurs de hachage sont différentes",
+ "The path to H_0 is invalid": "Le chemin vers H_0 n'est pas valide",
+ "The path to H_1 is invalid": "Le chemin vers H_1 n'est pas valide",
+ "file": "fichier",
+ "hash value": "valeur de hash",
+
+
+ "_comment5": "Digital signatures",
+ "Digital signatures": "Signatures numériques",
+ "sign": "signer",
+ "verify": "vérifier",
+ "Secret key": "clé secrète",
+ "Public key": "clé publique",
+ "generate keys": "générer des clés",
+ "The computation started, please wait": "Le calcul est lancé, veuillez patienter",
+ "Signed": "Signé",
+ "The key is invalid": "la clé n'est pas valide",
+ "The file could not be found": "Le fichier n'a pas pu être trouvé",
+ "Signature is correct": "La signature est correcte",
+ "Signature was forged or corrupt": "signature a été falsifiée ou corrompue",
+
+ "_comment6": "main",
+ "Cryptography": "Cryptographie",
+ "Compare hashes": "Comparer les hachages",
+ "Generate hash": "Générer un hachage"
+}
\ No newline at end of file
diff --git a/c5dec/assets/tshparams/openproject_params.csv b/c5dec/assets/tshparams/openproject_params.csv
new file mode 100644
index 0000000..6127ab6
--- /dev/null
+++ b/c5dec/assets/tshparams/openproject_params.csv
@@ -0,0 +1,2 @@
+WP,Domain,Type
+C5-DEC,CyFORT,RD
\ No newline at end of file
diff --git a/c5dec/assets/tshparams/tshformat.json b/c5dec/assets/tshparams/tshformat.json
new file mode 100644
index 0000000..8e21263
--- /dev/null
+++ b/c5dec/assets/tshparams/tshformat.json
@@ -0,0 +1,36 @@
+{
+ "ALab-TSH-columns": [
+ "ACR",
+ "Date",
+ "MM",
+ "YYYY",
+ "Day",
+ "Type",
+ "Domain/Project name",
+ "Cust/WP",
+ "Task",
+ "Location",
+ "Start",
+ "End",
+ "Hours",
+ "Days",
+ "Description"
+ ],
+ "Alternative-TSH-columns": [
+ "ACR",
+ "Date",
+ "MM",
+ "YYYY",
+ "Day",
+ "Type",
+ "Domain/Project name",
+ "Cust/WP",
+ "Task",
+ "Location",
+ "Start",
+ "End",
+ "Hours",
+ "Days",
+ "Description"
+ ]
+}
\ No newline at end of file
diff --git a/c5dec/common.py b/c5dec/common.py
new file mode 100644
index 0000000..260174d
--- /dev/null
+++ b/c5dec/common.py
@@ -0,0 +1,133 @@
+"""Common exceptions, classes, and functions for C5-DEC."""
+
+import argparse
+import logging
+import os
+import json
+import functools
+
+import c5dec.settings as c5settings
+import doorstop
+
+verbosity = 0 # global verbosity setting for controlling string formatting
+PRINT_VERBOSITY = 0 # minimum verbosity to using `print`
+STR_VERBOSITY = 3 # minimum verbosity to use verbose `__str__`
+MAX_VERBOSITY = 4 # maximum verbosity level implemented
+
+
+def _trace(self, message, *args, **kws):
+ if self.isEnabledFor(logging.DEBUG - 1):
+ self._log(logging.DEBUG - 1, message, args, **kws) # pylint: disable=W0212
+
+
+logging.addLevelName(logging.DEBUG - 1, "TRACE") # add new logging level
+logging.Logger.trace = _trace # type: ignore
+
+logger = logging.getLogger
+log = logger(__name__)
+
+
+class HelpFormatter(argparse.ArgumentDefaultsHelpFormatter):
+ """Command-line help text formatter with wider help text."""
+
+ def __init__(self, *args, **kwargs):
+ kwargs["max_help_position"] = 40
+ super().__init__(*args, **kwargs)
+
+def read_line_from_file(path):
+ first_line = ""
+ with open(path, "r") as f:
+ first_line = f.readline()
+ return first_line
+
+def get_value_from_json(key, default_value):
+ """Returns the corresponding value to a key in the config.json
+ file.
+
+ :param key: the setting whose value is searched
+ :type key: str
+ :param default_value: the value that will be used if the file
+ cannot be loaded
+ :type default_value: str or int
+
+ :return: the value that belongs to the entered key
+ :rtype: str or int
+ """
+ try:
+ with open(c5settings.STARTUP_CONFIG_JSON_PATH) as f:
+ dictionary = json.load(f)
+ value = dictionary[key]
+ except:
+ value = default_value
+ return value
+
+def feature_flag(flag):
+ def decorator_feature_flag(func):
+ @functools.wraps(func)
+ def wrapper_decorator_feature_flag(*args, **kwargs):
+ if flag == "ON":
+ func(*args, **kwargs)
+
+ return wrapper_decorator_feature_flag
+
+ return decorator_feature_flag
+
+def create_dirname(path):
+ """Ensure a parent directory exists for a path."""
+ dirpath = os.path.dirname(path)
+ if dirpath and not os.path.isdir(dirpath):
+ log.info("creating directory {}...".format(dirpath))
+ os.makedirs(dirpath)
+
+# exception classes ##########################################################
+
+
+class C5decError(Exception):
+ """Generic c5dec error."""
+
+class C5decWarning(C5decError, Warning):
+ """Generic c5dec warning."""
+
+class C5decInfo(C5decWarning, Warning):
+ """Generic c5dec info."""
+
+class Capture: # pylint: disable=R0903
+ """Context manager to catch :class:`~doorstop.common.DoorstopError` and
+ :class:`~c5dec.common.C5decError`."""
+
+ def __init__(self, catch=True):
+ self.catch = catch
+ self._success = True
+
+ def __bool__(self):
+ return self._success
+
+ def __enter__(self):
+ return self
+
+ def __exit__(self, exc_type, exc_value, traceback):
+ if exc_type and (issubclass(exc_type, doorstop.DoorstopError) or issubclass(exc_type, C5decError)):
+ self._success = False
+ if self.catch:
+ log.error(exc_value)
+ return True
+ return False
+
+
+# Logging classes #################
+
+class WarningFormatter(logging.Formatter):
+ """Logging formatter that displays verbose formatting for WARNING+."""
+
+ def __init__(self, default_format, verbose_format, *args, **kwargs):
+ super().__init__(*args, **kwargs)
+ self.default_format = default_format
+ self.verbose_format = verbose_format
+
+ def format(self, record):
+ """Python 3 hack to change the formatting style dynamically."""
+ if record.levelno > logging.INFO:
+ self._style._fmt = self.verbose_format # pylint: disable=W0212
+ else:
+ self._style._fmt = self.default_format # pylint: disable=W0212
+ return super().format(record)
diff --git a/c5dec/core/__init__.py b/c5dec/core/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/c5dec/core/cct.py b/c5dec/core/cct.py
new file mode 100644
index 0000000..ac9b59a
--- /dev/null
+++ b/c5dec/core/cct.py
@@ -0,0 +1,3605 @@
+from abc import ABC, abstractmethod
+from lxml import etree as etree_
+import doorstop
+import json
+import os
+import sys
+import re
+import copy
+import c5dec.settings as c5settings
+import c5dec.common as common
+
+log = common.logger(__name__)
+
+UTF8 = "utf-8"
+CP437 = "cp437"
+ASCII = "ascii"
+
+BOX = {
+ "end": {UTF8: "│ ", CP437: "┬ ", ASCII: "| "},
+ "tee": {UTF8: "├── ", CP437: "├── ", ASCII: "+-- "},
+ "bend": {UTF8: "└── ", CP437: "└── ", ASCII: "+-- "},
+ "pipe": {UTF8: "│ ", CP437: "│ ", ASCII: "| "},
+ "space": {UTF8: " ", CP437: " ", ASCII: " "},
+}
+ENCODING = UTF8
+
+"""Start: Helper Functions"""
+
+
+def clean_string(string):
+ clean_newline = string.replace("\n", "").strip()
+ clean_string = re.sub(r"\s+", " ", clean_newline).strip()
+ return clean_string
+
+
+class Index:
+ """
+ Singleton class for managing object indexing by ID.
+ """
+ _instance = None
+ _index = {}
+
+ def __new__(cls):
+ """
+ Create a new instance of Index or return the existing instance if it exists.
+
+ :returns: The Index instance.
+ """
+ if cls._instance is None:
+ cls._instance = super(Index, cls).__new__(cls)
+ return cls._instance
+
+ def __str__(cls):
+ return cls._index.__str__()
+
+ @classmethod
+ def keys(cls):
+ return cls._index.keys()
+
+ @classmethod
+ def update(cls, key, value):
+ """
+ Add a key-value pair to the index. Check for uniqueness and raise
+ an error if not unique.
+
+ :param key: The ID of the key.
+ :type key: str
+ :param value: The object associated with the key.
+ :type value: BaseClass or list of BaseClass
+
+ :raises ValueError: If a non-unique ID is encountered or if value
+ is not an instance of BaseClass or a list of BaseClass instances.
+ """
+ if isinstance(value, list):
+ for item in value:
+ if not isinstance(item, BaseClass):
+ raise common.C5decError(f"Value Type is: {type(value)}, but must be BaseClass or a list of BaseClass")
+
+ # Ensure all items in the list are unique
+ unique_items = set(value)
+ if len(unique_items) != len(value):
+ info_msg = f"Duplicate in {value}!"
+ raise common.C5decError(info_msg)
+
+ elif not isinstance(value, BaseClass):
+ raise common.C5decError(f"Value Type is: {type(value)}. Expected: BaseClass")
+
+ existing_object = cls._index.get(key.lower()) # get the current value of the key in lower case
+ if existing_object:
+ # raise exception if the key refers to an object other than 'value'
+ if existing_object is not value:
+ raise common.C5decError(f"ID '{key}' already exists for the "
+ f"object {id(existing_object)}: "
+ f"{existing_object.__repr__()}.\n"
+ "Cannot be assigned to a different "
+ f"object: {id(value)}: {value.__repr__()}")
+ else:
+ cls._index[key.lower()] = value
+
+ @classmethod
+ def get(cls, key):
+ """
+ Returns a a key-value pair.
+ :param key: The ID of the key.
+ :type key: str
+
+ :raises KeyError: If the ID is not found.
+ """
+ obj_ = cls._index.get(key.lower())
+ if not obj_:
+ error_msg = f"Invalid Id {key}!"
+ raise KeyError(error_msg)
+ return obj_
+
+ @classmethod
+ def yield_obj(cls, obj_type):
+ """
+ Yield objects of a given type from the index.
+
+ :param obj_type: The type of objects to retrieve.
+ :type obj_type: type
+ """
+ # Iterate over values in the index
+ for value in cls._index.values():
+ # If value is a list, check individual objects inside the list
+ if isinstance(value, list):
+ for item in value:
+ if isinstance(item, obj_type):
+ yield item
+ # If value is a single object, check its type
+ elif isinstance(value, obj_type):
+ yield value
+
+ @classmethod
+ def clear(cls):
+ """
+ Clear the index, removing all entries.
+ """
+ cls._index.clear()
+
+
+class UniqueIDManager:
+ """
+ Singleton class for managing unique IDs.
+ The IDs are of the form
+ where
+ - separator is a single character
+ - num is a positive integer expressed in
+ a fixed length notation.
+ """
+ _instance = None
+
+ def __new__(cls, separator='-', count_width=1):
+ if len(separator) != 1:
+ raise common.C5decError("Separator must be a single character.")
+ if not isinstance(count_width, int) or count_width <= 0:
+ raise common.C5decError("Count width must be a positive integer.")
+ if cls._instance is None:
+ cls._instance = super(UniqueIDManager, cls).__new__(cls)
+ cls._id_counters = {}
+ cls._instance._count_width = count_width # length of the numeric part of an id
+ cls._instance._separator = separator
+ return cls._instance
+
+ @classmethod
+ def next(cls, prefix):
+ """
+ Get the next unique ID with a given prefix.
+
+ :param prefix: Prefix for the unique ID.
+ :type prefix: str
+
+ :returns: The next unique ID.
+ :rtype: str
+ """
+ count = cls._instance._id_counters.get(prefix, 0) + 1
+ cls._instance._id_counters[prefix] = count
+ count_str = str(count).zfill(cls._instance._count_width)
+ sep = cls._instance._separator
+ return f"{prefix}{sep}{count_str}"
+
+ @classmethod
+ def reset(cls):
+ """
+ Reset the UniqueIDManager instance.
+ """
+ cls._instance = None
+ cls._id_counters = {}
+
+
+"""End: Helper Functions"""
+
+"""Start: Super classes"""
+
+
+class BaseClass(ABC):
+ """
+ BaseClass with common attributes and methods.
+ """
+
+ def __init__(self, _id=None, _name=None):
+ """
+ Initialize a BaseClass instance.
+
+ :param _id: The ID of the element.
+ :type _id: str
+ :param _name: The name of the element.
+ :type _name: str
+ """
+ self._id = _id
+ self._name = _name
+ self.parent = None
+ self.children = []
+ self.text = ""
+ self.container = []
+
+ def __str__(self):
+ """
+ Return a string representation of the BaseClass instance.
+
+ :returns: The string representation.
+ :rtype: str
+ """
+ sout = (self.get_formatted_text() + "\n\n\n"
+ + self.get_item_tree(pretty_print=True))
+ return sout
+
+ def __repr__(self):
+ """
+ Return a representation of the BaseClass instance.
+
+ :returns: The representation.
+ :rtype: str
+ """
+ return f""
+
+ def clone(self):
+ """
+ Create a deep copy of the BaseClass instance.
+
+ :returns: A deep copy of the instance.
+ :rtype: BaseClass
+ """
+ return copy.deepcopy(self)
+
+ @property
+ def attrib(self):
+ """
+ Get the attributes of the BaseClass instance.
+
+ :returns: The attributes.
+ :rtype: dict
+ """
+ attributes = {}
+ for key, value in self.__dict__.items():
+ if not callable(value) and not key.startswith("__"):
+ attributes[key] = value
+ return attributes
+
+ def collector(self, target, mode="attribute"):
+ """
+ Collect elements that match a target condition.
+
+ :param target: The target condition (attribute or type).
+ :type target: str or Type[BaseClass]
+ :param mode: The collection mode ('attribute' or 'type').
+ :type mode: str
+
+ :returns: A generator yielding matching elements.
+ :rtype: generator
+ """
+ if mode == "attribute":
+ if hasattr(self, target):
+ yield getattr(self, target)
+ elif mode == "type" and isinstance(self, target):
+ yield self
+
+ for child_container in ["children", "container"]:
+ if hasattr(self, child_container):
+ for child in getattr(self, child_container):
+ if hasattr(child, 'collector'):
+ yield from child.collector(target, mode)
+
+ def get_formatted_text(self, level=1.0):
+ """
+ Get a formatted text representation of the BaseClass instance.
+
+ :param level: The formatting level.
+ :type level: float
+
+ :returns: The formatted text.
+ :rtype: str
+ """
+ formatted_text = ""
+ header_level = "#" * int(level)
+ formatted_text += f"\n{header_level} {self._id.upper()} {self._name or ''}\n\n"
+ for element in self.container:
+ if hasattr(element, 'get_formatted_text'):
+ formatted_text += element.get_formatted_text(level=(level + 1))
+ else:
+ raise AttributeError(f"Object {element} does not have a 'get_formatted_text' method.")
+ return formatted_text
+
+ def is_empty(self):
+ """
+ Check if the BaseClass instance is empty.
+
+ :returns: True if the instance is empty, False otherwise.
+ :rtype: bool
+ """
+ return not any([self.text, self.children, self.container])
+
+ def has_valid_id(self):
+ """
+ Check if the ID is valid.
+
+ :raises ValueError: If the ID is missing or not of type string.
+ :returns: True if the ID is valid.
+ :rtype: bool
+ """
+ if not self._id or not isinstance(self._id, str):
+ info_msg = f"<{self.__repr__()} at {id(self)}> ID is missing or is not of type string."
+ raise common.C5decError(info_msg)
+ return True
+
+ def has_valid_name(self):
+ """
+ Check if the name is valid.
+
+ :raises ValueError: If the name is missing or not of type string.
+ :returns: True if the name is valid.
+ :rtype: bool
+ """
+ if not self._name or not isinstance(self._name, str):
+ info_msg = f"<{self.__repr__()} at {id(self)}> Name is missing or is not of type string."
+ raise common.C5decError(info_msg)
+ return True
+
+ # @abstractmethod
+ def is_valid(self):
+ """
+ Check whether the instance is valid according to the CC DTD.
+ Since the CC XMLs themselves are not valid, this method
+ only raises info messages.
+
+ Must be implemented for each subclass.
+ """
+ pass
+
+ def contains(self, element):
+ """
+ Check if the BaseClass instance contains a specific element.
+
+ :param element: The element to check for.
+ :type element: BaseClass
+
+ :returns: True if the element is contained, False otherwise.
+ :rtype: bool
+ """
+ return element in self.children or element in self.container
+
+ def get_children(self):
+ """
+ Get the children of the BaseClass instance.
+
+ :returns: The children.
+ :rtype: list[BaseClass]
+ """
+ return self.children
+
+ def get_child_by_id(self, child_id):
+ """
+ Get a child element by ID.
+
+ :param child_id: The ID of the child.
+ :type child_id: str
+
+ :returns: The child element or None if not found.
+ :rtype: BaseClass or None
+ """
+ for child in self.children:
+ if child._id == child_id.lower():
+ return child
+ return None
+
+ def get_descendants(self, visited=None):
+ """
+ Get the descendants of the BaseClass instance.
+
+ :param visited: A set of visited elements (used for cycle detection).
+ :type visited: set[BaseClass]
+
+ :returns: The descendants.
+ :rtype: list[BaseClass]
+ """
+ if visited is None:
+ visited = set()
+
+ descendants = []
+ for child in self.children:
+ if child in visited:
+ raise common.C5decError(f"Circular reference detected at {child._id} for {self._id}.")
+ visited.add(child)
+ descendants.append(child)
+ descendants.extend(child.get_descendants(visited))
+ return descendants
+
+ def get_parent(self):
+ """
+ Get the parent of the BaseClass instance.
+
+ :returns: The parent element.
+ :rtype: BaseClass
+ """
+ return self.parent
+
+ def get_ancestors(self):
+ """
+ Get the ancestors of the BaseClass instance.
+
+ :returns: The ancestors.
+ :rtype: list[BaseClass]
+ """
+ ancestors = []
+ visited = set()
+ current = self.parent
+
+ while current:
+ if current in visited:
+ info_msg = f"Circular reference detected at {current._id} for {self._id}."
+ raise common.C5decError(info_msg)
+ visited.add(current)
+ ancestors.append(current)
+ current = current.parent
+
+ return ancestors
+
+ def get_siblings(self):
+ """
+ Get the siblings of the BaseClass instance.
+
+ :returns: The siblings.
+ :rtype: list[BaseClass]
+ """
+ if not self.parent:
+ return []
+ return [child for child in self.parent.children if child != self]
+
+ def _pretty_print_tree(self, tree, prefix="", is_last=True):
+ """
+ Helper function to pretty-print a tree structure.
+
+ :param tree: The tree structure.
+ :type tree: dict
+ :param prefix: The prefix for indentation.
+ :type prefix: str
+ :param is_last: True if the element is the last in its branch.
+ :type is_last: bool
+
+ :returns: The lines of the pretty-printed tree.
+ :rtype: list[str]
+ """
+ lines = []
+
+ connector = BOX["bend"][ENCODING] if is_last else BOX["tee"][ENCODING]
+ id_name = f"{prefix}{connector}{tree['id'] or ''} {tree['name'] or ''}"
+ lines.append(id_name)
+
+ prefix += BOX["space"][ENCODING] if is_last else BOX["pipe"][ENCODING]
+
+ children = tree.get("children", [])
+ child_count = len(children)
+ for index, child in enumerate(children):
+ is_last_child = (index == child_count - 1)
+ lines.extend(self._pretty_print_tree(child, prefix, is_last_child))
+
+ return lines
+
+ def get_item_tree(self, pretty_print=False):
+ """
+ Get the item tree structure of the BaseClass instance.
+
+ :param pretty_print: Whether to pretty-print the tree.
+ :type pretty_print: bool
+
+ :returns: The item tree structure.
+ :rtype: dict or str
+ """
+ tree = {"id": self._id, "name": self._name}
+ if self.children:
+ tree["children"] = [child.get_item_tree(pretty_print=False)
+ for child in self.children]
+
+ if pretty_print:
+ return "\n".join(self._pretty_print_tree(tree))
+ return tree
+
+
+class BaseBuilder(ABC):
+ """
+ Base class for building instances of BaseClass or its subclasses from XML nodes.
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize a BaseBuilder instance.
+
+ :param instance: The instance to build.
+ :type instance: BaseClass
+ """
+ self.instance = instance
+
+ def _build_attributes(self, node, parent_obj):
+ """
+ Build attributes (ID and name) of the instance from an XML node.
+
+ :param node: The XML node.
+ :type node: Element
+ :param parent_obj: The parent object.
+ :type parent_obj: BaseClass
+ """
+ self.instance.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "id":
+ self.instance._id = node.get(attribute)
+ if attribute == "name":
+ self.instance._name = node.get(attribute)
+
+ @abstractmethod
+ def _build_children(self, child):
+ """
+ Build children of the instance from an XML node.
+
+ :param child: The child XML node.
+ :type child: Element
+ """
+ pass
+
+ def build(self, node, parent_obj=None):
+ """
+ Build the instance from an XML node and update the index.
+
+ :param node: The XML node.
+ :type node: Element
+ :param parent_obj: The parent object.
+ :type parent_obj: BaseClass or None
+
+ :returns: The built instance.
+ :rtype: BaseClass
+ """
+ self._build_attributes(node, parent_obj)
+ for child in node:
+ self._build_children(child)
+ Index.update(self.instance._id, self.instance)
+ self.instance.is_valid()
+ return self.instance
+
+
+class BaseExporter(ABC):
+ """
+ To be added in future iterations.
+ """
+ def __init__(self, instance):
+ self.instance = instance
+
+ def _construct_data(self):
+ _id = self.instance._id
+ if self.instance._name:
+ _name = self.instance._name
+ header = _id + " " + _name
+ else:
+ _name = ""
+ header = _id
+
+ if self.instance.parent:
+ links = self.instance.parent.id.lower()
+ else:
+ links = []
+
+ text = self.instance.get_formatted.text()
+
+ keys = ["id", "name", "header", "text", "links"]
+ values = [_id, _name, header, text, links]
+
+ data = dict(zip(keys, values))
+ return data
+
+ @abstractmethod
+ def _export_children(self, child, doc, level, index,
+ itemformat="markdown", seperator="-", silence=True):
+ pass
+
+ def doorstop_export(self, tree, level, index,
+ itemformat="markdown", seperator="-", silence=True):
+ """
+ TBA.
+ """
+ pass
+
+
+"""End: Super classes"""
+
+
+"""Start: Common Text Elements"""
+# @TST-010
+
+class Text(BaseClass):
+
+ def __init__(self, value=None):
+ self.text = value
+
+ def get_formatted_text(self, level=1.0):
+ _ = level #just for the linter
+ formatted_text = clean_string(self.text)
+ return formatted_text
+
+ def set_text(self, value):
+ self.text = value
+
+ def empty_text(self):
+ self.text = None
+
+ def is_valid(self):
+ if self.is_empty():
+ raise common.C5decError("'Text' is empty.")
+ return True
+
+
+class Italic(Text):
+
+ def __init__(self, value=None):
+ self.text = str(value)
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = " *" + clean_string(self.text) + "* "
+ return formatted_text
+
+
+class Bold(Text):
+
+ def __init__(self, value=None):
+ self.text = str(value)
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = " **" + clean_string(self.text) + "** "
+ return formatted_text
+
+
+class Math(Text):
+ def __init__(self, value=None):
+ self.text = value
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = f" ${self.text}$ "
+ return formatted_text
+
+
+class XRef(BaseClass):
+
+ VALID_SHOW = ["title", "link", "none", "id"]
+
+ def __init__(self, _id=None, tail=None, fake_id=None, show="link"):
+ self._id = _id
+ self.fakeid = fake_id
+ if show not in XRef.VALID_SHOW:
+ raise common.C5decError(f"Invalid 'show' attribute {show}. Must be one of {XRef.VALID_SHOW}")
+ self.show = show
+ self.tail = tail
+ self.parent = None
+ self.text = ""
+ self.container = []
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ def get_formatted_text(self, level=1.0):
+ _ = level # just for the linter
+ formatted_text = f" [{self._id}]() "
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "id":
+ self._id = node.get(attribute)
+ if attribute == "fakeid":
+ self.fakeid = node.get(attribute)
+ if attribute == "show":
+ self.show = node.get(attribute)
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ if self.tail:
+ self.tail = node.tail
+ self.container.append(Text(node.tail))
+ return self
+
+
+class URL(BaseClass):
+
+ def __init__(self,
+ _id=None,
+ title=None):
+ self._id = _id
+ self.title = title
+ self.parent = None
+ self.text = ""
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ @property
+ def attrib(self):
+ attributes = {}
+ for key, value in self.__dict__.items():
+ if not callable(value) and not key.startswith("__"):
+ attributes[key] = value
+ return attributes
+
+ def get_formatted_text(self, level=1.0):
+ _ = level # just for the linter
+ formatted_text = f" [{self._id}]({self._id}) "
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "id":
+ self._id = node.get(attribute)
+ if attribute == "title":
+ self.title = node.get(attribute)
+
+ def _build_text(self, node):
+ url_text = f"<{node.get('id')}>"
+ self.text = url_text
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ return self
+
+
+class Item(BaseClass):
+
+ def __init__(self):
+ self.parent = None
+ self.text = ""
+ self.container = []
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ def __repr__(self):
+ return str(type(self))
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=level)
+ return formatted_text
+
+ def _build_children(self, child):
+ node_name = child.tag
+
+ if node_name == "para":
+ obj_ = Para().build(child, self)
+ self.text += obj_.text
+ self.container.append(obj_)
+ if node_name == "xref":
+ obj_ = XRef().build(child, self)
+ self.text += obj_.text
+ self.container.append(obj_)
+ if child.tail:
+ self.text += child.tail
+ self.container.append(Text(child.tail))
+ if node_name == "url":
+ obj_ = URL().build(child, self)
+ self.text += obj_.text
+ self.container.append(obj_)
+ if node_name == "list":
+ obj_ = List().build(child, self)
+ self.text += obj_.text
+ self.container.append(obj_)
+ if node_name == "bold":
+ bold = Bold(child.text)
+ self.container.append(bold)
+ if child.tail:
+ self.text += child.tail
+ self.container.append(Text(child.tail))
+ if node_name == "italic":
+ italic = Italic(child.text)
+ self.container.append(italic)
+ if child.tail:
+ self.text += child.tail
+ self.container.append(Text(child.tail))
+ if node_name == "sub":
+ base = self.text[-1]
+ math = f"{base}_{{ {str(child.text)} }}"
+ self.text = self.text[:-1]
+ if isinstance(self.container[-1], Text):
+ base_text = self.container[-1].text
+ self.container[-1] = Text(base_text[:-1])
+ self.container.append(Math(math))
+ if child.tail:
+ self.text += child.tail
+ self.container.append(Text(child.tail))
+
+ def build(self, node, parent_obj=None):
+ self.parent = parent_obj
+ if node.text:
+ self.text += node.text
+ self.container.append(Text(node.text))
+ for child in node:
+ self._build_children(child)
+ return self
+
+
+class List(BaseClass):
+
+ VALID_TYPE = ["itemized", "enumerated"]
+
+ def __init__(self, ltype="enumerated"):
+ self.type = ltype
+ self.item = []
+ self.parent = None
+ self.text = ""
+ self.container = []
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = "\n"
+ if self.type == self.VALID_TYPE[0]:
+ marker = "- "
+ for element in self.item:
+ formatted_text += marker + element.get_formatted_text(level=level) + "\n"
+
+ if self.type == self.VALID_TYPE[1]:
+ enum = 1
+ for element in self.item:
+ marker = f"{enum}. "
+ formatted_text += marker + element.get_formatted_text(level=level) + "\n"
+ enum += 1
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "type":
+ self.type = node.get(attribute)
+
+ def _build_children(self, child):
+ node_name = child.tag
+ if node_name == "item":
+ obj_ = Item().build(child, self)
+ self.text += obj_.text
+ self.item.append(obj_)
+ self.container.append(obj_)
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ for child in node:
+ self._build_children(child)
+ return self
+
+
+class Example(BaseClass):
+
+ def __init__(self):
+ self.exampleterm = None
+ self.exampledef = None
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "id":
+ self._id = node.get(attribute)
+
+ def _build_children(self, child):
+ if child.tag in ["exampleterm", "exampledef"]:
+ obj_ = Para().build(child, self)
+ setattr(self, child.tag, obj_)
+ self.container.append(obj_)
+
+ def build(self, node, parent_obj=None):
+ self.original_tag = node.tag
+ self._build_attributes(node, parent_obj)
+ for child in node:
+ self._build_children(child)
+ return self
+
+
+class TEntry(BaseClass):
+
+ def __init__(self):
+ self.rowspan = 1
+ self.columnspan = 1
+ self.width = 100
+ self.style = None
+ self.align = "left"
+ self.container = []
+
+ def get_formatted_text(self):
+ column_text = ""
+ for element in self.container:
+ column_text += element.get_formatted_text()
+ formatted_text = " | " + column_text + (" | | " * (self.columnspan - 1))
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "rowspan":
+ self.rowspan = int(node.get(attribute))
+ if attribute == "columnspan":
+ self.columnspan = int(node.get(attribute))
+ if attribute == "width":
+ self.width = node.get(attribute)
+ if attribute == "style":
+ self.style = node.get(attribute)
+ if attribute == "align":
+ self.align = node.get(attribute)
+
+ def _build_children(self, child):
+ if child.tag == "xref":
+ xref = XRef().build(child, self)
+ self.container.append(xref)
+ if child.tail:
+ self.container.append(Text(child.tail))
+ if child.tag == "bold":
+ bold = Bold(child.text)
+ self.container.append(bold)
+ if child.tail:
+ self.container.append(Text(child.tail))
+ if child.tag == "italic":
+ italic = Italic(child.text)
+ self.container.append(italic)
+ if child.tail:
+ self.container.append(Text(child.tail))
+ if child.tag == "footnote":
+ footnote = Para().build(child, self)
+ self.container.append(footnote)
+
+ def build(self, node, parent_obj=None):
+ self.original_tag = node.tag
+ self._build_attributes(node, parent_obj)
+ if node.text:
+ self.container.append(Text(node.text))
+ for child in node:
+ self._build_children(child)
+ return self
+
+class TRow(BaseClass):
+
+ def __init__(self):
+ self.entry = []
+
+ def get_formatted_text(self, columns=1):
+ row_text = ""
+ rowspan = 0
+ columnspan = 0
+ for entry in self.entry:
+ if entry.rowspan > rowspan:
+ rowspan = entry.rowspan
+ row_text += entry.get_formatted_text()
+ columnspan += entry.columnspan
+ if columnspan < columns:
+ diff = columns - columnspan
+ formatted_text = (" | | " * diff) + row_text
+ else:
+ formatted_text = row_text
+ if rowspan > 1:
+ formatted_text += " | | " * columns
+ return formatted_text
+
+ def _build_attributes(self, parent_obj=None):
+ self.parent = parent_obj
+
+ def _build_children(self, child):
+ if child.tag == "entry":
+ entry = TEntry().build(child)
+ self.entry.append(entry)
+
+ def build(self, node, parent_obj=None):
+ self.original_tag = node.tag
+ self._build_attributes(parent_obj)
+ for child in node:
+ self._build_children(child)
+ return self
+
+class TGroup(BaseClass):
+
+ def __init__(self):
+ self.cols = 1
+ self.thead = None
+ self.tfoot = None
+ self.tbody = None
+
+ def get_formatted_text(self):
+ #auto fill rows to column specification.
+ formatted_text = ""
+ if self.thead:
+ for row in self.thead:
+ formatted_text += row.get_formatted_text(columns=self.cols) + " |\n"
+ hdelimiter = ("|----" * self.cols) + "|\n"
+ formatted_text += hdelimiter
+ for row in self.tbody:
+ formatted_text += row.get_formatted_text(columns=self.cols) + " |\n"
+ if self.tfoot:
+ for row in self.tfoot:
+ formatted_text += row.get_formatted_text(columns=self.cols) + " |\n"
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "cols":
+ self.cols = int(node.get(attribute))
+
+ def _build_children(self, child):
+
+ if child.tag == "thead":
+ thead = []
+ for row in child:
+ row = TRow().build(row, self)
+ thead.append(row)
+ self.thead = thead
+ if child.tag == "tfoot":
+ tfoot = []
+ for row in child:
+ row = TRow().build(row, self)
+ tfoot.append(row)
+ self.tfoot = tfoot
+ if child.tag == "tbody":
+ tbody = []
+ for row in child:
+ row = TRow().build(row, self)
+ tbody.append(row)
+ self.tbody = tbody
+
+ def build(self, node, parent_obj=None):
+ self.original_tag = node.tag
+ self._build_attributes(node, parent_obj)
+ for child in node:
+ self._build_children(child)
+ return self
+
+class Table(BaseClass):
+
+ def __init__(self):
+ self.title = None
+ self.tgroup = []
+ self.container = []
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ for element in self.container:
+ formatted_text += element.get_formatted_text()
+ if self.title:
+ formatted_text += f"\n Table: {self.title.text}\n"
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "id":
+ self._id = node.get(attribute)
+
+ def _build_children(self, child):
+ if child.tag == "tgroup":
+ tgroup = TGroup().build(child, self)
+ self.tgroup.append(tgroup)
+ self.container.append(tgroup)
+ if child.tag == "title":
+ # don't append to container title == caption
+ self.title = Text(str(child.text))
+
+ def build(self, node, parent_obj=None):
+ self.original_tag = node.tag
+ self._build_attributes(node, parent_obj)
+ for child in node:
+ self._build_children(child)
+ return self
+
+
+class Para(BaseClass):
+
+ VALID_TYPES = ("normal", "isonote", "ccmbnote")
+
+ def __init__(self,
+ title = None,
+ ptype = "normal",
+ _id = None,
+ level = 1,
+ patch= None):
+ self.title = title
+ self._id = _id
+ self.parent = None
+ self.level = str(level)
+ self.patch = patch
+ if ptype not in Para.VALID_TYPES:
+ raise common.C5decError(f"Invalid 'para' type {ptype}. "
+ f"Must be one of {Para.VALID_TYPES}")
+ self.type = ptype
+ self.text = ""
+ self.container = []
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ @property
+ def attrib(self):
+ attributes = {}
+ for key, value in self.__dict__.items():
+ if not callable(value) and not key.startswith("__"):
+ attributes[key] = value
+ return attributes
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#" * int(level)
+ if self.title:
+ formatted_text += f"\n{header_level} {self.title}\n"
+ level += 1
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=level)
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "title":
+ self.title = node.get(attribute)
+ if attribute == "id":
+ self._id = node.get(attribute)
+ if attribute == "type":
+ self.type = node.get(attribute)
+
+ def _build_children(self, node):
+ para_text = ""
+ if node.text:
+ para_text += node.text
+ self.container.append(Text(node.text))
+ for child in node:
+ if child.tag == "xref":
+ xref = XRef().build(child, self)
+ para_text += xref.text
+ self.container.append(xref)
+ if child.tail:
+ para_text += child.tail
+ self.container.append(Text(child.tail))
+ if child.tag == "url":
+ url = URL().build(child, self)
+ para_text += url.text
+ self.container.append(url)
+ if child.tag == "list":
+ plist = List().build(child, self)
+ para_text += plist.text
+ self.container.append(plist)
+ if child.tag == "bold":
+ bold = Bold(child.text)
+ self.container.append(bold)
+ if child.tail:
+ self.text += child.tail
+ self.container.append(Text(child.tail))
+ if child.tag == "italic":
+ italic = Italic(child.text)
+ self.container.append(italic)
+ if child.tail:
+ para_text += child.tail
+ self.container.append(Text(child.tail))
+ if child.tag == "sub":
+ base = para_text[-1]
+ math = f"{base}_{{{str(child.text)}}}"
+ para_text = para_text[:-1]
+ if isinstance(self.container[-1], Text):
+ base_text = self.container[-1].text
+ self.container[-1] = Text(base_text[:-1])
+ self.container.append(Math(math))
+ if child.tail:
+ para_text += child.tail
+ self.container.append(Text(child.tail))
+
+ para_text = para_text.replace("\n", "").strip()
+ clean_text = re.sub(r"\s+", " ", para_text).strip()
+ self.text = clean_text
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ self._build_children(node)
+ return self
+
+
+class ParaSequence(BaseClass):
+
+ def __init__(self):
+ self.subclause = []
+ self.para = []
+ self.table = []
+ self.example = []
+ self.figure = []
+ self.acronym = []
+ self.biblioentry = []
+ self.glossentry = []
+ self.parent = None
+ self.original_tag = None
+ self.text = ""
+ self.container = []
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ @property
+ def attrib(self):
+ attributes = {}
+ for key, value in self.__dict__.items():
+ if not callable(value) and not key.startswith("__"):
+ attributes[key] = value
+ return attributes
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#" * int(level)
+ if self.original_tag:
+ formatted_text += "\n\n" + header_level + " "
+ formatted_text += self.original_tag.upper() + "\n\n"
+ level += 1
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=level) + "\n"
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ """
+ Intended to be overridden by subclasses to handle node attributes.
+ Does nothing in the base class.
+ """
+ pass
+
+ def _build_children(self, child):
+ if child.tag == "subclause":
+ subclause = SubClause().build(child, self)
+ self.text += "\n#" + subclause.title + "\n\n" + subclause.text + "\n"
+ self.subclause.append(subclause)
+ self.container.append(subclause)
+ if child.tag == "para":
+ para = Para().build(child, self)
+ self.text += para.text + "\n"
+ self.para.append(para)
+ self.container.append(para)
+ if child.tag == "example":
+ example = Example().build(child, self)
+ self.text += example.text + "\n"
+ self.example.append(example)
+ self.container.append(example)
+ if child.tag == "table":
+ table = Table().build(child, self)
+ self.table.append(table)
+ self.container.append(table)
+
+ def build(self, node, parent_obj=None):
+ self.original_tag = node.tag
+ self._build_attributes(node, parent_obj)
+ for child in node:
+ self._build_children(child)
+ return self
+
+
+class SubClause(ParaSequence):
+
+
+ def __init__(self,
+ title = None,
+ _id = None,
+ patch= None):
+ super().__init__()
+ self.title = title
+ self._id = _id
+ self.patch = patch
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ @property
+ def attrib(self):
+ attributes = {}
+ for key, value in self.__dict__.items():
+ if not callable(value) and not key.startswith("__"):
+ attributes[key] = value
+ return attributes
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#" * int(level)
+ if self.title:
+ formatted_text += f"\n\n{header_level} {self.title}\n\n"
+ level += 1
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=level) + "\n"
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "title":
+ self.title = node.get(attribute)
+ if attribute == "id":
+ self._id = node.get(attribute)
+
+
+class Clause(ParaSequence):
+
+ VALID_TYPES = ["normal", "annex"]
+ VALID_CATEGORY = ["normative", "informative"]
+
+ def __init__(self,
+ title = None,
+ _id = None,
+ ctype = "normal",
+ category = "normative",
+ patch= None):
+ super().__init__()
+ self.title = title
+ self._id = _id
+ if ctype not in Clause.VALID_TYPES:
+ raise common.C5decError(f"Invalid 'Clause' type {ctype}.\
+ Must be one of {Clause.VALID_TYPES}")
+ self.type = ctype
+ if category not in Clause.VALID_CATEGORY:
+ raise common.C5decError(f"Invalid 'Clause' type {category}.\
+ Must be one of {Clause.VALID_CATEGORY}")
+ self.category = category
+ self.patch = patch
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ @property
+ def attrib(self):
+ attributes = {}
+ for key, value in self.__dict__.items():
+ if not callable(value) and not key.startswith("__"):
+ attributes[key] = value
+ return attributes
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#"
+ if self.title:
+ formatted_text += f"\n{header_level} {self.title}\n"
+ level += 1
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=level)
+ return formatted_text
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "title":
+ self.title = node.get(attribute)
+ if attribute == "id":
+ self._id = node.get(attribute)
+ if attribute == "type":
+ self.type = node.get(attribute)
+ if attribute == "category":
+ self.category = node.get(attribute)
+
+"""End: Common Text Elements"""
+
+
+"""Start: Functional Class Elements"""
+
+
+class Operation(BaseClass):
+ """
+ Represents an Element Operation in the context of CC. It is not differentiated between
+ functional and assurance operations. The distinction is handled via the object's parent
+ object.
+
+ :param _id: The ID of the operation.
+ :type _id: str
+ :param op_type: The type of the operation ("selection" or "assignment").
+ :type op_type: str
+ :param exclusive: Whether the operation is exclusive ("YES" or "NO").
+ :type exclusive: str
+ """
+
+ VALID_TYPES = ["selection", "assignment"]
+
+ def __init__(self, _id=None, op_type=None, exclusive="NO"):
+ super().__init__(_id=_id, _name=None)
+ self.type = op_type
+ self.exclusive = exclusive
+ self.note = None
+ self.item = []
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = f" [_{self.type}_: "
+ for element in self.container:
+ # ParaSequences are Operation Notes. These are handled in FElement and AElement.
+ if not isinstance(element, ParaSequence):
+ formatted_text += element.get_formatted_text(level=level) + ", "
+ formatted_text = formatted_text[:-2]
+ formatted_text += "] "
+ return formatted_text
+
+ def is_valid(self):
+ if self.type not in self.VALID_TYPES:
+ # not explicit requiremnt in CC DTD, but given the implementation it must be checked
+ # if operations are of valid type.
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> invalid.\
+ \nOperation must be one of type {self.VALID_TYPES}. Is {self.type}"
+ raise common.C5decError(info_msg)
+ if not self.item and not hasattr(self.parent, "type"):
+ # Only Assurance Elements (AElement) are allowed to not contain operation items (FEItem)
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> invalid.\
+ \nOperation must contain {self.type}item/s."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class OperationBuilder(BaseBuilder):
+ """
+ Builder class for creating Operation instances.
+
+ :param instance: An instance of Operation to build upon.
+ :type instance: Operation
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an OperationBuilder instance.
+
+ :param instance: An instance of Operation to build upon.
+ :type instance: Operation
+ :raises ValueError: If the provided instance is not an Operation object.
+ """
+ if not isinstance(instance, Operation):
+ info_msg = f"Object must be {Operation}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.instance.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "id":
+ self.instance._id = node.get(attribute)
+ if attribute == "exclusive":
+ self.instance.exclusive = node.get(attribute)
+
+ def _build_children(self, child):
+ node_name = child.tag
+ if node_name in ["fe-assignmentitem", "fe-selectionitem"]:
+ item = FEItem()
+ obj_ = FEItemBuilder(item).build(child, self.instance)
+ self.instance.item.append(obj_)
+ self.instance.container.append(obj_)
+ if node_name in ["fe-assignmentnotes", "fe-selectionnotes"]:
+ obj_ = ParaSequence().build(child, self.instance)
+ self.instance.note = obj_
+ self.instance.container.append(obj_)
+ if node_name == "fe-list":
+ flist = FEList()
+ obj_ = FEListBuilder(flist).build(child, self.instance)
+ self.instance.container.append(obj_)
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ for child in node:
+ self._build_children(child)
+ self.instance.is_valid()
+ return self.instance
+
+
+class FEItem(BaseClass):
+ """
+ In the context of CC this class represents either a fe-assignmentitem, fe-selectionitem,
+ or a fe-item. The distinction is made via the parent object.
+
+ Inherits from `BaseClass` and adds attributes:
+ - `list` (list): A list of FEList objects
+ - `operation` (list): A list of Operation objects.
+ """
+ def __init__(self):
+ super().__init__(_id=None, _name=None)
+ self.list = []
+ self.operation = []
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=level)
+ return formatted_text
+
+ def is_valid(self):
+ if self.is_empty():
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> cannot be empty."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class FEItemBuilder(BaseBuilder):
+ """
+ Builder class for creating FEItem instances.
+
+ :param instance: An instance of FEItem to build upon.
+ :type instance: Operation
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an FEItemBuilder instance.
+
+ :param instance: An instance of FEItem to build upon.
+ :type instance: FEItem
+ :raises ValueError: If the provided instance is not an FEItem object.
+ """
+ if not isinstance(instance, FEItem):
+ info_msg = f"Object must be {FEItem}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_children(self, child):
+
+ node_name = child.tag
+ if child.text:
+ self.instance.container.append(Text(child.text))
+ if child.tail:
+ self.instance.container.append(Text(child.tail))
+ if node_name == "fe-list":
+ flist = FEList()
+ obj_ = FEListBuilder(flist).build(child, self.instance)
+ self.instance.list.append(obj_)
+ self.instance.container.append(obj_)
+ else:
+ op_type = re.sub(r"fe-(.*?)", r"\1", node_name)
+ operation = Operation(op_type=op_type)
+ obj_ = OperationBuilder(operation).build(child, self.instance)
+ self.instance.operation.append(obj_)
+ self.instance.container.append(obj_)
+
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ if node.text:
+ self.instance.container.append(Text(node.text))
+ if len(node):
+ for child in node:
+ self._build_children(child)
+ self.instance.is_valid()
+ return self.instance
+
+
+class FEList(BaseClass):
+ """
+ Class representing a Functional Element (FE) List in the context of CC.
+
+ Inherits from `BaseClass` and adds the following attribute:
+ - `item` (list): A list of FEItem.
+ """
+
+ def __init__(self):
+ super().__init__(_id=None, _name=None)
+ self.item = []
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = "\n"
+ marker = "- "
+ for element in self.container:
+ formatted_text += marker + element.get_formatted_text(level=level) + "\n"
+ return formatted_text
+
+ def is_valid(self):
+ if not self.item:
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> must contain items."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class FEListBuilder(BaseBuilder):
+ """
+ Builder class for creating FEList instances.
+
+ :param instance: An instance of FEList to build upon.
+ :type instance: FEList
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an FEListBuilder instance.
+
+ :param instance: An instance of FEList to build upon.
+ :type instance: FEList
+ :raises ValueError: If the provided instance is not an FEList object.
+ """
+ if not isinstance(instance, FEList):
+ info_msg = f"Object must be {FEList}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.instance.parent = parent_obj
+
+ def _build_children(self, child):
+ node_name = child.tag
+ if node_name == "fe-item":
+ item = FEItem()
+ obj_ = FEItemBuilder(item).build(child, self.instance)
+ self.instance.container.append(obj_)
+ self.instance.item.append(obj_)
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ for child in node:
+ self._build_children(child)
+ self.instance.is_valid()
+ return self.instance
+
+
+class FElement(BaseClass):
+ """
+ This class represents a functional element in the context of CC.
+
+ :param _id: The ID of the FElement.
+ :type _id: str
+ :param _name: The name of the FElement.
+ :type _name: str
+
+ Inherits from `BaseClass` and adds the following attribute:
+ - `list` (list): A list of FEList objects
+ - `operation` (list): A list of Operation objects.
+ - `requirement` (str): The requirement stated by the FElement.
+ """
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.list = None
+ self.operation = []
+ self.requirement = ""
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#" * int(level)
+ formatted_text += f"\n{header_level} {self._id.upper()} {self._name or ''}\n\n"
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=(level+1))
+
+ formatted_text += "\n\n"
+ notes = self.collector("note")
+ for note in notes:
+ formatted_text += note.get_formatted_text(level=(level+1)) + "\n"
+
+ return formatted_text
+
+ def is_valid(self):
+ self.has_valid_id()
+ if self.is_empty():
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> cannot be empty."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class FElementBuilder(BaseBuilder):
+ """
+ Builder class for creating FElement instances.
+
+ :param instance: An instance of FElement to build upon.
+ :type instance: FElement
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an FElementBuilder instance.
+
+ :param instance: An instance of FElement to build upon.
+ :type instance: FElement
+ :raises ValueError: If the provided instance is not an FElement object.
+ """
+ if not isinstance(instance, FElement):
+ info_msg = f"Object must be {FElement}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+
+ def _build_requirement(self):
+ requirement = ""
+ for element in self.instance.container:
+ requirement += element.text
+ self.instance.requirement = clean_string(requirement)
+
+ def _build_children(self, child):
+ node_name = child.tag
+ if node_name != "fe-list":
+ if child.text:
+ self.instance.container.append(Text(child.text))
+
+ op_type = re.sub(r"fe-(.*?)", r"\1", node_name)
+ operation = Operation(op_type=op_type)
+ obj_ = OperationBuilder(operation).build(child, self.instance)
+ self.instance.operation.append(obj_)
+ self.instance.container.append(obj_)
+
+ if child.tail:
+ self.instance.container.append(Text(child.tail))
+ else:
+ flist = FEList()
+ obj_ = FEListBuilder(flist).build(child, self.instance)
+ self.instance.container.append(obj_)
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ if node.text:
+ self.instance.container.append(Text(node.text))
+ for child in node:
+ self._build_children(child)
+ if node.tail:
+ self.instance.container.append(Text(node.tail))
+ self._build_requirement()
+ Index.update(self.instance._id, self.instance)
+ self.instance.is_valid()
+ return self.instance
+
+
+class FCoAudit(BaseClass):
+ """
+ Class representing a functional component audit in the context of CC.
+
+ :param level: The level of the Combined Audit ("minimal", "basic", or "detailed").
+ :type level: str
+ :raises ValueError: If the provided `level` is not one of the valid levels ("minimal", "basic", or "detailed").
+ """
+
+ VALID_LEVEL = ["minimal", "basic", "detailed"]
+
+ def __init__(self, level="minimal"):
+ super().__init__(_id=None, _name=None)
+ self.level = level
+ self.isequal = None
+ self.text = ""
+
+ def is_valid(self):
+ if self.level not in self.VALID_LEVEL:
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> Level missing or not valid level. {self.level}"
+ raise common.C5decError(info_msg)
+ if self.is_empty():
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> cannot be empty."
+ raise common.C5decError(info_msg)
+ return True
+
+ def get_formatted_text(self, level=1.0):
+ header_level = "#" * int(level)
+ formatted_text = f"\n{header_level} Audit: " + self.text + "\n"
+ return formatted_text
+
+
+class FCoAuditBuilder(BaseBuilder):
+ """
+ Builder class for creating FCoAudit instances.
+
+ :param instance: An instance of FCoAudit to build upon.
+ :type instance: FCoAudit
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an FCoAuditBuilder instance.
+
+ :param instance: An instance of FCoAudit to build upon.
+ :type instance: FCoAudit
+ :raises ValueError: If the provided instance is not an FCoAudit object.
+ """
+ if not isinstance(instance, FCoAudit):
+ info_msg = f"Object must be {FCoAudit}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.instance.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "level":
+ self.instance.level = node.get(attribute)
+ if attribute == "equal":
+ self.instance.isequal = node.get(attribute)
+
+ def _build_children(self, child):
+ """
+ FCoAudit does not contain any child items.
+ Method implemented since enforced by abstractclass defined in BaseBuilder.
+ """
+ pass
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ if self.instance.isequal:
+ self.instance.text += "Equal to " + self.instance.isequal
+ else:
+ self.instance.text += node.text
+ self.instance.text = clean_string(self.instance.text)
+ self.instance.is_valid()
+ return self.instance
+
+
+class FCoManagement(BaseClass):
+ """
+ Class representing functional component management in the context of CC.
+
+ :param _id: The ID of the FCoManagement element.
+ :type _id: str or None
+ :param _name: The name of the FCoManagement element.
+ :type _name: str or None
+ """
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.isequal = None
+ self.text = ""
+
+
+ def get_formatted_text(self, level=1.0):
+ header_level = "#" * int(level)
+ formatted_text = f"\n{header_level} Management: " + self.text + "\n"
+ return formatted_text
+
+ def is_valid(self):
+ if self.is_empty():
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> cannot be empty."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class FCoManagementBuilder(BaseBuilder):
+ """
+ Builder class for creating FCoManagement instances.
+
+ :param instance: An instance of FCoManagement to build upon.
+ :type instance: FCoManagement
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an FCoManagementBuilder instance.
+
+ :param instance: An instance of FCoManagement to build upon.
+ :type instance: FCoManagement
+ :raises ValueError: If the provided instance is not an FCoManagement object.
+ """
+ if not isinstance(instance, FCoManagement):
+ info_msg = f"Object must be {FCoManagement}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.instance.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "equal":
+ self.instance.isequal = node.get(attribute)
+
+ def _build_children(self, child):
+ """
+ FCoManagement does not contain any child items.
+ Method implemented since enforced by abstractclass defined in BaseBuilder.
+ """
+ pass
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ if self.instance.isequal:
+ self.instance.text += "Equal to " + self.instance.isequal
+ else:
+ self.instance.text += node.text
+ self.instance.text = clean_string(self.instance.text)
+ self.instance.is_valid()
+ return self.instance
+
+
+class FComponent(BaseClass):
+ """
+ Class representing a Functional Component in the context of CC:
+
+ :param _id: The ID of the FComponent.
+ :type _id: str, optional
+ :param _name: The name of the FComponent.
+ :type _name: str, optional
+
+ Inherits from `BaseClass` and adds the following attribute:
+ - `hierarchical` (list): list of Ids
+ - `dependencies` (list): list of Ids
+ - `management` (FCoManagement): the component management
+ - `audit`(FCoAudit): the component audit
+ - `fco_rationale` (ParaSequence): the component rationale
+ - `fco_user_notes` (ParaSequence): component user notes
+ - `fco_evaluator_notes` (ParaSequence): component evaluator notes
+ - `fco_levelling` (ParaSequence): componente levelling
+ """
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.hierarchical = []
+ self.dependencies = []
+ self.management = None
+ self.audit = None
+ self.fco_rationale = None
+ self.fco_user_notes = None
+ self.fco_evaluator_notes = None
+ self.fco_levelling = None
+
+ @property
+ def element(self):
+ return self.children
+
+ def get_hierarchical_tree(self, h_tree=None, visited=None):
+ if h_tree is None:
+ h_tree = set()
+ if visited is None:
+ visited = set()
+ if self in visited:
+ return h_tree
+ visited.add(self)
+ h_components = self.hierarchical
+ if not h_components:
+ return h_tree
+ else:
+ h_tree.update(h_components)
+ for h_component in h_components:
+ h_obj = Index.get(h_component)
+ h_obj.get_hierarchical_tree(h_tree=h_tree, visited=visited)
+ return h_tree
+
+ def get_dependency_pool(self, d_pool=None, visited=None):
+ if d_pool is None:
+ d_pool = set()
+ if visited is None:
+ visited = set()
+ if self in visited:
+ return d_pool
+ visited.add(self)
+ d_components = self.dependencies
+
+ for d_component in d_components:
+ # check if d_component is list and hence OR dependencies
+ if isinstance(d_component, list):
+ # add the OR tuple to the set
+ d_pool.add(tuple(d_component))
+ # iterate through or_components
+ for or_component in d_component:
+ if or_component not in visited:
+ d_obj = Index.get(or_component)
+ d_obj.get_dependency_pool(d_pool=d_pool, visited=visited)
+ else:
+ d_pool.add(d_component)
+ if d_component not in visited:
+ d_obj = Index.get(d_component)
+ d_obj.get_dependency_pool(d_pool=d_pool, visited=visited)
+ return d_pool
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#" * int(level)
+ formatted_text += f"\n{header_level} {self._id.upper()} {self._name or ''}\n"
+
+ if self.hierarchical:
+ formatted_text += f"\nHierarchical to: {''.join(self.hierarchical[0])}\n"
+
+ if self.dependencies:
+ formatted_text += "\nDependencies: "
+ for component in self.dependencies:
+ # check if "or" dependency
+ if len(component) > 1 and not isinstance(component, str):
+ formatted_text += f"[{' or '.join(component)}] "
+ else:
+ # if no "or" dependency
+ formatted_text += f"{component} "
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=(level+1))
+ return formatted_text
+
+ def is_valid(self):
+ self.has_valid_id()
+ self.has_valid_name()
+ if not self.fco_levelling\
+ or self.fco_levelling.original_tag != "fco-levelling":
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> is missing component levelling."
+ raise common.C5decError(info_msg)
+ if not self.children \
+ or not all(isinstance(child, FElement) for child in self.children):
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> must contain child elements of type {FElement}."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class FComponentBuilder(BaseBuilder):
+ """
+ Builder class for creating FComponent instances.
+
+ :param instance: An instance of FComponent to build upon.
+ :type instance: FComponent
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an FComponentBuilder instance.
+
+ :param instance: An instance of FComponent to build upon.
+ :type instance: FComponent
+ :raises ValueError: If the provided instance is not an FComponent object.
+ """
+ if not isinstance(instance, FComponent):
+ info_msg = f"Object must be {FComponent}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+
+ def _build_children(self, child):
+ PARASEQUENCE_OBJECTS = ["fco-rationale",
+ "fco-user-notes",
+ "fco-evaluator-notes",
+ "fco-levelling"]
+ node_name = child.tag
+ if node_name in PARASEQUENCE_OBJECTS:
+ str_to_attrib = node_name.replace("-", "_")
+ obj_ = ParaSequence().build(child, self.instance)
+ self.instance.container.append(obj_)
+ setattr(self.instance, str_to_attrib, obj_)
+ if node_name == "fco-management":
+ mgmt = FCoManagement()
+ obj_ = FCoManagementBuilder(mgmt).build(child, self.instance)
+ self.instance.management = obj_
+ self.instance.container.append(obj_)
+ if node_name == "fco-audit":
+ audit = FCoAudit()
+ obj_ = FCoAuditBuilder(audit).build(child, self.instance)
+ self.instance.audit = obj_
+ self.instance.container.append(obj_)
+ if node_name == "f-element":
+ element = FElement()
+ obj_ = FElementBuilder(element).build(child, self.instance)
+ self.instance.children.append(obj_)
+ if node_name == "fco-hierarchical":
+ self.instance.hierarchical = [child.get("fcomponent")]
+ if node_name == "fco-dependencies":
+ for grandchild in child:
+ if grandchild.tag == "fco-or":
+ component_list = []
+ for component in grandchild:
+ component_list.append(component.get("fcomponent"))
+ self.instance.dependencies.append(component_list)
+ else:
+ if(grandchild.get("fcomponent") == None):
+ # no component
+ pass
+ else:
+ self.instance.dependencies.append(grandchild.get("fcomponent"))
+
+
+class FFamily(BaseClass):
+ """
+ Class representing a Functional Family in the context of CC:
+
+ :param _id: The ID of the FFamily.
+ :type _id: str, optional
+ :param _name: The name of the FFamily.
+ :type _name: str, optional
+
+ Inherits from `BaseClass` and adds the following attributes:
+ - `ff_behaviour` (str): The behavior of the Functional Family.
+ - `ff_application_notes` (ParaSequence): Application notes for the Functional Family.
+ - `ff_user_notes` (ParaSequence): User notes for the Functional Family.
+ - `ff_evaluator_notes` (ParaSequence): Evaluator notes for the Functional Family.
+ """
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.ff_behaviour = None
+ self.ff_application_notes = None
+ self.ff_user_notes = None
+ self.ff_evaluator_notes = None
+
+ @property
+ def component(self):
+ return self.children
+
+ def is_valid(self):
+ self.has_valid_id()
+ self.has_valid_name()
+ if not self.ff_behaviour\
+ or self.ff_behaviour.original_tag != "ff-behaviour":
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> is missing family behaviour."
+ raise common.C5decError(info_msg)
+ if not self.children \
+ or not all(isinstance(child, FComponent) for child in self.children):
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> must contain child elements of type {FComponent}."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class FFamilyBuilder(BaseBuilder):
+ """
+ Builder class for creating FFamily instances.
+
+ :param instance: An instance of FFamily to build upon.
+ :type instance: FFamily
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an FFamilyBuilder instance.
+
+ :param instance: An instance of FFamily to build upon.
+ :type instance: FFamily
+ :raises ValueError: If the provided instance is not an FFamily object.
+ """
+ if not isinstance(instance, FFamily):
+ info_msg = f"Object must be {FFamily}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_children(self, child):
+ PARASEQUENCE_OBJECTS = ["ff-behaviour",
+ "ff-application-notes",
+ "ff-user-notes",
+ "ff-evaluator-notes"]
+ node_name = child.tag
+ if node_name in PARASEQUENCE_OBJECTS:
+ str_to_attrib = node_name.replace("-", "_")
+ obj_ = ParaSequence().build(child, self.instance)
+ self.instance.container.append(obj_)
+ setattr(self.instance, str_to_attrib, obj_)
+ if node_name == "f-component":
+ component = FComponent()
+ obj_ = FComponentBuilder(component).build(child, self.instance)
+ self.instance.children.append(obj_)
+
+
+class FClass(BaseClass):
+ """
+ Class representing a Functional Class in the context of CC.
+
+ :param _id: The ID of the Functional Class.
+ :type _id: str, optional
+ :param _name: The name of the Functional Class.
+ :type _name: str, optional
+
+ Inherits from `BaseClass` and adds the following attributes:
+ - `fc_introduction` (str): Introduction of the Functional Class.
+ - `fc_informative_notes` (str): Informative notes related to the Functional Class.
+ """
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.fc_introduction = None
+ self.fc_informative_notes = None
+
+ @property
+ def family(self):
+ return self.children
+
+ def is_valid(self):
+ self.has_valid_id()
+ self.has_valid_name()
+ if not self.fc_introduction\
+ or self.fc_introduction.original_tag != "fc-introduction":
+ info_msg = f"<{self.__class__} at {hex(id(self))}>\
+ Must contain fc-introduction."
+ raise common.C5decError(info_msg)
+ if not self.fc_informative_notes\
+ or self.fc_informative_notes.original_tag != "fc-informative-notes":
+ info_msg = f"<{self.__class__} at {hex(id(self))}>\
+ Must contain fc-informative-notes."
+ raise common.C5decError(info_msg)
+ if not self.children \
+ or not all(isinstance(child, FFamily) for child in self.children):
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> must contain child elements of type {FFamily}."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class FClassBuilder(BaseBuilder):
+ """
+ Builder class for creating FClass instances.
+
+ :param instance: An instance of FClass to build upon.
+ :type instance: FClass
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an FClassBuilder instance.
+
+ :param instance: An instance of FClass to build upon.
+ :type instance: FClass
+ :raises ValueError: If the provided instance is not an FClass object.
+ """
+ if not isinstance(instance, FClass):
+ info_msg = f"Object must be {FClass}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_children(self, child):
+ PARASEQUENCE_OBJECTS = ["fc-introduction",
+ "fc-informative-notes"]
+ node_name = child.tag
+ if node_name in PARASEQUENCE_OBJECTS:
+ str_to_attrib = node_name.replace("-", "_")
+ obj_ = ParaSequence().build(child, self.instance)
+ self.instance.container.append(obj_)
+ setattr(self.instance, str_to_attrib, obj_)
+ if node_name == "f-family":
+ family = FFamily()
+ obj_ = FFamilyBuilder(family).build(child, self.instance)
+ self.instance.children.append(obj_)
+
+
+"""End: Functional Class Elements"""
+
+"""Start: Assurance Class Elements"""
+
+
+class DCElement:
+ """
+ Class representing a ae-dc-element in the context of CC.
+ This class is a child object of a WorkUnit and only contains
+ an Id referring to an existing AElement of type `developer` or `content`.
+ """
+ def __init__(self, _id=None):
+ self._id = _id
+
+
+class WorkUnit(BaseClass):
+ """
+ Class representing a work unit in the context of CC.
+
+ :param _id: The ID of the work unit.
+ :type _id: str, optional
+ :param _name: The name of the work unit.
+ :type _name: str, optional
+
+ Inherits from `BaseClass` and adds the following attribute:
+ - `dc_element` (list): List of DC elements.
+ """
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.dc_element = []
+
+ def is_valid(self):
+ self.has_valid_id()
+ if self.is_empty():
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> cannot be empty."
+ raise common.C5decError(info_msg)
+ return True
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#" * int(level)
+ formatted_text += f"{header_level} {self._id.upper()} {self._name or ''}\n"
+ for element in self.container:
+ if isinstance(element, DCElement):
+ continue
+ formatted_text += element.get_formatted_text(level=(level+1))
+ return formatted_text
+
+
+class WorkUnitBuilder(BaseBuilder):
+ """
+ Builder class for creating WorkUnit instances.
+
+ :param instance: An instance of WorkUnit to build upon.
+ :type instance: WorkUnit
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize a WorkUnitBuilder instance.
+
+ :param instance: An instance of WorkUnit to build upon.
+ :type instance: WorkUnit
+ :raises ValueError: If the provided instance is not a WorkUnit object.
+ """
+ if not isinstance(instance, WorkUnit):
+ info_msg = f"Object must be {WorkUnit}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.instance.parent = parent_obj
+ parent_id = parent_obj._id.rsplit(".", 1)[0]
+ unit_id = UniqueIDManager().next(parent_id)
+ if node.get("id"):
+ assigned_id = node.get("id")
+ if unit_id != assigned_id:
+ unit_id = assigned_id
+ info_msg = f"Derived Id for <{self.__repr__()} at {id(self)}> does not match\
+ assigned Id. Derived Id {unit_id} is overwritten with assigned Id {assigned_id}."
+ log.info(info_msg)
+ self.instance._id = unit_id
+
+ def _build_children(self, child):
+ node_name = child.tag
+ if node_name == "ae-dc-element":
+ elem_id = child.get("id")
+ self.instance.dc_element.append(DCElement(elem_id))
+ self.instance.container.append(DCElement(elem_id))
+ if node_name == "para":
+ obj_ = Para().build(child, self.instance)
+ self.instance.container.append(obj_)
+ if node_name == "subclause":
+ obj_ = SubClause().build(child, self.instance)
+
+ self.instance.container.append(obj_)
+
+
+class AElement(BaseClass):
+ """
+ Class representing an assurance element in the context of CC. To differentiate
+ between the element type the AElement is assigned one of the valid types
+ ("developer", "content", "evaluator").
+
+ :param _id: The ID of the AElement.
+ :type _id: str, optional
+ :param el_type: The type of the AElement ("developer", "content", "evaluator").
+ :type el_type: str, optional
+
+ Inherits from `BaseClass` and adds the following attributes:
+ - `type` (str): The type of the AElement.
+ - `list` (list): A List.
+ - `operation` (list): A list of Operation associated with the AElement.
+ - `requirement` (str): the requirement stated by the AElement.
+ """
+
+ VALID_TYPES = ["developer", "content", "evaluator"]
+
+ def __init__(self, _id=None, el_type=None):
+ super().__init__(_id, None)
+ self.type = el_type
+ self.list = []
+ self.operation = []
+ self.requirement = ""
+
+ def is_valid(self):
+ self.has_valid_id()
+ if self.type not in self.VALID_TYPES:
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}>\
+ type must be one of {self.VALID_TYPES}, but is {self.type}."
+ raise common.C5decError(info_msg)
+ if self.is_empty():
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}>\ cannot be empty."
+ raise common.C5decError(info_msg)
+ return True
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#" * int(level)
+ formatted_text += f"\n{header_level} {self._id.upper()} {self._name or ''}\n\n"
+ for element in self.container:
+ if hasattr(element, 'get_formatted_text'):
+ formatted_text += element.get_formatted_text(level=(level + 1))
+ else:
+ raise common.C5decError(f"AttributeError: Object {element} does\
+ not have a 'get_formatted_text' method.")
+ return formatted_text
+
+
+class AElementBuilder(BaseBuilder):
+ """
+ Builder class for creating AElement instances.
+
+ :param instance: An instance of AElement to build upon.
+ :type instance: AElement
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an AElementBuilder instance.
+
+ :param instance: An instance of AElement to build upon.
+ :type instance: AElement
+ :raises ValueError: If the provided instance is not an AElement object.
+ """
+ if not isinstance(instance, AElement):
+ info_msg = f"Object must be {AElement}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.instance.parent = parent_obj
+ for attribute in node.attrib:
+ if attribute == "id":
+ self.instance._id = node.get("id")
+
+ def _build_children(self, child):
+ node_name = child.tag
+ if node_name == "list":
+ obj_ = List().build(child, self.instance)
+ self.instance.list.append(obj_)
+ self.instance.container.append(obj_)
+ if node_name in ["assignment", "selection"]:
+ operation = Operation(op_type=node_name)
+ obj_ = OperationBuilder(operation).build(child, self.instance)
+ self.instance.operation.append(obj_)
+ self.instance.container.append(obj_)
+ if node_name == "xref":
+ obj_ = XRef().build(child, self.instance)
+ self.instance.container.append(obj_)
+ if node_name == "m-workunit":
+ unit = WorkUnit()
+ obj_ = WorkUnitBuilder(unit).build(child, self.instance)
+ self.instance.children.append(obj_)
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node, parent_obj)
+ if node.text:
+ text = clean_string(node.text) + "\n"
+ self.instance.requirement += text
+ self.instance.container.append(Text(text))
+
+ for child in node:
+ self._build_children(child)
+ Index.update(self.instance._id, self.instance)
+ self.instance.is_valid()
+ return self.instance
+
+
+class AComponent(BaseClass):
+ """
+ Class representing an Assurance Component in the context of CC.
+
+ :param _id: The ID of the AComponent.
+ :type _id: str, optional
+ :param _name: The name of the AComponent.
+ :type _name: str, optional
+
+ Inherits from `BaseClass` and adds the following attributes:
+ - `hierarchical` (list): list of Ids
+ - `dependencies` (list): list of Ids
+ - `aco_objectives` (ParaSequence): component objectives
+ - `aco_application_notes` (ParaSequence): component application notes
+ - `msa_objectives` (ParaSequence): objective of the associated
+ evaluation sub-activity
+ - `msa_application_notes` (ParaSequence): application notes of the
+ associated evaluation sub-activity
+ - `msa_input` (ParaSequence): required input of the associated evaluation
+ sub-activity
+ """
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.hierarchical = []
+ self.dependencies = []
+ self.aco_objectives = None
+ self.aco_application_notes = None
+ self.msa_objectives = None
+ self.msa_application_notes = None
+ self.msa_input = None
+
+ @property
+ def elements(self):
+ return self.children
+
+ @property
+ def input(self):
+ if self.msa_input:
+ collection = self.msa_input.collector(Item, "type")
+ else:
+ collection = []
+ input_items = []
+ for item in collection:
+ input_items.append(clean_string(item.text)[:-1])
+ return input_items
+
+ def get_hierarchical_tree(self, h_tree=None, visited=None):
+ if h_tree is None:
+ h_tree = set()
+ if visited is None:
+ visited = set()
+ if self in visited:
+ return h_tree
+ visited.add(self)
+ h_components = self.hierarchical
+ if not h_components:
+ return h_tree
+ else:
+ h_tree.update(h_components)
+ for h_component in h_components:
+ h_obj = Index.get(h_component)
+ h_obj.get_hierarchical_tree(h_tree=h_tree, visited=visited)
+ return h_tree
+
+ def get_dependency_pool(self, d_pool=None, visited=None):
+ if d_pool is None:
+ d_pool = set()
+ if visited is None:
+ visited = set()
+ if self in visited:
+ return d_pool
+ visited.add(self)
+ d_components = self.dependencies
+ if not d_components:
+ return d_pool
+ else:
+ d_pool.update(d_components)
+ for d_component in d_components:
+ if d_component not in visited:
+ d_obj = Index.get(d_component)
+ d_obj.get_dependency_pool(d_pool=d_pool, visited=visited)
+ return d_pool
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#" * int(level)
+ formatted_text += f"\n{header_level} {self._id.upper()} {self._name or ''}\n"
+
+ if self.hierarchical:
+ formatted_text += f"\nHierarchical to: {''.join(self.hierarchical[0])}\n"
+
+ if self.dependencies:
+ formatted_text += "\nDependencies: "
+ for component in self.dependencies:
+ # check if "or" dependency
+ if len(component) > 1 and not isinstance(component, str):
+ comp_set = [comp for comp in component]
+ formatted_text += f"[{','.join(component)}], or\n"
+ else:
+ # if no "or" dependency
+ formatted_text += f"{component}\n"
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=(level+1))
+ return formatted_text
+
+ def is_valid(self):
+ self.has_valid_id()
+ self.has_valid_name()
+ if not self.children \
+ or not all(isinstance(child, AElement) for child in self.children):
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}>\
+ must (only) contain child elements of type {AElement}."
+ if self._id in ["ace_spd.1", "ace_obj.1"]:
+ # ace_spd.1 and ace_obj.1 refer to respective APE components.
+ log.info(info_msg)
+ else:
+ raise common.C5decError(info_msg)
+ return True
+
+
+class AComponentBuilder(BaseBuilder):
+ """
+ Builder class for creating AComponent instances.
+
+ :param instance: An instance of AComponent to build upon.
+ :type instance: AComponent
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an AComponentBuilder instance.
+
+ :param instance: An instance of AComponent to build upon.
+ :type instance: AComponent
+ :raises ValueError: If the provided instance is not an AComponent object.
+ """
+ if not isinstance(instance, AComponent):
+ info_msg = f"Object must be {AComponent}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_children(self, child):
+ PARASEQUENCE_OBJECTS = ["aco-objectives",
+ "aco-application-notes",
+ "msa-objectives",
+ "msa-application-notes",
+ "msa-input"]
+ AELEMENT = ["ae-developer", "ae-content", "ae-evaluator"]
+
+ node_name = child.tag
+ if node_name in PARASEQUENCE_OBJECTS:
+ str_to_attrib = node_name.replace("-", "_")
+ obj_ = ParaSequence().build(child, self.instance)
+ self.instance.container.append(obj_)
+ setattr(self.instance, str_to_attrib, obj_)
+ if node_name in AELEMENT:
+ el_type = node_name.split("-")[1]
+ element = AElement(el_type=el_type)
+ obj_ = AElementBuilder(element).build(child, self.instance)
+ self.instance.children.append(obj_)
+ if node_name == "aco-hierarchical":
+ self.instance.hierarchical.append(child.get("acomponent"))
+ if node_name == "aco-dependsoncomponent":
+ self.instance.dependencies.append(child.get("acomponent"))
+
+
+class AFamily(BaseClass):
+ """
+ Class representing an Assurance Family in the context of CC.
+
+ :param _id: The ID of the AFamily.
+ :type _id: str, optional
+ :param _name: The name of the AFamily.
+ :type _name: str, optional
+
+ Inherits from `BaseClass` and adds the following attributes:
+ - `af_objectives` (ParaSequence): family objectives
+ - `af_overview` (ParaSequence): family overview
+ - `af_levelling_criteria` (ParaSequence): family levelling criteria
+ - `af_application_notes` (ParaSequence): family application notes
+ """
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.af_objectives = None
+ self.af_overview = None
+ self.af_levelling_criteria = None
+ self.af_application_notes = None
+
+ @property
+ def component(self):
+ return self.children
+
+ def is_valid(self):
+ self.has_valid_id()
+ self.has_valid_name()
+ if not self.children \
+ or not all(isinstance(child, AComponent) for child in self.children):
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> must (only) contain child elements of type {AComponent}."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class AFamilyBuilder(BaseBuilder):
+ """
+ Builder class for creating AFamily instances.
+
+ :param instance: An instance of AFamily to build upon.
+ :type instance: AFamily
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an AFamilyBuilder instance.
+
+ :param instance: An instance of AFamily to build upon.
+ :type instance: AFamily
+ :raises ValueError: If the provided instance is not an AFamily object.
+ """
+ if not isinstance(instance, AFamily):
+ info_msg = f"Object must be {AFamily}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_children(self, child):
+ PARASEQUENCE_OBJECTS = ["af-objectives",
+ "af-overview",
+ "af-levelling-criteria",
+ "af-application-notes"]
+ node_name = child.tag
+ if node_name in PARASEQUENCE_OBJECTS:
+ str_to_attrib = node_name.replace("-", "_")
+ obj_ = ParaSequence().build(child, self.instance)
+ self.instance.container.append(obj_)
+ setattr(self.instance, str_to_attrib, obj_)
+ if node_name == "a-component":
+ component = AComponent()
+ obj_ = AComponentBuilder(component).build(child, self.instance)
+ self.instance.children.append(obj_)
+
+
+class AClass(BaseClass):
+ """
+ Class representing an Assurance Class in the context of CC.
+
+ :param _id: The ID of the Assurance Class.
+ :type _id: str, optional
+ :param _name: The name of the Assurance Class.
+ :type _name: str, optional
+
+ Inherits from `BaseClass` and adds the following attributes:
+ - `ac_introduction` (str): assurance class introduction.
+ - `ac_overview` (str): assurance class overview.
+ - `ac_application_notes` (ParaSequence): assurance class
+ application note.
+ - `ma_introduction` (str): introduction of associated
+ evaluation activity
+ - `ma_objectives` (ParaSequence): objectives of associated
+ evaluation activity
+ - `ma_application_note` (ParaSequence): application note of
+ associated evaluation activity
+ """
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.ac_introduction = None
+ self.ac_overview = None
+ self.ac_application_notes = None
+ self.ma_introduction = None
+ self.ma_objectives = None
+ self.ma_application_note = None
+
+ @property
+ def family(self):
+ return self.children
+
+ def is_valid(self):
+ self.has_valid_id()
+ self.has_valid_name()
+ if not self.ac_introduction\
+ or self.ac_introduction.original_tag != "ac-introduction":
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}>\
+ Must contain ac-introduction."
+ raise common.C5decError(info_msg)
+ if not self.children \
+ or not all(isinstance(child, AFamily) for child in self.children):
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> must (only) contain child elements of type {AFamily}."
+ raise common.C5decError(info_msg)
+ return True
+
+
+class AClassBuilder(BaseBuilder):
+ """
+ Builder class for creating AClass instances.
+
+ :param instance: An instance of AClass to build upon.
+ :type instance: AClass
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize an AClassBuilder instance.
+
+ :param instance: An instance of AClass to build upon.
+ :type instance: AClass
+ :raises ValueError: If the provided instance is not an AClass object.
+ """
+ if not isinstance(instance, AClass):
+ info_msg = f"Object must be {AClass}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+
+ def _build_children(self, child):
+ PARASEQUENCE_OBJECTS = ["ac-introduction",
+ "ac-overview",
+ "ac-application-notes",
+ "ma-introduction",
+ "ma-objectives",
+ "ma-application-notes"]
+
+ node_name = child.tag
+ if node_name in PARASEQUENCE_OBJECTS:
+ str_to_attrib = node_name.replace("-", "_")
+ obj_ = ParaSequence().build(child, self.instance)
+ self.instance.container.append(obj_)
+ setattr(self.instance, str_to_attrib, obj_)
+ if node_name == "a-family":
+ afamily = AFamily()
+ obj_ = AFamilyBuilder(afamily).build(child, self.instance)
+ self.instance.children.append(obj_)
+
+
+"""End: Assurance Class Elements"""
+
+"""Start: Evaluataion Assurance Levels"""
+
+class Package(BaseClass):
+
+ def __init__(self, _id=None, _name=None):
+ super().__init__(_id, _name)
+ self.acronym = None
+ self.type = "assurance"
+ self.objectives = None
+ self.assurance_components = None
+
+ def __str__(self):
+ return self.get_formatted_text()
+
+ def get_formatted_text(self, level=1.0):
+ formatted_text = ""
+ header_level = "#" * int(level)
+ formatted_text += f"\n{header_level} {self._id.upper()} {self._name or ''}\n"
+ for element in self.container:
+ formatted_text += element.get_formatted_text(level=(level+1))
+ formatted_text += "\nComponent List:\n\n"
+ formatted_text += "ID | Name \n"
+ formatted_text += "----------|---------------\n"
+ for child in self.children:
+ formatted_text += f"{child._id} | {child._name}\n"
+ return formatted_text
+
+ @property
+ def components(self):
+ return self.children
+
+ def link_components(self):
+ # method to call after CCDocument was build to replace component str with respectice objects
+ if not all(isinstance(child, str) for child in self.children) and self.is_valid():
+ return
+ components = []
+ for child in self.children:
+ component = Index.get(child)
+ components.append(component)
+ self.children = components
+
+ def is_valid(self):
+ self.has_valid_id()
+ self.has_valid_name()
+ if not self.objectives:
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> must contain an objective."
+ raise common.C5decError(info_msg)
+ if not self.assurance_components:
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> must contain Assurance Components."
+ raise common.C5decError(info_msg)
+ if not self.children:
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> must contain components."
+ raise common.C5decError(info_msg)
+
+ types = set([type(child) for child in self.children])
+ if len(types) > 1:
+ # check if children are all of same type:
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> components are of different types {types}."
+ raise common.C5decError(info_msg)
+ if all(isinstance(child, str) for child in self.children):
+ # is valid is called after build and component Ids not yet linked to object
+ try:
+ if not all(isinstance(Index.get(child), (AComponent, FComponent)) for child in self.children):
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> component IDs must correspond to assurance of functional components."
+ raise common.C5decError(info_msg)
+ except KeyError:
+ info_msg = f"Components of <{self.__repr__()} at {hex(id(self))}> not in Index."
+ raise common.C5decError(info_msg)
+ child_0 = Index.get(self.children[0])
+ if not all(isinstance(Index.get(child), type(child_0)) for child in self.children):
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> component IDs must all correspond to same component type. "
+ raise common.C5decError(info_msg)
+ return True
+ if all(isinstance(child, BaseClass) for child in self.children):
+ # is_valid called after linking Ids to objects or when manually defining Packages and assigning Component Objects.
+ if not all(child._id.lower() in Index._index for child in self.children):
+ info_msg = f"Components of <{self.__repr__()} at {hex(id(self))}> not in Index."
+ raise common.C5decError(info_msg)
+ if not all(isinstance(child, (AComponent, FComponent)) for child in self.children):
+ info_msg = f"Components of <{self.__repr__()} at {hex(id(self))}> must be of type {AComponent} or {FComponent}."
+ raise common.C5decError(info_msg)
+ if not all(isinstance(child, type(self.children[0])) for child in self.children):
+ info_msg = f"Components of <{self.__repr__()} at {hex(id(self))}> must be of same type!"
+ raise common.C5decError(info_msg)
+ return True
+
+ def get_descendants(self, visited=None):
+ self.link_components()
+ super().get_descendants(visited=visited)
+
+class PackageBuilder(BaseBuilder):
+
+ def __init__(self, instance):
+ if not isinstance(instance, Package):
+ info_msg = f"Object must be {Package}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_attributes(self, node, parent_obj):
+ self.instance.parent = parent_obj
+ self.instance.acronym = node.tag
+ for attribute in node.attrib:
+ if attribute == "id":
+ self.instance._id = node.get(attribute)
+ if attribute == "name":
+ self.instance._name = node.get(attribute)
+
+ def _build_children(self, child):
+ PARASEQUENCE_OBJECTS = [f"{self.instance.acronym}-objectives",
+ f"{self.instance.acronym}-assurance-components"]
+
+ node_name = child.tag
+ if node_name in PARASEQUENCE_OBJECTS:
+ str_to_attrib = node_name.split('-', 1)[-1].replace("-", "_")
+ obj_ = ParaSequence().build(child, self.instance)
+ self.instance.container.append(obj_)
+ setattr(self.instance, str_to_attrib, obj_)
+ if node_name == f"{self.instance.acronym}-component":
+ acomponent = child.get("acomponent")
+ self.instance.children.append(acomponent)
+
+
+"""End: Evaluation Assurance Levels"""
+
+"""Start: CC Document Class"""
+
+
+class CCDocument(BaseClass):
+ """
+ The CCDocument class serves as the root class for initializing and representing
+ a Common Criteria document.
+
+ :param version: Version of the Common Criteria document, defaults to None
+ :type version: str, optional
+ :param revision: Revision number of the Common Criteria document, defaults to None
+ :type revision: str, optional
+ :param lang: Language in which the document is written, defaults to "EN"
+ :type lang: str, optional
+
+ Inherits from `BaseClass` and adds the following attributes:
+ - `clause` (list): List of clauses.
+ - `f_class` (list): List of Functional Classes.
+ - `a_class` (list): List of Assurance Classes.
+ - `eal` (list): List of Evaluation Assurance Levels.
+ - `cap` (list): List of Composed Assurance Package.
+ """
+
+ def __init__(self, version=None, revision=None, lang="EN"):
+ super().__init__()
+ self.version = version
+ self.revision = revision
+ self.lang = lang
+ self.clause = []
+ self.f_class = []
+ self.a_class = []
+ self.eal = []
+ self.cap = []
+
+ def __str__(self):
+ """
+ Returns a formatted string representation of the CCDocument object.
+
+ :return: Formatted string
+ :rtype: str
+ """
+ """sout = f"This is version {self.version}{self.revision} of the Common Criteria.\n"
+ sout += "The document is outlined as follows:\n"
+ sout += "Index\t Clause title\t Clause type\n"
+ index = 0
+ for clause in self.clause:
+ sout += f"{index}\t {clause.title}\t {clause.type}\n"
+ index += 1
+ return sout"""
+ sout = ""
+ for container in self.container:
+ sout += container.get_formatted_text()
+ return sout
+
+ def is_valid(self):
+ if not self.version:
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> Version is missing."
+ raise common.C5decError(info_msg)
+ if not self.revision:
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> Revision is missing"
+ raise common.C5decError(info_msg)
+ if not all([self.clause, self.f_class, self.a_class, self.eal, self.cap]):
+ info_msg = f"<{self.__repr__()} at {hex(id(self))}> Incomplete."
+ raise common.C5decWarning(info_msg)
+ for element in self.container:
+ element.is_valid()
+ return True
+
+
+class CCDocumentBuilder(BaseBuilder):
+ """
+ Builder class for creating CCDocument instances.
+
+ :param instance: An instance of CCDocument to build upon.
+ :type instance: CCDocument
+ """
+
+ def __init__(self, instance):
+ """
+ Initialize a CCDocumentBuilder instance.
+
+ :param instance: An instance of CCDocument to build upon.
+ :type instance: CCDocument
+ :raises ValueError: If the provided instance is not a CCDocument object.
+ """
+ if not isinstance(instance, CCDocument):
+ info_msg = f"Object must be {CCDocument}, but is {type(instance)}."
+ raise common.C5decError(info_msg)
+ super().__init__(instance)
+
+ def _build_attributes(self, node, parent_obj=None):
+ self.instance._original_tagname = node.tag
+ for attribute in node.attrib:
+ if attribute == "version":
+ self.instance.version = node.get(attribute)
+ if attribute == "revision":
+ revision = node.get(attribute)
+ try:
+ self.instance.revision = int(float(revision))
+ except ValueError:
+ match = re.search(r"(\d+)", revision)
+ self.instance.revision = int(match.group(1)) if match else 1
+ if attribute == "lang":
+ self.instance.lang = node.get(attribute)
+ self.instance._id = "CCv" + str(int(float(self.instance.version))) + \
+ "R" + str(int(float(self.instance.revision)))
+
+ def _build_children(self, child):
+ UniqueIDManager()
+ node_name = child.tag
+ if node_name == "clause":
+ obj_ = Clause().build(child, self.instance)
+ obj_.original_tagname_ = node_name
+ self.instance.clause.append(obj_)
+ self.instance.container.append(obj_)
+ if node_name == "f-class":
+ fclass = FClass()
+ obj_ = FClassBuilder(fclass).build(child, self.instance)
+ obj_.original_tagname_ = node_name
+ self.instance.f_class.append(obj_)
+ self.instance.container.append(obj_)
+ if node_name == "a-class":
+ aclass = AClass()
+ obj_ = AClassBuilder(aclass).build(child, self.instance)
+ self.instance.a_class.append(obj_)
+ self.instance.container.append(obj_)
+ if node_name in ["eal", "cap"]:
+ package = Package()
+ obj_ = PackageBuilder(package).build(child, self.instance)
+ getattr(self.instance, obj_.acronym).append(obj_)
+ self.instance.container.append(obj_)
+
+ def build(self, node, parent_obj=None):
+ self._build_attributes(node)
+ for child in node:
+ self._build_children(child)
+ Index.update(self.instance._id, self.instance)
+ packages = list(Index.yield_obj(Package))
+ for package in packages:
+ package.link_components()
+ self.instance.is_valid()
+ return self.instance
+
+"""End: CC Document Class"""
+
+
+
+"""Start: Read XML"""
+
+def parsexml_(file_path, parser=None, **kwargs):
+ """
+ Parse an XML file using the specified parser or a default parser.
+
+ :param inFilePath: The path to the XML file to be parsed.
+ :type inFilePath: str or os.PathLike
+ :param parser: The XML parser to use (optional). If not provided, a default parser is used.
+ :type parser: lxml.etree.XMLParser, optional
+ :param **kwargs: Additional keyword arguments to pass to the XML parser.
+
+ :return: The parsed XML document.
+ :rtype: lxml.etree.ElementTree
+
+ This function reads and parses an XML file located at the specified path.
+ It allows you to specify a custom XML parser (such as one with specific options)
+ or use the default lxml ElementTree compatible parser. Any additional keyword
+ arguments provided are passed to the XML parser.
+
+ Example usage:
+ ```
+ parsed_doc = parsexml_("/path/to/myfile.xml")
+ ```
+ """
+ if parser is None:
+ # Use the lxml ElementTree compatible parser so that, e.g., comments are ignored.
+ try:
+ parser = etree_.ETCompactXMLParser()
+ except AttributeError:
+ # fallback to xml.etree
+ parser = etree_.XMLParser()
+ try:
+ if isinstance(file_path, os.PathLike):
+ file_path = os.path.join(file_path)
+ except AttributeError:
+ pass
+ doc = etree_.parse(file_path, parser=parser, **kwargs)
+ return doc
+
+def load_cc_xml(version, parser=None, silence=False):
+ """
+ Load a Common Criteria XML document based on the specified version.
+
+ :param version: The Common Criteria version to load (e.g., "3R5").
+ :type version: str
+ :param parser: The XML parser to use (optional). If not provided, a default parser is used.
+ :type parser: lxml.etree.XMLParser, optional
+ :param silence: Whether to suppress standard output messages (default is False).
+ :type silence: bool
+
+ :return: The root object representing the loaded Common Criteria document.
+ :rtype: CCDocument
+
+ This function loads a Common Criteria XML document based on the specified version.
+ It reads the XML file associated with the version and constructs a Python object
+ representing the Common Criteria document. You can optionally provide a custom
+ XML parser (such as one with specific options) or use the default parser. The
+ function also allows you to silence standard output messages.
+
+ Example usage:
+ ```
+ root_object = load_cc_xml("3R5", parser=None, silence=True)
+ ```
+ """
+ if not version:
+ version = "3R5"
+ xml_version_path = c5settings.CC_VERSION_TO_PATH.get(version)
+
+ doc = parsexml_(xml_version_path, parser)
+ root_node = doc.getroot()
+
+ if root_node.tag == "cc":
+ root_class = CCDocument()
+ else:
+ info_msg = f"Root element is {root_node.tag}. Root element must be 'cc'."
+ raise common.C5decError(info_msg)
+
+ root_obj = CCDocumentBuilder(root_class).build(root_node)
+
+ info_msg = "XML successfully parsed. "
+ info_msg += f"CC version {root_obj.version} Revision {root_obj.revision} loaded.\n"
+ log.info(info_msg)
+
+ if not silence:
+ sys.stdout.write(info_msg)
+
+ return root_obj
+
+"""End: Read XML"""
+
+"""Start: dependency validation methods"""
+
+def check_hierarchical(component, components_set, inverted=False):
+ if not inverted:
+ component_obj = Index.get(component)
+ h_tree = component_obj.get_hierarchical_tree()
+ if h_tree and any([h_comp in components_set for h_comp in h_tree]):
+ components_set -= set(h_tree)
+ return True
+ else:
+ for comp in components_set:
+ comp_obj = Index.get(comp)
+ h_tree = comp_obj.get_hierarchical_tree()
+ if component in h_tree:
+ return True
+ return False
+
+def check_dependencies(component, components_set):
+ component_obj = Index.get(component)
+ dependency_pool = component_obj.get_dependency_pool()
+
+ added = False
+ for dep in dependency_pool:
+ # check if OR dependency
+ if isinstance(dep, tuple):
+ # check if any OR component exists or any hierarchical components.
+ if not any(component in components_set for component in dep)\
+ and not any(check_hierarchical(component, components_set, inverted=True) for component in dep):
+ components_set.add(dep[0])
+ added = True
+ else:
+ if dep not in components_set\
+ and not check_hierarchical(dep, components_set, inverted=True):
+ components_set.add(dep)
+ added = True
+ return added
+
+def validate_dependencies(component_ids):
+ """
+ Validate dependencies and identify redundant or missing components in a components set.
+
+ This function checks the dependencies of components to identify any missing
+ dependencies and redundant components. It returns a boolean value indicating the validaty
+ of the provided set and a potential valid set in case the provided set is invalid.
+
+ :param components: A list of components to validate.
+ :type components: list/set of BaseClass (FComponent | AComponent)
+ :return: A tuple containing sets of redundant components and missing dependencies.
+ :rtype: tuple of (set, set)
+ """
+ components = [comp_id.lower() for comp_id in component_ids]
+ components_set = set(components)
+ processed = set()
+ component_queue = components.copy()
+
+ changed = set()
+ while component_queue:
+ component = component_queue.pop(0)
+ processed.add(component)
+ # Checking for hierarchical components that supersede others
+ removed_superseded = check_hierarchical(component, components_set)
+ changed.add(removed_superseded)
+ # Checking for missing dependencies
+ added_missing = check_dependencies(component, components_set)
+ changed.add(added_missing)
+ # add components that were not processed to component_queue
+ to_visit = components_set - processed
+ component_queue.extend(to_visit)
+
+ selection_is_valid = not any(changed)
+
+
+ return selection_is_valid, components_set
+
+
+"""End: dependency validation methods"""
+
+"""Start: Doorstop Index"""
+
+
+def save_index(index, filepath):
+ filepath += "/index.json"
+ with open(filepath, 'w') as file:
+ json.dump(index, file, indent=4)
+
+
+def load_index(filepath) -> None:
+ filepath += "/index.json"
+ with open(filepath, 'r') as file:
+ index = json.load(file)
+ return index
+
+
+def update_index(prefix):
+ """method to update the doorstop index in case changes where made manually."""
+ doc = get_evaluation_documents(doc_prefix=prefix)
+ index = load_index(doc.path)
+
+ components = index.get("Components")
+ for component, details in components.items():
+ for workunit, udetails in details.get("workunit").items():
+ item = doc.find_item(udetails["UID"])
+ item.review()
+ if udetails["hash"] != item._data["reviewed"]:
+ udetails["verdict"] = item._data["verdict"]
+ udetails["hash"] = str(item._data["reviewed"])
+ save_index(index, doc.path)
+
+
+def validate_index(index) -> bool:
+ """called when loading index to validate that index """
+ try:
+ root = index["DoorstopInfo"]["root"]
+ path = index["DoorstopInfo"]["path"]
+ prefix = index["DoorstopInfo"]["prefix"]
+ tree = doorstop.build(cwd=path, root=root)
+ doc = tree.find_document(prefix)
+ except doorstop.common.DoorstopError:
+ info_msg = f"Index Document with Prefix {prefix} does not exist."
+ raise common.C5decError(info_msg)
+
+ components = index["Components"]
+
+ units_validated = 0
+ for data in components.values():
+ workunits = data["workunit"]
+ for unit in workunits:
+ uid = workunits[unit]["UID"]
+ # check that item exists
+ try:
+ item = doc.find_item(uid)
+ # check that item does contain correct Work Unit
+ if item._data["header"].lower() != unit:
+ info_msg = f"Mismatch: Doorstop Item {uid} does not contain Work Unit {unit}"
+ raise common.C5decError(info_msg)
+ except doorstop.common.DoorstopError:
+ info_msg = f"Work Unit {unit} missing!"
+ raise common.C5decError(info_msg)
+
+ # check that index does refer to the latest version of item
+ item.review()
+ if workunits[unit]["hash"] != item._data["reviewed"].value:
+ info_msg = f"Discrepancy between Index and doorstop document at {uid}!"
+ raise common.C5decError(info_msg)
+ units_validated += 1
+ # check that Doorstop Document does not contain additional Work units
+ if units_validated != len(doc._items):
+ info_msg = "Additional Work Units detected!"
+ raise common.C5decError(info_msg)
+ return True
+
+
+def create_index(eval_index: dict, workunits: dict, gen_info: dict, filepath) -> dict:
+ """
+ implement checks for input. Document what gen_info should include
+ """
+ component_dict = {"Components" : {key : {'input': eval_index[key],
+ 'workunit': workunits[key]
+ } for key in eval_index}}
+
+ index = {**gen_info, **component_dict}
+ save_index(index, filepath)
+ return index
+
+
+"""End: Doorstop Index"""
+
+"""Start: Evaluation Checklist"""
+
+
+def save_document_config(doc):
+ data = {}
+ sets = {}
+ for key, value in doc._data.items():
+ if key == "prefix":
+ sets[key] = str(value)
+ elif key == "parent":
+ if value:
+ sets[key] = value
+ else:
+ sets[key] = value
+ data["settings"] = sets
+
+ attributes = {}
+ attributes["defaults"] = c5settings.DEFAULT_EVALUATION_ATTRIBUTES
+ attributes["publish"] = c5settings.DEFAULT_PUBLISH_ATTRIBUTES
+ attributes["reviewed"] = c5settings.DEFAULT_EVALUATION_REVIEWED
+ data["attributes"] = attributes
+ text = doc._dump(data)
+ doc._write(text, doc.config)
+
+
+def create_evaluation_document(rootpath=None, doc_prefix=None):
+ if rootpath == None:
+ root = c5settings.PROJECT_ROOT
+ else:
+ root = rootpath
+ if doc_prefix == None:
+ doc_prefix = "EVAL"
+ path = root + "/evaluation/" + doc_prefix.lower()
+
+ tree = doorstop.build(cwd=path, root=root)
+ doc = doorstop.Document.new(tree, path, root=rootpath, prefix=doc_prefix,
+ sep=c5settings.DEFAULT_SEPARATOR,
+ digits=c5settings.DEFAULT_DIGITS,
+ parent=c5settings.DOORSTOP_ROOT,
+ itemformat=c5settings.DEFAULT_ITEMFORMAT,
+ auto=False)
+ save_document_config(doc)
+ doc.load(reload=True)
+ log.info(f"Doorstop was initilaized at {path}")
+ return doc
+
+
+def get_evaluation_documents(rootpath=None, doc_prefix=None):
+ index = "index.json"
+ if rootpath == None:
+ root = c5settings.PROJECT_ROOT
+ else:
+ root = rootpath
+ tree = doorstop.build(cwd=".", root=root)
+
+ if doc_prefix:
+ document = tree.find_document(doc_prefix)
+ index_path = os.path.join(document.path, index)
+ if os.path.isfile(index_path):
+ return document
+
+ evaluation_documents = []
+ for document in tree.documents:
+ index_path = os.path.join(document.path, index)
+ if os.path.isfile(index_path):
+ evaluation_documents.append(document)
+ return evaluation_documents
+
+
+def get_doorstop_document(rootpath=None, doc_prefix=None):
+ if rootpath == None:
+ root = c5settings.PROJECT_ROOT
+ else:
+ root = rootpath
+ if doc_prefix == None:
+ doc_prefix = "EVAL"
+ path = root + "/evaluation/" + doc_prefix.lower()
+ tree = doorstop.build(cwd=path, root=root)
+ doc = tree.find_document(doc_prefix)
+ return doc
+
+
+def get_checklist_items(prefix):
+ try:
+ doc = get_evaluation_documents(doc_prefix=prefix)
+ except doorstop.common.DoorstopError:
+ docs = get_evaluation_documents()
+ docs_prefix = [str(doc.prefix) for doc in docs]
+ options = ('\n').join(docs_prefix)
+ raise common.C5decError(f"No Evaluation Checklist found for {prefix}. \nPlease select from: \n{options}")
+
+ index = load_index(doc.path)
+ components = index.get("Components")
+
+ units = []
+ for component, details in components.items():
+ for workunit in details.get("workunit"):
+ uid = components[component]["workunit"][workunit]["UID"]
+ item = doc.find_item(uid)
+ units.append((workunit.upper(), item))
+ return units
+
+
+def get_workunits_for_components(components: [AComponent]) -> dict:
+ if not all(isinstance(component, AComponent) for component in components):
+ info_msg = "Input components must be of type AComponent."
+ raise common.C5decError(info_msg)
+
+ component_dict = {}
+ for component in components:
+ workunits = component.collector(WorkUnit, mode="type")
+ component_dict[component._id] = {unit._id: {"UID":"",
+ "hash":""
+ } for unit in workunits}
+ return component_dict
+
+
+def get_input_for_components(components: [AComponent]) -> dict:
+ if not all(isinstance(component, AComponent) for component in components):
+ info_msg = "Input components must be of type AComponent."
+ raise common.C5decError(info_msg)
+
+ component_dict = {}
+ for component in components:
+ inputs = component.input
+ component_dict[component._id] = inputs
+ return component_dict
+
+
+def create_eval_item_dict(workunit: WorkUnit) -> dict:
+ def get_info(obj):
+ return {
+ 'id': getattr(obj, '_id', None),
+ 'text': obj.get_formatted_text() if hasattr(obj, 'get_formatted_text') else None
+ }
+
+ workunit_info = get_info(workunit)
+ workunit_id = workunit_info['id'].upper()
+ workunit_text = ('\n').join(workunit_info['text'].split('\n')[1:])
+ element = workunit.parent
+ element_info = get_info(element)
+ component = element.parent
+ component_info = get_info(component)
+ dc_elements = workunit.dc_element if isinstance(workunit.dc_element, list) else [workunit.dc_element]
+ dc_elements_info = [get_info(Index.get(dc_elem._id)) for dc_elem in dc_elements]
+
+ eval_item_dict = {
+ 'component': component_info['id'],
+ 'element': element_info['id'],
+ 'element_description': element_info['text'],
+ 'dc_element': [],
+ 'dc_element_description': [],
+ 'header': workunit_id,
+ 'text': workunit_text,
+ 'evidence': '',
+ 'verdict': 'inconclusive'
+ }
+
+ for info in dc_elements_info:
+ eval_item_dict['dc_element'].append(info['id'])
+ eval_item_dict['dc_element_description'].append(info['text'])
+ return eval_item_dict
+
+
+def create_evaluation_checklist(components: [AComponent], gen_info: dict, export_path=None, doc_prefix=None) -> None:
+ eval_input = get_input_for_components(components)
+ # If component set is valid retrieve component - workunits dict
+ workunit_dict = get_workunits_for_components(components)
+ doc = create_evaluation_document(export_path, doc_prefix)
+
+ doorstop_info = {"DoorstopInfo": {"root": doc.root,
+ "path": doc.path,
+ "prefix": doc.prefix}}
+ index_info = {**doorstop_info, **gen_info}
+
+ for component in components:
+ units = workunit_dict[component._id]
+ for unit in list(units.keys()):
+ unit_object = Index.get(unit)
+ defaults = create_eval_item_dict(unit_object)
+ item = doc.add_item()
+ item.set_attributes(defaults)
+ item.review()
+ units[unit]["UID"] = str(item.uid)
+ units[unit]["verdict"] = "inconclusive"
+ units[unit]["hash"] = item._data["reviewed"].value
+
+ create_index(eval_input, workunit_dict, index_info, filepath=doc.path)
+ return doc
+
+
+"""End: Evaluation Checklist"""
+
+"""Start: CLI methods"""
+
+
+def get_item(item_id, version, silence=True):
+ load_cc_xml(version, silence=silence)
+ item = Index.get(item_id)
+ print(item)
+
+
+def validate(item_ids, version, mode="dep", silence=True):
+ """
+ Validate components in a Common Criteria document.
+
+ This function validates components in a Common Criteria document based on the specified mode.
+
+ :param item_ids: A list of item IDs to validate.
+ :type item_ids: list of str
+ :param version: The version of the Common Criteria document.
+ :type version: str
+ :param mode: The validation mode ('dep' for dependency validation), defaults to "dep".
+ :type mode: str, optional
+ :param silence: If True, suppresses printing validation messages, defaults to True.
+ :type silence: bool, optional
+ """
+ if mode == "dep":
+ load_cc_xml(version, silence=silence)
+ is_valid, valid_set = validate_dependencies(item_ids)
+
+ if is_valid:
+ print("Selection valid!")
+ else:
+ print(f"Selection invalid!\n Potential valid set based on your selection {valid_set}")
+ else:
+ print("Validation mode currently not supported")
+
+
+class CLIChecklistHandler:
+
+ def __init__(self):
+ # maybe add a path at some point and default to root if not specified.
+ pass
+
+ def create(self, version, item_ids, prefix, info=None, silence=True):
+ load_cc_xml(version, silence=silence)
+ is_valid, valid_set = validate_dependencies(item_ids)
+ if not is_valid:
+ print(f"Component selection not valid. Potential valid set: {valid_set}")
+ return
+ components = [Index.get(_id) for _id in item_ids]
+ create_evaluation_checklist(components, info, doc_prefix=prefix)
+
+ def list(self, prefix):
+ items = get_checklist_items(prefix)
+ output = "Work Unit ID\tUID\t\tVerdict\n"
+ for workunit, item in items:
+ output += f"{workunit.upper()}\t{str(item.uid)}\t{item._data['verdict']}\n"
+ print(output)
+
+ def update(self, prefix):
+ update_index(prefix)
+
+ def validate(self, prefix):
+ """
+ Method to validate Checklist. For now only validates that index corresponds to current doc
+ In the future this will be the wrapper for all relevant validations.
+ """
+ doc = get_evaluation_documents(doc_prefix=prefix)
+ index = load_index(doc.path)
+ if validate_index(index):
+ print(f"{prefix} is valid.")
+
+ def _extract_verdicts(self, index):
+ for component in index["Components"].values():
+ for workunit in component["workunit"].values():
+ yield workunit["verdict"]
+
+ def status(self, prefix):
+ doc = get_evaluation_documents(doc_prefix=prefix)
+ index = load_index(doc.path)
+ verdicts = list(self._extract_verdicts(index))
+ total = len(verdicts)
+ if total == 0:
+ status = f"No Work Units for {prefix}."
+ print(status)
+ return
+ passed = 0
+ failed = 0
+ for verdict in verdicts:
+ if verdict == "pass":
+ passed += 1
+ if verdict == "fail":
+ failed += 1
+ status = f" Passed: {passed}, Failed: {failed}, Total: {total}"
+ print(status)
+
+ def edit(self, prefix, _id):
+ doc = get_evaluation_documents(doc_prefix=prefix)
+ _id = _id.lower()
+ try:
+ # assuming that _id is UID
+ item = doc.find_item(_id)
+ except doorstop.common.DoorstopError:
+ # not an UID or does not exist, try converting _id to UID
+ index = load_index(doc.path)
+ uid = None
+ for _, details in index.get("Components", {}).items():
+ if _id in details.get("workunit", {}):
+ uid = details["workunit"][_id]["UID"]
+ if not uid:
+ print(f"No item found for {prefix} and {_id}.")
+ return
+ item = doc.find_item(uid)
+ return item.path
+
+ def publish(self, prefix, path, template=None):
+ tree = doorstop.build()
+ doc = tree.find_document(prefix)
+ doorstop.core.publisher.publish(doc, path, template=template)
+
+
+"""End: CLI methods"""
diff --git a/c5dec/core/cpssa.py b/c5dec/core/cpssa.py
new file mode 100644
index 0000000..a34930c
--- /dev/null
+++ b/c5dec/core/cpssa.py
@@ -0,0 +1 @@
+# On the roadmap and planned for a future release (see the corresponding user manual entry)
\ No newline at end of file
diff --git a/c5dec/core/cryptography.py b/c5dec/core/cryptography.py
new file mode 100644
index 0000000..a34930c
--- /dev/null
+++ b/c5dec/core/cryptography.py
@@ -0,0 +1 @@
+# On the roadmap and planned for a future release (see the corresponding user manual entry)
\ No newline at end of file
diff --git a/c5dec/core/isms.py b/c5dec/core/isms.py
new file mode 100644
index 0000000..1bc2ff2
--- /dev/null
+++ b/c5dec/core/isms.py
@@ -0,0 +1,551 @@
+from copy import deepcopy
+import docx
+from docx.enum.dml import MSO_THEME_COLOR_INDEX
+from docx.text.run import Run
+from docx.oxml.text.run import CT_R
+import re
+import pandas as pd
+import os.path
+from datetime import datetime
+from time import time
+import json
+import pathlib
+import numpy as np
+import pandas as pd
+import re
+import os
+import csv
+import warnings
+import c5dec.settings as c5settings
+warnings.filterwarnings('ignore', category=UserWarning, module='openpyxl')
+
+class WordTagProcessor:
+ """
+ The model class for the MS Word tag processor.
+ """
+
+ def __init__(self) -> None:
+ self.params_are_set = False
+ self.ignore_missing_tag_mapping = False
+ self.default_link = "https://google.com"
+
+ self.regex_text = "(.*?)(#S(?:-\w+)+)(.*?)"
+ self.tag_regex = re.compile(r"{}".format(self.regex_text))
+
+ def set_params(self, doc_path, csv_path, regex_text, ignore_missing_tag=False):
+ self.doc_path = doc_path
+ self.csv_path = csv_path
+ self.regex_text = regex_text
+ self.tag_regex = re.compile(r"{}".format(regex_text))
+ self.keep_style = False
+ self.ignore_missing_tag_mapping = ignore_missing_tag
+ self.output_name = ""
+
+ self.doc = docx.Document(doc_path)
+ self.paras = self.doc.paragraphs
+
+ self.tag_dictionary = self.read_csv_into_dict(filepath=csv_path)
+
+ if self.output_name == "":
+ self.output_name = 'processed-'+os.path.basename(doc_path)+'.docx'
+
+ self.params_are_set = True
+
+ if self.tag_dictionary is None:
+ self.params_are_set = False
+
+ @staticmethod
+ def create_run_element():
+ # Create a w:r element
+ run = docx.oxml.shared.OxmlElement('w:r')
+ rPr = docx.oxml.shared.OxmlElement('w:rPr')
+ run.append(rPr)
+
+ return run
+
+ @staticmethod
+ def create_text_element(text):
+ # Create a w:t text element
+ new_text = docx.oxml.shared.OxmlElement('w:t')
+ tPr = docx.oxml.shared.OxmlElement('w:tPr')
+ new_text.append(tPr)
+ new_text.text = text
+
+ return new_text
+
+ @staticmethod
+ def create_hyperlink_element(p, link):
+ # Create a hyperlink element
+ r_id = p.part.relate_to(
+ link, docx.opc.constants.RELATIONSHIP_TYPE.HYPERLINK, is_external=True)
+ hyperlink = docx.oxml.shared.OxmlElement('w:hyperlink')
+ hyperlink.set(docx.oxml.shared.qn('r:id'), r_id, )
+
+ return hyperlink
+
+ @staticmethod
+ def create_hyperlink_run(hyperlink_element, link_text, para, run):
+
+ new_run_element = para._element._new_r()
+ run._element.addnext(new_run_element)
+ new_run = Run(new_run_element, run._parent)
+ new_run.text = link_text
+
+ hyperlink_element.append(new_run_element)
+ run._r.append(para.add_run(" ")._element)
+ run._r.append(hyperlink_element)
+
+ new_run.font.color.theme_color = MSO_THEME_COLOR_INDEX.HYPERLINK
+ new_run.font.underline = True
+
+ def read_csv_into_dict(self, filepath):
+ try:
+ tag_link_dict = pd.read_csv(
+ filepath, header=None, index_col=0).squeeze("columns").to_dict()
+ except Exception:
+ return None
+
+ return tag_link_dict
+
+ @staticmethod
+ def delete_para(p):
+ p = p._element
+ p.getparent().remove(p)
+ p._p = p._element = None
+
+ def extend_para(self, p, text, tag, link, skip_tag=False):
+ """
+ Adds a hyperlink to the tag in paragraph p, pointing to link.
+ """
+ # Create a run
+ new_text_run = self.create_run_element()
+
+ # Create a new run for the original text in front of the tag
+ new_text = self.create_text_element(text)
+ new_text_run.append(new_text)
+
+ # Add an extra run in between to add a space character and then add the text run to the paragraph
+ r = p.add_run(new_text_run.text, new_text_run.style)
+ p.add_run(" ")
+
+ if skip_tag:
+ # Create a run
+ new_text_run = self.create_run_element()
+
+ # Create a new run for the original text in front of the tag
+ new_text = self.create_text_element(tag)
+ new_text_run.append(new_text)
+
+ # Add an extra run in between to add a space character and then add the text run to the paragraph
+ p.add_run(new_text_run.text, new_text_run.style)
+ p.add_run(" ")
+ else:
+ # Create a hyperlink element
+ hyperlink = self.create_hyperlink_element(p, link)
+ self.create_hyperlink_run(hyperlink, tag, p, r)
+
+ def rebuild_para(self, p, text1, tag, text2, link):
+ """
+ Adds a hyperlink to the tag in paragraph p, pointing to link.
+ """
+ if text1 != "":
+ # Create a run
+ new_text_run = self.create_run_element()
+
+ # Create a new run for the original text in front of the tag
+ new_text = self.create_text_element(text1)
+ new_text_run.append(new_text)
+
+ # Add an extra run in between to add a space character and then add the text run to the paragraph
+ r = p.add_run()
+ r._r.append(new_text_run)
+ p.add_run(" ")
+
+ # Create a hyperlink element
+ hyperlink = self.create_hyperlink_element(p, link)
+
+ # Create a run (w:r) element and a new properties (w:rPr) element
+ new_run = self.create_run_element()
+
+ # Join all xml elements and update the hyperlink text
+ new_run.text = tag
+ hyperlink.append(new_run)
+
+ # Create a new Run object and add the hyperlink to it
+ r = p.add_run()
+ r._r.append(hyperlink)
+
+ # Workaround for when hyperlink style missing; delete if using a template that has a hyperlink style
+ r.font.color.theme_color = MSO_THEME_COLOR_INDEX.HYPERLINK
+ r.font.underline = True
+
+ # Create a w:r element and a new w:rPr element
+ new_text_run = self.create_run_element()
+
+ # Create a new run for the original text in front of the tag
+ new_text = self.create_text_element(text2)
+ new_text_run.append(new_text)
+
+ # Add an extra run in between to add a space character and then add the text run to the paragraph
+ p.add_run(" ")
+ r = p.add_run()
+ r._r.append(new_text_run)
+
+ def process_paras_for_tags(self):
+ """
+ For each regex match, i.e., a compatible hash tag pattern, remove the
+ hash tag and replace it with a hyperlink (in place).
+ This algorithm builds on a run-based logic (see Microsoft OXML specs for runs)
+ by going over runs per paragraph, retrieving the first pattern hit, adding a
+ hyperlink based on the found tag to the previous run and removing the tag from
+ the run in which it was found.
+ This implementation preserves the original paragraph style info.
+ """
+ paras = self.paras
+ tag_link_dict = self.tag_dictionary
+ tag_regex = self.tag_regex
+ total_matches = 0
+ for p in paras:
+ for i, run in enumerate(p.runs):
+ match = tag_regex.search(run.text)
+ if match:
+ total_matches += 1
+ previous_run = None
+ try:
+ previous_run = p.runs[i-1]
+ except IndexError:
+ previous_run = run
+
+ tag = match.group(2).strip()
+ link = tag_link_dict.get(tag)
+ if link is None:
+ if self.ignore_missing_tag_mapping:
+ continue
+ else:
+ link = self.default_link
+
+ leading_tag = False
+ if run.text.find(tag) == 0:
+ leading_tag = True
+
+ run.text = run.text.replace(tag, "")
+
+ hyperlink = self.create_hyperlink_element(p, link)
+
+ # Handle corner case where tag appears at the very
+ # beginning of a run: add tag to new run; append a
+ # copy of the original run
+ if i == 0 and leading_tag:
+ p_copy = deepcopy(p)
+ p.clear()
+ new_run_element = p._element._new_r()
+ r = p.add_run()
+ r._r.append(new_run_element)
+ previous_run = r
+
+ self.create_hyperlink_run(
+ hyperlink, tag, p, previous_run)
+
+ for r in p_copy.runs:
+ new_r = p.add_run()
+ new_r._r.append(r._element)
+ else:
+ self.create_hyperlink_run(
+ hyperlink, tag, p, previous_run)
+
+ def rebuild_paras_for_tags(self):
+ """
+ Makes hyperlinks based on hash tags and tag to link mapping by
+ rebuilding the paragraphs.
+ Does not preserve style information (more reliable solution).
+ """
+ paras = self.paras
+ tag_link_dict = self.tag_dictionary
+ tag_regex = re.compile(r"(.*?)(#S(?:-\w+)+)(.*)")
+ for p in paras:
+
+ t = str(p.text)
+ match = tag_regex.search(t)
+ match_found = False
+ match_count = 0
+
+ while match:
+ match_count += 1
+ match_found = True
+ if match_count == 1:
+ new_p = p.insert_paragraph_before()
+ p.clear()
+ text_after_tag = ""
+
+ text_before_tag = match.group(1).strip()
+ tag = match.group(2).strip()
+ text_after_tag = match.group(3).strip()
+
+ t = text_after_tag
+
+ link = tag_link_dict.get(tag)
+ skip_tag = False
+ if link is None:
+ if self.ignore_missing_tag_mapping:
+ skip_tag = True
+ else:
+ link = self.default_link
+
+ self.extend_para(new_p, text_before_tag, tag, link, skip_tag=skip_tag)
+
+ match = tag_regex.search(t)
+
+ if match_found:
+ new_p.add_run(t)
+ self.delete_para(p)
+
+ def convert_tags_to_hyperlinks(self, keep_style=False):
+ if not self.params_are_set:
+ raise IOError
+ if keep_style:
+ self.process_paras_for_tags()
+ else:
+ self.rebuild_paras_for_tags()
+ self.doc.save(os.path.join('./', self.output_name))
+
+class DocListAssistant:
+ """The model of the doc list assistant.
+
+ This is the model part of the MVC strcuture.
+ """
+ def __init__(self):
+ """Set up the key attributes needed for doc list assistance.
+
+ Get all authors from the json file in which they are stored.
+ """
+ self.doclist = list()
+ self.doclist_path = ""
+ self.doc_scan_path = ""
+ self.unlisted_docs = list()
+
+ self.used_filename_column_name = "UsedFilename"
+
+ self.folders = dict()
+
+ def get_unlisted_docs(self):
+ self.unlisted_docs = list()
+ df = pd.read_excel(self.doclist_path, sheet_name='DocList')
+
+ folder = pathlib.Path(self.doc_scan_path)
+
+ indexed_files_map = dict()
+ if not self.used_filename_column_name in df:
+ self.used_filename_column_name = "Filename"
+ return list()
+
+ for fn in df[self.used_filename_column_name]:
+ indexed_files_map[fn] = True
+ content_obj = folder.rglob("*")
+ file_list = list(filter(lambda item: item.is_file(), content_obj))
+ namepath_list = list()
+ scanned_file_list = []
+ for item in file_list:
+ pathAndFile = str(item).rsplit(os.sep, 1)
+ filename = pathAndFile[1]
+ scanned_file_list.append(filename)
+ namepath_list.append(pathAndFile)
+
+ unindexed_file_count = 0
+ for i, f in enumerate(scanned_file_list):
+ if f not in indexed_files_map:
+ unindexed_file_count += 1
+ self.unlisted_docs.append(f+" at: "+str(namepath_list[i][0]))
+
+ return self.unlisted_docs
+
+ def scandir(self):
+ """Scan a directory and collect all files and folders in a
+ dictionary.
+ """
+ folders = dict()
+ for dir, subdirs, files in os.walk(self.path):
+ dir = dir[len(self.path):]
+ listed_files = []
+ for i in files:
+ path = self.path + dir + "/" + i
+ if os.path.getmtime(path) > self.beginning_date:
+ listed_files.append(i)
+ folders.update({dir: listed_files})
+ self.folders = folders
+
+ def save_to_csv(self, csv_file):
+ """Save the activity report to a csv file.
+
+ :param csv_file: the filepath to the csv file
+ :type csv_file: str
+ """
+ with open(csv_file, "w", newline="") as csvfile:
+ writer = csv.writer(csvfile, delimiter=",")
+ for folder, files in self.activity_report.items():
+ for file_data in files:
+ entry = []
+ entry.append(folder+"/"+file_data.pop(0))
+ entry.extend(file_data)
+ writer.writerow(entry)
+
+class ActivityReport:
+ """The model of the activity report.
+
+ This is the model part of the MVC strcuture for the activity report
+ function.
+ """
+ def __init__(self):
+ """Set up the key attributes needed to generate an activity
+ report.
+
+ Get all authors from the json file in which they are stored.
+ """
+ self.authors = self.get_authors()
+ self.path = ""
+ self.author = ""
+ self.beginning_date = 0
+
+ self.folders = dict()
+ self.activity_report = dict()
+
+ def get_authors(self):
+ """Load all authors from the corresponding json file.
+
+ :return: the authors and their acronyms
+ :rtype: dictionary
+ """
+ with open(c5settings.PERSON_ACRONYMS_FILE_PATH) as f:
+ dictionary = json.load(f)
+
+ return dictionary
+
+ def set_date(self, months, days, hours):
+ """Set the date after which all files should be collected.
+
+ :param months: how many months to look back
+ :type months: int
+ :param days: how many days to look back
+ :type days: int
+ :param hours: how many hours to look back
+ :type hours: int
+ """
+ new_date = time()
+ new_date -= (hours*3600)
+ new_date -= (days*24*3600)
+ for i in range(months):
+ year = datetime.fromtimestamp(new_date).year
+ month = datetime.fromtimestamp(new_date).month-1
+ new_date -= (self.get_days_in_month(month, year)*24*3600)
+ self.beginning_date = new_date
+
+ def get_days_in_month(self, month, year):
+ """Get the amount of days in a specific month.
+
+ :param month: the current month as a number (e.g. June = 6)
+ :type month: int
+ :param year: the current year
+ :type year: int
+
+ :return: the number of days in a month
+ :rtype: int
+ """
+ if month in [1,3,5,7,8,10,12]:
+ return 31
+ elif month == 2:
+ if year%4 == 0 and (year%100 != 0 or year%400 == 0):
+ return 29
+ else:
+ return 28
+ else:
+ return 30
+
+ def scandir(self):
+ """Scan a directory and collect all files and folders in a
+ dictionary.
+ """
+ folders = dict()
+ for dir, subdirs, files in os.walk(self.path):
+ dir = dir[len(self.path):]
+ listed_files = []
+ for i in files:
+ path = self.path + dir + "/" + i
+ if os.path.getmtime(path) > self.beginning_date:
+ listed_files.append(i)
+ folders.update({dir: listed_files})
+ self.folders = folders
+
+ def get_activity_report(self):
+ """Create the activity report of a folder."""
+ self.scandir()
+ folder_activities = dict()
+ for folder, files in self.folders.items():
+ activities = []
+ for file in files:
+ filename = file
+ user = self.get_user(filename)
+ if self.author != 0:
+ if self.author != user:
+ continue
+ date_and_event = self.get_date_and_event(folder, file)
+ date = date_and_event[0]
+ event = date_and_event[1]
+ activities.append([filename, user, date, event])
+ folder_activities.update({folder: activities})
+ self.activity_report = folder_activities
+
+ return self.activity_report
+
+ def get_user(self, filename):
+ """Get the user/ author of a file by its filename.
+
+ :param filename: the name of the file
+ :type filename: str
+
+ :return: the author of the file
+ :rtype: str
+ """
+ user = filename[filename.rfind("-")+1:filename.rfind(".")]
+ match = False
+ for name, acronym in self.authors.items():
+ if acronym.lower() == user.lower():
+ user = name
+ match = True
+ if not match:
+ user = ""
+ return user
+
+ def get_date_and_event(self, folder, file):
+ """Get the last modification date and last event of a file.
+
+ :param folder: the folder in which the file is stored
+ :type folder: str
+ :param file: the file name
+ :type file: str
+
+ :return: the last modification time and the last event
+ :rtype: tuple
+ """
+ path = self.path + folder + "/" + file
+ lmtime = os.path.getmtime(path)
+ if lmtime == os.path.getctime(path):
+ event = "created"
+ else:
+ event = "edited"
+ lmtime = datetime.fromtimestamp(lmtime)
+ lmtime = lmtime.strftime("%d/%m/%Y %H:%M")
+ return (lmtime, event)
+
+ def save_to_csv(self, csv_file):
+ """Save the activity report to a csv file.
+
+ :param csv_file: the filepath to the csv file
+ :type csv_file: str
+ """
+ with open(csv_file, "w", newline="") as csvfile:
+ writer = csv.writer(csvfile, delimiter=",")
+ for folder, files in self.activity_report.items():
+ for file_data in files:
+ entry = []
+ entry.append(folder+"/"+file_data.pop(0))
+ entry.extend(file_data)
+ writer.writerow(entry)
diff --git a/c5dec/core/pm.py b/c5dec/core/pm.py
new file mode 100644
index 0000000..ea531bb
--- /dev/null
+++ b/c5dec/core/pm.py
@@ -0,0 +1,205 @@
+from datetime import datetime, timedelta, date
+import time
+import json
+import numpy as np
+import pandas as pd
+import os
+import pathlib
+import re
+import warnings
+import c5dec.settings as c5settings
+import c5dec.common as common
+log = common.logger(__name__)
+warnings.filterwarnings('ignore', category=UserWarning, module='openpyxl')
+
+class TimeReportAssistant:
+ """The model of the time report assistant.
+
+ This is the model part of the MVC strcuture.
+ """
+ def __init__(self):
+ """Set up the key attributes needed for time report assistance.
+ """
+ self.input_file_path = ""
+ self.tsh_folder_path = "."
+ self.apply_filters = False
+ self.from_date = None
+ self.to_date = None
+ self.filter_field = ""
+ self.filter_field_value = ""
+ self.df = None
+ self.consolidated_tsh_df = None
+
+ def set_tsh_folder_path(self, path):
+ self.tsh_folder_path = path
+
+ def set_timerep_parameters(self, source_folder, apply_filters=False, from_date=None, to_date=None,
+ filter_field="", filter_field_value=""):
+ self.tsh_folder_path = source_folder
+ self.apply_filters = apply_filters
+ self.from_date = from_date
+ self.to_date = to_date
+ self.filter_field = filter_field
+ self.filter_field_value = filter_field_value
+
+ def get_timerep_fields(self):
+ return self.read_tshparams_config_into_dict().get("ALab-TSH-columns")
+
+ def consolidate_timesheets(self):
+ folder = self.tsh_folder_path
+ folder_obj = pathlib.Path(folder)
+
+ df = None
+ columns = self.read_tshparams_config_into_dict().get("ALab-TSH-columns")
+ for index, item in enumerate(folder_obj.iterdir()):
+ if not item.is_dir():
+ if index == 0:
+ df = pd.read_excel(item, sheet_name='Timesheet')
+ df = df[columns]
+ else:
+ df_new = pd.read_excel(item, sheet_name='Timesheet')
+ df_new = df_new[columns]
+ df = pd.concat([df, df_new], ignore_index=True)
+
+ if self.apply_filters == True:
+ filtered_df = None
+
+ df['Date'] = pd.to_numeric(df['Date'], errors='coerce')
+ df['Date'] = df['Date'].fillna(0).astype(int)
+ df = df.dropna(subset=['Date'])
+
+ df['MM'] = pd.to_numeric(df['MM'], errors='coerce')
+ df['MM'] = df['MM'].fillna(0).astype(int)
+ df = df.dropna(subset=['MM'])
+
+ if self.from_date != None and self.to_date != None:
+ filtered_df = df.query("MM >= {} and MM <= {}".format(self.from_date.month, self.to_date.month))
+
+ if self.filter_field != "" and self.filter_field_value != "":
+ filtered_df = filtered_df.loc[filtered_df[self.filter_field] == self.filter_field_value]
+
+ df = filtered_df
+
+ self.consolidated_tsh_df = df
+
+ self.clean_consolidated_dataframe()
+ self.save_consolidated_tsh_df_to_excel()
+
+ def make_date_field(self, row):
+ try:
+ date_object = date(year=row["Year"], month=row["MM"], day=row["Date"])
+ return date_object
+ except Exception as e:
+ log.info("invalid date at row {}...".format(row))
+ return False
+
+ def clean_consolidated_dataframe(self):
+ df = self.consolidated_tsh_df
+
+ df = df.dropna(axis=0, how='all')
+
+ self.consolidated_tsh_df = df
+
+ def convert_openproject_time_report_to_IAL_format(self):
+ df = pd.read_excel(self.input_file_path, sheet_name=1, skiprows=[0]).dropna()
+
+ self.add_missing_columns(df)
+ # Parameters file containing WP to type and domain mappings
+ openproject_params_df = self.read_csv_to_df(c5settings.OPENPROJECT_PARAMS_CSV_FILE_PATH)
+
+ # Staff name acronyms
+ staff_acr_dict = self.get_staff_acronyms_dictionary()
+ df.replace({"User": staff_acr_dict}, inplace=True)
+
+ # Apply mappings to populate newly added columns
+ self.replace_key_with_value_in_df_column(df, "Type", openproject_params_df.WP, openproject_params_df.Type)
+ self.replace_key_with_value_in_df_column(df, "Domain/Project name", openproject_params_df.WP, openproject_params_df.Domain)
+
+ # Convert the OpenProject Date (Spent) value to day, month, year and weekday
+ df["Date"] = df["Date"].apply(lambda x: str(x).split('-')[2])
+ df["MM"] = df["MM"].apply(lambda x: str(x).split('-')[1])
+ df["YYYY"] = df["YYYY"].apply(lambda x: str(x).split('-')[0])
+ df["Day"] = df["Day"].apply(lambda x: pd.Timestamp(x).day_name())
+
+ # Extract start time from the Comment field; compute end time based on duration; populate both columns
+ df = self.extract_time_interval(df, "Start", "End", "Units")
+
+ # Rename columns according to ALab TSH template
+ df.rename(columns={"User": "ACR", "Activity": "Task", "Project": "Cust/WP", "Units": "Hours", "Work package": "Description"}, inplace=True)
+
+ # Adapt the column ordering according to ALab TSH template
+ new_col_order = ['ACR', 'Date', 'MM', 'YYYY', 'Day', 'Type', 'Domain/Project name', 'Cust/WP', 'Task', 'Location', 'Start', 'End', 'Hours', 'Days', 'Description']
+ df = df[new_col_order]
+
+ self.df = df
+
+ self.save_processed_timerep_df_to_excel()
+
+ return df
+
+ def read_csv_to_df(self, csv_path) -> pd.DataFrame:
+ return pd.read_csv(csv_path)
+
+ def read_tshparams_config_into_dict(self):
+ with open(c5settings.TSHFORMAT_JSON_FILE_PATH) as tshformat_json_file:
+ tshformat_json_file_content = tshformat_json_file.read()
+
+ parsed_tshformat = json.loads(tshformat_json_file_content)
+ return parsed_tshformat
+
+ def save_consolidated_tsh_df_to_excel(self) -> None:
+ current_time = time.strftime("%Y%m%d-%H%M%S")
+ file_path = "{0}/consolidated-TSH-{1}.xlsx".format(os.getcwd(), current_time)
+ self.consolidated_tsh_df.to_excel(file_path)
+
+ def save_processed_timerep_df_to_excel(self) -> None:
+ current_time = time.strftime("%Y%m%d-%H%M%S")
+ file_path = "{0}/output-{1}.xlsx".format(os.getcwd(), current_time)
+ self.df.to_excel(file_path)
+
+ def get_staff_acronyms_dictionary(self):
+ """Get all acronyms that are stored in a json file.
+
+ :param file: the file that stores acronyms (.json)
+ :type file: str
+
+ :return: a list that contains all acronyms in the file
+ :rtype: list
+ """
+ staff_acr_file_path = c5settings.PERSON_ACRONYMS_FILE_PATH
+
+ # read file
+ with open(staff_acr_file_path, 'r') as file:
+ data = file.read()
+
+ # parse file
+ acr_dict = json.loads(data)
+
+ return acr_dict
+
+ def add_missing_columns(self, df):
+ df["Date"] = df["Date (Spent)"]
+ df["MM"] = df["Date (Spent)"]
+ df["YYYY"] = df["Date (Spent)"]
+ df["Day"] = df["Date (Spent)"]
+ df["Type"] = df["Project"]
+ df["Domain/Project name"] = df["Project"]
+ df["Location"] = df["User"]
+ df["Start"] = df["Comment"]
+ df["End"] = df["Comment"]
+ df["Days"] = df["Units"]/8.0
+
+ def replace_key_with_value_in_df_column(self, dataframe, df_col_name, key_list, value_list):
+ keyvalue_dict = dict(zip(key_list, value_list))
+ dataframe.replace({df_col_name: keyvalue_dict}, inplace=True)
+
+ def extract_time_interval(self, df, start_col_name, end_col_name, duration_col_name):
+ df_copy = df.copy()
+ for index, row in df.iterrows():
+ start_cell = row[start_col_name]
+ duration = row[duration_col_name]
+ result = re.search(r".*{(\d+:\d+)}.*", start_cell)
+ if not result == None:
+ df_copy.at[index, start_col_name] = result.group(1)
+ df_copy.at[index, end_col_name] = (datetime.strptime(str(result.group(1)), "%H:%M") + timedelta(minutes=duration*60.0)).strftime('%H:%M')
+ return df_copy
\ No newline at end of file
diff --git a/c5dec/core/settings.py b/c5dec/core/settings.py
new file mode 100644
index 0000000..a34930c
--- /dev/null
+++ b/c5dec/core/settings.py
@@ -0,0 +1 @@
+# On the roadmap and planned for a future release (see the corresponding user manual entry)
\ No newline at end of file
diff --git a/c5dec/core/ssdlc.py b/c5dec/core/ssdlc.py
new file mode 100644
index 0000000..3aa994c
--- /dev/null
+++ b/c5dec/core/ssdlc.py
@@ -0,0 +1,139 @@
+import doorstop
+import os
+import c5dec.settings as c5settings
+import c5dec.common as common
+
+log = common.logger(__name__)
+
+def get_artifact_tree():
+ path = c5settings.PROJECT_ROOT
+ tree = doorstop.build(cwd=os.getcwd(), root=path)
+ return tree
+
+def get_documents():
+ path = c5settings.PROJECT_ROOT
+ tree = doorstop.build(cwd=os.getcwd(), root=path)
+ return tree.documents
+
+def create_artifact_repository(repo_prefix, path=None, parent_prefix=None):
+ if path is None:
+ path = c5settings.PROJECT_ROOT
+ tree = get_artifact_tree()
+ if parent_prefix is None:
+ tree.create_document(path, repo_prefix, sep=c5settings.DEFAULT_SEPARATOR)
+ else:
+ tree.create_document(path, repo_prefix, parent=parent_prefix, sep=c5settings.DEFAULT_SEPARATOR)
+
+def delete_artifact_repository(repo_prefix):
+ path = c5settings.PROJECT_ROOT
+ tree = get_artifact_tree()
+ document = tree.find_document(repo_prefix)
+
+ prefix, relpath = document.prefix, document.relpath
+ document.delete()
+
+def get_artifact_repository(repo_prefix, parent_repo_prefix=None):
+ tree = doorstop.build()
+ document = tree.find_document(repo_prefix)
+ return document
+
+def reorder_artifact_repository(repo_prefix):
+ tree = doorstop.build()
+ document = tree.find_document(repo_prefix)
+ document.reorder(manual=False)
+
+def clear_repository(repo_id):
+ tree = doorstop.build()
+ document = tree.find_document(repo_id)
+ for item in document.items:
+ item.clear()
+
+def clear_item(item_id):
+ tree = get_artifact_tree()
+ item = tree.find_item(item_id)
+ item.clear()
+
+def review_repository(repo_id):
+ tree = doorstop.build()
+ document = tree.find_document(repo_id)
+ for item in document.items:
+ item.review()
+
+def review_item(item_id):
+ tree = get_artifact_tree()
+ item = tree.find_item(item_id)
+ item.review()
+
+def add_item(repo_prefix, level=None, count=1):
+ path = c5settings.PROJECT_ROOT
+ tree = get_artifact_tree()
+ document = tree.find_document(repo_prefix)
+
+ for _ in range(count):
+ item = document.add_item(
+ level=level
+ )
+
+def remove_item(item_id):
+ path = c5settings.PROJECT_ROOT
+ tree = get_artifact_tree()
+ item = tree.find_item(item_id)
+ item.delete()
+
+def get_item_text(item_id):
+ path = c5settings.PROJECT_ROOT
+ tree = get_artifact_tree()
+ item = tree.find_item(item_id)
+ return item.text
+
+def set_item_text(item_id, text):
+ path = c5settings.PROJECT_ROOT
+ tree = get_artifact_tree()
+ item = tree.find_item(item_id)
+ item.text = text
+
+def link_child_item_to_parent(child_id, parent_id):
+ path = c5settings.PROJECT_ROOT
+ tree = get_artifact_tree()
+ tree.link_items(child_id, parent_id)
+
+def unlink_child_item_to_parent(child_id, parent_id):
+ path = c5settings.PROJECT_ROOT
+ tree = get_artifact_tree()
+ tree.unlink_items(child_id, parent_id)
+
+def get_item_links(item_id):
+ path = c5settings.PROJECT_ROOT
+ tree = get_artifact_tree()
+ item = tree.find_item(item_id)
+ links_string_list = [uid.string for uid in item.links]
+ return links_string_list
+
+def get_respository_attributes(repo_prefix):
+ tree = doorstop.build()
+ document = tree.find_document(repo_prefix)
+ print(document.extended_reviewed)
+ print(document.config)
+ print(document.publish)
+
+def generate_rtm():
+ """Generate a requirements traceability matrix."""
+ pass
+
+def link_artifacts_in_batch():
+ """Create item links from input table of ID mappings."""
+ pass
+
+def add_item_attribute_from_file():
+ """Read attributes, default values and publish status from CSV file
+ and write to Doorstop document YAML.
+ """
+ pass
+
+def visualize_req_graph():
+ """Visualize graph of req., specs and tests with status color coding."""
+ pass
+
+
+def tag_item():
+ pass
\ No newline at end of file
diff --git a/c5dec/core/transformer.py b/c5dec/core/transformer.py
new file mode 100644
index 0000000..6c1e5a1
--- /dev/null
+++ b/c5dec/core/transformer.py
@@ -0,0 +1,44 @@
+import doorstop
+import os
+import c5dec.settings as c5settings
+import c5dec.common as common
+import time
+
+log = common.logger(__name__)
+
+project_root = c5settings.PROJECT_ROOT
+
+def import_ssdlc_document(path, prefix, format):
+ tree = doorstop.build()
+ document = tree.find_document(prefix)
+ doorstop.importer.import_file(path, document, format)
+
+def export_ssdlc_document(label, path=None, format=".yml") -> str:
+ tree = doorstop.build()
+ if label != "all":
+ document = tree.find_document(label)
+ current_time = time.strftime("%Y%m%d-%H%M%S")
+ if path is None:
+ path = "{}/{}-export-{}{}".format(c5settings.EXPORT_FOLDER, label, current_time, format)
+ doorstop.exporter.export(document, path, format)
+ else:
+ if path is None:
+ path = "./export"
+ common.create_dirname(path)
+ doorstop.exporter.export(tree, path, format)
+ return path
+
+def publish_ssdlc_document(prefix, path=None, format="html"):
+ tree = doorstop.build()
+ if prefix != "all":
+ document = tree.find_document(prefix)
+ current_time = time.strftime("%Y%m%d-%H%M%S")
+ if path is None:
+ path = "{}/{}-publish-{}{}".format(c5settings.EXPORT_FOLDER, prefix, current_time, format)
+ doorstop.publisher.publish(document, path, format)
+ else:
+ if path is None:
+ path = "./export"
+ common.create_dirname(path)
+ doorstop.publisher.publish(tree, path, format)
+ return path
diff --git a/c5dec/frontend/__init__.py b/c5dec/frontend/__init__.py
new file mode 100644
index 0000000..0996955
--- /dev/null
+++ b/c5dec/frontend/__init__.py
@@ -0,0 +1,3 @@
+# import sys
+# sys.path.append(".")
+# sys.path.append("./app/app_start")
\ No newline at end of file
diff --git a/c5dec/frontend/cli/__init__.py b/c5dec/frontend/cli/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/c5dec/frontend/cli/commands.py b/c5dec/frontend/cli/commands.py
new file mode 100644
index 0000000..6facbb3
--- /dev/null
+++ b/c5dec/frontend/cli/commands.py
@@ -0,0 +1,132 @@
+"""CLI command functions."""
+
+# CLI design is based on that of Doorstop
+
+import os, sys, tempfile
+import time
+import subprocess
+from typing import Set
+
+import c5dec.frontend.tui.main as tui
+from c5dec import common
+import c5dec.settings as c5settings
+import c5dec.core.ssdlc as ssdlc
+import c5dec.core.pm as pm
+from datetime import datetime
+import c5dec.core.cct as cct
+
+log = common.logger(__name__)
+
+def open_editor(editor, filepath):
+ if not editor:
+ EDITOR = c5settings.DEFAULT_EDITOR
+ else:
+ EDITOR = os.environ.get('EDITOR', editor)
+
+ if EDITOR in ['vim', 'nano']:
+ with open(filepath, "r") as file:
+ initial = file.read()
+
+ with tempfile.NamedTemporaryFile(suffix=".tmp") as tf:
+ tf.write(bytes(initial, 'utf--8'))
+ tf.flush()
+ subprocess.run([EDITOR, tf.name])
+ tf.seek(0)
+ edited = tf.read()
+
+ if edited.decode('utf-8') != initial:
+ with open(filepath, "w") as file:
+ file.write(edited.decode('utf-8'))
+ info_msg = "File successfully saved."
+ log.info(info_msg)
+ else:
+ try:
+ subprocess.run([EDITOR, "-r", filepath], check=True,
+ stdin=sys.stdin, stdout=sys.stdout, stderr=sys.stderr)
+ except subprocess.CalledProcessError as e:
+ log.error(f"{e}")
+ except FileNotFoundError:
+ log.error(f"Editor {EDITOR} not found.")
+
+def get(name):
+ """Get a command function by name."""
+ if name:
+ log.debug("running command '{}'...".format(name))
+ return globals()["run_" + name]
+ else:
+ log.debug("launching main command...")
+ return run
+
+def run(args, cwd, error, catch=True): # pylint: disable=W0613
+ """Process arguments and run the `c5dec` subcommand.
+
+ :param args: Namespace of CLI arguments
+ :param cwd: current working directory
+ :param error: function to call for CLI errors
+ :param catch: catch and log :class:`~c5dec.common.c5decError`
+
+ """
+ tui.main(args, cwd)
+ return True
+
+def run_exportoptime(args, cwd, _, catch=True):
+ timerep_assistant = pm.TimeReportAssistant()
+ timerep_assistant.input_file_path = args.path
+ timerep_assistant.convert_openproject_time_report_to_IAL_format()
+
+def run_consolidate(args, cwd, _, catch=True):
+ timerep_assistant = pm.TimeReportAssistant()
+ timerep_assistant.set_tsh_folder_path(args.path)
+ date_format = '%d-%m-%Y'
+ if args.filter == None:
+ timerep_assistant.set_timerep_parameters(source_folder=args.path,apply_filters=False)
+ else:
+ timerep_assistant.set_timerep_parameters(source_folder=args.path, apply_filters=True,
+ from_date=datetime.strptime(args.fromdate, date_format),
+ to_date=datetime.strptime(args.to, date_format),
+ filter_field=args.field,
+ filter_field_value=args.value)
+ timerep_assistant.consolidate_timesheets()
+
+# This function is no longer used and should be removed
+# @deprecated
+def run_retrieveattr(args, cwd, _, catch=True):
+ ssdlc.get_respository_attributes(args.prefix)
+ timerep_assistant.consolidate_timesheets()
+
+def run_view(args, cwd, _, catch=True):
+ if args.verbose:
+ cct.get_item(args.id, args.version)
+ else:
+ cct.get_item(args.id, args.version, silence=True)
+
+def run_validate(args, cwd, _, catch=True):
+ if args.verbose:
+ cct.validate(args.id, args.version, mode=args.mode)
+ else:
+ cct.validate(args.id, args.version, mode=args.mode, silence=True)
+
+def run_checklist(args, cwd, _, catch=True):
+ if args.create:
+ if args.info:
+ info_dict = {k: v for k, v in (item.split('=') for item in args.info)}
+ else:
+ info_dict = {"GeneralInfo": f"{args.version or '3R5'}"}
+ cct.CLIChecklistHandler().create(args.version, args.id, args.prefix, info=info_dict)
+ if args.list:
+ cct.CLIChecklistHandler().list(args.prefix)
+ if args.update:
+ cct.CLIChecklistHandler().update(args.prefix)
+ if args.validate:
+ cct.CLIChecklistHandler().validate(args.prefix)
+ if args.status:
+ cct.CLIChecklistHandler().status(args.prefix)
+ if args.edit:
+ item = args.edit
+ abs_item_path = cct.CLIChecklistHandler().edit(args.prefix, item)
+ if abs_item_path:
+ rel_item_path = os.path.relpath(abs_item_path, cwd)
+ open_editor(args.editor, rel_item_path)
+ if args.publish:
+ path = os.path.abspath(os.path.join(cwd, args.publish))
+ cct.CLIChecklistHandler().publish(args.prefix, path)
\ No newline at end of file
diff --git a/c5dec/frontend/cli/main.py b/c5dec/frontend/cli/main.py
new file mode 100644
index 0000000..3500fd6
--- /dev/null
+++ b/c5dec/frontend/cli/main.py
@@ -0,0 +1,162 @@
+# CLI design is based on that of Doorstop
+
+import argparse
+import os
+import sys
+import doorstop
+
+from c5dec import common, settings
+from c5dec.frontend.cli import commands
+from c5dec.frontend.cli import utils
+
+log = common.logger(__name__)
+
+
+def run(args=None):
+ """Process command-line arguments and run the program."""
+ from c5dec import CLI, DESCRIPTION, VERSION
+
+ # Shared options
+ project = argparse.ArgumentParser(add_help=False)
+ try:
+ root = doorstop.builder.vcs.find_root(os.getcwd())
+ except doorstop.common.DoorstopError:
+ root = None
+ project.add_argument(
+ "-j",
+ "--project",
+ metavar="PATH",
+ help="set the path to the root of the project",
+ default=root,
+ )
+ settings.PROJECT_ROOT = root
+
+ debug = argparse.ArgumentParser(add_help=False)
+ debug.add_argument("-V", "--version", action="version", version=VERSION)
+ group = debug.add_mutually_exclusive_group()
+ group.add_argument(
+ "-v", "--verbose", action="count", default=0, help="enable verbose logging"
+ )
+
+ shared = {
+ "formatter_class": common.HelpFormatter,
+ "parents": [project, debug],
+ }
+
+ # Build main parser
+ parser = argparse.ArgumentParser(
+ prog=CLI, description=DESCRIPTION, **shared)
+
+ parser.add_argument(
+ "-t",
+ "--tui",
+ action="store_true",
+ help="run the textual user interface",
+ )
+
+ # Build sub-parsers
+ subs = parser.add_subparsers(help="", dest="command", metavar="")
+ _transformrep(subs)
+ _consolidate(subs)
+ _retrieveattr(subs)
+ _view(subs)
+ _validate(subs)
+ _checklist(subs)
+
+ # Parse arguments
+ args = parser.parse_args(args=args)
+
+ # Configure logging
+ utils.configure_logging(args.verbose)
+
+ # Run the program
+ function = commands.get(args.command)
+ try:
+ success = function(args, os.getcwd(), parser.error)
+ except common.C5decError as exc:
+ log.error(exc)
+ success = False
+ except KeyboardInterrupt:
+ log.debug("command cancelled")
+ success = False
+ if success:
+ log.debug("command succeeded")
+ else:
+ log.debug("command failed")
+ sys.exit(1)
+
+@common.feature_flag("ON")
+def _transformrep(subs):
+ info = "Invoke the OpenProject time report conversion command"
+ sub = subs.add_parser(
+ "transformrep", description=info.capitalize() + ".", help=info
+ )
+ sub.add_argument("path", help="path to OpenProject time report")
+
+@common.feature_flag("ON")
+def _consolidate(subs):
+ info = "Invoke the time report consolidation command"
+ sub = subs.add_parser(
+ "consolidate", description=info.capitalize() + ".", help=info
+ )
+ sub.add_argument("path", help="path to directory containing time reports")
+ sub.add_argument("-l", "--filter", help="apply filters to the consolidated report")
+ sub.add_argument("-f", "--fromdate", help="starting from date, i.e., entries having date after this input")
+ sub.add_argument("-t", "--to", help="up to date, i.e., entries having date before this input")
+ sub.add_argument("-d", "--field", help="Field name to filter for, e.g., Domain")
+ sub.add_argument("-v", "--value", help="Field value to filter for, e.g., RD")
+
+@common.feature_flag("OFF")
+def _retrieveattr(subs):
+ """Configure the `c5dec attribute retrieval` subparser."""
+ info = "Invoke the attributes retrieval command from the SSDLC module"
+ sub = subs.add_parser(
+ "retrieveattr", description=info.capitalize() + ".", help=info)
+ sub.add_argument("prefix", help="prefix of artifact repository")
+
+def add_common_args(sub):
+ versions_supported = ["3R1", "3R2", "3R3", "3R4", "3R5"]
+ sub.add_argument("-v", "--verbose", action="store_true")
+ sub.add_argument("--version",
+ help=f"Specify the Common Criteria (CC) version: {versions_supported}")
+
+def _view(subs):
+ info = "Retrieve CC item with id or name."
+ sub = subs.add_parser(
+ "view", description=info.capitalize() + ".", help=info)
+ sub.add_argument("id", help="CC item ID. Case insensitive.")
+ add_common_args(sub)
+
+def _validate(subs):
+ info = "CC validation interface."
+ sub = subs.add_parser(
+ "validate", description=info.capitalize() + ".", help=info)
+ sub.add_argument("id", help="List of CC component IDs.", nargs="+")
+ sub.add_argument("-d", "--dependency", action="store_const", const="dep", dest="mode",
+ help="Validate Component List for dependencies.")
+ add_common_args(sub)
+
+def _checklist(subs):
+ info = "Evaluation Checklist"
+ sub = subs.add_parser(
+ "checklist", description=f"{info.capitalize()}. NOTE: the must appear before the options: c5dec checklist prefix [options]" + ".", help=info)
+ sub.add_argument("prefix", help="The identifier/name of the checklist, used as a prefix to name its components.")
+
+ group = sub.add_mutually_exclusive_group()
+ group.add_argument("-c", "--create", action="store_true",
+ help="Create evaluation checklist from component and/or package IDs.")
+ group.add_argument("-l", "--list", const=True, default=False,
+ help="List all available checklists.", nargs="?")
+ group.add_argument("--edit", help="Edit Work Unit.")
+ group.add_argument("-u", "--update", action="store_true",
+ help="Update Evaluation Checklist.")
+ group.add_argument("--validate", action="store_true",
+ help="Validate Evaluation Checklist.")
+ group.add_argument("-s", "--status", action="store_true",
+ help="Retrieve the status of Evaluation Checklist.")
+ group.add_argument("--publish", help="Publish Evaluation Checklist to path.")
+
+ sub.add_argument("--id", help="List of Component IDs",
+ required='-c' in sys.argv or '--create' in sys.argv, nargs="+")
+ sub.add_argument("--info", help="General Information of Evaluation Project.", nargs="+")
+ sub.add_argument("--editor", help="Set editor. Defaults to 'vim'.")
diff --git a/c5dec/frontend/cli/utils.py b/c5dec/frontend/cli/utils.py
new file mode 100644
index 0000000..8f78090
--- /dev/null
+++ b/c5dec/frontend/cli/utils.py
@@ -0,0 +1,87 @@
+"""Common functions used by CLI functionality."""
+
+from c5dec import settings, common
+import logging
+
+log = common.logger(__name__)
+
+def configure_logging(verbosity=0):
+ """Configure logging using the provided verbosity level (0+)."""
+ assert common.PRINT_VERBOSITY == 0
+ assert common.STR_VERBOSITY == 3
+ assert common.MAX_VERBOSITY == 4
+
+ # Configure the logging level and format
+ if verbosity == -1:
+ level = settings.QUIET_LOGGING_LEVEL
+ default_format = settings.DEFAULT_LOGGING_FORMAT
+ verbose_format = settings.LEVELED_LOGGING_FORMAT
+ elif verbosity == 0:
+ level = settings.DEFAULT_LOGGING_LEVEL
+ default_format = settings.DEFAULT_LOGGING_FORMAT
+ verbose_format = settings.LEVELED_LOGGING_FORMAT
+ elif verbosity == 1:
+ level = settings.VERBOSE_LOGGING_LEVEL
+ default_format = settings.DEFAULT_LOGGING_FORMAT
+ verbose_format = settings.LEVELED_LOGGING_FORMAT
+ elif verbosity == 2:
+ level = settings.VERBOSE2_LOGGING_LEVEL
+ default_format = verbose_format = settings.VERBOSE_LOGGING_FORMAT
+ elif verbosity == 3:
+ level = settings.VERBOSE3_LOGGING_LEVEL
+ default_format = verbose_format = settings.VERBOSE_LOGGING_FORMAT
+ else:
+ level = settings.VERBOSE3_LOGGING_LEVEL
+ default_format = verbose_format = settings.VERBOSE2_LOGGING_FORMAT
+
+ # Set a custom formatter
+ if not logging.root.handlers:
+ logging.basicConfig(level=level)
+ logging.captureWarnings(True)
+ formatter = common.WarningFormatter(default_format, verbose_format)
+ logging.root.handlers[0].setFormatter(formatter)
+
+ # Warn about excessive verbosity
+ if verbosity > common.MAX_VERBOSITY:
+ msg = "maximum verbosity level is {}".format(common.MAX_VERBOSITY)
+ logging.warning(msg)
+ common.verbosity = common.MAX_VERBOSITY
+ else:
+ common.verbosity = verbosity
+
+
+def configure_settings(args):
+ """Update settings based on the command-line options."""
+
+ # Parse common settings
+ if args.no_reformat is not None:
+ settings.REFORMAT = args.no_reformat is False
+ if args.reorder is not None:
+ settings.REORDER = args.reorder is True
+ if args.no_level_check is not None:
+ settings.CHECK_LEVELS = args.no_level_check is False
+ if args.no_ref_check is not None:
+ settings.CHECK_REF = args.no_ref_check is False
+ if args.no_child_check is not None:
+ settings.CHECK_CHILD_LINKS = args.no_child_check is False
+ if args.strict_child_check is not None:
+ settings.CHECK_CHILD_LINKS_STRICT = args.strict_child_check is True
+ if args.no_suspect_check is not None:
+ settings.CHECK_SUSPECT_LINKS = args.no_suspect_check is False
+ if args.no_review_check is not None:
+ settings.CHECK_REVIEW_STATUS = args.no_review_check is False
+ if args.no_cache is not None:
+ settings.CACHE_DOCUMENTS = args.no_cache is False
+ settings.CACHE_ITEMS = args.no_cache is False
+ settings.CACHE_PATHS = args.no_cache is False
+ if args.warn_all is not None:
+ settings.WARN_ALL = args.warn_all is True
+ if args.error_all is not None:
+ settings.ERROR_ALL = args.error_all is True
+
+ # Parse `publish` settings
+ if hasattr(args, "no_child_links") and args.no_child_links is not None:
+ settings.PUBLISH_CHILD_LINKS = args.no_child_links is False
+ if hasattr(args, "no_levels") and args.no_levels is not None:
+ settings.PUBLISH_BODY_LEVELS = False
+ settings.PUBLISH_HEADING_LEVELS = args.no_levels != "all"
\ No newline at end of file
diff --git a/c5dec/frontend/tui/__init__.py b/c5dec/frontend/tui/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/c5dec/frontend/tui/application.py b/c5dec/frontend/tui/application.py
new file mode 100644
index 0000000..79dd2d4
--- /dev/null
+++ b/c5dec/frontend/tui/application.py
@@ -0,0 +1,155 @@
+from asciimatics.scene import Scene
+from asciimatics.screen import Screen
+from asciimatics.exceptions import ResizeScreenError
+from c5dec.frontend.tui.foundation.menu import Menu, MenuView
+from i18n import t as translate
+import sys
+import i18n
+import json
+import c5dec.settings as c5settings
+
+
+class Application(Menu):
+ """The primary element of the program.
+
+ The application creates and contains all scenes of the program.
+ """
+ def __init__(self):
+ """Set up the Application, its template and language.
+
+ :param app_name: the name of the app and title of the main menu,
+ defaults to None
+ :type app_name: str, optional
+ :param lang: the language in which the TUI will be displayed,
+ defaults to en
+ :type lang: str
+ """
+ app_name = self.get_value_from_json("title", "C5-DEC CAD")
+ lang = self.get_value_from_json("language", "en")
+ self.setLanguage(lang)
+ self.menu_view = None
+ super(Application, self).__init__(name=translate(app_name))
+ self.data_models = {}
+
+ def get_data_model(self, name):
+ return self.data_models.get(name)
+
+ def set_data_model(self, name, model):
+ self.data_models[name] = model
+
+ def demo(self, screen, scene, menu):
+ """Create all the scenes.
+
+ :param screen: the screen of the TUI (automatically passed)
+ :type screen: class `Screen`
+ :param scene: the starting scene of the TUI
+ :type scene: class `Scene`
+ :param menu: the main menu that is used to build up the program
+ :type menu: class `Menu`
+ """
+ self.menu_view = MenuView(screen, menu)
+ main_menu = self.menu_view
+ scenes = [Scene([main_menu], -1, name=menu.name)]
+
+ # Add all functions of the main menu to the scenes.
+ submenus = menu.get_all_submenus()
+ for function_name in list(menu.functions.keys()):
+ scenes.append(
+ Scene(
+ [menu.functions[function_name](screen, menu)],
+ -1,
+ name=function_name)
+ )
+
+ # Add all submenus and all its functions to the scenes
+ for submenu in submenus:
+ scenes.append(
+ Scene(
+ [MenuView(screen, submenu)],
+ -1,
+ name=submenu.name)
+ )
+ for function_name in list(submenu.functions.keys()):
+ function_view = submenu.functions[function_name](screen, submenu, self.get_data_model(function_name))
+ scenes.append(
+ Scene(
+ [function_view],
+ -1,
+ name=function_name)
+ )
+
+ # Play the scenes.
+ screen.play(scenes,
+ stop_on_resize=True,
+ start_scene=scene,
+ allow_int=True)
+
+ def run(self):
+ """Start the application and the tui.
+
+ The arguments of the self.demo function are passed by the list
+ arguments in the row below.
+ This function displays the scenes, so it starts the TUI
+ """
+ last_scene = None
+ while True:
+ try:
+ Screen.wrapper(
+ self.demo,
+ arguments=[last_scene, self],
+ catch_interrupt=False)
+ sys.exit(0)
+ except ResizeScreenError as e:
+ last_scene = e.scene
+
+ def setLanguage(self, lang):
+ """Set the language of the tui.
+
+ :param lang: the language in which the TUI should be displayed
+ :type lang: str
+ """
+ lang_dict = {
+ "en": {"english", "englisch", "anglais"},
+ "de": {"german", "deutsch", "allemand"},
+ "fr": {"french", "französisch", "francais"}
+ }
+
+ # Find the selected language.
+ lang = lang.lower()
+ for key, value in lang_dict.items():
+ if lang == key or lang in value:
+ lang = key
+ break
+
+ if lang not in lang_dict.keys():
+ raise ValueError("Unknown language string")
+
+ # Load the translations and translate.
+ # import os
+ i18n.load_path.append(c5settings.TRANSLATION_ASSETS_FOLDER_PATH)
+ i18n.set('skip_locale_root_data', True)
+ i18n.set('file_format', 'json')
+ i18n.set('filename_format', '{locale}.{format}')
+ i18n.set('locale', lang)
+
+ def get_value_from_json(self, key, default_value):
+ """Returns the corresponding value to a key in the config.json
+ file.
+
+ :param key: the setting whose value is searched
+ :type key: str
+ :param default_value: the value that will be used if the file
+ cannot be loaded
+ :type default_value: str or int
+
+ :return: the value that belongs to the entered key
+ :rtype: str or int
+ """
+ try:
+ with open(c5settings.STARTUP_CONFIG_JSON_PATH) as f:
+ dictionary = json.load(f)
+ value = dictionary[key]
+ except:
+ value = default_value
+
+ return value
\ No newline at end of file
diff --git a/c5dec/frontend/tui/foundation/__init__.py b/c5dec/frontend/tui/foundation/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/c5dec/frontend/tui/foundation/builder.py b/c5dec/frontend/tui/foundation/builder.py
new file mode 100644
index 0000000..903a1f0
--- /dev/null
+++ b/c5dec/frontend/tui/foundation/builder.py
@@ -0,0 +1,550 @@
+from asciimatics.widgets import Button, Layout, CheckBox, MultiColumnListBox,\
+ RadioButtons, Divider, Text, TextBox, DropdownList, Widget, ListBox, Label, DatePicker
+from asciimatics.parsers import AsciimaticsParser
+from i18n import t as translate
+import pyperclip as pc
+
+
+class Builder:
+ """The Builder is used to build a frame layout on the template.
+
+ The builder can be passed to the template to set up new frame
+ layouts on the same template more efficiently. The footer can be
+ spared and the builder provides several, more efficient ways to add
+ widgets.
+ """
+ def __init__(self, title):
+ """Set up the builder with the frame's title.
+
+ :param title: the title for the menu
+ :type title: str
+ """
+ self.title = title
+ self.widgets = []
+
+ def addLayout(self, list, fill_frame=False):
+ """Add a layout.
+
+ :param list: list of columns and relational widths, eg. [1,1,1]
+ :type list: list
+ :param fill_frame if the layout fills out the rest of the
+ frame, defaults to False
+ :type fill_frame: bool
+ """
+ widget = Layout(list, fill_frame=fill_frame)
+ self.widgets.append(widget)
+ return widget
+
+ def addWidget(self, widget, position=0, span=1):
+ """Add a widget to a optionally specified column.
+
+ :param widget: the widget that should be added to the layout
+ :type widget: class `Widget`
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position:, int
+
+ :return: The widget that is added
+ :rtype: class `Widget`
+ """
+ self.widgets.append((widget, position, span))
+ return widget
+
+ def add_label(self, label, position=0,
+ gap=False, gap_height=1, disabled=False):
+ """Add a label with an optional gap.
+
+ :param label: the string in front of the input field
+ :type label: str
+ :param name: the name of the widget, useful for data[name]
+ :type name: str
+ :param on_change: function that is called when the input
+ changes, defaults to None
+ :type on_change: function, optional
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position: int
+ :param validator: a statement to check if the value of the text
+ corresponds the wanted input restriction, defaults to None
+ :type validator: function or regex, optional
+ :param gap: whether there should be a gap after the text field,
+ defaults to False
+ :type gap: bool
+ :param gap_height: the height of the gap, defaults to 1
+ :type gap_height: int
+ :param disabled: whether the text field should be disabled or
+ not, defaults to False
+ :type disabled: bool
+
+ :return: The text widget that is added
+ :rtype: class `Text`
+ """
+ widget = Label(
+ translate(label),
+ height=1,
+ align="^")
+ self.addWidget(widget, position=position)
+ if gap:
+ self.addDivider(height=gap_height)
+ if disabled:
+ widget.disabled = True
+ return widget
+
+ def addText(self, label, name, on_change=None, position=0,
+ validator=None, gap=False, gap_height=1, disabled=False):
+ """Add a text field with an optional gap.
+
+ :param label: the string in front of the input field
+ :type label: str
+ :param name: the name of the widget, useful for data[name]
+ :type name: str
+ :param on_change: function that is called when the input
+ changes, defaults to None
+ :type on_change: function, optional
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position: int
+ :param validator: a statement to check if the value of the text
+ corresponds the wanted input restriction, defaults to None
+ :type validator: function or regex, optional
+ :param gap: whether there should be a gap after the text field,
+ defaults to False
+ :type gap: bool
+ :param gap_height: the height of the gap, defaults to 1
+ :type gap_height: int
+ :param disabled: whether the text field should be disabled or
+ not, defaults to False
+ :type disabled: bool
+
+ :return: The text widget that is added
+ :rtype: class `Text`
+ """
+ widget = Text(
+ translate(label),
+ name,
+ on_change=on_change,
+ validator=validator)
+ self.addWidget(widget, position=position)
+ if gap:
+ self.addDivider(height=gap_height)
+ if disabled:
+ widget.disabled = True
+ return widget
+
+ def add_textbox(self, label, name, height=5, on_change=None, position=0,
+ gap=False, gap_height=1, readonly=False, disabled=False):
+ """Add a text box with an optional gap.
+
+ :param label: the string in front of the input field
+ :type label: str
+ :param name: the name of the widget, useful for data[name]
+ :type name: str
+ :param on_change: function that is called when the input
+ changes, defaults to None
+ :type on_change: function, optional
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position: int
+ :param validator: a statement to check if the value of the text
+ corresponds the wanted input restriction, defaults to None
+ :type validator: function or regex, optional
+ :param gap: whether there should be a gap after the text field,
+ defaults to False
+ :type gap: bool
+ :param gap_height: the height of the gap, defaults to 1
+ :type gap_height: int
+ :param disabled: whether the text field should be disabled or
+ not, defaults to False
+ :type disabled: bool
+
+ :return: The textbox widget that is added
+ :rtype: class `Text`
+ """
+ if height == "max":
+ height=Widget.FILL_FRAME
+ widget = TextBox(height,
+ translate(label),
+ name,
+ as_string=True,
+ line_wrap=True,
+ on_change=on_change,
+ readonly=readonly
+ )
+ widget.auto_scroll = True
+ self.addWidget(widget, position=position)
+ if gap:
+ self.addDivider(height=gap_height)
+ if disabled:
+ widget.disabled = True
+ return widget
+
+ def addPath(self, label="filepath", name="filepath", position=0):
+ """Add a text field for a filepath and a divider.
+
+ :param label: the string in front of the input field,
+ defaults to filepath
+ :type label: str
+ :param name: the name of the widget, useful for data[name],
+ defaults to filepath
+ :type name: str
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position: int
+
+ :return: The text widget that is added as path input field
+ :rtype: class `Text`
+ """
+ path_widget = Text(translate(label), name)
+ self.addWidget(path_widget, position=position)
+ self.addDivider()
+ return path_widget
+
+ def addButton(self, text, on_click, position=0, gap=False, gap_height=1, name=None):
+ """Add a button.
+
+ :param text: The text for the button
+ :type text: str
+ :param on_click: function that is called when the button is
+ pressed
+ :type on_click: function
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position: int
+
+ :return: The button that is added.
+ :rtype: class `Button`
+ """
+ button = Button(text=translate(text), on_click=on_click, name=name)
+ self.addWidget(button, position=position)
+ if gap:
+ self.addDivider(height=gap_height)
+ return button
+
+ def addDivider(self, draw_line=False, height=1, position=0):
+ """Add a divider.
+
+ :param draw_line: if the divider is invisible or contains a
+ line, defaults to False
+ :type draw_line: bool
+ :param height: the height of the divider in rows,
+ defaults to 0
+ :type height: int
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position: int
+ """
+ if height == "max":
+ height=Widget.FILL_FRAME
+ divider = Divider(draw_line=draw_line, height=height)
+ self.addWidget(divider, position=position)
+
+ def addCopyButton(self, text_field, position=0):
+ """Add a button to copy a widget's content to the clipboard.
+
+ :param text_field: the text field whose content will be copied
+ by the button
+ :type text_field: class `Text`
+ :param position: which column the widger should be assigned to,
+ defaults to 0
+ :type position: int, optional
+ """
+ def copyFieldToClipboard():
+ self.copyToClipboard(text_field)
+ button = Button(translate("copy to clipboard"), copyFieldToClipboard)
+ self.addWidget(button, position)
+
+ def copyToClipboard(self, text):
+ """Copy the content of a text field to the clipboard.
+
+ :param text: the widget whose content should be copied
+ :type text: class `Text`
+ """
+ if text.value:
+ string = str(text.value)
+ pc.copy(string)
+ else:
+ pass
+
+ def addChoose(self, name, options, on_change=None, position=0,
+ gap=False, gap_height=1):
+ """Add radiobuttons to choose between options.
+
+ :param name: the name of the widget, useful for data[name]
+ :type name: str
+ :param options: a list of options to choose from
+ :type options: list
+ :param on_change: function that is called when the input
+ changes, defaults to None
+ :type on_change: function, optional
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position: int
+ :param gap: whether there should be a gap after the text field,
+ defaults to False
+ :type gap: bool
+ :param gap_height: the height of the gap, defaults to 1
+ :type gap_height: int
+
+ :return: The radiobuttons that are added.
+ :rtype: class `RadioButtons`
+ """
+ options = [translate(i) for i in options]
+ options = self.zipOfList(options)
+ radiobuttons = RadioButtons(
+ options,
+ name=name,
+ on_change=on_change
+ )
+ self.addWidget(radiobuttons, position=position)
+ if gap:
+ self.addDivider(height=gap_height)
+ return radiobuttons
+
+ def addResult(self, label="Result", name="result", copyButton=False):
+ """Add a result field with a 'copy to clipboard' button.
+
+ :param label: the string in front of the input field,
+ defaults to Result
+ :type label: str
+ :param name: the name of the widget, useful for data[name],
+ defaults to result
+ :type name: str
+ :param copyButton: if a button to copy the content should be
+ added, defaults to False
+ :type copyButton: bool
+
+ :return: The text widget for the result.
+ :rtype: class `Text`
+ """
+ result = Text(translate(label), name)
+ result.disabled = True
+ self.addWidget(result, 0)
+ if copyButton:
+ self.addCopyButton(result)
+ self.addDivider()
+ return result
+
+ def addDropdownList(self, label, name, options=[], on_change=None,
+ position=0, gap=False, gap_height=1):
+ """Add a dropdownlist.
+
+ :param label: the string in front of the input field
+ :type label: str
+ :param name: the name of the widget, useful for data[name]
+ :type name: str
+ :param options: a list of options to choose from,
+ defaults to []
+ :type options: list
+ :param on_change: function that is called when the input
+ changes, defaults to None
+ :type on_change: function, optional
+ :param position: which column the widget should be assigned to
+ :type position: int
+ :param gap: whether there should be a gap after the
+ dropdownList, defaults to False
+ :type gap: bool
+ :param gap_height: the height of the gap, defaults to 1
+ :type gap_height: int
+
+
+ :return: The DropdownList that is added.
+ :rtype: class `DropdownList`
+ """
+ if options:
+ options = self.zipOfList(options)
+ else:
+ options = [(translate("no entries found"), 0)]
+ ddlist = DropdownList(
+ label=translate(label),
+ name=name,
+ options=options,
+ on_change=on_change
+ )
+ self.addWidget(ddlist, position=position)
+ if gap:
+ self.addDivider(height=gap_height)
+ return ddlist
+
+ def add_date_picker(self, name, label, on_change=None):
+ date_picker = DatePicker(
+ label=label,
+ name=name,
+ on_change=on_change,
+ )
+ self.addWidget(date_picker)
+ return date_picker
+
+ def addListBox(
+ self, name, height, options=[], parser=False,
+ on_change=None, on_select=None, position=0):
+ """Add a listbox.
+
+ :param name: the name of the widget, useful for data[name]
+ :type name: str
+ :param height: the height of the ListBox in rows
+ :type height: int
+ :param options: a list of options to choose from,
+ defaults to []
+ :type options: list
+ :param parser: if a parser should be added to color text,
+ defaults to False
+ :type parser: bool
+ :param on_change: function that is called when selection
+ changes, defaults to None
+ :type on_change: function, optional
+ :param on_select: function called when an entry is selected,
+ defaults to None
+ :type on_select: function, optional
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position: int
+
+ :return: The ListBox that is added.
+ :rtype: class `ListBox`
+ """
+ if height == "max":
+ height=Widget.FILL_FRAME
+ if parser:
+ parser = AsciimaticsParser()
+ else:
+ parser = None
+ listbox = ListBox(
+ height=height,
+ options=options,
+ name=name,
+ parser=parser,
+ add_scroll_bar=True,
+ on_change=on_change,
+ on_select=on_select
+ )
+ self.addWidget(listbox, position=position)
+ return listbox
+
+ def addTable(self, height, titles, options, columns=2, position=0, name="table"):
+ """Add a table.
+
+ :param height: the height of the table in rows
+ :type height: int
+ :param titles: the title for each column
+ :type titles: list
+ :param options: a list of list of options to choose from
+ :type options: list
+ :param columns: number or structure of columns of the table,
+ defaults to 2
+ :type columns: int, list
+ :param name: the name of the widget, useful for data[name],
+ defaults to table
+ :type name: str
+
+ :return: The table/ MultiColumnListBox that is added.
+ :rtype: class `MultiColumnListBox`
+ """
+ if height == "max":
+ height=Widget.FILL_FRAME
+
+ columnsList = []
+ if isinstance(columns, list):
+ for i in columns:
+ i = str(i)
+ column = "<" + i + "%"
+ columnsList.append(column)
+ else:
+ for i in range(columns):
+ width = str(100 // columns)
+ column = "<" + width + "%"
+ columnsList.append(column)
+
+ titles = [translate(i) for i in titles]
+ # The options structure is [[1.1, 1.2], [2.1, 2.2]].
+ options = self.zipOfList(options)
+ table = MultiColumnListBox(
+ height=height,
+ titles=titles,
+ columns=columnsList,
+ options=options,
+ add_scroll_bar=True,
+ name=name
+ )
+ self.addWidget(table, position=position)
+ return table
+
+ def addStatusBar(self, span=1, **kwargs):
+ """Add a status bar.
+
+ :return: The status bar that is added.
+ :rtype: class `Text`
+ """
+ statusBar = Text(
+ label=translate("Status bar: "),
+ name="Statusbar"
+ )
+ self.disable(statusBar)
+ self.addWidget(statusBar, position=0, span=span, **kwargs)
+ return statusBar
+
+ def addTickBox(self, label, name, on_change=None, position=0):
+ """Add a tickbox.
+
+ :param label: the text of the tickbox (to describe its effect)
+ :type label: str
+ :param name: the name of the widget, useful for data[name]
+ :type name: str
+ :param on_change: function called when the state is changed,
+ defaults to None
+ :type on_change: function, optional
+ :param position: which column the widget should be assigned to,
+ defaults to 0
+ :type position: int
+
+ :return: the added tickbox
+ :rtype: class `CheckBox`
+ """
+ tickbox = CheckBox(
+ text=translate(label),
+ name=name,
+ on_change=on_change
+ )
+ self.addWidget(tickbox, position=position)
+ return tickbox
+
+ def disable(self, widget):
+ """Disable a widget.
+
+ :param widget: the widget that should be disabled
+ :type widget: class `Widget`
+ """
+ widget.disabled = True
+
+ def enable(self, widget):
+ """Enable a widget.
+
+ :param widget: the widget that should be enabled
+ :type widget: class `Widget`
+ """
+ widget.disabled = False
+
+ def zipOfList(self, options):
+ """Create a zip object with the list and a counter.
+
+ This structure is often used in asciimatics elements where you
+ can choose an element from a list.
+ Structure: [(a,1), (b,2), ...]
+
+ :param options: list of options to choose from
+ :type options: list
+
+ :return: List of tuples of options and increasing numbers.
+ :rtype: list
+ """
+ return list(zip(options, range(len(options))))
+
+ def update(self, frame):
+ self.widgets = frame._layouts
+
+ def build(self):
+ """Pass the widgets to the Frame.
+
+ :return: All the widgets that were added
+ :rtype: list
+ """
+ return self.widgets
\ No newline at end of file
diff --git a/c5dec/frontend/tui/foundation/menu.py b/c5dec/frontend/tui/foundation/menu.py
new file mode 100644
index 0000000..ecb3dec
--- /dev/null
+++ b/c5dec/frontend/tui/foundation/menu.py
@@ -0,0 +1,469 @@
+from asciimatics.widgets import Layout, Button, Divider, Frame
+from asciimatics.screen import Screen
+from asciimatics.exceptions import NextScene, StopApplication
+from c5dec.frontend.tui.foundation.builder import Builder
+import c5dec.settings as c5settings
+import c5dec.frontend.tui.application as app_mod
+from c5dec import common
+import json
+from i18n import t as translate
+from abc import ABC, abstractmethod
+
+
+class Menu:
+ """The model of the menu.
+
+ As everything should be in a MVC model, this class is the 'model'
+ of the menus.
+ """
+
+ def __init__(self, name):
+ """Set up the key attributes of a menu.
+
+ It has a name, functions, submenus and if applicable a
+ root menu.
+
+ :param name: name of the menu
+ :type name: str
+ """
+ self.name = translate(name)
+ self.functions = {}
+ self.submenus = {}
+ self.root_menu = None
+
+ def add_function(self, name, classtype, data_model=None):
+ """Add a function to the menu.
+
+ :param name: the name of the function
+ :type name: str
+ :param classtype: the function type (App type)
+ :type classtype: class
+ """
+ name = translate(name)
+ self.functions.update({name: classtype})
+
+ app: app_mod.Application = self.get_ref_to_app()
+ app.set_data_model(name, data_model)
+
+ def add_menu(self, name):
+ """Add a submenu to the menu.
+
+ :param name: name of the menu that is added
+ :type name: str
+ """
+ name = translate(name)
+ self.submenus.update({name : Menu(name)})
+ self.get_submenu(name).root_menu = self
+
+ def get_ref_to_app(self):
+ root_menu_type = type(self.root_menu)
+ if root_menu_type is app_mod.Application:
+ return self.root_menu
+
+ parent = None
+ while root_menu_type is not app_mod.Application:
+ parent = self.root_menu.root_menu
+ root_menu_type = type(parent)
+
+ return parent
+
+ def get_submenu(self, name):
+ """Return a submenu by taking its name.
+
+ :param name: the name of the requested menu
+ :type name: str
+
+ :return: The requested menu
+ :rtype: class `Menu`
+ """
+ name = translate(name)
+ return self.submenus[name]
+
+ def get_nested_submenu(self, list):
+ """Return a nested submenu with a list of names to the menu.
+
+ :param list: list of the root menus' names of the requested menu
+ :type list: list
+
+ :return: The requested menu
+ :rtype: class `Menu`
+ """
+ menu = self
+ for i in list:
+ menu = menu.get_submenu(i)
+ return menu
+
+ def get_path(self):
+ """Get the path to get to the current menu.
+
+ :return: The list of menus to get to the current menu
+ :rtype: list
+ """
+ root = self.root_menu
+ if not root:
+ return []
+ else:
+ path = [root]
+ while root.root_menu:
+ root = root.root_menu
+ path.append(root)
+ path.reverse()
+ path_with_names = [i.name for i in path]
+ return path_with_names
+
+ def get_all_submenus(self):
+ """Get all submenus (also nested) of a menu as objects.
+
+ :return: List of all submenus (and its submenus) in a menu
+ :rtype: list
+ """
+ all_submenus = list(self.submenus.values())
+ index = 0
+ while index < len(all_submenus):
+ cur_menu = all_submenus[index]
+ cur_submenus = list(cur_menu.submenus.values())
+ all_submenus.extend(cur_submenus)
+ index += 1
+ return all_submenus
+
+ def get_submenus(self):
+ """Get a list of submenus of a menu.
+
+ :return: List of submenu names
+ :rtype: list
+ """
+ return list(self.submenus.keys())
+
+ def get_functions(self):
+ """Get a list of functions of a menu.
+
+ :return: List of functions of the menu
+ :rtype: list
+ """
+ return list(self.functions.keys())
+
+class BaseView(Frame):
+ """The template for all scenes created in this program.
+
+ The 'Template' class is an asciimatics Frame on which all other
+ scenes can be built on using additionally the 'Builder'.
+ """
+ def __init__(self, screen, root_menu, builder=None):
+ """Set up the basic elements of a scene.
+
+ These elements are the size of the screen and the footer. This
+ footer contains the 'back' and the 'quit' button. In addition,
+ add the builder to enable to build on this basic template.
+
+ :param screen: the screen on which the Frame should be shown
+ :type screen: class `Screen`
+ :param root_menu: the root menu of the assigned menu
+ :type root_menu: class `Menu`
+ :param builder: the builder who adds the content of the frame,
+ defaults to None
+ :type builder: class `Builder`, optional
+ """
+ self.root_menu = root_menu
+ self.menu_title = "Default title"
+ self.builder = builder
+
+ # Configure the title.
+ if builder:
+ title = builder.title
+ else:
+ title = "Template"
+
+ width = common.get_value_from_json("width", 90)
+ height = common.get_value_from_json("height", 90)
+
+ # Initialize the screen.
+ super(BaseView, self).__init__(
+ screen,
+ screen.height*height // 100,
+ screen.width*width // 100,
+ hover_focus=True,
+ can_scroll=True,
+ title=translate(title),
+ has_border=True
+ )
+
+ self.assemble()
+
+ self.fix()
+
+ def back(self):
+ """Get back to the previous menu."""
+ scene = self.root_menu.name
+ raise NextScene(scene)
+
+ @staticmethod
+ def quit():
+ """Quit the application."""
+ raise StopApplication("User pressed quit")
+
+ def assemble(self):
+ # Insert the builder and its configuration.
+ builder = self.builder
+ if builder:
+ widgets = builder.build()
+ for element in widgets:
+ if isinstance(element, Layout):
+ layout = element
+ self.add_layout(layout)
+ else:
+ widget = element[0]
+ position = element[1]
+ layout.add_widget(widget, position)
+ else:
+ layout = Layout([100], fill_frame=True)
+ self.add_layout(layout)
+
+ # Add the footer, containing the 'back' and 'quit' button.
+ layout = Layout([100])
+ self.add_layout(layout)
+ layout.add_widget(Divider())
+ layout = Layout([1, 1, 1, 1])
+ self.add_layout(layout)
+ back_button = Button(translate("Back"), self.back)
+ layout.add_widget(back_button, 0)
+ if not self.root_menu:
+ back_button.disabled = True
+ layout.add_widget(Button(translate("Quit"), self.quit), 3)
+
+ def get_value_from_json(self, key, default_value):
+ """Returns the corresponding value to a key in the config.json
+ file.
+
+ :param key: the setting whose value is searched
+ :type key: str
+ :param default_value: the value that will be used if the file
+ cannot be loaded
+ :type default_value: str or int
+
+ :return: the value that belongs to the entered key
+ :rtype: str or int
+ """
+ try:
+ with open(c5settings.STARTUP_CONFIG_JSON_PATH) as f:
+ dictionary = json.load(f)
+ value = dictionary[key]
+ except:
+ value = default_value
+
+ return value
+
+ def clear_text_fields(self, field_list):
+ for fl in field_list:
+ fl.value = ""
+
+ def setController(self, controller):
+ """Assign a controller to the view.
+
+ :param controller: the controller that is assigned to the view
+ :type controller: class `Controller`
+ """
+ self.controller = controller
+
+ def set_data_model(self, model):
+ self.data_model = model
+
+ def get_data_model(self):
+ return self.data_model
+
+ def get_menu_title(self):
+ return self.menu_title
+
+ def set_menu_title(self, title):
+ self.menu_title = title
+
+class PopUpMenu(Frame, ABC):
+ """The template for all PopUp Menus created in this program.
+
+ The 'PopUpMenu Template' class is a modal asciimatics Frame that
+ creates an overlay over the invoking Frame.
+ """
+ # Default Frame pattern
+ _default_popup = {
+ "background": (Screen.COLOUR_WHITE, Screen.A_NORMAL, Screen.COLOUR_CYAN),
+ "shadow": (Screen.COLOUR_BLACK, Screen.A_BOLD, Screen.COLOUR_BLACK),
+ "disabled": (Screen.COLOUR_BLACK, Screen.A_BOLD, Screen.COLOUR_CYAN),
+ "invalid": (Screen.COLOUR_YELLOW, Screen.A_BOLD, Screen.COLOUR_RED),
+ "label": (Screen.COLOUR_GREEN, Screen.A_BOLD, Screen.COLOUR_CYAN),
+ "borders": (Screen.COLOUR_BLACK, Screen.A_NORMAL, Screen.COLOUR_CYAN),
+ "scroll": (Screen.COLOUR_CYAN, Screen.A_NORMAL, Screen.COLOUR_BLUE),
+ "title": (Screen.COLOUR_WHITE, Screen.A_BOLD, Screen.COLOUR_CYAN),
+ "edit_text": (Screen.COLOUR_WHITE, Screen.A_NORMAL, Screen.COLOUR_CYAN),
+ "focus_edit_text": (Screen.COLOUR_BLACK, Screen.A_BOLD, Screen.COLOUR_WHITE),
+ "readonly": (Screen.COLOUR_BLACK, Screen.A_BOLD, Screen.COLOUR_BLUE),
+ "focus_readonly": (Screen.COLOUR_BLACK, Screen.A_BOLD, Screen.COLOUR_CYAN),
+ "button": (Screen.COLOUR_WHITE, Screen.A_BOLD, Screen.COLOUR_CYAN),
+ "focus_button": (Screen.COLOUR_WHITE, Screen.A_BOLD, Screen.COLOUR_WHITE),
+ "control": (Screen.COLOUR_YELLOW, Screen.A_NORMAL, Screen.COLOUR_CYAN),
+ "selected_control": (Screen.COLOUR_YELLOW, Screen.A_BOLD, Screen.COLOUR_CYAN),
+ "focus_control": (Screen.COLOUR_YELLOW, Screen.A_NORMAL, Screen.COLOUR_WHITE),
+ "selected_focus_control": (Screen.COLOUR_YELLOW, Screen.A_BOLD, Screen.COLOUR_WHITE),
+ "field": (Screen.COLOUR_WHITE, Screen.A_NORMAL, Screen.COLOUR_CYAN),
+ "selected_field": (Screen.COLOUR_CYAN, Screen.A_BOLD, Screen.COLOUR_WHITE),
+ "focus_field": (Screen.COLOUR_CYAN, Screen.A_NORMAL, Screen.COLOUR_WHITE),
+ "selected_focus_field": (Screen.COLOUR_WHITE, Screen.A_BOLD, Screen.COLOUR_WHITE),
+ }
+
+ def __init__(self, screen, builder=None, on_close_callback=None, footer=None, palette=None):
+ """Set up the PopUp Menu.
+
+ :para, screen: the screen on which the Frame should be shown
+ :type screen: class 'Screen'
+ :param builder: the builder who adds the content of the frame,
+ defaults to None
+ :type builder: class 'Builder', optional
+ :param on_close_callback: the function to catch the return of
+ PopUpMenu
+ :type on_close_callback: class 'function'
+ :param footer: footer labels, defaults to 'Submit' and 'Cancel'
+ only 'Submit' can be 'changed'.
+ :type footer: string
+ """
+ self._screen = screen
+ self.builder = builder
+ self._on_close_callback=on_close_callback
+ self._footer = footer
+ # Configure the title.
+ if builder:
+ title = builder.title
+ else:
+ title = "PopUpTemplate"
+
+ super(PopUpMenu, self).__init__(screen,
+ screen.height // 2,
+ screen.width // 2,
+ has_border=True,
+ can_scroll=False,
+ is_modal=False,
+ hover_focus=True,
+ title=translate(title))
+
+ if not palette:
+ self.palette = self._default_popup
+
+ self.assemble()
+ self.fix()
+
+ def _close(self):
+ """Close the Popup Menu"""
+ self._scene.remove_effect(self)
+
+ @abstractmethod
+ def _submit(self):
+ pass
+
+ def assemble(self):
+ # Insert the builder and its configuration.
+ builder = self.builder
+ if builder:
+ widgets = builder.build()
+ for element in widgets:
+ if isinstance(element, Layout):
+ layout = element
+ self.add_layout(layout)
+ else:
+ widget = element[0]
+ position = element[1]
+ layout.add_widget(widget, position)
+ else:
+ layout = Layout([100], fill_frame=True)
+ self.add_layout(layout)
+
+ # Add the footer, containing the 'back' and 'quit' button.
+ layout = Layout([100])
+ self.add_layout(layout)
+ layout.add_widget(Divider())
+ layout = Layout([1, 1, 1, 1])
+ self.add_layout(layout)
+ if self._footer:
+ proceed = self._footer
+ else:
+ proceed = "Submit"
+ layout.add_widget(Button(translate(proceed), self._submit), 0)
+ layout.add_widget(Button(translate("Close"), self._close), 3)
+
+class MenuView(BaseView):
+ """The 'view' of the menu.
+
+ As everything should be in a MVC model, this class is the 'view'
+ for the presentation of the menus.
+ """
+ def __init__(self, screen, menu):
+ """Set up the view for the menus.
+
+ The menus are displayed by showing their submenus and their
+ functions in two ListBoxes side by side. It is build on the
+ universal template with the builder.
+
+ :param screen: the screen the Frame should be displayed on
+ :type screen: class: `Screen`
+ :param menu: the menu the frame is assigned to
+ :type menu: class: `Menu`
+ """
+ self.model = menu
+
+ builder = Builder(menu.name)
+ builder.addLayout([1,1], True)
+
+ # Add the left ListBox with the submenus.
+ self.listbox_submenus = builder.addListBox(
+ "submenus", "max", on_select=self.launch_submenu, position=0
+ )
+
+ # Add the right ListBox with the functions.
+ self.listbox_functions = builder.addListBox(
+ "functions", "max", on_select=self.launch_function, position=1
+ )
+
+ # Build on the template.
+ super(MenuView, self).__init__(screen, menu.root_menu, builder)
+
+ self.builder = builder
+ self.set_options()
+
+ def set_options(self):
+ """Get and insert the options of the ListBoxes."""
+ self.submenus = self.model.get_submenus()
+ self.insert(self.listbox_submenus, self.submenus)
+
+ self.functions = self.model.get_functions()
+ self.insert(self.listbox_functions, self.functions)
+
+ def insert(self, widget, options):
+ """Insert the options into the widget or disable the widget.
+
+ :param widget: the widget whose options will be changed
+ :type widget: class `Widget`
+ :param options: the options that will set to the widget
+ :type options: list
+ """
+ if options:
+ widget.options = self.builder.zipOfList(options)
+ else:
+ widget.disabled = True
+
+ def launch_scene(self, widget_name, scene_list):
+ """Launch the selected scene in a list of scenes.
+
+ :param widget_name: the widget whose selected item
+ should be received
+ :type widget_name: str
+ :param scene_list: the list of scenes you can choose
+ :type scene_list: list
+ """
+ self.save()
+ index = int(self.data[widget_name])
+ next_scene = scene_list[index]
+ raise NextScene(next_scene)
+
+ def launch_function(self):
+ """Launch the selected function."""
+ self.launch_scene("functions", self.functions)
+
+ def launch_submenu(self):
+ """Launch the selected submenu."""
+ self.launch_scene("submenus", self.submenus)
\ No newline at end of file
diff --git a/c5dec/frontend/tui/main.py b/c5dec/frontend/tui/main.py
new file mode 100644
index 0000000..31210f4
--- /dev/null
+++ b/c5dec/frontend/tui/main.py
@@ -0,0 +1,163 @@
+from c5dec.frontend.tui.application import Application
+from c5dec.frontend.tui.miniapps.ssdlcapp import (
+ RepositoryManagementModel,
+ RepositoryManagementView,
+ ItemManagementModel,
+ ItemManagementView,
+ ItemRelationModel,
+ ItemRelationManagementView,
+ ArtifactStatusManagementModel,
+ ArtifactStatusManagementView
+)
+from c5dec.frontend.tui.miniapps.transformerapp import (
+ ImportModel,
+ ImportView,
+ ExportModel,
+ ExportView,
+ PublisherModel,
+ PublisherView,
+ ConverterModel,
+ ConverterView
+)
+from c5dec.frontend.tui.miniapps.ismsapp import (
+ ActivityReportModel,
+ ActivityReportView,
+ DocListAssistantModel,
+ DocListAssistantView,
+ MSWordTagProcessingModel,
+ MSWordTagProcessingView,
+)
+from c5dec.frontend.tui.miniapps.pmapp import (
+ TimeReportModel,
+ OpenProjectTimeReportAssistantView,
+ TimeReportAssistantView
+)
+from c5dec.frontend.tui.miniapps.cctapp import (
+ CCBrowserModel,
+ CCBrowserView,
+ CreateChecklistModel,
+ CreateChecklistView,
+ WorkUnitModel,
+ WorkUnitView
+)
+from c5dec.frontend.tui.miniapps.miniappbase import (
+ MiniAppPlaceholderModel,
+ MiniAppPlaceholderView
+)
+import c5dec.common as common
+
+
+def add_function_to_tui(app, app_name, function_name, view, model):
+ app.get_submenu(app_name).add_function(
+ function_name, view, model)
+
+@common.feature_flag('ON')
+def add_ssdlc_module(app, name):
+ SSDLC_app_name = name
+ app.add_menu(SSDLC_app_name)
+ app.get_submenu(SSDLC_app_name).add_function(
+ "Manage artifact repositories", RepositoryManagementView, RepositoryManagementModel())
+ app.get_submenu(SSDLC_app_name).add_function(
+ "Manage artifact items", ItemManagementView, ItemManagementModel())
+ app.get_submenu(SSDLC_app_name).add_function(
+ "Manage item relations", ItemRelationManagementView, ItemRelationModel())
+ app.get_submenu(SSDLC_app_name).add_function(
+ "Manage repository structure and item status", ArtifactStatusManagementView, ArtifactStatusManagementModel())
+
+@common.feature_flag('ON')
+def add_cryptography_module(app, name):
+ cryptography_app_name = name
+ app.add_menu(cryptography_app_name)
+ app.get_submenu(cryptography_app_name).add_function(
+ "PQC public-key encryption (not implemented, on the roadmap)", MiniAppPlaceholderView, MiniAppPlaceholderModel)
+ app.get_submenu(cryptography_app_name).add_function(
+ "PQC digital signature (not implemented, on the roadmap)", MiniAppPlaceholderView, MiniAppPlaceholderModel)
+
+@common.feature_flag('ON')
+def add_cct_module(app, name):
+ CCT_app_name = name
+ app.add_menu(CCT_app_name)
+ app.get_submenu(CCT_app_name).add_function(
+ "Browse Common Criteria", CCBrowserView, CCBrowserModel())
+ app.get_submenu(CCT_app_name).add_function(
+ "Create Evaluation Checklist", CreateChecklistView, CreateChecklistModel())
+ app.get_submenu(CCT_app_name).add_function(
+ "Evaluation Checklist", WorkUnitView, WorkUnitModel())
+
+@common.feature_flag('ON')
+def add_cpssa_module(app, name):
+ cpssa_app_name = name
+ app.add_menu(cpssa_app_name)
+ app.get_submenu(cpssa_app_name).add_function(
+ "Generate input for threagile (not implemented, on the roadmap)", MiniAppPlaceholderView, MiniAppPlaceholderModel)
+ app.get_submenu(cpssa_app_name).add_function(
+ "Generate input for TRICK Service (not implemented, on the roadmap)", MiniAppPlaceholderView, MiniAppPlaceholderModel)
+
+@common.feature_flag('ON')
+def add_transformer_module(app, name):
+ transformer_app_name = name
+ app.add_menu(transformer_app_name)
+ app.get_submenu(transformer_app_name).add_function("Import SSDLC data", ImportView, ImportModel())
+ app.get_submenu(transformer_app_name).add_function("Export SSDLC data", ExportView, ExportModel())
+ app.get_submenu(transformer_app_name).add_function("Publish SSDLC data", PublisherView, PublisherModel())
+ app.get_submenu(transformer_app_name).add_function("Convert data", ConverterView, ConverterModel())
+
+@common.feature_flag('ON')
+def add_isms_module(app, name):
+ ISMS_app_name = name
+ app.add_menu(ISMS_app_name)
+ app.get_submenu(ISMS_app_name).add_function(
+ "Activity Report", ActivityReportView, ActivityReportModel())
+ app.get_submenu(ISMS_app_name).add_function(
+ "Document list validation", DocListAssistantView, DocListAssistantModel())
+ app.get_submenu(ISMS_app_name).add_function(
+ "Convert Word tags to hyperlinks", MSWordTagProcessingView, MSWordTagProcessingModel())
+
+@common.feature_flag('ON')
+def add_pm_module(app, name):
+ pm_app_name = name
+ app.add_menu(pm_app_name)
+
+ @common.feature_flag('ON')
+ def add_openproject_assistant_submenu():
+ add_function_to_tui(app, pm_app_name, "OpenProject time report assistant", OpenProjectTimeReportAssistantView, TimeReportModel())
+
+ @common.feature_flag('ON')
+ def add_universal_time_sheet_assistant_submenu():
+ add_function_to_tui(app, pm_app_name, "Universal time report assistant", TimeReportAssistantView, TimeReportModel())
+
+ add_openproject_assistant_submenu()
+ add_universal_time_sheet_assistant_submenu()
+
+@common.feature_flag('OFF')
+def add_settings_module(app, name):
+ settings_app_name = name
+ app.add_menu(settings_app_name)
+ app.get_submenu(settings_app_name).add_function(
+ "Add SFR", RepositoryManagementView, RepositoryManagementModel())
+
+def main(args=None, cwd=None):
+ app = Application()
+
+ CCT_app_name = "1 - CCT: Common Criteria toolbox"
+ SSDLC_app_name = "2 - SSDLC: secure software development life cycle"
+ cryptography_app_name = "3 - Cryptography (see user manual)"
+ cpssa_app_name = "4 - CPSSA: Cyber-physical system security assessment (see user manual)"
+ transformer_app_name = "5 - Transformer: import, export, publish"
+ ISMS_app_name = "6 - ISMS: document management"
+ pm_app_name = "7 - PM: project resource management"
+ settings_app_name = "8 - Settings"
+
+ add_cct_module(app, CCT_app_name)
+ add_ssdlc_module(app, SSDLC_app_name)
+ add_cryptography_module(app, cryptography_app_name)
+ add_cpssa_module(app, cpssa_app_name)
+ add_transformer_module(app, transformer_app_name)
+ add_isms_module(app, ISMS_app_name)
+ add_pm_module(app, pm_app_name)
+ add_settings_module(app, settings_app_name)
+
+ app.run()
+
+if __name__ == "__main__":
+ main()
\ No newline at end of file
diff --git a/c5dec/frontend/tui/miniapps/cctapp.py b/c5dec/frontend/tui/miniapps/cctapp.py
new file mode 100644
index 0000000..02f38e5
--- /dev/null
+++ b/c5dec/frontend/tui/miniapps/cctapp.py
@@ -0,0 +1,1319 @@
+from c5dec.frontend.tui.foundation.menu import Menu, BaseView, PopUpMenu
+from c5dec.frontend.tui.foundation.builder import Builder
+from c5dec.frontend.tui.application import Application
+from asciimatics.widgets import PopUpDialog
+from asciimatics.exceptions import NextScene
+from datetime import datetime
+import c5dec.settings as c5settings
+import c5dec.common as common
+import c5dec.core.cct as cct
+import doorstop
+import os
+import logging
+
+MUTABLE_ATTRIBUTES = ["options", "value", "disabled"]
+
+log = logging.getLogger(__name__)
+log.setLevel(logging.ERROR)
+
+logHandler = logging.FileHandler("cctapp.log", mode='w')
+formatter = logging.Formatter("%(levelname)s - %(funcName)s() : %(message)s")
+logHandler.setFormatter(formatter)
+log.addHandler(logHandler)
+
+
+def auto_cache(func):
+ def wrapper(instance, *args, **kwargs):
+ widgets = func(instance, *args, **kwargs)
+
+ if not widgets:
+ return
+
+ elif not isinstance(widgets, list):
+ widgets = [widgets]
+
+ for widget in widgets:
+ name = widget.name
+ instance.CACHE[name] = widget
+
+ return widget
+ return wrapper
+
+def auto_reload(func):
+ def wrapper(instance, *args, **kwargs):
+
+ result = func(instance, *args, **kwargs)
+
+ cache = instance.CACHE
+ if not cache:
+ return
+
+ for name in list(cache.keys()):
+ widget = instance.find_widget(name)
+ for attrib in MUTABLE_ATTRIBUTES:
+ try:
+ attrib_to_set = getattr(cache[name], attrib)
+ setattr(widget, attrib, attrib_to_set)
+ except AttributeError:
+ pass
+ return result
+ return wrapper
+
+
+class ArtifactModel:
+ """Parent class for all artifact related models.
+ """
+ _index = {}
+ def __init__(self):
+ """Set up the key attributes for CC toolbox.
+
+ """
+ self.project_root = c5settings.PROJECT_ROOT
+ self.cc_version = "3R5"
+ if not ArtifactModel._index:
+ cct.load_cc_xml(version=self.cc_version)
+ ArtifactModel._index = cct.Index
+
+ def find(self, value):
+ return self._index.get(value)
+
+ def yield_obj(self, obj_type):
+ return self._index.yield_obj(obj_type)
+
+
+class CCBrowserModel(ArtifactModel):
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ super(CCBrowserModel, self).__init__()
+
+ self.selection = []
+
+class CCBrowserView(BaseView):
+
+ CACHE = {}
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view.
+
+ The REM module provides automation and
+ abstractions over doorstop.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self._screen = screen
+ self.data_model = model
+
+ app: Application = root_menu.get_ref_to_app()
+
+ max_height = screen.height
+ frame_height = max_height - 12
+ max_width = screen.width
+
+ builder = Builder("Common Criteria Browser")
+ builder.addLayout([13, 7, 10, 10, 10, 50], True)
+
+ builder.add_label("Security Domains", position=0, disabled=True)
+ builder.addDivider(draw_line=True, position=0)
+ self.domain_list = builder.addListBox("Domain", height=(frame_height-3)//2,
+ position=0, on_select=self.load_classes)
+ self.domain_list.options = [("Functional Components", 0),
+ ("Assurance Components", 1)]
+
+ builder.addDivider(draw_line=True, position=0)
+ builder.add_label("Search Bar", position=0, disabled=True)
+ self.search = builder.add_textbox("", "searchbox", height=1, position=0,
+ on_change=self.update_suggestion_list)
+ self.search_button = builder.addButton("Search", position=0, on_click=self.search_item)
+ self.suggestion_list = builder.addListBox("SuggestionBox", height=(frame_height-5)//2, position=0,
+ on_select=self.set_search_value)
+
+ builder.add_label("Classes", position=1, disabled=True)
+ builder.addDivider(draw_line=True, position=1)
+ self.class_list = builder.addListBox("Class", height=frame_height-2,
+ position=1, on_select=lambda: self.display_selection_data("Class"))
+
+ builder.add_label("Families", position=2, disabled=True)
+ builder.addDivider(draw_line=True, position=2)
+ self.family_list = builder.addListBox("Family", height=frame_height-2,
+ position=2, on_select=lambda: self.display_selection_data("Family"))
+
+ builder.add_label("Components", position=3, disabled=True)
+ builder.addDivider(draw_line=True, position=3)
+ self.component_list = builder.addListBox("Component", height=frame_height-2,
+ position=3, on_select=lambda: self.display_selection_data("Component"))
+
+ builder.add_label("Elements", position=4, disabled=True)
+ builder.addDivider(draw_line=True, position=4)
+ self.element_list = builder.addListBox("Element", height=frame_height-2,
+ position=4, on_select=lambda: self.display_selection_data("Element"))
+
+ builder.add_label("Item Preview", position=5, disabled=True)
+ builder.addDivider(True, position=5)
+ self.preview = builder.add_textbox("", "previewbox", height="max", position=5, readonly=True)
+
+ builder.addLayout([50,50])
+ builder.addDivider(True)
+ self.statusbar = builder.addStatusBar()
+ builder.addDivider(True, position=1)
+ self.export = builder.addButton("Open Export Menu", on_click=self.open_popup, position=1)
+
+ super(CCBrowserView, self).__init__(screen, root_menu, builder)
+ self._reload()
+ self.builder = builder
+ self.data_model: CCBrowserView = self.data_model
+
+ @auto_reload
+ def _reload(self):
+ pass
+
+ def update_suggestion_list(self):
+ height = self.suggestion_list._h
+ query = self.search.value.lower()
+ if not query:
+ self.suggestion_list.options = []
+ return
+ partial_matches = []
+ for potential_match in list(self.data_model._index.keys()):
+ if query in potential_match:
+ partial_matches.append(potential_match)
+
+ sorted_matches = sorted(partial_matches, key=len)
+ suggestions = [(match, idx) for idx, match in enumerate(sorted_matches)]
+ self.suggestion_list.options = suggestions[:height]
+
+
+ def set_selection_path(self, selection_path:list, initial_key):
+ listbox_dict = {"Class":self.class_list,
+ "Family":self.family_list,
+ "Component":self.component_list,
+ "Element":self.element_list}
+
+ current_key = initial_key
+ while selection_path:
+ selection = selection_path.pop(0)
+ for option, idx in listbox_dict[current_key].options:
+ if selection._id == option.lower():
+ listbox_dict[current_key].value = idx
+ self.display_selection_data(current_key)
+ current_key = self.get_next_key(current_key, listbox_dict)
+
+ def process_match(self, match):
+ # get ancestors and delete root object CCDocument
+ ancestors = match.get_ancestors()[:-1]
+
+ # determine if match is already Class
+ if ancestors:
+ matched_class = ancestors[-1]
+ else:
+ matched_class = match
+ # determine if match is of domain functional or assurance based on class match
+ if isinstance(matched_class, cct.FClass):
+ self.domain_list.value = 0 # corresponds to functional
+ else:
+ self.domain_list.value = 1 # corresponds to assurance
+ # load respective classes
+ self.load_classes()
+
+ # reverse ancestor list to match sequence of listbox (Class, Family, Component, Element)
+ selection_path = list(reversed(ancestors))
+ selection_path.append(match)
+ self.set_selection_path(selection_path, "Class")
+
+ def search_item(self):
+ INVALID_MATCH_TYPES = [cct.Package, cct.CCDocument, cct.WorkUnit, cct.Operation]
+
+ query = self.search.value
+ try:
+ match = self.data_model.find(query)
+ except KeyError:
+ match = None
+
+ if not match or type(match) in INVALID_MATCH_TYPES:
+ self.update_status(f"No matches found for {query}!")
+ return
+
+ self.process_match(match)
+ self.update_status(f"Selection path for {query} opened.")
+
+ def set_search_value(self):
+ query, _ = self.suggestion_list.options[self.suggestion_list.value]
+ self.search.value = query
+ self.search_item()
+
+ def save_selection(self, blacklist=None):
+ blacklist = blacklist or list()
+ selection = []
+ for widget in self.builder.widgets:
+ try:
+ if isinstance(widget, tuple):
+ widget = widget[0]
+ if widget.name != "Domain" and widget.name not in blacklist:
+ is_selectable = widget.options
+ selection.append(widget)
+ except AttributeError:
+ pass
+ self.data_model.selection = selection
+
+ def update_status(self, value):
+ self.statusbar.value = value
+
+ def open_popup(self):
+ # This will display the CustomPopUp and ask the user for input
+ self.save_selection(blacklist=["SuggestionBox"])
+ success = self._scene.add_effect(BrowserExportMenu(self._screen, self.data_model,
+ on_close_callback= self.update_status))
+ if success:
+ self.update_status("Selection successfully exported.")
+
+ def get_next_key(self, current_key, dictionary):
+ keys = iter(dictionary)
+ for key in keys:
+ if key == current_key:
+ return next(keys, None)
+ return None
+
+ @auto_cache
+ def load_classes(self):
+ domain = self.domain_list.value
+ if domain == 0:
+ get_object = cct.FClass
+ if domain == 1:
+ get_object = cct.AClass
+ classes = self.data_model.yield_obj(get_object)
+ class_ids = [CCclass._id.upper() for CCclass in classes]
+ self.class_list.options = self.get_display_options(class_ids)
+ self._clear_children_tabs("Class")
+ #return self.class_list
+
+ def get_children_ids(self, item_obj):
+ children_ids = [child._id.upper() for child in item_obj.children]
+ return children_ids
+
+ def get_display_options(self, options):
+ return [(option, i) for i, option in enumerate(options)]
+
+ @auto_cache
+ def display_selection_data(self, name):
+ listbox_dict = {"Class":self.class_list,
+ "Family":self.family_list,
+ "Component":self.component_list,
+ "Element":self.element_list}
+
+ index = self.data_model
+ listbox = listbox_dict[name]
+ next_list = self.get_next_key(name, listbox_dict)
+
+ idx = listbox.value
+ if idx == None:
+ self.statusbar.value = "Empty selection."
+ return
+ item, _ = listbox.options[idx]
+ item_obj = index.find(item)
+ self.preview.value = item_obj.get_formatted_text()
+
+ if next_list:
+ children = self.get_children_ids(item_obj)
+ children_options = self.get_display_options(children)
+ listbox_dict[next_list].options = children_options
+ log.debug(f"Set options for {next_list}: {children_options}")
+ self._clear_children_tabs(next_list)
+
+ #return listbox_dict[next_list]
+
+ # @auto_cache
+ def _clear_children_tabs(self,level):
+ '''Clears the areas of the CC browser screen
+ that are to the right of the given level
+ :param level: one of {Class, Familiy, Component, Element}
+ :type level: string
+ '''
+ d_tabs = {"Class":self.class_list,
+ "Family":self.family_list,
+ "Component":self.component_list,
+ "Element":self.element_list}
+
+ while level:=self.get_next_key(level, d_tabs):
+ log.debug(f"Cleaning options for {level}")
+ d_tabs[level]._options = []
+
+
+
+class BrowserExportMenu(PopUpMenu):
+ SUPPORTED_EXPORT_FORMATS = (".md")
+ def __init__(self, screen, data, on_close_callback=None):
+
+ self._screen = screen
+ self.export_data = data
+ self._on_close_callback = on_close_callback
+ self.empty_selection = False
+
+ max_height = screen.height//2
+ frame_height = max_height - 5
+ max_width = screen.width//2
+
+ builder = Builder("Export Menu")
+ builder.addLayout([40, 70])
+
+ selection_options = []
+ selection_preview = ""
+ for selectable in data.selection:
+ selection_options.append(selectable.name)
+ log.debug(f"Categories: {selectable.name} - {selectable.value}")
+ if selectable.value != None:
+ header_level = len(selection_options)
+ selection, _ = selectable.options[selectable.value]
+ obj_text = data.find(selection).get_formatted_text(header_level)
+ selection_preview += "\n" + obj_text
+
+ dropdown_options = []
+ for selection in data.selection:
+ dropdown_item = f"'{selection.name}' Selection"
+ dropdown_options.append(dropdown_item)
+
+ builder.add_label("Export Settings", position=0, gap=True)
+ self.dropdown = builder.addDropdownList("", "dlist", options=dropdown_options, position=0,
+ on_change=self.update_settings)
+
+ self.depth = builder.addChoose("exportoptions", position=0, options=["Only selected component", "Include subcomponents"],
+ on_change=self.update_settings)
+
+ builder.add_label("",0,True)
+
+ self.export_path = builder.add_textbox("Filepath", "filepath", height=1, position=0)
+ self.validation_info = builder.addText("", "info", position=0, disabled=True)
+
+ builder.add_label("Preview", position=1)
+ self.preview = builder.add_textbox("", "previewbox", height=frame_height, position=1)
+ self.preview.value = selection_preview
+
+ super(BrowserExportMenu, self).__init__(screen, builder,
+ on_close_callback=on_close_callback, footer="Export")
+ self.builder = builder
+ self.initial_selection = selection_preview
+ if not selection_preview:
+ self.empty_selection = True
+
+ @auto_reload
+ def _reload(self):
+ pass
+
+ def update_settings(self):
+ # if current path is selected set to initial and return
+ if self.dropdown.value == 0:
+ self.preview.value = self.initial_selection
+ return
+
+ selection = None
+ selected_domain, _ = self.dropdown.options[self.dropdown.value]
+ for selectable in self.export_data.selection:
+ if selectable.name in selected_domain and selectable.value != None:
+ selection, _ = selectable.options[selectable.value]
+
+ if selection:
+ data_object = self.export_data.find(selection)
+ else:
+ self.preview.value = "Selection empty."
+ return
+ explicit = data_object.get_formatted_text()
+ if self.depth.value == 1:
+ ancestors = data_object.get_ancestors()
+ descendants = data_object.get_descendants()
+ for descendant in descendants:
+ header_level = (len(descendant.get_ancestors()) - len(ancestors)) + 1
+ explicit += descendant.get_formatted_text(header_level)
+ self.preview.value = explicit
+
+ def validate_path(self, path):
+ directory, filename = os.path.split(path)
+ if not directory:
+ directory = "."
+ if not os.path.exists(directory):
+ return False
+ if not filename.lower().endswith(self.SUPPORTED_EXPORT_FORMATS):
+ return False
+ return True
+
+ def _submit(self):
+ if self.empty_selection:
+ self._on_close_callback("Empty selection.")
+ self._close()
+ return
+ filepath = self.export_path.value.strip()
+ if self.validate_path(filepath):
+ with open(filepath, "w+") as file:
+ file.write(self.preview.value)
+ if self._on_close_callback:
+ self._on_close_callback(f"Successfully exported to file {filepath}")
+ self._close()
+ self.validation_info.value = "Invalid filepath."
+
+
+class CreateChecklistModel(ArtifactModel):
+
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ super(CreateChecklistModel, self).__init__()
+
+ self.selection = []
+
+class CreateChecklistView(BaseView):
+ CACHE = {}
+
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view.
+
+ The REM module provides automation and
+ abstractions over doorstop.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self._screen = screen
+ self.data_model = model
+
+ app: Application = root_menu.get_ref_to_app()
+
+ max_height = screen.height
+ frame_height = max_height - 9
+ max_width = screen.width
+
+ builder = Builder("Evaluation Checklist - Creation")
+ builder.addLayout([20, 10, 10, 60], True)
+
+ # Input
+
+ builder.add_label("Packages", position=0, disabled=True)
+ builder.addDivider(True, position=0)
+ self.package_list = builder.addListBox("Package", height=(frame_height//2)-2, position=0,
+ on_select=lambda: self.toggle_selection("Package"))
+ self.package_list.options = self.get_packages()
+ builder.addDivider(True, position=0)
+
+ builder.add_label("Search Bar", position=0, disabled=True)
+ self.search = builder.add_textbox("", "searchbox", height=1, position=0)
+ self.search.value = "Search"
+ self.search_button = builder.addButton("Search", position=0, on_click=self.search_item)
+
+ builder.addDivider(True, position=0)
+ builder.add_label("Actions", position=0, disabled=True)
+ self.validate_button = builder.addButton("Validate Selection", position=0,
+ on_click=self.validate)
+ self.auto_button = builder.addButton("Auto Complete Selection", position=0,
+ on_click=self.auto_complete_selection)
+ self.create_button = builder.addButton("Create Evaluation Checklist", position=0,
+ on_click=self.open_form, name="Create")
+ self.create_button.disabled = True
+
+ builder.add_label("Select Item(s)", position=1, disabled=True)
+ builder.addDivider(True, position=1)
+ self.component_list = builder.addListBox("Component", height=frame_height-5, position=1,
+ on_select=lambda: self.toggle_selection("Component"))
+ self.component_list.options = self.get_components()
+
+ builder.add_label("Current Selection", position=2, disabled=True)
+ builder.addDivider(True, position=2)
+ self.selection_list = builder.addListBox("Selection", height=frame_height-4, position=2,
+ on_select=lambda: self.display_selection("Selection"))
+ self.deselect_button = builder.addButton("Deselect", position=2, on_click=self.deselect_option)
+ self.clear_button = builder.addButton("Clear", position=2, on_click=self.clear_selection)
+
+ builder.add_label("Item Preview", position=3, disabled=True)
+ builder.addDivider(True, position=3)
+ self.preview = builder.add_textbox("", "previewbox", height="max", position=3, readonly=True)
+
+ # Output
+ builder.addLayout([50,50])
+ builder.addDivider(True)
+ self.statusbar = builder.addStatusBar()
+ builder.addDivider(True, position=1)
+ self.export = builder.addButton("Open Export Menu", on_click=self.open_popup, position=1)
+
+ super(CreateChecklistView, self).__init__(screen, root_menu, builder)
+ self._reload()
+ self.builder = builder
+ self.data_model: CreateChecklistView = self.data_model
+
+ @auto_reload
+ def _reload(self):
+ pass
+
+ def get_display_options(self, options):
+ return [(f"{state} {name}", i) for i, (name, state) in enumerate(options)]
+
+ def get_packages(self):
+ packages = self.data_model.yield_obj(cct.Package)
+ package_options = [(package._id.upper(), '[ ]') for package in packages]
+ options = self.get_display_options(package_options)
+ return options
+
+ def get_components_for_package(self, package):
+ index = self.data_model
+ package = index.find(package)
+ package_components = [comp._id.upper() for comp in package.components]
+ return package_components
+
+ def get_components(self):
+ components = self.data_model.yield_obj(cct.AComponent)
+ component_options = [(component._id.upper(), '[ ]') for component in components]
+ options = self.get_display_options(component_options)
+ return options
+
+ def generate_preview(self, item):
+ index = self.data_model
+ item_obj = index.find(item)
+ self.preview.value = item_obj.get_formatted_text()
+
+ def clear_component_selection(self):
+ listbox = self.component_list
+ for option, idx in listbox.options:
+ if '[X]' in option:
+ toggle = option.replace('[X]', '[ ]')
+ listbox.options[idx] = (toggle, idx)
+ self.component_list.options = listbox.options
+
+ def clear_package_selection(self):
+ listbox = self.package_list
+ for option, idx in listbox.options:
+ if '[X]' in option:
+ toggle = option.replace('[X]', '[ ]')
+ listbox.options[idx] = (toggle, idx)
+ self.package_list.options = listbox.options
+
+ def deselect_option(self):
+ if not self.selection_list.options:
+ return
+ idx = self.selection_list.value
+ item, _ = self.selection_list.options[idx]
+ listbox_options = self.component_list.options
+ for option, idx in listbox_options:
+ if item in option:
+ listbox_options[idx] = ('[ ] ' + item, idx)
+ self.component_list.options = listbox_options
+ self.update_selection_list()
+ self.validate()
+
+ @auto_cache
+ def update_component_selection(self, selection, mode="add"):
+ listbox = self.component_list
+ if mode == "add":
+ for item in selection:
+ for option, idx in listbox.options:
+ if item.upper() in option and '[ ]' in option:
+ toggle = option.replace('[ ]', '[X]')
+ listbox.options[idx] = (toggle, idx)
+ elif mode == "delete":
+ for item in selection:
+ for option, idx in listbox.options:
+ if item.upper() in option and '[X]' in option:
+ toggle = option.replace('[X]', '[ ]')
+ listbox.options[idx] = (toggle, idx)
+
+ self.component_list.options = listbox.options
+ self.update_selection_list()
+ return self.component_list
+
+ @auto_cache
+ def update_selection_list(self):
+ selection_list = []
+ selection_idx = 0
+ for option, idx in self.component_list.options:
+ if '[X]' in option:
+ selection_list.append([option.split(' ')[-1], selection_idx])
+ selection_idx += 1
+ self.selection_list.options = selection_list
+ return self.selection_list
+
+ def auto_complete_selection(self):
+ selected_components = [component for component, idx in self.selection_list.options]
+ _, valid_set = cct.validate_dependencies(selected_components)
+ self.clear_component_selection()
+ self.update_component_selection(valid_set)
+ self.validate()
+
+ def clear_selection(self):
+ self.clear_component_selection()
+ self.clear_package_selection()
+ self.update_selection_list()
+ self.statusbar.value = "Selection cleared."
+ self.validate()
+
+ @auto_cache
+ def toggle_selection(self, name):
+ listbox_dict = {"Package":self.package_list,
+ "Component":self.component_list,
+ "Selection":self.selection_list}
+ listbox = listbox_dict[name]
+ idx = listbox.value
+ option, _ = listbox.options[idx]
+
+ if '[ ]' in option:
+ toggle = option.replace('[ ]', '[X]')
+ listbox.options[idx] = (toggle, idx)
+ self.generate_preview(toggle.split(' ')[-1])
+
+ else:
+ toggle = option.replace('[X]', '[ ]')
+ listbox.options[idx] = (toggle, idx)
+ self.preview.value = ""
+
+ if name == "Package":
+ self.clear_component_selection()
+ for package, _ in self.package_list.options:
+ if '[X]' in package:
+ package_id = package.split(' ')[-1]
+ components = self.get_components_for_package(package_id)
+ self.update_component_selection(components, mode="add")
+
+ listbox_dict[name] = listbox
+ self.update_selection_list()
+ self.validate()
+
+ return listbox_dict[name]
+
+ def display_selection(self, name):
+ listbox = self.find_widget(name)
+ idx = listbox.value
+ item, _ = listbox.options[idx]
+ self.generate_preview(item.split(' ')[-1])
+
+ def validate_package_selection(self):
+ index = self.data_model
+ selected_package = 0
+ listbox = self.package_list
+ for option in listbox.options:
+ if '[X]' in option[0]:
+ selected_package += 1
+ if selected_package > 1:
+ self.statusbar.value = "Only one Package can be selected."
+ self.create_button.disabled = True
+ return False
+ elif selected_package == 0:
+ self.statusbar.value = "Empty Selection."
+ self.create_button.disabled = True
+ return False
+ else:
+ self.statusbar.value = "Selection valid!"
+ self.create_button.disabled = False
+ return True
+
+ @auto_cache
+ def validate(self):
+ selected_components = []
+ listbox = self.selection_list
+ for option, _ in listbox.options:
+ selected_components.append(option.lower())
+ is_valid, valid_set = cct.validate_dependencies(selected_components)
+ if not is_valid:
+ self.statusbar.value = f"Selection Invalid! Valid set based on your selection {valid_set}"
+ self.create_button.disabled = True
+ elif len(selected_components) == 0:
+ self.statusbar.value = "Empty Selection."
+ self.create_button.disabled = True
+ else:
+ self.statusbar.value = "Selection valid!"
+ self.create_button.disabled = False
+
+ return [self.statusbar, self.create_button]
+
+ def save_selection(self, blacklist=None):
+ blacklist = blacklist or list()
+ selection = []
+ for widget in self.builder.widgets:
+ try:
+ if isinstance(widget, tuple):
+ widget = widget[0]
+ if widget.name != "Domain" and widget.name not in blacklist:
+ is_selectable = widget.options
+ selection.append(widget)
+ except AttributeError:
+ pass
+ self.data_model.selection = selection
+
+ def update_status(self, value):
+ self.statusbar.value = value
+
+ def open_popup(self):
+ # This will display the CustomPopUp and ask the user for input
+ self.save_selection(blacklist=["Selection"])
+ success = self._scene.add_effect(CreationExportMenu(self._screen, self.data_model,
+ on_close_callback=self.update_status))
+ if success:
+ self.update_status("Selection successfully exported.")
+
+ def search_request_handler(self, query, matching_components, selection=2):
+ if selection == 2:
+ query_obj = self.data_model.find(query)
+ self.update_component_selection(matching_components, mode="add")
+ self.preview.value = query_obj.get_formatted_text()
+ self.statusbar.value = f"{query} found and added to Selection."
+ elif selection == 0:
+ first_query_obj = self.data_model.find(matching_components[0])
+ self.update_component_selection(matching_components, mode="add")
+ self.preview.value = first_query_obj.get_formatted_text()
+ self.statusbar.value = f"{query} Class/Family Components added to Selection."
+ else:
+ self.statusbar.value = f"{query} not found!"
+
+ def search_item(self):
+ query = self.search.value.upper()
+
+ class_match = False
+ family_match = False
+ component_match = False
+
+ matching_components = []
+
+ for item, idx in self.component_list.options:
+ pruned_item = item.split(' ')[-1]
+ if query == pruned_item:
+ component_match = True
+ matching_components.append(pruned_item)
+
+ elif pruned_item.startswith(query):
+ matching_components.append(pruned_item)
+ if "_" not in query:
+ class_match = True
+ else:
+ family_match = True
+
+ if component_match:
+ self.search_request_handler(query, matching_components)
+ return
+ elif family_match or class_match:
+ self._scene.add_effect(
+ PopUpDialog(self._screen, "Select Class/Family Components?", ["Yes", "No"],
+ on_close=lambda selection: self.search_request_handler(query,
+ matching_components, selection)))
+ return
+ self.statusbar.value = f"{query} not found!"
+
+ def create_request_handler(self, selection):
+ if selection == 0:
+ raise NextScene("Evaluation Checklist")
+
+ def open_form(self):
+ # This will display the CustomPopUp and ask the user for input
+ self._scene.add_effect(FormView(self._screen,
+ on_close_callback=self.create_evaluation_checklist))
+
+ def create_evaluation_checklist(self, info):
+ gen_info = {"GeneralInfo" : {**{"CCVersion": self.data_model.cc_version}, **info}}
+ index = self.data_model
+ components = [index.find(component) for component, _ in self.selection_list.options]
+ usr_prefix = info["identifier"]
+
+ try:
+ log.debug(f"save in : {self.data_model.project_root} - with prefix: {usr_prefix}")
+ # abort if a doorstop document with the same prefix exists
+ if(doorstop.find_document(usr_prefix)):
+ self.statusbar.value = f"ERROR: The selected prefix '{usr_prefix}' is already in use in your repository."
+
+ except doorstop.common.DoorstopError as x:
+ log.debug(f"Doorstop error: {x}")
+ try:
+ cct.create_evaluation_checklist(components, gen_info,
+ export_path=self.data_model.project_root,
+ doc_prefix=usr_prefix)
+ self._scene.add_effect(PopUpDialog(self._screen,
+ "Proceed to Evaluation Checklist?", ["Yes", "No"],
+ on_close=self.create_request_handler,
+ theme="bright"))
+ self.statusbar.value = "Evaluation Checklist successfully created!"
+ except doorstop.common.DoorstopError as e:
+ self.statusbar.value = f"{e}"
+
+
+class FormView(PopUpMenu):
+
+ def __init__(self, screen, on_close_callback):
+
+ builder = Builder("Enter Details")
+ builder.addLayout([100], True)
+
+ self.identifier = builder.addText("Evaluation Identifier", "labelx")
+ self.creator = builder.addText("Creator","label1")
+ self.date = builder.addText("Creation Date", "label2")
+ builder.addButton("Today", on_click=self.get_date)
+
+ super(FormView, self).__init__(screen, builder,
+ on_close_callback=on_close_callback, footer="Create")
+ self.builder = builder
+
+ @auto_reload
+ def _reload(self):
+ pass
+
+ def get_date(self):
+ date = datetime.now().date()
+ self.date.value = str(date)
+
+ def get_attribute_dict(self):
+ keys = ["identifier", "creator", "date"]
+ _attributes = {}
+ for key in keys:
+ _attributes[key] = getattr(self, key).value
+ return _attributes
+
+ def _submit(self):
+ if self._on_close_callback:
+ attributes = self.get_attribute_dict()
+ self._on_close_callback(attributes)
+ self._close()
+
+class CreationExportMenu(PopUpMenu):
+ SUPPORTED_EXPORT_FORMATS = (".md")
+ def __init__(self, screen, data, on_close_callback=None):
+
+ self._screen = screen
+ self.export_data = data
+ self._on_close_callback = on_close_callback
+ self.empty_selection = False
+
+ max_height = screen.height//2
+ frame_height = max_height - 5
+ max_width = screen.width//2
+
+ builder = Builder("Export Menu")
+ builder.addLayout([30, 70])
+
+ dropdown_options = ["Current Selection"]
+ for selection in data.selection:
+ dropdown_item = f"'{selection.name}' Selection"
+ dropdown_options.append(dropdown_item)
+
+ builder.add_label("Export Settings", position=0)
+ self.dropdown = builder.addDropdownList("", "dlist", options=dropdown_options, position=0,
+ on_change=self.update_settings)
+
+ self.depth = builder.addChoose("exportoptions", position=0, options=["Only selected component", "Include subcomponents"],
+ on_change=self.update_settings)
+ self.export_path = builder.add_textbox("Filepath", "filepath", height=1, position=0)
+ self.validation_info = builder.addText("", "info", position=0, disabled=True)
+
+ builder.add_label("Preview", position=1)
+ self.preview = builder.add_textbox("", "previewbox", height=frame_height, position=1)
+ self.preview.value = self.load_initial_selection()
+
+ super(CreationExportMenu, self).__init__(screen, builder,
+ on_close_callback=on_close_callback, footer="Export")
+ self.builder = builder
+
+
+ @auto_reload
+ def _reload(self):
+ pass
+
+ def get_text(self, obj_, level=1.0):
+ obj_text = obj_.get_formatted_text(level)
+ level += 1
+ if self.depth.value == 1:
+ for child in obj_.children:
+ obj_text += self.get_text(child, level=level)
+ return obj_text
+
+ def prune_list(self, original_list, remove_list):
+ pruned_list = list(filter(lambda elem: elem not in remove_list, original_list))
+ return pruned_list
+
+ def load_initial_selection(self):
+
+ selected_packages = []
+ selected_components = []
+ for selectable in self.export_data.selection:
+ for option, _ in selectable.options:
+ if '[X]' in option:
+ selection = option.split(' ')[-1]
+ if selectable.name == "Package":
+ selected_packages.append(selection)
+ else:
+ selected_components.append(selection)
+ preview = ""
+ if selected_packages:
+ for package in selected_packages:
+ pkg_obj = self.export_data.find(package)
+ components = pkg_obj.components
+ component_ids = [comp._id.upper() for comp in components]
+ pkg_text = pkg_obj.get_formatted_text()
+ components_text = ""
+ for component in components:
+ components_text += self.get_text(component, level=2)
+ preview += pkg_text + components_text
+ selected_components = self.prune_list(selected_components, component_ids)
+
+ if selected_components:
+ # additional components were selected -> augmentation
+ header_level = 1
+ if selected_packages:
+ preview += "\n# Augmentations\n"
+ header_level = 2
+ for component in selected_components:
+ component_obj = self.export_data.find(component)
+ preview += self.get_text(component_obj, level=header_level)
+
+ if not any([selected_packages, selected_components]):
+ self.empty_selection = True
+ return
+ return preview
+
+
+ def update_settings(self):
+ # if current path is selected set to initial and return
+ if self.dropdown.value == 0:
+ preview = self.load_initial_selection()
+ self.preview.value = preview
+ return
+ else:
+ selection = []
+ selected_domain, _ = self.dropdown.options[self.dropdown.value]
+ for selectable in self.export_data.selection:
+ if selectable.name in selected_domain and selectable.value != None:
+ for option, _ in selectable.options:
+ if '[X]' in option:
+ selection.append(option.split(' ')[-1])
+ preview = ""
+ if not selection:
+ self.preview.value = ""
+ return
+
+ for _id in selection:
+ data_object = self.export_data.find(_id)
+ preview += self.get_text(data_object)
+
+ self.preview.value = preview
+
+ def validate_path(self, path):
+ directory, filename = os.path.split(path)
+ if not directory:
+ directory = "."
+ if not os.path.exists(directory):
+ return False
+ if not filename.lower().endswith(self.SUPPORTED_EXPORT_FORMATS):
+ return False
+ return True
+
+ def _submit(self):
+ if self.empty_selection:
+ self._on_close_callback("Empty selection.")
+ self._close()
+ return
+ filepath = self.export_path.value.strip()
+ if self.validate_path(filepath):
+ with open(filepath, "w+") as file:
+ file.write(self.preview.value)
+ if self._on_close_callback:
+ self._on_close_callback("Export successful!")
+ self._close()
+ self.validation_info.value = "Invalid filepath."
+
+
+
+class WorkUnitModel(ArtifactModel):
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ super(WorkUnitModel, self).__init__()
+ self.doc = None
+ self.d_index = {}
+ self.current_item = None
+ self.current_unit = None
+
+ def find_key_in_dict(self, d, target_key):
+ if target_key in d.keys(): # base case
+ return d[target_key]
+ for key, value in d.items():
+ if isinstance(value, dict): # if value is a dictionary, recurse
+ result = self.find_key_in_dict(value, target_key)
+ if result: # if found in the nested dictionary
+ return result
+ return None # not found
+
+ def set_current(self, item):
+ self.current_item = item
+ self.current_unit = item._data["header"].upper()
+
+ def get_item(self, item_id):
+ log.debug(f"Search for: {item_id}")
+ uid = self.find_key_in_dict(self.d_index, item_id.lower())["UID"]
+ item = self.doc.find_item(uid)
+ self.set_current(item)
+ return item
+
+ def update_item(self, item, _data):
+ item._data = _data
+ item.review()
+
+ def get_item_status(self, item_id):
+ item = self.get_item(item_id)
+ status = item._data["verdict"]
+ return status
+
+ def update_index(self, item):
+ index_entry = self.find_key_in_dict(self.d_index, item._data["header"].lower())
+ index_entry["verdict"] = item._data["verdict"]
+ index_entry["hash"] = item._data["reviewed"].value
+ cct.save_index(self.d_index, self.doc.path)
+
+ def update_item(self, data):
+ """
+ Update Work Unit with provided evaluation evidence and verdict.
+ """
+ item = self.current_item
+ for key in list(data.keys()):
+ item._data[key] = data[key]
+ item.review()
+ self.update_index(item)
+
+class WorkUnitView(BaseView):
+ CACHE = {}
+
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view.
+
+ The REM module provides automation and
+ abstractions over doorstop.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self._screen = screen
+ self.data_model = model
+ app: Application = root_menu.get_ref_to_app()
+
+ max_height = screen.height
+ frame_height = max_height - 8
+ max_width = screen.width
+ narrow = max_width//10
+ wide = (max_width*2)//5
+
+ builder = Builder("Evaluation Checklist")
+ builder.addLayout([narrow, narrow, wide, wide])
+
+ builder.add_label("Checklist(s)", position=0, disabled=True)
+ self.project_listbox = builder.addListBox("checklist", height=frame_height-3, options=[],
+ position=0, on_select=self.load_units)
+ self.load = builder.addButton("Load Evaluation Checklist(s)", position=0,
+ on_click=self.load_evaluation_checklists)
+
+ builder.add_label("Evaluation Items", position=1, disabled=True)
+ self.unit_listbox = builder.addListBox("workunitlist", height=frame_height-2, options=[],
+ position=1, on_select=self.load_item)
+
+ builder.add_label("Evaluation Evidence", position=2, disabled=True)
+ self.eval_evidence = builder.add_textbox("", "evalevidence", height=frame_height-5, position=2,
+ on_change=self.toggle_verdict)
+ self.pass_button = builder.addButton("Pass", position=2,
+ on_click=lambda: self.update_item("pass"))
+ self.pass_button.disabled = True
+ self.fail_button = builder.addButton("Fail", position=2,
+ on_click=lambda: self.update_item("fail"))
+ self.fail_button.disabled = True
+ self.inconclusive_button = builder.addButton("Inconclusive", position=2,
+ on_click=lambda: self.update_item("inconclusive"))
+ self.inconclusive_button.disabled = True
+
+ builder.add_label("Work Unit", position=3, disabled=True)
+ self.task_box = builder.add_textbox("", "taskbox", position=3, height=frame_height-2, readonly=True)
+
+ # Output
+ builder.addLayout([50, 20, 30])
+ builder.addDivider(draw_line=True, position=0)
+ self.statusbar = builder.addStatusBar()
+ builder.addDivider(True, position=1)
+ builder.addDivider(draw_line=True, position=2)
+ self.progress = builder.addText("Evaluation Progress", "Test", position=2, disabled=True)
+
+ super(WorkUnitView, self).__init__(screen, root_menu, builder)
+ self._reload()
+ self.builder = builder
+
+ @auto_reload
+ def _reload(self):
+ pass
+
+ @auto_cache
+ def toggle_verdict(self, toggle=False):
+ if not self.data_model.current_unit:
+ return
+ self.pass_button.disabled = toggle
+ self.fail_button.disabled = toggle
+ self.inconclusive_button.disabled = toggle
+ return [self.pass_button, self.fail_button, self.inconclusive_button]
+
+ @auto_cache
+ def update_item(self, verdict):
+ """
+ Update Work Unit with provided evaluation evidence and verdict.
+ """
+ if not self.data_model.current_unit:
+ return
+ data = {}
+ data["evidence"] = self.eval_evidence.value
+ data["verdict"] = verdict
+ log.debug(f"New data = {data}")
+ self.data_model.update_item(data)
+ self.statusbar.value = self.data_model.current_unit + " updated."
+ self.get_evaluation_progress()
+ self.display_workunits()
+ return self.statusbar
+
+ @auto_cache
+ def load_evaluation_checklists(self):
+ documents = cct.get_evaluation_documents(self.data_model.project_root)
+ project_prefix = [doc.prefix for doc in documents]
+ self.project_listbox.options = self.to_options(project_prefix)
+ if project_prefix:
+ self.statusbar.value = f" {len(project_prefix)} Evaluation Project/s found!"
+ else:
+ self.statusbar.value = "No Evaluation Project found! Please create Evaluation Checklist."
+ return [self.project_listbox, self.statusbar]
+
+ @auto_cache
+ def load_units(self):
+ with common.Capture(catch=True) as success:
+ idx = self.project_listbox.value
+ project_prefix, _ = self.project_listbox.options[idx]
+ self.data_model.doc = cct.get_doorstop_document(self.data_model.project_root, project_prefix)
+ log.debug(f"Load eval list in document: {self.data_model.doc.path}")
+ index = cct.load_index(self.data_model.doc.path)
+ cct.validate_index(index)
+ self.data_model.d_index = index
+ self.display_workunits()
+ self.get_evaluation_progress()
+ self.statusbar.value = f"Project {project_prefix} successfully loaded and validated!"
+ if not success:
+ self.statusbar.value = "An error occur when loading and validating the project."
+ return self.statusbar
+
+ def to_options(self, options: list) -> list:
+ option_list = []
+ for idx, option in enumerate(options):
+ option_list.append((option, idx))
+ return option_list
+
+ def get_workunits_from_index(self, index):
+ workunits = {}
+ for _, data in index["Components"].items():
+ comp_units = data["workunit"]
+ for unit, data in comp_units.items():
+ workunits[unit] = data
+ return workunits
+
+ @auto_cache
+ def display_workunits(self):
+ index = self.data_model.d_index
+ log.debug(f"INDX: {index}")
+ units = self.get_workunits_from_index(index)
+ workunits = []
+ for unit, data in units.items():
+ if data["verdict"] != "inconclusive":
+ unit_string = unit.upper() + "\t" + data["verdict"]
+ else:
+ unit_string = unit.upper()
+ workunits.append(unit_string)
+ workunit_options = self.to_options(workunits)
+ self.unit_listbox.options = workunit_options
+ log.debug(f"Workunits: {self.unit_listbox.options}")
+ return self.unit_listbox
+
+ def format_data(self, data, section_dict, delimiter, width):
+ delimiter = delimiter * width
+ display_lines = []
+ for section in section_dict.values():
+ # Add formatted header
+ padding = " " * ((width - len(section["header"]))//2)
+ padded_header = padding + section["header"] + padding
+ display_lines.append(padded_header)
+ display_lines.append(delimiter)
+ # Add content based on keys
+ for key, desc in section["keys"]:
+ if desc:
+ if isinstance(data[key], list):
+ for k, d in zip(data[key], data[desc]):
+ display_lines.extend([d[2:], delimiter])
+ else:
+ display_lines.extend([data[desc][2:], delimiter])
+ else:
+ display_lines.append(data[key])
+ display_lines.append(delimiter)
+ return "\n".join(display_lines)
+
+ def display_item_data(self, item_data: dict):
+ if item_data["evidence"]:
+ self.eval_evidence.value = item_data["evidence"]
+ else:
+ self.eval_evidence.value = "Insert Evaluation Evidence."
+ sections = {
+ "evaluation": {
+ "header": "EVALUATOR ACTION ELEMENT",
+ "keys": [("element", "element_description")]
+ },
+ "content": {
+ "header": "CONTENT OR DEVELOPER ELEMENT",
+ "keys": [("dc_element", "dc_element_description")]
+ },
+ "work_unit": {
+ "header": "WORK UNIT TASK",
+ "keys": [("text", None)]
+ }
+ }
+ width = self.task_box.width
+ delimiter = "-"
+ self.task_box.value = self.format_data(item_data, sections, delimiter, width)
+
+ def extract_wu_id(self, displayed_workunit):
+ # extract an evaluation item's id from a string
+ # formatted by display_workunits()
+ return displayed_workunit.split('\t')[0]
+
+ def load_item(self):
+ ''' Load an item into memory
+ '''
+ data = self.data_model
+ # get the ListBox tuple for the currently selected value
+ workunit, _ = self.unit_listbox.options[self.unit_listbox.value]
+ log.debug(f"Displayed workunit = {workunit}")
+ workunit = self.extract_wu_id(workunit)
+ log.debug(f"Clean workunit ID = {workunit}")
+ item = data.get_item(workunit)
+ data = item._data
+ self.display_item_data(data)
+ self.toggle_verdict(True)
+
+ def extract_verdicts(self):
+ index = self.data_model.d_index
+ for component in index["Components"].values():
+ for workunit in component["workunit"].values():
+ yield workunit["verdict"]
+
+ def get_evaluation_progress(self):
+ verdicts = list(self.extract_verdicts())
+ total = len(verdicts)
+ if total == 0:
+ progress = None
+ passed = 0
+ for verdict in verdicts:
+ if verdict == "pass":
+ passed += 1
+ progress = (passed/total)*100
+ self.display_evaluation_progress(progress)
+
+ @auto_cache
+ def display_evaluation_progress(self, progress):
+ progress_string = str(int(progress)) + "%"
+ width = self.progress.width
+ pad = " " * ((width - len(progress_string))//2)
+ self.progress.value = pad + progress_string + pad
+ return self.progress
+
+ def update_status(self, value):
+ self.statusbar.value = value
+
+
\ No newline at end of file
diff --git a/c5dec/frontend/tui/miniapps/cpssaapp.py b/c5dec/frontend/tui/miniapps/cpssaapp.py
new file mode 100644
index 0000000..a34930c
--- /dev/null
+++ b/c5dec/frontend/tui/miniapps/cpssaapp.py
@@ -0,0 +1 @@
+# On the roadmap and planned for a future release (see the corresponding user manual entry)
\ No newline at end of file
diff --git a/c5dec/frontend/tui/miniapps/cryptographyapp.py b/c5dec/frontend/tui/miniapps/cryptographyapp.py
new file mode 100644
index 0000000..a34930c
--- /dev/null
+++ b/c5dec/frontend/tui/miniapps/cryptographyapp.py
@@ -0,0 +1 @@
+# On the roadmap and planned for a future release (see the corresponding user manual entry)
\ No newline at end of file
diff --git a/c5dec/frontend/tui/miniapps/ismsapp.py b/c5dec/frontend/tui/miniapps/ismsapp.py
new file mode 100644
index 0000000..83e5ce0
--- /dev/null
+++ b/c5dec/frontend/tui/miniapps/ismsapp.py
@@ -0,0 +1,289 @@
+from c5dec.frontend.tui.foundation.menu import BaseView
+# from c5dec.frontend.tui.models.docmanagement.msword_tag_processor import WordTagProcessor
+from c5dec.core.isms import WordTagProcessor
+from c5dec.core.isms import DocListAssistant
+from c5dec.core.isms import ActivityReport
+# from c5dec.frontend.tui.controllers.docmanagement.msoffice_controller import MSOfficeController
+from c5dec.frontend.tui.foundation.builder import Builder
+from docx.opc.exceptions import PackageNotFoundError
+
+from os.path import exists, isfile
+from i18n import t as translate
+
+class MSWordTagProcessingModel:
+ def __init__(self) -> None:
+ pass
+
+class MSWordTagProcessingView(BaseView):
+ """The view of MS Word tag processing.
+
+ This is the view part of the MVC structure of the MS Word tag processing
+ function.
+ """
+ def __init__(self, screen, root_menu, model):
+ """Set up the view for the Word tag processor.
+
+ The Word tag processor has an input field for the docx
+ path and another one for the CSV file.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ builder = Builder("MS Word tag processor")
+ builder.addLayout([100])
+
+ # Input
+ self.doc_path = builder.addPath('MS Word (.docx) file path')
+ self.csv_path = builder.addPath('CSV file path')
+ self.keep_style_flag = False
+ self.ignore_missing_tag_mapping = False
+
+ self.keep_style_tb = builder.addTickBox("Keep style?", "keep_style", self.toggle_style_status)
+ self.ignore_missing_tag_tb = builder.addTickBox("Ignore missing tag to link mapping?", "ignore_tag", self.toggle_missing_tag_behavior)
+
+ builder.addButton("Process", self.process_word_tags, gap=True,
+ gap_height=5)
+
+ # Output
+ builder.addLayout([100], True)
+ self.statusbar = builder.addStatusBar()
+ super(MSWordTagProcessingView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+ self.data_model: WordTagProcessor = WordTagProcessor()
+
+ def toggle_style_status(self):
+ self.keep_style_flag = self.keep_style_tb.value
+
+ def toggle_missing_tag_behavior(self):
+ self.ignore_missing_tag_mapping = self.ignore_missing_tag_tb.value
+
+ def process_word_tags(self):
+ """Process word tags and create new document.
+ """
+ doc_path = self.doc_path.value
+ csv_path = self.csv_path.value
+ regex_text = "(.*?)(#S(?:-\w+)+)(.*?)"
+ try:
+ if not (doc_path is None or csv_path is None):
+ self.data_model.set_params(doc_path, csv_path, regex_text, ignore_missing_tag=self.ignore_missing_tag_mapping)
+ self.data_model.convert_tags_to_hyperlinks(keep_style=self.keep_style_flag)
+ except IOError:
+ self.statusbar.value = translate("Missing or bad arguments.")
+ return None
+ except PackageNotFoundError:
+ self.statusbar.value = translate("No docx file found at the provided path.")
+ return None
+ self.statusbar.value = translate(
+ "The processed Word document can be found in the same folder.")
+
+class DocListAssistantModel:
+ def __init__(self) -> None:
+ pass
+
+class DocListAssistantView(BaseView):
+ """The view of the document list assistant.
+
+ This is the view part of the MVC structure of the document list
+ validator.
+ """
+ def __init__(self, screen, root_menu, model):
+ """Set up the view for the doc list validator.
+
+ The doc list validator ...
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ builder = Builder("Document list assistant")
+ builder.addLayout([100])
+
+ # Input
+ self.scan_path = builder.addPath("Path to folder:")
+ self.doclist_path = builder.addPath("Path to the document list (DOL):")
+ self.filename_col_name = builder.addText(
+ "Table column name for used filename (optional)", "UsedFilename", gap=True, gap_height=2)
+
+ builder.addButton("Show docs not listed in DOL", self.show_unlisted_docs, gap=True,
+ gap_height=2)
+
+ builder.addButton("Clear fields", self.clear_fields)
+
+ # Output
+ builder.addLayout([100], True)
+ self.listbox_files = builder.addListBox(
+ "files", "max", [], parser=True, position=0)
+ self.statusbar = builder.addStatusBar()
+ super(DocListAssistantView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+ self.data_model: DocListAssistant = DocListAssistant()
+
+
+ def show_unlisted_docs(self):
+ self.listbox_files.options = self.builder.zipOfList(list())
+
+ doclist_path = self.doclist_path.value
+ doc_scan_path = self.scan_path.value
+ col_name = self.filename_col_name.value
+ try:
+ if not (doclist_path is None or doc_scan_path is None):
+ self.data_model.doclist_path = doclist_path
+ self.data_model.doc_scan_path = doc_scan_path
+ if not col_name == "":
+ self.data_model.used_filename_column_name = col_name
+
+ options = self.builder.zipOfList(self.data_model.get_unlisted_docs())
+ self.listbox_files.options = options
+ except IOError:
+ self.statusbar.value = translate("Missing or bad arguments.")
+ return None
+ except PackageNotFoundError:
+ self.statusbar.value = translate("No xlsx file found at the provided path.")
+ return None
+ self.statusbar.value = translate(
+ "The unlisted documents are shown above.")
+
+
+ def clear_fields(self):
+ self.scan_path.value = ""
+ self.doclist_path.value = ""
+
+class ActivityReportModel(ActivityReport):
+ def __init__(self) -> None:
+ super(ActivityReportModel, self).__init__()
+
+class ActivityReportView(BaseView):
+ """The view of the activity report.
+
+ This is the view part of the MVC structure of the activity report
+ function.
+ """
+ def __init__(self, screen, root_menu, model):
+ """Set up the view for the activity report generator.
+
+ The activity report generator has an input field for the folder
+ path, input fields for months, days and hours to set how long
+ to look back, a dropdownlist to specify the author, a checkbox
+ to say if you want to save the output to a csv file and a
+ corresponding input field to give the output file.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ builder = Builder("Activity Report")
+ builder.addLayout([100])
+
+ # Input
+ self.path = builder.addPath()
+ self.months = builder.addText("months", "months")
+ self.days = builder.addText("days", "days")
+ self.hours = builder.addText("hours", "hours", gap=True)
+ self.author = builder.addDropdownList("Author", "author",
+ options=self.get_authors(), gap=True)
+ self.csv = builder.addTickBox("Save as csv?", "csv", self.toggle_csv)
+ self.saveto = builder.addText("Save to", "save_to", gap=True)
+ builder.addButton("List", self.get_activity_report, gap=True,
+ gap_height=2)
+
+ # Output
+ builder.addLayout([100], True)
+ self.activities_table = builder.addTable(
+ "max", ["Folder", "File", "User", "Date", "Event"], [],
+ columns=[25, 33, 17, 15, 10])
+ builder.addLayout([100])
+ self.statusbar = builder.addStatusBar()
+ super(ActivityReportView, self).__init__(screen, root_menu, builder)
+ self.toggle_csv()
+
+ def get_authors(self):
+ """Get the authors from the model.
+
+ :return: all authors by their full names
+ :rtype: list
+ """
+ self.authors = [translate("all")]
+ self.authors.extend(list(self.data_model.authors.keys()))
+ return self.authors
+
+ def toggle_csv(self):
+ """Enable/ Disable the input field of the output file according
+ to the corresponding tickbox."""
+ if self.csv.value:
+ self.builder.enable(self.saveto)
+ else:
+ self.builder.disable(self.saveto)
+
+ def if_empty_return_0(self, widget):
+ """Evaluate the input of a widget and set it to 0 if it is
+ empty.
+
+ :param widget: the widget whose value should be evaluated
+ :type widget: class `Widget`
+
+ :return: 0 or the the value of the widget
+ :rtype: int
+ """
+ if widget.value.strip() == "":
+ widget.value = "0"
+ return 0
+ else:
+ value = int(widget.value.strip())
+ return value
+
+ def get_activity_report(self):
+ """Get and display the activity report and optionally, save to
+ a csv file.
+ """
+ path = self.path.value
+ try:
+ months = self.if_empty_return_0(self.months)
+ days = self.if_empty_return_0(self.days)
+ hours = self.if_empty_return_0(self.hours)
+ except:
+ self.activities_table.options = self.builder.zipOfList([])
+ self.statusbar.value = translate("The duration is invalid")
+ return None
+ if exists(path) and not isfile(path):
+ self.statusbar.value = ""
+ self.data_model.path = path.strip(" /")
+ self.data_model.set_date(months, days, hours)
+ if self.author.value != 0:
+ author = self.authors[self.author.value]
+ else:
+ author = 0
+ self.data_model.author = author
+ activities = self.data_model.get_activity_report()
+ list_activities = []
+
+ # Prepare the activity report to be able to be displayed
+ for folder, files in activities.items():
+ entry = [folder]
+ for file_data in files:
+ entry.extend(file_data)
+ list_activities.append(entry)
+ entry = [""]
+ # Save to csv file
+ if self.csv.value:
+ csv_file = self.saveto.value
+ if exists(csv_file) and isfile(csv_file):
+ self.data_model.save_to_csv(csv_file)
+ self.statusbar.value = translate(
+ "file successfully saved")
+ else:
+ self.statusbar.value = translate(
+ "The path to the CSV file is invalid")
+
+ options = self.builder.zipOfList(list_activities)
+ else:
+ options = self.builder.zipOfList([])
+ self.statusbar.value = translate(
+ "The path to the folder is invalid")
+ self.activities_table.options = options
\ No newline at end of file
diff --git a/c5dec/frontend/tui/miniapps/miniappbase.py b/c5dec/frontend/tui/miniapps/miniappbase.py
new file mode 100644
index 0000000..ea4781c
--- /dev/null
+++ b/c5dec/frontend/tui/miniapps/miniappbase.py
@@ -0,0 +1,54 @@
+from c5dec.frontend.tui.foundation.menu import Menu, BaseView, PopUpMenu
+from c5dec.frontend.tui.foundation.builder import Builder
+from c5dec.frontend.tui.application import Application
+from asciimatics.widgets import PopUpDialog
+from asciimatics.exceptions import NextScene
+from datetime import datetime
+import c5dec.settings as c5settings
+import c5dec.common as common
+import doorstop
+import os
+import logging
+
+MUTABLE_ATTRIBUTES = ["options", "value", "disabled"]
+
+log = logging.getLogger(__name__)
+log.setLevel(logging.ERROR)
+
+logHandler = logging.FileHandler("baseapp.log", mode='w')
+formatter = logging.Formatter("%(levelname)s - %(funcName)s() : %(message)s")
+logHandler.setFormatter(formatter)
+log.addHandler(logHandler)
+
+
+class MiniAppPlaceholderModel:
+ def __init__(self):
+ pass
+
+class MiniAppPlaceholderView(BaseView):
+
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view.
+
+ Explanation goes here...
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self._screen = screen
+ self.data_model = model
+
+ app: Application = root_menu.get_ref_to_app()
+
+ max_height = screen.height
+ frame_height = max_height - 12
+ max_width = screen.width
+
+ builder = Builder("Planned for future release")
+ builder.addLayout([13, 7, 10, 10, 10, 50], True)
+
+ super(MiniAppPlaceholderView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+ self.data_model: MiniAppPlaceholderModel = self.data_model
\ No newline at end of file
diff --git a/c5dec/frontend/tui/miniapps/pmapp.py b/c5dec/frontend/tui/miniapps/pmapp.py
new file mode 100644
index 0000000..e7a42a3
--- /dev/null
+++ b/c5dec/frontend/tui/miniapps/pmapp.py
@@ -0,0 +1,175 @@
+from c5dec.frontend.tui.foundation.menu import BaseView
+from c5dec.core.pm import TimeReportAssistant
+from c5dec.frontend.tui.foundation.builder import Builder
+import os
+from os.path import exists, isfile
+from i18n import t as translate
+from docx.opc.exceptions import PackageNotFoundError
+
+class TimeReportModel(TimeReportAssistant):
+ def __init__(self) -> None:
+ super(TimeReportModel, self).__init__()
+
+class OpenProjectTimeReportAssistantView(BaseView):
+ """The view of the time report assistant.
+
+ This is the view part of the MVC structure.
+ """
+ def __init__(self, screen, root_menu, model):
+ """Set up the view.
+
+ The time report assistant performs post-processing on OpenProject time reports.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ builder = Builder("OpenProject time report assistant")
+ builder.addLayout([100])
+
+ # Input
+ self.input_file_path = builder.addPath("Path to OpenProject time report file:")
+
+ builder.addButton("Convert to IAL timesheet format", self.run_timerep_conversion, gap=True,
+ gap_height=2)
+
+ builder.addButton("Clear fields", self.clear_fields)
+
+ # Output
+ builder.addLayout([100], True)
+ self.statusbar = builder.addStatusBar()
+ super(OpenProjectTimeReportAssistantView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+ self.data_model: TimeReportAssistant = TimeReportAssistant()
+
+
+ def run_timerep_conversion(self):
+ input_file_path = self.input_file_path.value
+ try:
+ if not (input_file_path is None):
+ self.data_model.input_file_path = input_file_path
+ _ = self.data_model.convert_openproject_time_report_to_IAL_format()
+ except IOError:
+ self.statusbar.value = translate("Missing or bad arguments.")
+ return None
+ except PackageNotFoundError:
+ self.statusbar.value = translate("No xlsx file found at the provided path.")
+ return None
+ except Exception as e:
+ self.statusbar.value = translate("Something unexpected went wrong: {}".format(e))
+ return None
+ self.statusbar.value = translate(
+ "Done, the post-processed time report can be found in the C5-DEC folder.")
+
+ def clear_fields(self):
+ self.input_file_path.value = ""
+
+class TimeReportAssistantView(BaseView):
+ """The view of the time report assistant.
+
+ This is the view part of the MVC structure.
+ """
+ def __init__(self, screen, root_menu, model):
+ """Set up the view.
+
+ The time report assistant performs post-processing on OpenProject time reports.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ builder = Builder("Time report assistant")
+ builder.addLayout([100])
+
+ # Input
+ self.tsh_folder_path = builder.addPath("Path to folder containing time report files:")
+
+ self.use_filters = builder.addTickBox("Apply filters?", "filteruse")
+
+ self.from_date_picker = builder.add_date_picker("fromdatepicker", "From date:")
+ self.to_date_picker = builder.add_date_picker("todatepicker", "To date:")
+
+ # self.filter_field_name = builder.addText("Field to filter:", "fieldfiltername", gap=False)
+ self.filter_field_list = builder.addDropdownList(
+ "Field to filter", "targetfield", on_change=None,
+ gap=True, gap_height=2)
+ self.populate_filter_field_listbox(builder=builder)
+
+ self.filter_field_value = builder.addText("Field value to filter:", "fieldvaluefiltername", gap=False)
+
+ builder.addButton("Consolidate time reports", self.run_tsh_consolidation, gap=True, gap_height=2)
+
+ # self.input_file_path = builder.addPath("Path to consolidated timesheet file:")
+ # self.to_be_merged_file = builder.addPath("Path to TSH to merge with consoliated TSH:")
+
+ # builder.addButton("Merge file with consolidated TSH", self.merge_tsh_with_consolidated_tsh, gap=True,
+ # gap_height=2)
+
+ builder.addButton("Clear fields", self.clear_fields)
+
+ # Output
+ builder.addLayout([100], True)
+ self.statusbar = builder.addStatusBar()
+ super(TimeReportAssistantView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+ self.data_model: TimeReportAssistant = TimeReportAssistant()
+
+
+ # def merge_tsh_with_consolidated_tsh(self):
+ # # self.statusbar.value = str(self.from_date_picker.value.year)
+ # self.statusbar.value = "Not implemented yet..."
+ # return
+ # input_file_path = self.input_file_path.value
+ # try:
+ # if not (input_file_path is None):
+ # # self.controller.set_model_params(input_file_path=input_file_path)
+ # self.data_model.input_file_path = input_file_path
+ # # self.data_model.set_tsh_folder_path(tsh_folder_path)
+ # # self.controller.convert_time_report_to_IAL_format()
+ # # _ = self.data_model.convert_openproject_time_report_to_IAL_format()
+ # except IOError:
+ # self.statusbar.value = translate("Missing or bad arguments.")
+ # # self.statusbar.value = os.getcwd()+"--"+input_file_path
+ # return None
+ # except PackageNotFoundError:
+ # self.statusbar.value = translate("No xlsx file found at the provided path.")
+ # return None
+ # self.statusbar.value = translate(
+ # "Done: the post-processed time report can be found in the C5-DEC folder.")
+
+ def populate_filter_field_listbox(self, builder):
+ timerep_fields = self.data_model.get_timerep_fields()
+ self.filter_field_list.options = builder.zipOfList(timerep_fields)
+
+ def run_tsh_consolidation(self):
+ folder_path = self.tsh_folder_path.value
+ try:
+ if not (folder_path is None):
+ filter_field = self.filter_field_list.options[self.filter_field_list.value][0]
+ self.data_model.set_timerep_parameters(source_folder=self.tsh_folder_path.value,
+ apply_filters=self.use_filters.value,
+ from_date=self.from_date_picker.value,
+ to_date=self.to_date_picker.value,
+ filter_field=filter_field,
+ filter_field_value=self.filter_field_value.value)
+ _ = self.data_model.consolidate_timesheets()
+ except IOError:
+ self.statusbar.value = translate("Missing or bad arguments.")
+ return None
+ except PackageNotFoundError:
+ self.statusbar.value = translate("No xlsx file found at the provided path.")
+ return None
+ except Exception as e:
+ self.statusbar.value = translate("Something unexpected went wrong: {}".format(e))
+ return None
+ self.statusbar.value = translate(
+ "Done, time reports have been successfully consolidated.")
+
+
+ def clear_fields(self):
+ # self.input_file_path.value = ""
+ self.tsh_folder_path.value = ""
\ No newline at end of file
diff --git a/c5dec/frontend/tui/miniapps/settingsapp.py b/c5dec/frontend/tui/miniapps/settingsapp.py
new file mode 100644
index 0000000..e69de29
diff --git a/c5dec/frontend/tui/miniapps/ssdlcapp.py b/c5dec/frontend/tui/miniapps/ssdlcapp.py
new file mode 100644
index 0000000..48c937d
--- /dev/null
+++ b/c5dec/frontend/tui/miniapps/ssdlcapp.py
@@ -0,0 +1,373 @@
+from c5dec.frontend.tui.foundation.menu import BaseView
+from c5dec.frontend.tui.foundation.builder import Builder
+from c5dec.frontend.tui.foundation.menu import Menu
+import c5dec.settings as c5settings
+import c5dec.common as common
+from c5dec.frontend.tui.application import Application
+import c5dec.core.ssdlc as ssdlc
+from i18n import t as translate
+
+class ArtifactModel:
+ """Parent class for all artifact related models.
+ """
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ self.project_root = c5settings.PROJECT_ROOT
+
+ def get_project_root(self):
+ return self.project_root
+
+class RepositoryManagementModel(ArtifactModel):
+ """The model of the REM management submodule.
+ """
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ super(RepositoryManagementModel, self).__init__()
+
+ def create_repository(self, repo_prefix, path=None, parent_prefix=None):
+ ssdlc.create_artifact_repository(repo_prefix=repo_prefix, path=path, parent_prefix=parent_prefix)
+
+ def delete_repository(self, repo_prefix):
+ ssdlc.delete_artifact_repository(repo_prefix=repo_prefix)
+
+class RepositoryManagementView(BaseView):
+ """The view of the REM management module.
+ """
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view.
+
+ The REM module provides automation,
+ abstractions and workflows on top of Doorstop.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ app: Application = root_menu.get_ref_to_app()
+
+ builder = Builder("Manage artifact repositories")
+ builder.addLayout([100])
+
+ # Input
+ self.repo_name = builder.addText("Artifact repository PREFIX:", "reponame", gap=False)
+ self.repo_parent_name = builder.addText("Parent repository PREFIX:", "parentreponame", gap=False)
+
+ self.repo_path = builder.addPath("Path to artifact repository directory:")
+ self.repo_path.value = c5settings.PROJECT_ROOT
+
+ builder.addButton("Create artifact repository", self.handle_create_artifact_repo_event, gap=False,
+ gap_height=1)
+ builder.addButton("Delete artifact repository", self.handle_delete_artifact_repo_event, gap=True, gap_height=1)
+
+ builder.addButton("Reset fields", self.clear_fields)
+
+ # Output
+ builder.addLayout([100], True)
+ self.statusbar = builder.addStatusBar()
+ super(RepositoryManagementView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+ self.data_model: RepositoryManagementModel = self.data_model
+
+ def handle_create_artifact_repo_event(self):
+ with common.Capture(catch=True) as success:
+ self.data_model.create_repository(self.repo_name.value, self.repo_path.value, self.repo_parent_name.value)
+ self.statusbar.value = "Repository created"
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def handle_delete_artifact_repo_event(self):
+ with common.Capture(catch=True) as success:
+ self.data_model.delete_repository(self.repo_name.value)
+ self.statusbar.value = "Repository deleted"
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def clear_fields(self):
+ self.repo_name.value = ""
+ self.repo_parent_name.value = ""
+ self.repo_path.value = self.data_model.get_project_root()
+
+class ItemManagementModel(ArtifactModel):
+ """The model of the REM item management submodule.
+ """
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ super(ItemManagementModel, self).__init__()
+
+ def add_item(self, repo_prefix, path=None, parent_prefix=None):
+ pass
+
+ def remove_item(self, repo_prefix):
+ pass
+
+class ItemManagementView(BaseView):
+ """The view of the REM artifact management module.
+ """
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view.
+
+ The REM module provides automation and
+ abstractions over doorstop.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ app: Application = root_menu.get_ref_to_app()
+
+ builder = Builder("Manage artifact items")
+ builder.addLayout([100])
+
+ # Input
+ self.repo_name = builder.addText("Enter artifact repository PREFIX:", "reponame")
+
+ builder.addButton("Add artifact item", self.handle_add_item_event, gap=True,
+ gap_height=1)
+
+ self.item_id = builder.addText("ID of item to edit or remove:", "removeitemid", gap=False, gap_height=1)
+
+ builder.addButton("Show item text", self.handle_edit_item_event, gap=False, gap_height=1)
+ self.textbox = builder.add_textbox("Item content:", "itemtext", gap=True, gap_height=1)
+ builder.addButton("Save item text", self.handle_save_item_text_event, gap=False, gap_height=1)
+
+ builder.addButton("Remove item", self.handle_remove_item_event, gap=True, gap_height=1)
+
+ builder.addButton("Reset fields", self.clear_fields)
+
+ # Output
+ builder.addLayout([100], True)
+ self.statusbar = builder.addStatusBar()
+ super(ItemManagementView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+ self.data_model: ItemManagementModel = self.data_model
+
+ def handle_add_item_event(self):
+ with common.Capture(catch=True) as success:
+ ssdlc.add_item(self.repo_name.value)
+ self.statusbar.value = "Item added"
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def handle_edit_item_event(self):
+ with common.Capture(catch=True) as success:
+ text = ssdlc.get_item_text(self.item_id.value)
+ self.textbox.value = text
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def handle_save_item_text_event(self):
+ new_text = self.textbox.value
+ with common.Capture(catch=True) as success:
+ ssdlc.set_item_text(self.item_id.value, new_text)
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def handle_remove_item_event(self):
+ with common.Capture(catch=True) as success:
+ ssdlc.remove_item(self.item_id.value)
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def clear_fields(self):
+ self.repo_name.value = ""
+ self.item_id.value = ""
+ self.item_id.value = ""
+
+class ItemRelationModel(ArtifactModel):
+ """The model of the REM item management submodule.
+ """
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ super(ItemRelationModel, self).__init__()
+
+ def add_item(self, repo_prefix, path=None, parent_prefix=None):
+ pass
+
+ def remove_item(self, repo_prefix):
+ pass
+
+class ItemRelationManagementView(BaseView):
+ """The view of the REM artifact management module.
+ """
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view.
+
+ The REM module provides automation and
+ abstractions over doorstop.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ app: Application = root_menu.get_ref_to_app()
+
+ builder = Builder("Manage item relations")
+ builder.addLayout([100])
+
+ # Input
+ self.child_item_id = builder.addText("Child item ID:", "childitemid")
+ self.parent_item_id = builder.addText("Parent item ID:", "parentitemid")
+
+ builder.addButton("Create link", self.handle_create_link_event, gap=True,
+ gap_height=1)
+ builder.addButton("Remove link", self.handle_remove_link_event, gap=True,
+ gap_height=1)
+
+ builder.addButton("Show child item links", self.handle_show_link_event, gap=False, gap_height=1)
+
+ builder.addLayout([1,1], True)
+ self.links_to_parents_listbox = builder.addListBox(
+ "linkslevel1", "max", [], on_change=self.handle_link_list_selection_event, position=0)
+ self.textbox = builder.add_textbox("Item content:", "itemtext", position=1)
+
+ builder.addButton("Reset fields", self.clear_fields)
+
+ # Output
+ # builder.addLayout([100], True)
+ self.statusbar = builder.addStatusBar()
+ super(ItemRelationManagementView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+ self.data_model: ItemRelationManagementView = self.data_model
+
+ def handle_create_link_event(self):
+ with common.Capture(catch=True) as success:
+ ssdlc.link_child_item_to_parent(self.child_item_id.value, self.parent_item_id.value)
+ self.statusbar.value = "Link added."
+ self.refresh_listbox_of_linked_items()
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def handle_remove_link_event(self):
+ with common.Capture(catch=True) as success:
+ ssdlc.unlink_child_item_to_parent(self.child_item_id.value, self.parent_item_id.value)
+ self.statusbar.value = "Link removed."
+ self.refresh_listbox_of_linked_items()
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def handle_show_link_event(self):
+ with common.Capture(catch=True) as success:
+ link_list = ssdlc.get_item_links(self.child_item_id.value)
+ self.links_to_parents_listbox.options = self.builder.zipOfList(link_list)
+ self.statusbar.value = "Links retrieved."
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def handle_link_list_selection_event(self):
+ index = self.links_to_parents_listbox.value
+ with common.Capture(catch=True) as success:
+ if index is not None:
+ item_id = self.links_to_parents_listbox.options[index][0]
+ item_text = ssdlc.get_item_text(item_id)
+ self.textbox.value = item_text
+ self.statusbar.value = "Linked item {} text retrieved.".format(item_id)
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def refresh_listbox_of_linked_items(self):
+ with common.Capture(catch=True) as success:
+ link_list = ssdlc.get_item_links(self.child_item_id.value)
+ self.links_to_parents_listbox.options = self.builder.zipOfList(link_list)
+ self.statusbar.value = "Links retrieved."
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def clear_fields(self):
+ self.clear_text_fields([self.child_item_id, self.parent_item_id])
+
+class ArtifactStatusManagementModel(ArtifactModel):
+ """The model of the SSDLC status management submodule.
+ """
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ super(ArtifactStatusManagementModel, self).__init__()
+
+class ArtifactStatusManagementView(BaseView):
+ """The view of the SSDLC status management submodule.
+ """
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view.
+
+ The SSDLC artifact status module provides ...
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ app: Application = root_menu.get_ref_to_app()
+
+ builder = Builder("Manage repository structure and item status")
+ builder.addLayout([100], True)
+
+ # Input
+
+ self.repo_name = builder.addText("Artifact repository PREFIX:", "reponame", gap=False)
+ builder.addButton("Reorder artifact repository", self.handle_reorder_repository_event, gap=True, gap_height=1)
+
+ self.label_type = builder.addChoose(
+ "LabelType", ["item UID", "repository prefix"], self.handle_label_change_event, gap=True, gap_height=1)
+
+ self.label_choice = builder.addText("Repository PREFIX or item ID:", "reponame", gap=False)
+ builder.addButton("Clear: absolve of suspect link status", self.handle_clear_event, gap=False, gap_height=1)
+ builder.addButton("Review: absolve of unreviewed status", self.handle_review_event, gap=True, gap_height=2)
+
+ builder.addButton("Reset fields", self.clear_fields)
+
+ # Output
+ builder.addLayout([100])
+ self.statusbar = builder.addStatusBar()
+ super(ArtifactStatusManagementView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+ self.data_model: ArtifactStatusManagementModel = self.data_model
+
+ def handle_reorder_repository_event(self):
+ with common.Capture(catch=True) as success:
+ ssdlc.reorder_artifact_repository(repo_prefix=self.repo_name.value)
+ self.statusbar.value = "Repository reordered."
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def handle_label_change_event(self):
+ pass
+
+ def handle_clear_event(self):
+ with common.Capture(catch=True) as success:
+ label_type = self.label_type.value
+ if label_type == 0:
+ ssdlc.clear_item(self.label_choice.value)
+ self.statusbar.value = "Item cleared."
+ else:
+ ssdlc.clear_repository(self.label_choice.value)
+ self.statusbar.value = "Repository cleared."
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ def handle_review_event(self):
+ with common.Capture(catch=True) as success:
+ label_type = self.label_type.value
+ if label_type == 0:
+ ssdlc.review_item(self.label_choice.value)
+ self.statusbar.value = "Item reviewed."
+ else:
+ ssdlc.review_repository(self.label_choice.value)
+ self.statusbar.value = "Repository reviewed."
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+
+ def clear_fields(self):
+ self.repo_name.value = ""
+ self.label_choice.value = ""
\ No newline at end of file
diff --git a/c5dec/frontend/tui/miniapps/transformerapp.py b/c5dec/frontend/tui/miniapps/transformerapp.py
new file mode 100644
index 0000000..c06a250
--- /dev/null
+++ b/c5dec/frontend/tui/miniapps/transformerapp.py
@@ -0,0 +1,298 @@
+from c5dec.frontend.tui.foundation.menu import Menu, BaseView
+from c5dec.frontend.tui.foundation.builder import Builder
+import c5dec.settings as c5settings
+import c5dec.common as common
+from c5dec.frontend.tui.application import Application
+import c5dec.core.ssdlc as ssdlc
+import c5dec.core.transformer as transformer
+import doorstop
+from i18n import t as translate
+from docx.opc.exceptions import PackageNotFoundError
+
+class TransformerModel:
+ def __init__(self) -> None:
+ pass
+
+class ExportModel(TransformerModel):
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ super(ExportModel, self).__init__()
+
+class ExportView(BaseView):
+ """The view of the data export submodule.
+
+ This is the view part of the MVC structure.
+ """
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view for the data export submodule.
+
+ The view of the data export submodule provides an easy-to-use
+ UI for triggering various data export functions.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ builder = Builder("SSDLC data export")
+ builder.addLayout([100], True)
+
+ # Export which document/repository
+ self.target_repository = builder.addDropdownList(
+ "Export one document or all", "target_repo", on_change=self.handle_target_repo_change_event,
+ gap=True, gap_height=2)
+
+ self.populate_document_listbox(builder=builder)
+
+ self.export_format = builder.addDropdownList(
+ "Export format", "export_format", on_change=self.handle_target_repo_change_event,
+ gap=True, gap_height=1)
+
+ self.export_format.options = builder.zipOfList([".yml", ".csv", ".tsv", ".xlsx"])
+
+ # builder.addLayout([100])
+ builder.addButton(
+ "Export", self.handle_export_button_press_event, gap=True, gap_height=1)
+
+ # builder.addButton("Clear fields", self.clear_fields)
+
+ self.statusbar = builder.addStatusBar()
+ super(ExportView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+
+ def populate_document_listbox(self, builder):
+ documents = ssdlc.get_documents()
+ lb_name_list = []
+ for d in documents:
+ lb_name_list.append(d.prefix)
+ lb_name_list.append("all")
+ self.target_repository.options = builder.zipOfList(lb_name_list)
+
+ def handle_target_repo_change_event(self):
+ pass
+
+ def handle_export_button_press_event(self):
+ label = self.target_repository.options[self.target_repository.value][0]
+ export_format = self.export_format.options[self.export_format.value][0]
+ with common.Capture(catch=True) as success:
+ path = transformer.export_ssdlc_document(label=label, format=export_format)
+ self.statusbar.value = "Export finished: {}".format(path)
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ # def clear_fields(self):
+ # pass
+
+class ImportModel(TransformerModel):
+ def __init__(self):
+ """Set up the key attributes needed for requirements management.
+ """
+ super(ImportModel, self).__init__()
+
+class ImportView(BaseView):
+ """The view of the data export submodule.
+
+ This is the view part of the MVC structure.
+ """
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view for the data import submodule.
+
+ The view of the data import submodule provides an easy-to-use
+ UI for triggering various SSDLC data import functions.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ builder = Builder("SSDLC data import")
+ builder.addLayout([100], True)
+
+ # Import which document/repository
+ self.target_repository = builder.addDropdownList(
+ "Import document", "target_repo", on_change=self.handle_target_repo_change_event,
+ gap=True, gap_height=2)
+
+ self.populate_document_listbox(builder=builder)
+
+ self.import_format = builder.addDropdownList(
+ "Import format", "export_format", on_change=self.handle_target_repo_change_event,
+ gap=True, gap_height=1)
+
+ self.import_format.options = builder.zipOfList([".yml", ".csv", ".tsv", ".xlsx"])
+
+ self.document_path = builder.addPath("Path to previously exported document:")
+ self.document_path.value = "{}/...".format(c5settings.PROJECT_ROOT)
+
+ # builder.addLayout([100])
+ builder.addButton(
+ "Import", self.handle_import_button_press_event, gap=True, gap_height=1)
+
+ # builder.addButton("Clear fields", self.clear_fields)
+
+ self.statusbar = builder.addStatusBar()
+ super(ImportView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+
+ def populate_document_listbox(self, builder):
+ documents = ssdlc.get_documents()
+ lb_name_list = []
+ for d in documents:
+ lb_name_list.append(d.prefix)
+ self.target_repository.options = builder.zipOfList(lb_name_list)
+
+ def handle_target_repo_change_event(self):
+ pass
+
+ def handle_import_button_press_event(self):
+ label = self.target_repository.options[self.target_repository.value][0]
+ import_format = self.import_format.options[self.import_format.value][0]
+ with common.Capture(catch=True) as success:
+ transformer.import_ssdlc_document(path=self.document_path.value, prefix=label, format=import_format)
+ self.statusbar.value = "Import finished."
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+ # def clear_fields(self):
+ # pass
+
+class PublisherModel(TransformerModel):
+ def __init__(self):
+ """Set up the key attributes needed for the publisher model.
+ """
+ super(PublisherModel, self).__init__()
+
+class PublisherView(BaseView):
+ """The view of the publisher submodule.
+
+ This is the view part of the MVC structure.
+ """
+ def __init__(self, screen, root_menu: Menu, model):
+ """Set up the view for the data import submodule.
+
+ The view of the data import submodule provides an easy-to-use
+ UI for triggering various SSDLC data import functions.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ builder = Builder("SSDLC publishing")
+ builder.addLayout([100], True)
+
+ # Import which document/repository
+ self.target_repository = builder.addDropdownList(
+ "Document to publish", "target_repo", on_change=self.handle_target_repo_change_event,
+ gap=True, gap_height=2)
+
+ self.populate_document_listbox(builder=builder)
+
+ self.publish_format = builder.addDropdownList(
+ "Publishing format", "export_format", on_change=self.handle_target_repo_change_event,
+ gap=True, gap_height=1)
+
+ self.publish_format.options = builder.zipOfList([".txt", ".md", ".html", ".tex"])
+
+ self.document_path = builder.addPath("Path to file or directory:")
+ # self.document_path.value = "{}/...".format(c5settings.PROJECT_ROOT)
+
+ # builder.addLayout([100])
+ builder.addButton(
+ "Publish", self.handle_publish_button_press_event, gap=True, gap_height=1)
+
+ # builder.addButton("Clear fields", self.clear_fields)
+
+ self.statusbar = builder.addStatusBar()
+ super(PublisherView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+
+ def populate_document_listbox(self, builder):
+ documents = ssdlc.get_documents()
+ lb_name_list = []
+ for d in documents:
+ lb_name_list.append(d.prefix)
+ lb_name_list.append("all")
+ self.target_repository.options = builder.zipOfList(lb_name_list)
+
+ def handle_target_repo_change_event(self):
+ pass
+
+ def handle_publish_button_press_event(self):
+ label = self.target_repository.options[self.target_repository.value][0]
+ publish_format = self.publish_format.options[self.publish_format.value][0]
+ publish_path = None
+ if self.document_path.value != "":
+ publish_path = self.document_path.value
+ with common.Capture(catch=True) as success:
+ transformer.publish_ssdlc_document(label, path=publish_path, format=publish_format)
+ self.statusbar.value = "Publish finished."
+ if not success:
+ self.statusbar.value = "Something went wrong..."
+
+class ConverterModel(TransformerModel):
+ def __init__(self) -> None:
+ super().__init__()
+
+class ConverterView(BaseView):
+ """The view of the converter submodule.
+
+ This is the view part of the MVC structure.
+ """
+ def __init__(self, screen, root_menu, model):
+ """Set up the view for the converter submodule.
+
+ The view of the converter submodule provides an easy-to-use
+ UI for triggering various data conversion functions.
+
+ :param screen: the screen that displays this function
+ :type screen: class `Screen`
+ :param root_menu: the menu that owns this function
+ :type root_menu: class `Menu`
+ """
+ self.data_model = model
+ builder = Builder("Data converter")
+ builder.addLayout([100], True)
+
+ # Input
+ self.input_file_path = builder.addPath("Path to file you wish to convert:")
+
+ # Convert from what
+ self.source_type = builder.addDropdownList(
+ "Source type", "source_type", on_change=self.generate_source_type_change_event,
+ gap=True, gap_height=2)
+ self.source_type.options = builder.zipOfList(["Markdown", "YAML", "LaTeX", "docx"])
+
+ # Convert to what
+ self.target_type = builder.addDropdownList(
+ "Target type", "target_type", on_change=self.generate_target_type_change_event,
+ gap=True, gap_height=2)
+ self.target_type.options = builder.zipOfList(["Markdown", "YAML", "LaTeX", "docx"])
+
+ # builder.addLayout([100])
+ builder.addButton(
+ "Convert", self.generate_converter_press_event, gap=True, gap_height=1)
+
+ builder.addButton("Clear fields", self.clear_fields)
+
+ super(ConverterView, self).__init__(screen, root_menu, builder)
+ self.builder = builder
+
+ def generate_source_type_change_event(self):
+ pass
+
+ def generate_target_type_change_event(self):
+ pass
+
+ def generate_converter_press_event(self):
+ """Trigger controller function for handling an import
+ button press event.
+ """
+ pass
+
+ def clear_fields(self):
+ self.input_file_path.value = ""
\ No newline at end of file
diff --git a/c5dec/psi/__init__.py b/c5dec/psi/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/c5dec/psi/graph.py b/c5dec/psi/graph.py
new file mode 100644
index 0000000..e69de29
diff --git a/c5dec/psi/search.py b/c5dec/psi/search.py
new file mode 100644
index 0000000..e69de29
diff --git a/c5dec/psi/security.py b/c5dec/psi/security.py
new file mode 100644
index 0000000..663d3bc
--- /dev/null
+++ b/c5dec/psi/security.py
@@ -0,0 +1,6 @@
+class InputValidation:
+ def __init__(self) -> None:
+ pass
+
+ def validate_input_with_regex(self, input, regex):
+ pass
\ No newline at end of file
diff --git a/c5dec/settings.py b/c5dec/settings.py
new file mode 100644
index 0000000..ff9bdd4
--- /dev/null
+++ b/c5dec/settings.py
@@ -0,0 +1,77 @@
+"""Settings for the C5-DEC package."""
+
+import logging
+import os
+
+# Logging settings
+DEFAULT_LOGGING_FORMAT = "%(message)s"
+LEVELED_LOGGING_FORMAT = "%(levelname)s: %(message)s"
+VERBOSE_LOGGING_FORMAT = "[%(levelname)-8s] %(message)s"
+VERBOSE2_LOGGING_FORMAT = "[%(levelname)-8s] (%(name)s @%(lineno)4d) %(message)s"
+QUIET_LOGGING_LEVEL = logging.WARNING
+TIMED_LOGGING_FORMAT = "%(asctime)s" + " " + VERBOSE_LOGGING_FORMAT
+DEFAULT_LOGGING_LEVEL = logging.WARNING
+VERBOSE_LOGGING_LEVEL = logging.INFO
+VERBOSE2_LOGGING_LEVEL = logging.DEBUG
+VERBOSE3_LOGGING_LEVEL = logging.DEBUG - 1
+
+# Application configurations
+ASSETS_FOLDER_NAME = "assets"
+STARTUP_CONFIG_JSON_PATH = ASSETS_FOLDER_NAME+"/config.json"
+TRANSLATION_ASSETS_FOLDER_PATH = ASSETS_FOLDER_NAME+"/translations"
+PERSON_ACRONYMS_FILE_PATH = ASSETS_FOLDER_NAME+"/acronyms/persons.json"
+ACRONYMS_FOLDER_PATH = ASSETS_FOLDER_NAME+"/acronyms/"
+OPENPROJECT_PARAMS_CSV_FILE_PATH = ASSETS_FOLDER_NAME+"/tshparams/openproject_params.csv"
+TSHFORMAT_JSON_FILE_PATH = ASSETS_FOLDER_NAME+"/tshparams/tshformat.json"
+EXPORT_FOLDER = os.getcwd()
+
+feature_flags = {"ssdlc": True, "cct": True, "cryptography": True, "cpssec": True, "isms": True, "pm": True, "transformer": True, "settings": False}
+
+CC_VERSION_TO_PATH = {
+ "3R1": ASSETS_FOLDER_NAME + "/database/SecurityControls/cc3R1.xml",
+ "3R2": ASSETS_FOLDER_NAME + "/database/SecurityControls/cc3R2.xml",
+ "3R3": ASSETS_FOLDER_NAME + "/database/SecurityControls/cc3R3.xml",
+ "3R4": ASSETS_FOLDER_NAME + "/database/SecurityControls/cc3R4.xml",
+ "3R5": ASSETS_FOLDER_NAME + "/database/SecurityControls/cc3R5.xml"
+}
+CCDTD_FILE_PATH = ASSETS_FOLDER_NAME+"/database/SecurityControls/cc3r5.dtd"
+EVALLIST_JSON_PATH = ASSETS_FOLDER_NAME+"/database/eval.json"
+EXPORT_FOLDER = os.getcwd()
+
+# Project parameters
+PROJECT_ROOT = None
+
+LOG_FILE = "rem.log"
+
+DEFAULT_PROJECT_FOLDER_PATH = os.path.join(os.getcwd(), "default-rem-folder")
+
+# Doorstop defaults
+DOORSTOP_ROOT = "MRS"
+DEFAULT_SEPARATOR = "-"
+DEFAULT_DIGITS = 3
+DEFAULT_ITEMFORMAT = "markdown"
+DEFAULT_EDITOR = "vim"
+
+DEFAULT_EVALUATION_ATTRIBUTES = {'component' : '',
+ 'element' : '',
+ 'element_description' : '',
+ 'dc_element' : '',
+ 'dc_element_description' : '',
+ 'evidence' : '',
+ 'evaluator' : '',
+ 'evaluation_date' : '',
+ 'verdict': 'inconclusive'}
+DEFAULT_PUBLISH_ATTRIBUTES = {'component' : '',
+ 'element' : '',
+ 'dc_element' : '',
+ 'evidence' : '',
+ 'evaluator' : '',
+ 'evaluation_date' : '',
+ 'verdict': 'inconclusive'}
+
+DEFAULT_EVALUATION_REVIEWED = ['evidence', 'verdict', 'evaluator', 'evaluation_date']
+
+ROOT_REPO_NAME = "REQ"
+ROOT_REPO_FOLDER_NAME = "reqs"
+
+DOORSTOP_YAML = ".doorstop.yml"
diff --git a/docs/manual/_figures/CyFORT-logo.png b/docs/manual/_figures/CyFORT-logo.png
new file mode 100644
index 0000000..a0bf3cb
Binary files /dev/null and b/docs/manual/_figures/CyFORT-logo.png differ
diff --git a/docs/manual/_figures/Python3-8-WindowsStore.png b/docs/manual/_figures/Python3-8-WindowsStore.png
new file mode 100644
index 0000000..faa52f9
Binary files /dev/null and b/docs/manual/_figures/Python3-8-WindowsStore.png differ
diff --git a/docs/manual/_figures/c5dec-cad-pm.png b/docs/manual/_figures/c5dec-cad-pm.png
new file mode 100644
index 0000000..bb5e8ab
Binary files /dev/null and b/docs/manual/_figures/c5dec-cad-pm.png differ
diff --git a/docs/manual/_figures/c5dec-cad-ssdlc.png b/docs/manual/_figures/c5dec-cad-ssdlc.png
new file mode 100644
index 0000000..682eab8
Binary files /dev/null and b/docs/manual/_figures/c5dec-cad-ssdlc.png differ
diff --git a/docs/manual/_figures/c5dec-cad-tui.png b/docs/manual/_figures/c5dec-cad-tui.png
new file mode 100644
index 0000000..ba9a0bb
Binary files /dev/null and b/docs/manual/_figures/c5dec-cad-tui.png differ
diff --git a/docs/manual/_figures/c5dec-cad-vscode-gui.png b/docs/manual/_figures/c5dec-cad-vscode-gui.png
new file mode 100644
index 0000000..5ccbb6f
Binary files /dev/null and b/docs/manual/_figures/c5dec-cad-vscode-gui.png differ
diff --git a/docs/manual/_figures/c5dec-cad-zettlr-gui.png b/docs/manual/_figures/c5dec-cad-zettlr-gui.png
new file mode 100644
index 0000000..c3de5a3
Binary files /dev/null and b/docs/manual/_figures/c5dec-cad-zettlr-gui.png differ
diff --git a/docs/manual/_figures/c5dec-cli.png b/docs/manual/_figures/c5dec-cli.png
new file mode 100644
index 0000000..badec7e
Binary files /dev/null and b/docs/manual/_figures/c5dec-cli.png differ
diff --git a/docs/manual/_figures/c5dec-isms-activity-report.png b/docs/manual/_figures/c5dec-isms-activity-report.png
new file mode 100644
index 0000000..68fbe6a
Binary files /dev/null and b/docs/manual/_figures/c5dec-isms-activity-report.png differ
diff --git a/docs/manual/_figures/c5dec-isms-document-list-assistant.png b/docs/manual/_figures/c5dec-isms-document-list-assistant.png
new file mode 100644
index 0000000..51d1f6d
Binary files /dev/null and b/docs/manual/_figures/c5dec-isms-document-list-assistant.png differ
diff --git a/docs/manual/_figures/c5dec-isms-tag-processor.png b/docs/manual/_figures/c5dec-isms-tag-processor.png
new file mode 100644
index 0000000..bd15efc
Binary files /dev/null and b/docs/manual/_figures/c5dec-isms-tag-processor.png differ
diff --git a/docs/manual/_figures/c5dec-openproject-time-rep-assistant.png b/docs/manual/_figures/c5dec-openproject-time-rep-assistant.png
new file mode 100644
index 0000000..7910c64
Binary files /dev/null and b/docs/manual/_figures/c5dec-openproject-time-rep-assistant.png differ
diff --git a/docs/manual/_figures/c5dec-openproject-time-report-converter.png b/docs/manual/_figures/c5dec-openproject-time-report-converter.png
new file mode 100644
index 0000000..d08e338
Binary files /dev/null and b/docs/manual/_figures/c5dec-openproject-time-report-converter.png differ
diff --git a/docs/manual/_figures/c5dec-time-rep-consolidation.png b/docs/manual/_figures/c5dec-time-rep-consolidation.png
new file mode 100644
index 0000000..6ba324f
Binary files /dev/null and b/docs/manual/_figures/c5dec-time-rep-consolidation.png differ
diff --git a/docs/manual/_figures/cctbrowser.png b/docs/manual/_figures/cctbrowser.png
new file mode 100644
index 0000000..b907462
Binary files /dev/null and b/docs/manual/_figures/cctbrowser.png differ
diff --git a/docs/manual/_figures/cctsubmenu.png b/docs/manual/_figures/cctsubmenu.png
new file mode 100644
index 0000000..870a71e
Binary files /dev/null and b/docs/manual/_figures/cctsubmenu.png differ
diff --git a/docs/manual/_figures/checklist.png b/docs/manual/_figures/checklist.png
new file mode 100644
index 0000000..861b947
Binary files /dev/null and b/docs/manual/_figures/checklist.png differ
diff --git a/docs/manual/_figures/d_evalitem.png b/docs/manual/_figures/d_evalitem.png
new file mode 100644
index 0000000..a13f353
Binary files /dev/null and b/docs/manual/_figures/d_evalitem.png differ
diff --git a/docs/manual/_figures/evalcreation.png b/docs/manual/_figures/evalcreation.png
new file mode 100644
index 0000000..d43141c
Binary files /dev/null and b/docs/manual/_figures/evalcreation.png differ
diff --git a/docs/manual/_figures/ssdlc-create-delete-artifact-document.png b/docs/manual/_figures/ssdlc-create-delete-artifact-document.png
new file mode 100644
index 0000000..3a0ebd1
Binary files /dev/null and b/docs/manual/_figures/ssdlc-create-delete-artifact-document.png differ
diff --git a/docs/manual/_figures/ssdlc-create-item-link.png b/docs/manual/_figures/ssdlc-create-item-link.png
new file mode 100644
index 0000000..f534284
Binary files /dev/null and b/docs/manual/_figures/ssdlc-create-item-link.png differ
diff --git a/docs/manual/_figures/ssdlc-manage-artifact-document.png b/docs/manual/_figures/ssdlc-manage-artifact-document.png
new file mode 100644
index 0000000..8a2e47c
Binary files /dev/null and b/docs/manual/_figures/ssdlc-manage-artifact-document.png differ
diff --git a/docs/manual/_figures/ssdlc-manage-artifact-items.png b/docs/manual/_figures/ssdlc-manage-artifact-items.png
new file mode 100644
index 0000000..03ad7d0
Binary files /dev/null and b/docs/manual/_figures/ssdlc-manage-artifact-items.png differ
diff --git a/docs/manual/_figures/ssdlc-manage-document-structure.png b/docs/manual/_figures/ssdlc-manage-document-structure.png
new file mode 100644
index 0000000..533b2b0
Binary files /dev/null and b/docs/manual/_figures/ssdlc-manage-document-structure.png differ
diff --git a/docs/manual/_figures/ssdlc-transformer-convert-data.png b/docs/manual/_figures/ssdlc-transformer-convert-data.png
new file mode 100644
index 0000000..2cf4cb2
Binary files /dev/null and b/docs/manual/_figures/ssdlc-transformer-convert-data.png differ
diff --git a/docs/manual/_figures/ssdlc-transformer-export.png b/docs/manual/_figures/ssdlc-transformer-export.png
new file mode 100644
index 0000000..bd7d7ae
Binary files /dev/null and b/docs/manual/_figures/ssdlc-transformer-export.png differ
diff --git a/docs/manual/_figures/ssdlc-transformer-import.png b/docs/manual/_figures/ssdlc-transformer-import.png
new file mode 100644
index 0000000..f1f1d6d
Binary files /dev/null and b/docs/manual/_figures/ssdlc-transformer-import.png differ
diff --git a/docs/manual/_figures/ssdlc-transformer-publish.png b/docs/manual/_figures/ssdlc-transformer-publish.png
new file mode 100644
index 0000000..0688ef5
Binary files /dev/null and b/docs/manual/_figures/ssdlc-transformer-publish.png differ
diff --git a/docs/manual/_figures/ssdlc-view-child-items.png b/docs/manual/_figures/ssdlc-view-child-items.png
new file mode 100644
index 0000000..1588a63
Binary files /dev/null and b/docs/manual/_figures/ssdlc-view-child-items.png differ
diff --git a/docs/manual/cct.md b/docs/manual/cct.md
new file mode 100644
index 0000000..fbacc4a
--- /dev/null
+++ b/docs/manual/cct.md
@@ -0,0 +1,153 @@
+# Common Criteria Toolbox
+
+The Common Criteria Toolbox (CCT) submodule serves as another integrated mini-app within C5-DEC, encompassing a comprehensive suite of functionalities designed to streamline the Common Criteria certification process for both developers and evaluators. Central to the CCT's functionality is the CC database (CC-DB), a dedicated database housing the CC in a structured format that is parsed and deserialized from the XML files sourced from the [Common Criteria portal](https://commoncriteriaportal.org/). Complementing the CCT and its CC database, the CC Knowledge Base stands as another valuable resource, offering users with guidance and support in understanding the Common Criteria and its various concepts.
+
+## Quick start guide
+
+The CCT can be accessed via the CLI or TUI.
+
+### TUI
+
+In the main menu of the TUI navigate to the 'Common Criteria Toolbox' module. The TUI can be navigated either using the arrow keys and enter or the mouse and double left-click.
+
+
+
+#### Browse the Common Criteria
+
+The Common Criteria Browser provides a tree-based viewing experience to browse the hierarchically structured Security Components of the Common Criteria. Select between Functional and Assurance Components to display all respective Classes. Selecting a Class will display the Class description in the 'Item Preview' as well as load all its Families. The same applies to Components and Elements.
+
+
+
+#### Create an Evaluation Checklist
+
+If you want to create an Evaluation Checklist navigate to 'Create Evaluation Checklist' in the CCT's submenu. Once in the 'Evaluation Checklist - Creation' function menu you can select the set of assurance components for which an evaluation checklist shall be created. You can either select a Package under 'Packages' or create a custom set by selecting individual components under 'Select Item/s'.
+
+Your current selection is displayed under 'Current Selection' and it is automatically validated to ensure that all the hierarchical and dependency relationships are satisfied within the set of selected components.
+The validation status is always displayed in the 'Status bar'.
+
+The description of the item currently selected is displayed in the 'Item Preview' section.
+
+
+
+**Search**
+
+In the _Common Criteria Browser_ and in the _Evaluation checklist-Creation_ views, you can search for Components using the 'Search Bar'. The search is case insensitive and allows you to match entire Classes or Families, as well as individual components.
+
+Individual Components are searched when a perfect match is found, e.g., ADV_INT.1. Classes or Families are searched when partial matches are found, e.g., searching for 'ACO' will match all the components belonging to the 'Composition' class; similarly, searching for 'ACO_DEV' will match all components belonging to the 'Composistion Development Evidence' family.
+
+You will be prompted to accept or decline the automatic selection of components in case of class/family matches.
+
+**Package augmentation**
+
+Augmenting a package is easily done by selecting the desired package and additional components under 'Select Item/s'. The selection will be automatically validated.
+
+**Auto complete selection**
+
+The 'Auto Complete Selection' feature provides a potential valid set that includes the current selection.
+
+**Deselect**
+
+Components can be deselected from the 'Current Selection' using the 'Deselect' button underneath.
+
+**Creating the Evaluation Checklist**
+
+Upon selection of a valid set you can create an Evaluation Checklist. The 'Create Evaluation Checklist' button will prompt a screen asking for information to uniquely identify the checklist:
+- Evaluation Identifier (``): a folder with this name is be created to store the selected evaluation items. A file per evaluation item is created and named with the format `-`, where `num` denotes a sequential number. These files contain the description of the evaluation item and are used to track the evaluation verdicts.
+- Creator
+- Creation Date.
+
+After submission, a doorstop document will be created. Each item (a markdown file with yaml frontmatter) of this document corresponds to a selected evaluation item and contains the Work Units that correspond to the selected components. As an example, Work Unit ADV_ARC.1-1 is displayed below. After successfully creating the Evaluation Checklist the system will ask you to proceed to the Evaluation Checklist.
+
+
+
+
+#### Evaluation Checklist
+
+When navigating to the 'Evaluation Checklist' functional menu you first have to load the Evaluation Checklist(s) using the button 'Load Evaluation Checklist/s' on the bottom left.
+
+Afterwards, you can select a checklist to start or proceed with your evaluation. All evaluation items are listed under 'Evaluation Item/s'. Selecting an item will display the corresponding Work Unit on the very right and the evidence (if already provided) under 'Evaluation Evidence'.
+
+With the buttons underneath the 'Evaluation evidence' section, a verdict (*pass*, *fail*, or *inconclusive*) can be set for the Work Unit. The changes are persisted.
+
+On the bottom right your progress is tracked for the current Evaluation Checklist.
+
+
+
+
+*_Note - Please enter your evidence in Markdown format._*
+
+
+### CLI
+
+Note that in the following examples, we assume C5-DEC CAD to be installed via pipx using the Wheel (.whl) distribution file, but in case C5-DEC CAD is deployed and launched with the containerized environment shipped with the GitHub repository, the commands must be preceded with `poetry run` due to our use of Poetry for dependency management and packaging. Note also that the Docker Desktop Engine must also be running prior to opening the project in the containerized environment via VS Code. An example below for the usage:
+
+Running the CLI for a pipx-based installation, i.e., C5-DEC CAD installed as an application using pipx, the following command can be used to get the help menu for the CLI:
+
+```sh
+ c5dec -h
+```
+
+which then becomes
+
+```sh
+ poetry run c5dec -h
+```
+
+in the containerized environment.
+
+Similarly, `poetry run c5dec` simply becomes `c5dec` when the tool is [installed via pipx](./installation.md).
+
+In the Alpha version the following commands are exposed to the CLI:
+
+**view**
+```sh
+ c5dec view
+ c5dec view > .md
+```
+This command prints the selected CC item's content and hierarchical tree to the console in Markdown format. Output redirection can be used to save the output as a Markdown file.
+
+The '--version' flag allows to specify the CC version. Currently supported versions are 3R1, 3R2, 3R3, 3R4, 3R5 with 3R5 being the default version.
+
+**validate**
+
+```sh
+ c5dec validate -d
+```
+
+The 'validate' command currently supports only the validation/verification of the dependencies for a provided set of components both functional and/or assurance.
+
+In the case of an invalid selection a potential valid selection is provided. Note that the provided valid selection can be just one of many valid selections. This is particularly true for a set of functional components since these often define *or-dependencies*, i.e., the dependency is fulfilled when one of the components listed as an *or-dependency* is included in the set.
+
+In future releases you'll be able to blacklist *or-dependencies* you do not want to include in your project such that you'll be able to iteratively explore all the available valid options.
+
+**checklist**
+
+The Evaluation Checklist as described above can also be created via the CLI with
+
+```sh
+ c5dec checklist -c --id --info
+```
+This will automatically validate the provided set of components and create the checklist if and only if it is a valid selection.
+
+The 'prefix' corresponds to the Evaluation Identifier mentioned earlier, and the 'info' is the general information that uniquely identifies the project/TOE for which the Evaluation Checklist is created. The 'info' can be a json file.
+
+Once an Evaluation Checklist is created you can run the following to list all created checklists, you can list all evaluation items of an Evaluation Checklist with
+
+```sh
+ c5dec checklist -l/--list
+```
+
+The most efficient approach to edit an Evaluation Item is using the TUI, but in case you want to edit it manually you can run the following command:
+```sh
+ c5dec checklist --edit [--editor ]
+```
+If no 'editor' is specified if defaults to 'vim'.
+
+After you're finished with editing the Evaluation Checklist run
+```sh
+ c5dec checklist -u/--update
+```
+to update the index that keeps track of the current evaluation progress. Retrieve the status of an evaluation with
+```sh
+ c5dec checklist -s/--status
+```
\ No newline at end of file
diff --git a/docs/manual/cpssa.md b/docs/manual/cpssa.md
new file mode 100644
index 0000000..8fcf7be
--- /dev/null
+++ b/docs/manual/cpssa.md
@@ -0,0 +1,7 @@
+# Cyber-Physical System Security Assessment (CPSSA)
+
+The CPSSA module largely delegates its functions to already existing open source software solutions such as [threagile](https://threagile.io/) for DevSecOps oriented threat modelling and security risk assessment (SRA), [ADTool](https://satoss.uni.lu/members/piotr/adtool/) for attack tree modelling and analysis, [Threat Dragon](https://owasp.org/www-project-threat-dragon/) for threat modelling and [Capella Darc Viewpoint](https://github.com/eclipse/capella-cybersecurity/wiki) for more advanced and detailed threat modelling using Capella, following the [ARCADIA method](https://en.wikipedia.org/wiki/Arcadia_(engineering)).
+
+For more information, we refer the reader to our CPSSA report, published as part of the knowledge base elements of C5-DEC. In our CPSSA report, in addition to providing a literature review, we describe our threat modelling and security risk assessment method adapted to the Common Criteria, while building on best practices and well-established methods such as the hybrid method developed by the software engineering institute (SEI) of Carnegie Mellon University (CMU).
+
+CPSSA features currently planned for future development and releases of the C5-DEC CAD component include export of assets for direct use by threagile and the [TRICK Service](https://www.trickservice.com/) web application for risk management.
\ No newline at end of file
diff --git a/docs/manual/cryptography.md b/docs/manual/cryptography.md
new file mode 100644
index 0000000..9acdaed
--- /dev/null
+++ b/docs/manual/cryptography.md
@@ -0,0 +1,11 @@
+# Cryptography
+
+Cryptography-related features of C5-DEC CAD are not implemented for the current Alpha release, however, the following functions are included in our backlog candidates and are on the roadmap.
+
+- Integration of one or more public-key encryption algorithms using a PQC solution, selected either from the NIST PQC 2022 selected algorithms or the ENISA post-quantum cryptography integration study of October 2022 by Daniel J. Bernstein (djb), Tanja Lange et al.
+
+- Integration of a feature for cryptographically signing individual files and verifying digital signatures, e.g., via OpenPGP, to verify the authenticity of a file, with an additional option to sign using a digital signature algorithm either from NIST PQC 2022 selected algorithms or the ENISA post-quantum cryptography integration study October 2022.
+
+In the meantime, we recommend using the well-known OpenPGP suite, and for the more technically proficient users, we recommend the suite of cryptographic software developed by Daniel J. Bernstein et al., e.g., [NACL](https://nacl.cr.yp.to/), [libpqcrypto](https://libpqcrypto.org/); it is also worth mentioning the [Open Quantum Safe](https://openquantumsafe.org/) project.
+
+Our future implementations will be building on such endeavors, but with a preference for building on top of verified cryptographic implementations, e.g., see [EverCrypt](https://www.microsoft.com/en-us/research/publication/evercrypt-a-fast-veri%EF%AC%81ed-cross-platform-cryptographic-provider/) and [HACL*](https://hacl-star.github.io/HaclValeEverCrypt.html).
\ No newline at end of file
diff --git a/docs/manual/installation.md b/docs/manual/installation.md
new file mode 100644
index 0000000..cbb893c
--- /dev/null
+++ b/docs/manual/installation.md
@@ -0,0 +1,110 @@
+# Installation
+
+C5-DEC CAD requires Python 3 and Git, the distributed version control system. Once Python is installed, install C5-DEC CAD using one of the following methods.
+
+## Requirements
+
+- [Python 3](https://www.python.org/)
+- [git](https://git-scm.com/), the distributed version control system
+
+### Optional
+
+- Doorstop (recommended to install via `pipx`)
+
+Strictly speaking, a Doorstop installation is not required; nevertheless, we strongly recommend installing Doorstop such that it can be used in combination with C5-DEC CAD. This is mainly due to the fact that the SSDLC module in the current implementation of C5-DEC CAD does not provide a full coverage of the Doorstop API, which is why users may find it easier to carry out certain complementary operations using Doorstop.
+
+To install Doorstop, we recommend the following method using [pipx](https://pypa.github.io/pipx/) as it is rather straightforward. Once `pipx` is installed, simply run the following command:
+```sh
+$ pipx install doorstop==3.0b10
+```
+
+## GNU/Linux
+
+On most modern GNU/Linux distributions Python 3.8 or above comes already preinstalled.
+
+Open a terminal (e.g., bash, Zsh) and execute the following commands:
+
+```sh
+python3 -m pip install --user pipx
+python3 -m pipx ensurepath
+```
+
+### Install C5-DEC using pipx
+
+Open a terminal and run the following command, assuming that the Wheel distribution file (.whl) is placed in the current directory:
+```sh
+pipx install ./c5dec--py3-none-any.whl
+```
+
+where can be in the following form: X.Y[.Z], e.g., 0.1, 0.2, 1.0, 1.1.2, 2.0, 2.2.1, etc.
+
+### Launching C5-DEC
+
+You can start C5-DEC CAD by simply entering “c5dec” in an open terminal, with the current directory being an unpacked copy of the C5-DEC CAD [project folder]().
+
+## MacOS
+
+Install Python 3.8 or above if not already available.
+
+Open a terminal (e.g., bash, Zsh) and execute the following commands:
+
+```sh
+python3 -m pip install --user pipx
+python3 -m pipx ensurepath
+```
+
+### Install C5-DEC using pipx
+
+Open a terminal and run the following command, assuming that the Wheel distribution file (.whl) is placed in the current directory:
+
+```sh
+pipx install ./c5dec--py3-none-any.whl
+```
+
+where can be in the following form: X.Y[.Z], e.g., 0.1, 0.2, 1.0, 1.1.2, 2.0, 2.2.1, etc.
+
+### Launching C5-DEC
+
+You can start C5-DEC CAD by simply entering “c5dec” in an open terminal, with the current directory being an unpacked copy of the C5-DEC CAD [project folder]().
+
+## Windows
+
+### Install Python
+
+1. Launch the “Microsoft Store” application from the Windows Start Menu.
+1. Search for Python in the Microsoft Store search bar and select Python 3.8, or any version higher than or equal to 3.8 and smaller than Python 3.12.
+1. Press the “Get” or “Install” button as shown in the screenshot below.
+
+
+
+
+### Install pipx
+
+Open a terminal and execute the following commands:
+
+```sh
+python3 -m pip install --user pipx
+python3 -m pipx ensurepath
+```
+
+### Install C5-DEC using pipx
+
+Open a terminal and run the following command, assuming that the Wheel distribution file (.whl) is placed in the current directory:
+
+```sh
+pipx install .\c5dec--py3-none-any.whl
+```
+
+where can be in the following form: X.Y[.Z], e.g., 0.1, 0.2, 1.0, 1.1.2, 2.0, 2.2.1, etc.
+
+You can download the latest distribution file (.whl) from the GitHub repository of C5-DEC CAD.
+
+### Launching C5-DEC
+
+You can simply start C5-DEC by entering “c5dec” in an open terminal or by double-clicking the “run-c5dec” batch file found in the C5-DEC distribution folder.
+
+
+
+## Setting up the C5-DEC containerized environment
+
+See the _Getting started_ section in the [README](../../README.md#getting-started) page.
\ No newline at end of file
diff --git a/docs/manual/isms.md b/docs/manual/isms.md
new file mode 100644
index 0000000..e0f891c
--- /dev/null
+++ b/docs/manual/isms.md
@@ -0,0 +1,40 @@
+# Information Security Management System (ISMS)
+
+Roughly speaking, this module is aimed at providing functionality that enhances activities related to the ISO/IEC 27000 series of standards for organizationals security, often referred to as an Information Security Management System as a whole.
+
+## Activity report
+
+The activity report function allows the user to get an overview of all files that have been created or modified during a certain time period. To achieve this, the user is expected to specify the number of past hours, days and months, along with an absolute path to a folder, which are then taken as input to scan the indicated folder recursively and compile a list of all modified files for the indicated duration in the past.
+
+The user can also specify the name of a specific user to filter the returned results for that specific user; the convention used in the current version relies on a three-letter acronym for names, e.g., Evariste Galois (ega), Pierre de Fermat (pfe) and Carl Friedrich Gauss (cfg) shown in the example below. This means that for the tool to be able to retrieve and filter results, the file names are expected to have the user acryonm appended to the end of the file name.
+
+
+
+## Document list assistant
+
+The document list assistant allows the user to check whether or not all documents stored in a given folder (or within any of its subfolders) are tracked in a given document list spreadsheet. It requires the column header storing the file name to be provided as input, as shown below.
+
+
+
+### Assumptions
+
+This function assumes the presence of a sheet in the referenced spreadsheet named "DocList"; this hardcoded requirement will be removed in a future release.
+
+## MS Word tag processor
+
+This, rather specific feature allows the user to replace all tags in an MS Word document with hyperlinks pointing to a URL specified in an auxiliary CSV input file, that maps tags to URLs (see the example provided in the zipped archive).
+
+
+
+### Assumptions
+
+The expected tag format simply requires the tags to start with the "#" symbol, e.g., "tag-to-link-mapping.csv":
+
+```sh
+#S-1-24, https://github.com
+#S-61-21, https://scholar.google.com
+```
+
+## Universal file/folder management automation
+
+This function is currently unavailable and planned for a future release. In the meantime, we recommend the open-source solution called [organize](https://github.com/tfeldmann/organize), a CLI program implemented fully in Python that can be easily installed using pipx and used as a CLI; see its [official documentation](https://organize.readthedocs.io/en/latest/) for more details.
\ No newline at end of file
diff --git a/docs/manual/overview.md b/docs/manual/overview.md
new file mode 100644
index 0000000..4c1b1d1
--- /dev/null
+++ b/docs/manual/overview.md
@@ -0,0 +1,33 @@
+# C5-DEC CAD User Manual
+
+## Table of contents
+
+- [Installation](./installation.md)
+- [Setup](./setup.md)
+- [Quick start](./start.md)
+- [CCT: Common Criteria Toolbox](./cct.md)
+- [SSDLC: secure software development life cycle](./ssdlc.md)
+- [Cryptography](./cryptography.md)
+- [CPSSA: Cyber-Physical System Security Assessment](./cpssa.md)
+- [Transformer: import, export, publish](./transformer.md)
+- [ISMS: document management](./isms.md)
+- [PM: project (resource) management](./pm.md)
+- [C5-DEC Common Criteria wiki](../../c5dec/assets/database/KnowledgeBase/0_MapofContent.md)
+
+## Overview
+
+C5-DEC, short for "Common Criteria for Cybersecurity, Cryptography, Clouds – Design, Evaluation and Certification", is a subproject of the CyFORT project, in turn short for "Cloud Cybersecurity Fortress of Open Resources and Tools for Resilience".
+
+C5-DEC consists of two key elements: a software component and a knowledge base including guides and a wiki of key CC concepts. These elements complement each other to form a coherent set of tools aimed at supporting activities related to CC certification, secure software development life cycle and security assessment of cyber-physical systems.
+
+One of the goals of C5-DEC is carrying out impartial assessments of the security of computer systems and software according to the Common Criteria (CC), a set of internationally recognized standards (ISO/IEC 15408), and the complementary methodology ISO/IEC 18045, dealing with a common methodology for computer security evaluation (CEM). CC certification gives users the assurance that a product satisfies the security guarantees and properties it claims to possess.
+
+The CC and CEM are complex resources resulting from the efforts of several countries since 1980, and present an extensive catalogue of security requirements and a challenging methodology. The certification processes, involving vendors/developers and evaluation laboratories, are often costly and lengthy.
+
+The Common Criteria Toolbox (CCT) of C5-DEC is aimed at making these procedures more accessible and efficient, assisting analysts and designers in the design and evaluation of system/product-oriented information security with a comprehensive CC database and a CC browser for navigating and filtering specific parts of the DB in a targeted manner. The CCT also assist evaluators in the creation of evaluation checklists and ffor tracking the evaluation progress.
+
+The SSDLC module of C5-DEC CAD aims at assisting with the development of secure software; this module supports the creation, storage and interconnection of requirements, architecture models, technical specifications, source code, test specifications, test execution reports and potentially other artifacts, within the same repository and using the same set of tools to allow for complete traceability.
+
+Moreover, the C5-DEC methodology for secure software development life cycle (SSDLC) and a guide for Cyber-Physical System Security Assessment (CPSSA) form part of the C5-DEC knowledge base, and are supported by the SSDLC module of C5-DEC CAD.
+
+Note that to fully implement the C5-DEC method described in the SSDLC and CPSSA reports, C5-DEC integrates and relies on other open-source solutions (e.g. doorstop-dev, OpenProject, GitLab, threagile, ADTool, Capella Darc Viewpoint, and Threat Dragon) for some of its features such as requirements and artifacts management, system design and testing, project (resource) management, DevSecOps, threat modeling, and security risk assessment.
diff --git a/docs/manual/pm.md b/docs/manual/pm.md
new file mode 100644
index 0000000..17708b1
--- /dev/null
+++ b/docs/manual/pm.md
@@ -0,0 +1,52 @@
+# Project resource management
+
+## OpenProject time report assistant
+
+The OpenProject time report assistant mini app enables the user to convert OpenProject time report exports to a user-defined format.
+
+
+
+It suffices to point the tool to the absolute path where the to-be-formatted OpenProject exported file is stored. Upon conversion, C5-DEC CAD stores the modified copy in the current folder.
+
+
+
+Also, note that the algorithm can generate starte and end timestamps and store them in the output file. To make use of this feature, the user would have to enter the start time (enclosed in curly braces) in the Comment field of the time logging pop-up window of OpenProject, e.g., for an input "\{14:00\}" and a logged duration of 1 hour, the converter will populate the start time field with "14:00" and the end time filed with "15:00".
+
+### Auxiliary configuration files
+
+- Note that the algorithm makes use of a JSON configuration file providing a mapping between full names and their corresponding algorithms, which can be found under the `assets` folder, in the `persons.json` file under "acronyms".
+
+- A second configuration file in the form of a comma-separated value (CSV) file, called `openproject_params.csv`, is used to define, among other things, the mapping of project names extracted from OpenProject, tracked via the "WP" column, for work package. The mapping is resolved according to user-defined "Type" and "Domain" entries per project. The data schema determining the final output format can be found in the `tshformat.json` file. Both these configuration files are stored in the `./assets/tshparams` folder.
+
+Note that in the current version, the consolidation algorithm takes the "ALab-TSH-params" entry from the `tshformat.json` file; the various column titles can be changed, but the schema cannot as the algorithm relies on this specific structure. In a future release, we intend to update this functionality and allow for custom-defined layouts specified by the user.
+
+## Time report consolidation assistant
+
+The time report assistant submodule is a mini app that deals with consolidating/merging, filtering, and cleaning raw time report data, the format of which can be defined in the TSH schema configuration file. The default schema is that of IAL (i.e., itrust + Abstractions Lab).
+The instructions below describe how to use this mini app.
+
+First, navigate to the “PM: project management” module, depicted in the figure below, by selecting the corresponding menu item, either using the keyboard arrow keys and pressing enter or by simply left clicking using the mouse.
+
+
+
+Next, select the “Time report assistant” menu item once you have entered the PM menu, as shown below.
+
+
+
+Finally, once you have entered the “Time report assistant” mini app interface, shown above, provide the following input parameters and press the “< Consolidate time reports >” button to trigger the consolidation algorithm.
+
+- **Path to folder containing time reports**: simply copy-paste the file system path to the folder in which you have added copies of all the time reports/sheets that you wish to consolidate. Note that if you use the “Copy as path” option on Windows, accessed by pressing shift + right click on a folder or file, the surrounding quotes (i.e., “”) must be removed.
+- **Apply filters?** If you select this menu item, the consolidation algorithm will consider the filtering options specified below, e.g., date range, field and filed value to apply filtering for. If this choice is not selected, all filtering options are disabled, and the algorithm consolidates all the input timesheet files in their entirety into a single file.
+- **From date**: specifies the start date indicating the beginning of the date interval that is to be extracted by the consolidation (in the current version only the month value is considered).
+- **To date**: specifies the date indicating the end of the date interval that is to be extracted by the consolidation (in the current version only the month value is considered).
+- **Field to filter + field value to filter**: specified the column/field that is to be filtered for, e.g., if “Domain/Project name” is selected, the consolidated time report will only contain entries that have a “Domain/Project name” value specified in the “Field value to filter” option.
+- **Clear fields**: the < clear fields > button simply clears/deletes the folder path specified in the first text field.
+
+Once the consolidation is finished, if executed successfully, the resulting output Excel file can be found in the same “C5-DEC” folder containing the assets folder, from which C5-DEC is executed, automatically named as follows:
+
+- “consolidated-TSH--.xlsx”, with an example provided below:
+ - consolidated-TSH-20230930-131452.xlsx
+
+## Auxiliary configuration files for consolidation
+
+See [the previous configuration files section](#auxiliary-configuration-files).
\ No newline at end of file
diff --git a/docs/manual/setup.md b/docs/manual/setup.md
new file mode 100644
index 0000000..ac14df5
--- /dev/null
+++ b/docs/manual/setup.md
@@ -0,0 +1,22 @@
+# Setup
+
+In order to successfully launch C5-DEC CAD, simply unpack the "C5DEC-setup" folder and rename it as you see fit; the folder name does not play a role in the correct execution of C5-DEC CAD, but for the sake of this guide, we assume the folder is simply named "c5dec".
+
+The unzipped archive comes with an "assets" folder containing:
+- a series of configuration files
+- a Common Criteria wiki
+- the entire Common Criteria data stored in dedicated YAML files, with the content encoded in Markdown and all these files being in turn managed by doorstop under the hood.
+
+For the current Alpha release, the user is expected to launch the `c5dec` command from within the unpacked folder, i.e., changing directory to the unpacked (and possibly renamed) folder and then running the `c5dec` command.
+
+We intend to add an installer in a future release to automate the above mentioned steps.
+
+## Git repository
+
+C5-DEC CAD assumes the presence of an existing git repository within its installation folder (i.e., the unpacked folder). For convenience, we include an already prepared repository that comes with the same zip archive.
+
+## Usage assumptions
+
+For the Alpha version of the C5-DEC release, the following assumptions hold:
+
+- There is a single git repository within the C5-DEC CAD installation folder.
\ No newline at end of file
diff --git a/docs/manual/ssdlc.md b/docs/manual/ssdlc.md
new file mode 100644
index 0000000..f8f901e
--- /dev/null
+++ b/docs/manual/ssdlc.md
@@ -0,0 +1,65 @@
+# Secure Software Development Life Cycle
+
+Since the SSDLC mini app exposed via the C5-DEC CAD TUI makes use of the doorstop API, it is strongly recommended to consult the official [doorstop documentation](https://doorstop.readthedocs.io/en/latest/) to gain a better understanding of the underlying concepts that the SSDLC module builds on.
+
+The secure software development life cycle (SSDLC) module supports three main functions by building on top of the open-source doorstop API:
+
+- Software artifact management such as repository creation, editing, deletion, e.g., separate and dedicated doorstop documents for storing mission requirements, technical specifications, source code, test case specifications, test report items (test execution result), etc.
+
+- Artifact item management including artifact creation, editing and deletion, e.g., for individual requirements, test case (TC) specifications and source code files in their corresponding documents
+
+- Artifact item relation management allowing the creation and removal of links between arbitrary items (e.g., TC to requirement, TC to soure code), as well as browsing linked items and their content, for a selected artifact item
+
+- Managing artifact repository structure such as suspect link resolution, and review status updates
+
+## Quick start guide
+
+Once you have installed C5-DEC, the SSDLC module can be accessed via the TUI, i.e., by simplying entering `c5dec` via the terminal, without any additional parameters.
+
+In order to access the SSDLC functionality, navigate to the corresponding menu item shown on the landing page of C5-DEC CAD, namely "2 - SSDLC: secure software development life cycle", as shown in the screenshot below.
+
+
+
+## Managing artifact collections
+
+Select the "Manage artifact repositories" submenu to access its artifact collection/repository creation and deletion features, shown below.
+
+
+
+Once the artifact management submenu is loaded, you can enter a prefix for the document/repository and also specify a parent prefix in case the document you are about to create should be considered a child node in the artifact document tree.
+
+In the example shown below, we specify `srs` for system/software requirements specification, which is a child document of `mrs`, which is short for Mission Requirements Specifications. This means that the artifact items added to `srs` will be linked to parent `mrs` items.
+
+
+
+The create and delete buttons depicted in the screenshot are self-explanatory; the reset fields button acts as a shortcut for quickly clearing the content of the text fields.
+
+## Managing artifact items
+
+Once the artifact management submenu is loaded, the user can create new artifact items and edit existing ones. Artifact items can range from requirement specifications to test cases, test report items and design diagrams.
+
+
+
+By simply entering a document prefix, e.g., `mrs` referring to mission requirements specification, new `mrs` items can be created, with an ID being generated and assigned to the created item automatically. In the example shown here, the user can edit the content of `mrs1` by entering its ID and pressing the "Show item text" button. Once the content has been modified, the user must press the "Save item text" for the change to be saved to disk.
+
+## Managing relations
+
+The "Manage item relations" submenu allows the user to create new relations between artifact items, e.g., linking an `mrs` item to an `srs` one, or linking a test case to its corresponding requirements. The same submenu also allows the user to remove or delete existing links. Moreover, the "Show child item links" button prints out the existing child items of a given parent artifact item.
+
+### Creating and removing links
+
+To create a new link, simply enter the IDs of the child and parent item, respectively, and press the "create link" or "remove link" buttons to confirm the desired operation.
+
+
+
+### Viewing existing child items
+
+Pressing the "Show child item links" button results in retrieving items linked to an item specified via its ID, as shown below. Upon selecting a linked item, its content is displayed in the right-hand side text box.
+
+
+
+## Managing artifact document structure and item status
+
+This submenu, shown below, allows the user to trigger the doorstop operations for reordering, clearing and reviewing; see the official doorstop documentation for its [reordering](https://doorstop.readthedocs.io/en/latest/cli/reordering/) and [validation](https://doorstop.readthedocs.io/en/latest/cli/validation/) commands.
+
+
\ No newline at end of file
diff --git a/docs/manual/start.md b/docs/manual/start.md
new file mode 100644
index 0000000..e5e2cc3
--- /dev/null
+++ b/docs/manual/start.md
@@ -0,0 +1,65 @@
+# Quick start
+
+In order to launch the application, either type “c5dec” in the terminal or if you are using Windows, simply double-click the “run-c5dec” batch file found in the distribution folder.
+
+Users can interact with C5-DEC CAD through three different interfaces, namely a native textual user interface (TUI) and command line interface (CLI) provided by C5-DEC CAD, along with various graphical user interfaces (GUI) such as VS Code, any web browser (Mozilla Firefox, Google Chrome, etc.) or Zettlr.
+
+By design, C5-DEC CAD uses open data formats and specifications, thereby allowing the use of a wide range of already existing open-source tools. For instance, by building on top of open-source solutions such as doorstop and pandoc and non-proprietary data storage formats such as YAML, Markdown, LaTeX, PlantUML, JSON, csv, etc. project files maintained and processed using C5-DEC CAD can be also edited, formatted, exported and viewed using existing tools such as web browsers and VS Code.
+
+## TUI: Textual User Interface
+
+Most of the features of C5-DEC CAD are currently exposed via its TUI. To launch the TUI, simply either run the `c5dec` command from the terminal or if you are using Windows, double-click the “run-c5dec” batch file.
+
+This would launch the TUI front-end, shown below.
+
+
+
+### Navigating the TUI
+
+You can navigate the TUI and move between menus and submenus using the mouse or the keyboard as follows:
+
+- Arrow keys (left, down, up, right): to change the current selection, i.e., for menus, buttons, text fields, etc.
+- Tab key: to hop from one widget or visual object to another, e.g., in the CCT browser, to move the focus from the explorer to other buttons
+- Enter key: press enter/return to confirm the current selection
+
+## CLI: Command Line Interface
+
+To run the CLI, simply append the command (and subcommands) to the C5-DEC launch command. You can access the help/manual of the CLI by using the -h parameter.
+
+```sh
+c5dec -h
+```
+
+This would print out a help menu similar to the one shown below.
+
+
+
+## GUI: Graphical User Interface
+
+While there may be many GUI candidates, we recommend the following options:
+
+### Visual Studio Code
+
+The popular, open-source and lightweight source code editor [Visual Studio (VS) Code](https://code.visualstudio.com/) by Microsoft is a natural candidate when it comes to choosing a graphical front-end. This is largely motivated by the following observations:
+
+- Highly extensible: The VS Code Extensions feature allows it to provide dedicated support for several features of C5-DEC CAD, e.g., Markdown and YAML editing, linters, diagramming plugins
+- Built-in source control support for git
+- Built-in Markdown viewers
+- Official extension by Microsoft for containerized development, making further development of C5-DEC CAD quite straightforward given the already existing configuration files provided by the C5-DEC CAD repository
+
+The screenshot below provides an example of how VS Code can be used to enhance the C5-DEC experience: the project files processed using C5-DEC CAD are easily accessible and can be navigated via the VS Code explorer, documentation in Markdown previewed by the viewer on the right and an instance of C5-DEC CAD itself executed and running through the VS Code terminal, allowing the user to make changes using VS Code tools and extensions together with C5-DEC CAD.
+
+
+
+### Zettlr
+
+While there are many knowledge-base management and note taking tools using Markdown as the underlying storage format, we recommend [Zettlr](https://www.zettlr.com/) due to its being entirely open source and integration with other technologies and formats being central to C5-DEC, namely its integration of pandoc powering its import and export features and support for LaTeX and linking capabilities.
+
+
+
+
+Thanks to its native usage of pandoc, Zettlr can provide a more accessible interface for converting and exporting to various formats such as LaTeX, docx,etc.
+
+### Firefox
+
+While any web browser can be used to view the published outcomes of C5-DEC CAD, which in turn invokes the native publishing command of doorstop, we recommend Mozilla Firefox.
\ No newline at end of file
diff --git a/docs/manual/transformer.md b/docs/manual/transformer.md
new file mode 100644
index 0000000..5ce5d4d
--- /dev/null
+++ b/docs/manual/transformer.md
@@ -0,0 +1,27 @@
+# Transformer
+
+The transformer module is currently aimed at importing, exporting and publishing content managed via the SSDLC module, which in turn builds on doorstop. Therefore, the three currently implemented functions, i.e., import, export and publish, act as a front-end to doorstop.
+
+## Import SSDLC data
+
+The import function can be used not only to import new content into a project repository managed by C5-DEC CAD, but it can also be used to temporarily move content out of the doorstop data store, modify it and have it imported back into the data store, thereby overwriting the content, e.g., exporting requirements to xlsx so they can be edited in MS Excel and then migrated back to the project repository. This is a front-end for invoking the [doorstop import](https://doorstop.readthedocs.io/en/latest/cli/interchange/) function.
+
+
+
+## Export SSDLC data
+
+The export function follows the same logic as above, just in reverse.
+
+
+
+## Publish SSDLC data
+
+The publish function can be used for viewing purposes and end-user analysis, navigation, etc. it can export to HTML, plain text (.txt), Markdown and LaTeX; it acts as a front-end to [doorstop publishing](https://doorstop.readthedocs.io/en/latest/cli/publishing/).
+
+
+
+## Convert data
+
+The convert data function is currently not implemented, but it is on the roadmap and part of the backlog candidates. The TUI component is however implemented, showcasing the currently planned feature. In the meantime, a similar functionality can be achieved by using Zettlr or pandoc directly. Users can also use the C5-DEC documentation engine (DocEngine), which is still under development; further details can be found in the corresponding entry on the Abstractions Lab GitHub page.
+
+
\ No newline at end of file
diff --git a/docs/reqs/mrs/.doorstop.yml b/docs/reqs/mrs/.doorstop.yml
new file mode 100644
index 0000000..d8d6e14
--- /dev/null
+++ b/docs/reqs/mrs/.doorstop.yml
@@ -0,0 +1,29 @@
+settings:
+ digits: 3
+ prefix: MRS
+ sep: '-'
+attributes:
+ defaults:
+ type: 'F'
+ vm: 'T'
+ rationale: "See mission analysis"
+ importance: "3"
+ urgency: "3"
+ risk: "1"
+ difficulty: "1"
+ reviewed:
+ - type
+ - vm
+ - rationale
+ - importance
+ - urgency
+ - risk
+ - difficulty
+ publish:
+ - type
+ - vm
+ - rationale
+ - importance
+ - urgency
+ - risk
+ - difficulty
\ No newline at end of file
diff --git a/docs/reqs/mrs/MRS-001.yml b/docs/reqs/mrs/MRS-001.yml
new file mode 100644
index 0000000..c2a5374
--- /dev/null
+++ b/docs/reqs/mrs/MRS-001.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 1
+links: []
+normative: true
+rationale: Efficiency and programmable diagram generation
+ref: ''
+reviewed: GLtxZ-9RMx5YWDSg6GEL8WZP8_9JSIPvu3Gc_CUGIPY=
+risk: 1
+text: |
+ The C5-DEC software SHALL integrate at least one open-source tool allowing users to create diagrams from a plain text language, e.g., PlantUML, Mermaid.
+type: F
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-002.yml b/docs/reqs/mrs/MRS-002.yml
new file mode 100644
index 0000000..1ac1024
--- /dev/null
+++ b/docs/reqs/mrs/MRS-002.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 2
+links: []
+normative: true
+rationale: To facilitate interlinking of assets
+ref: ''
+reviewed: k0lhAJJx5CGZKFFoQ642ubuGR9RHkrRszmg3JMxUFM8=
+risk: 1
+text: |
+ The C5-DEC software SHALL store textual requirements, test case definitions and design diagrams alongside source code in the same repository.
+type: F
+urgency: 5
+vm: T
diff --git a/docs/reqs/mrs/MRS-003.yml b/docs/reqs/mrs/MRS-003.yml
new file mode 100644
index 0000000..0f76967
--- /dev/null
+++ b/docs/reqs/mrs/MRS-003.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 3
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: qmKbETTl3eXCNHKFr0-F5HFssRoUdagVVVDvfnLVgK0=
+risk: 1
+text: |
+ The C5-DEC software SHALL store system artifact specifications (e.g., requirements, test cases, design diagram), created using its own suite of tools, in an open file format.
+type: F
+urgency: 5
+vm: T
diff --git a/docs/reqs/mrs/MRS-004.yml b/docs/reqs/mrs/MRS-004.yml
new file mode 100644
index 0000000..648116e
--- /dev/null
+++ b/docs/reqs/mrs/MRS-004.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 4
+links: []
+normative: true
+rationale: To ensure traceability
+ref: ''
+reviewed: RJJoMNLoIJ89tmxX6JYe4AFYWP718Uhvgmxk9-d6qvE=
+risk: 1
+text: |
+ The C5-DEC software SHALL identify all its stored artifacts using a unique identifier.
+type: F
+urgency: 5
+vm: T
diff --git a/docs/reqs/mrs/MRS-005.yml b/docs/reqs/mrs/MRS-005.yml
new file mode 100644
index 0000000..d08627a
--- /dev/null
+++ b/docs/reqs/mrs/MRS-005.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 5
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: pl-8uczD38cOUejaR9GsMV-LE2hTMJwJAkXAm2ge1Pc=
+risk: 1
+text: |
+ The C5-DEC software SHALL integrate an open-source solution for requirements engineering and requirements management.
+type: F
+urgency: 5
+vm: T
diff --git a/docs/reqs/mrs/MRS-006.yml b/docs/reqs/mrs/MRS-006.yml
new file mode 100644
index 0000000..7756396
--- /dev/null
+++ b/docs/reqs/mrs/MRS-006.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 6
+links: []
+normative: true
+rationale: To facilitate interlinking
+ref: ''
+reviewed: riewDe9AHm85JP-0_S3EU7uisxmsXwqtYADX7mjeysI=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide a feature for linking system artifacts with one another based on the artifacts’ respective IDs.
+type: F
+urgency: 5
+vm: T
diff --git a/docs/reqs/mrs/MRS-007.yml b/docs/reqs/mrs/MRS-007.yml
new file mode 100644
index 0000000..1fd02b9
--- /dev/null
+++ b/docs/reqs/mrs/MRS-007.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 7
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: yJiWlS4OV3FbzUjsfEbEzvoWMkZuJ-mn7PxmC9aWt54=
+risk: 1
+text: |
+ The C5-DEC software SHALL use a distributed version control system for the storage of its artifacts to track changes in its files/artifacts.
+type: F
+urgency: 5
+vm: R
diff --git a/docs/reqs/mrs/MRS-008.yml b/docs/reqs/mrs/MRS-008.yml
new file mode 100644
index 0000000..54a7f4c
--- /dev/null
+++ b/docs/reqs/mrs/MRS-008.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 8
+links: []
+normative: true
+rationale: Maturity, features, widely available tool support and documentation
+ref: ''
+reviewed: A9fs9zyX5jr508skvLtm-yLv4E7rQICBM_JLJlsOXYs=
+risk: 1
+text: |
+ The C5-DEC software SHOULD use the git version control software.
+type: F
+urgency: 5
+vm: R
diff --git a/docs/reqs/mrs/MRS-009.yml b/docs/reqs/mrs/MRS-009.yml
new file mode 100644
index 0000000..dcc34a4
--- /dev/null
+++ b/docs/reqs/mrs/MRS-009.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 9
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: FUiAzbF19iQTFzjMVos3U3h0xr5o0kZtO4EztCjPzoU=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide a requirements management functionality that can create requirement hierarchies.
+type: F
+urgency: 5
+vm: T
diff --git a/docs/reqs/mrs/MRS-010.yml b/docs/reqs/mrs/MRS-010.yml
new file mode 100644
index 0000000..9a7185d
--- /dev/null
+++ b/docs/reqs/mrs/MRS-010.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 10
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: oCDf1cbQMWEWb5dqlyP4vS8bycjAyA8qxRX68GFdkfE=
+risk: 1
+text: |2
+ The C5-DEC software SHALL provide requirements traceability.
+type: F
+urgency: 5
+vm: T
diff --git a/docs/reqs/mrs/MRS-011.yml b/docs/reqs/mrs/MRS-011.yml
new file mode 100644
index 0000000..39c1770
--- /dev/null
+++ b/docs/reqs/mrs/MRS-011.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 11
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: 2I3hEbfIpxOmYTQhxmXrgySp8koMf5t14Tlc8jjtLPQ=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide a V&V feature for creating test cases/procedures and generating test reports.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-012.yml b/docs/reqs/mrs/MRS-012.yml
new file mode 100644
index 0000000..e9f224d
--- /dev/null
+++ b/docs/reqs/mrs/MRS-012.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 12
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: BwaXe3Qt7OlsaE5P1N4hdxc_uB-pvzm-6f2A1McoMww=
+risk: 1
+text: |
+ The C5-DEC software MAY integrate an open-source testing framework/solution.
+type: F
+urgency: 5
+vm: R
diff --git a/docs/reqs/mrs/MRS-013.yml b/docs/reqs/mrs/MRS-013.yml
new file mode 100644
index 0000000..407da40
--- /dev/null
+++ b/docs/reqs/mrs/MRS-013.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 13
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: KW9GtoSvCrzhhobUetWPDLGpTJKdu7yryo2YDPa5fIs=
+risk: 1
+text: |
+ The C5-DEC software SHOULD allow the user to add/attach labels or tags to its artifacts, e.g., TC, REQ, DIA, etc.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-014.yml b/docs/reqs/mrs/MRS-014.yml
new file mode 100644
index 0000000..ce27940
--- /dev/null
+++ b/docs/reqs/mrs/MRS-014.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 14
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: VGuJE24e5SnczrSGFj9e2OtUXOTTTliu58RF5CG3C4Y=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide a project management feature for converting time reports generated by OpenProject to a tabular format defined by the user.
+type: F
+urgency: 4
+vm: T
diff --git a/docs/reqs/mrs/MRS-015.yml b/docs/reqs/mrs/MRS-015.yml
new file mode 100644
index 0000000..f284c2e
--- /dev/null
+++ b/docs/reqs/mrs/MRS-015.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 15
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: y8bQcfWtEzf6Am2_XsdbS47wzfxMVTm5MNUPHUl0nME=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide a PM feature for consolidating and merging individual time reports/sheets into a single time report.
+type: F
+urgency: 4
+vm: T
diff --git a/docs/reqs/mrs/MRS-016.yml b/docs/reqs/mrs/MRS-016.yml
new file mode 100644
index 0000000..f8785ec
--- /dev/null
+++ b/docs/reqs/mrs/MRS-016.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 2
+level: 16
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: y_ZJ7OiLxEiLugCJuVCMBOPVS0vR9W-3R_epVfYkIT4=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide an ISMS feature for verifying the presence of the content of a folder in a document list tracking the said content.
+type: F
+urgency: 2
+vm: T
diff --git a/docs/reqs/mrs/MRS-017.yml b/docs/reqs/mrs/MRS-017.yml
new file mode 100644
index 0000000..af091f8
--- /dev/null
+++ b/docs/reqs/mrs/MRS-017.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 17
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: -wwBD43VU-UTqTo7c1WR_PxHkDpTNV4SxWfXWT74fc8=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide import and export functions that can import and export all its artifacts from and to using at least one open file format, e.g., CSV, JSON, Markdown, etc.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-018.yml b/docs/reqs/mrs/MRS-018.yml
new file mode 100644
index 0000000..2610936
--- /dev/null
+++ b/docs/reqs/mrs/MRS-018.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 18
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: CeriBwUqqS6vjk0DTERrlYeYtKrJrUXzw_5micUWlbc=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide a collaboration feature or an option for integrating with an existing platform that allows the users of the C5-DEC software to access and share artifacts managed by the C5-DEC software.
+type: F
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-019.yml b/docs/reqs/mrs/MRS-019.yml
new file mode 100644
index 0000000..9c6626c
--- /dev/null
+++ b/docs/reqs/mrs/MRS-019.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 19
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: okk24mUpS6pRMDB7gJmZIReuzdEKIjur6JKwBD2oKMg=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide user management, including user creation, editing and deletion.
+type: F
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-020.yml b/docs/reqs/mrs/MRS-020.yml
new file mode 100644
index 0000000..79992ad
--- /dev/null
+++ b/docs/reqs/mrs/MRS-020.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 20
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: 7KgePQQEBsHtuLdo71R5FCmI2oBcRq-34IGxyzNlOwk=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide user authentication.
+type: F
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-021.yml b/docs/reqs/mrs/MRS-021.yml
new file mode 100644
index 0000000..bcb6839
--- /dev/null
+++ b/docs/reqs/mrs/MRS-021.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 21
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: ke3FFpf8MMSIKke5nbLVqUnxuvTlwZ7hxbdlAAuIBLo=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide user authorization.
+type: F
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-022.yml b/docs/reqs/mrs/MRS-022.yml
new file mode 100644
index 0000000..0c84d28
--- /dev/null
+++ b/docs/reqs/mrs/MRS-022.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 22
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: hSk0SGAEwVODOm7xT0ieExT9I9rUUTApnqRPxrO4S2Q=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide access control that can provide at least two types of asset access restriction: admin and standard user.
+type: F
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-023.yml b/docs/reqs/mrs/MRS-023.yml
new file mode 100644
index 0000000..7ea57ab
--- /dev/null
+++ b/docs/reqs/mrs/MRS-023.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 23
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: LJ9kG5ml5AY-pRJqP6WixXqZ29YsfYtBQaW80oLKvws=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide web-based sharing of assets.
+type: F
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-024.yml b/docs/reqs/mrs/MRS-024.yml
new file mode 100644
index 0000000..79d0afe
--- /dev/null
+++ b/docs/reqs/mrs/MRS-024.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 3
+level: 24
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: m7SmHeOcR9Xgt8mrqGEigPBbBGNeS8OC3tRs79yPZiY=
+risk: 1
+text: |
+ The C5-DEC software SHOULD provide a feature for performing cryptographic secret sharing, based on Shamir's secret sharing algorithm.
+type: F
+urgency: 2
+vm: T
diff --git a/docs/reqs/mrs/MRS-025.yml b/docs/reqs/mrs/MRS-025.yml
new file mode 100644
index 0000000..07b5bc3
--- /dev/null
+++ b/docs/reqs/mrs/MRS-025.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 3
+level: 25
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: 3FyBs3ZMpHV1GoqSOhTBOCPDvw2FHr1ThhiJdYpsjKg=
+risk: 1
+text: |
+ The C5-DEC software SHOULD provide a feature for computing a hash function, using SHA256, over a given a file to verify the integrity of this file by comparing the resulting hash digest value with a reference value.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-026.yml b/docs/reqs/mrs/MRS-026.yml
new file mode 100644
index 0000000..f0728cd
--- /dev/null
+++ b/docs/reqs/mrs/MRS-026.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 26
+links: []
+normative: true
+rationale: Project constraints and assumptions, system overview
+ref: ''
+reviewed: MNUc-QOcNCzeJQeWJsOobDXF3bMfZjIiCctpy88MrOs=
+risk: 1
+text: |
+ The C5-DEC software SHALL implement the modules specified in the project constraints and assumptions and the system overview, with the baseline features specified in the project constraints description.
+type: F
+urgency: 3
+vm: R
diff --git a/docs/reqs/mrs/MRS-027.yml b/docs/reqs/mrs/MRS-027.yml
new file mode 100644
index 0000000..d9e29d3
--- /dev/null
+++ b/docs/reqs/mrs/MRS-027.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 1
+level: 27
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: T-uFBOq-PTh2_sgWLq6R_qO_Pm15HI7KleCFZtbJ0po=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide a feature for linking requirements and test cases to specific lines or definitions (e.g., function, class) in source code by using annotations that encode the corresponding requirement or test case ID.
+type: F
+urgency: 1
+vm: T
diff --git a/docs/reqs/mrs/MRS-028.yml b/docs/reqs/mrs/MRS-028.yml
new file mode 100644
index 0000000..dcd813c
--- /dev/null
+++ b/docs/reqs/mrs/MRS-028.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 28
+links: []
+normative: true
+rationale: Ease of use and efficiency
+ref: ''
+reviewed: 0wMvZpsI0k0abBN1wlwFJsYu7ztiq1DPVOWZXeE1SRs=
+risk: 1
+text: |
+ The C5-DEC software SHOULD allow the user to search and filter requirements using full-text search and all requirement attributes.
+type: F
+urgency: 1
+vm: T
diff --git a/docs/reqs/mrs/MRS-029.yml b/docs/reqs/mrs/MRS-029.yml
new file mode 100644
index 0000000..afcba09
--- /dev/null
+++ b/docs/reqs/mrs/MRS-029.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 29
+links: []
+normative: true
+rationale: Ease of use and efficiency
+ref: ''
+reviewed: r6jJG4rEs2-64LSsU96EBJuy5Re3Evzh0HlxBipWmNY=
+risk: 1
+text: |
+ The C5-DEC software SHOULD allow the user to search and filter artifacts using labels or tags.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-030.yml b/docs/reqs/mrs/MRS-030.yml
new file mode 100644
index 0000000..57d4784
--- /dev/null
+++ b/docs/reqs/mrs/MRS-030.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 30
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: WD1oJQp095vxiYGs3qr31riG3NJviA8QU4IdXlf8gEk=
+risk: 1
+text: |
+ The C5-DEC software SHALL include a feature in its Common Criteria Toolbox (CC) that can store SFRs/SARs in the same open file format used for storing all other artifacts.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-031.yml b/docs/reqs/mrs/MRS-031.yml
new file mode 100644
index 0000000..b381d4d
--- /dev/null
+++ b/docs/reqs/mrs/MRS-031.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 31
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: t4wvjokO3-NpNr3SXdQDybt8NrlIFRLv1unOyvw2JC8=
+risk: 1
+text: |
+ The C5-DEC software MAY integrate an open-source threat modelling solution.
+type: F
+urgency: 3
+vm: R
diff --git a/docs/reqs/mrs/MRS-032.yml b/docs/reqs/mrs/MRS-032.yml
new file mode 100644
index 0000000..d1e8c3e
--- /dev/null
+++ b/docs/reqs/mrs/MRS-032.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 32
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+risk: 1
+text: |
+ The C5-DEC software SHALL provide a Common Criteria Toolbox (CCT) implementation satisfying the requirements stated in the C5-DEC CCM.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-033.yml b/docs/reqs/mrs/MRS-033.yml
new file mode 100644
index 0000000..23bba99
--- /dev/null
+++ b/docs/reqs/mrs/MRS-033.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 33
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: zIjnOXAvRLpMgdxhtSgdj0H9dIeRqqxRcPClVM-kzAU=
+risk: 1
+text: |
+ The C5-DEC software SHOULD either provide a threat modelling and analysis tool as part of the CPSSA module, based on the TM method described in the C5-DEC SSDLC and the C5-DEC CPSSA reports/guides or alternatively use data formats that do not prevent the use of already existing open-source solutions mentioned in the CPSSA report.
+type: F
+urgency: 3
+vm: R
diff --git a/docs/reqs/mrs/MRS-034.yml b/docs/reqs/mrs/MRS-034.yml
new file mode 100644
index 0000000..6426bb3
--- /dev/null
+++ b/docs/reqs/mrs/MRS-034.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 34
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: ivuQLUIWuzo4Q53bHnCid1Bw-Cz-XqCXVqkfMnymdUM=
+risk: 1
+text: |
+ The C5-DEC software SHOULD provide a feature for extracting user specified design assets (specified in design artifacts such as diagrams or a plain text Markup language) and exporting these to an open file format.
+type: F
+urgency: 2
+vm: T
diff --git a/docs/reqs/mrs/MRS-035.yml b/docs/reqs/mrs/MRS-035.yml
new file mode 100644
index 0000000..fc73cc3
--- /dev/null
+++ b/docs/reqs/mrs/MRS-035.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 35
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: xsVu22U3bkZFgHM7IEgkHSQZUMdZNEnx7SdqO3ZmWE4=
+risk: 1
+text: |
+ The C5-DEC software SHOULD either provide a risk management tool supporting the features described in the C5-DEC CCM or integrate an existing open-source solution.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-036.yml b/docs/reqs/mrs/MRS-036.yml
new file mode 100644
index 0000000..efb0df7
--- /dev/null
+++ b/docs/reqs/mrs/MRS-036.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: 3
+header: ''
+importance: 3
+level: 36
+links: []
+normative: true
+rationale: See Mission Analysis; risk related to availability
+ref: ''
+reviewed: CxmX-BEQNEemhvaifcx9we-Nm6qRgHv4EsJ1WvKMGvg=
+risk: 3
+text: |
+ The CC toolbox SHOULD store all Security Functional Classes, Security Assurance Classes, Evaluation Activities, and Packages, in a structured human and machine-readable format in the C5-DEC document-based data store.
+type: F
+urgency: 2
+vm: T
diff --git a/docs/reqs/mrs/MRS-037.yml b/docs/reqs/mrs/MRS-037.yml
new file mode 100644
index 0000000..35b81f8
--- /dev/null
+++ b/docs/reqs/mrs/MRS-037.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 37
+links: []
+normative: true
+rationale: See Mission Analysis; risk related to change in XML DTD
+ref: ''
+reviewed: sTsOMoKcRA4kWLCFswtK4SFJw0s7GRkTbYYZq6AueM4=
+risk: 3
+text: |
+ The CC toolbox SHOULD adopt a storage format that maintains a mapping to the available CC XML-file and that can be validated against the corresponding DTD file, either directly via a 1-to-1 mapping between CCT DB of CC and the official CC XML or through a reference file providing the mapping.
+type: F
+urgency: 1
+vm: T
diff --git a/docs/reqs/mrs/MRS-038.yml b/docs/reqs/mrs/MRS-038.yml
new file mode 100644
index 0000000..a6dc2d7
--- /dev/null
+++ b/docs/reqs/mrs/MRS-038.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 3
+level: 38
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: smY3JefrNiff-qIXQNAbGN5SM-7Ld1IQvC2baR25d18=
+risk: 3
+text: |
+ The CC toolbox SHOULD be able to automatically transform content from and to the CC defined XML format, relative to the C5-DEC custom data storage format.
+type: F
+urgency: 1
+vm: T
diff --git a/docs/reqs/mrs/MRS-039.yml b/docs/reqs/mrs/MRS-039.yml
new file mode 100644
index 0000000..06d9681
--- /dev/null
+++ b/docs/reqs/mrs/MRS-039.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 39
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: 8xhYVAyPmji-K5yhEpzeIKcrkqUI9ePplGaL5n2E-jo=
+risk: 1
+text: |
+ The CC toolbox SHALL maintain a Common Criteria Knowledge Base consisting of explanatory definitions and user guidance for CC Terms and Definitions, Concepts, and Core Constructs.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-040.yml b/docs/reqs/mrs/MRS-040.yml
new file mode 100644
index 0000000..69a2a52
--- /dev/null
+++ b/docs/reqs/mrs/MRS-040.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 2
+level: 40
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: jqwFH-P3Qx4REe8gp25Ql74vvsWy5f1n3U-K4vdW4BI=
+risk: 1
+text: |
+ The CC toolbox MAY include a CC forum and FAQ, complementing its Knowledge Base.
+type: F
+urgency: 2
+vm: T
diff --git a/docs/reqs/mrs/MRS-041.yml b/docs/reqs/mrs/MRS-041.yml
new file mode 100644
index 0000000..62d3466
--- /dev/null
+++ b/docs/reqs/mrs/MRS-041.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 41
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: FMqJAO209uF5E_OKNIXpfpbOWgQz9vS2EA-8lBf912A=
+risk: 1
+text: |
+ The CC toolbox SHOULD provide a database of generic threats, risks, and countermeasures.
+type: F
+urgency: 2
+vm: T
diff --git a/docs/reqs/mrs/MRS-042.yml b/docs/reqs/mrs/MRS-042.yml
new file mode 100644
index 0000000..ad6e2cd
--- /dev/null
+++ b/docs/reqs/mrs/MRS-042.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 3
+level: 42
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: lCGZ1IFVqu017jWx0T9oYyu3E7uDBsQX-0oxL799P34=
+risk: 1
+text: |
+ The CC toolbox DB of threats, risks and countermeasures MAY include content from the BSI Grundschutz, ISO 27005, NIST SPs and the CC.
+type: F
+urgency: 2
+vm: T
diff --git a/docs/reqs/mrs/MRS-043.yml b/docs/reqs/mrs/MRS-043.yml
new file mode 100644
index 0000000..7ed540c
--- /dev/null
+++ b/docs/reqs/mrs/MRS-043.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 3
+level: 43
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: nUykKj5kzIjP2NUIFlvWFsfNR5Dk1bMI6Dchi_iIpRE=
+risk: 1
+text: |
+ The CC toolbox SHOULD provide means of automation for the generation of ORs and ETRs used during and as a result of CC CEM-based security evaluation.
+type: F
+urgency: 1
+vm: T
diff --git a/docs/reqs/mrs/MRS-044.yml b/docs/reqs/mrs/MRS-044.yml
new file mode 100644
index 0000000..bcd2b6d
--- /dev/null
+++ b/docs/reqs/mrs/MRS-044.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 3
+level: 44
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: 2lpi84S-DbG-OkdOMMQ39vgc2UhtM6PvjNhjY0Xsu3Y=
+risk: 1
+text: |
+ Based on the C5-DEC CPSSA report of the C5-DEC knowledge base, the CC toolbox SHOULD provide a support mechanism for generating additional evaluation evidence required by the EUCC and provide guides for tailoring existing evaluation evidence to be conformant with EUCC requirements.
+type: F
+urgency: 1
+vm: T
diff --git a/docs/reqs/mrs/MRS-045.yml b/docs/reqs/mrs/MRS-045.yml
new file mode 100644
index 0000000..cca4d31
--- /dev/null
+++ b/docs/reqs/mrs/MRS-045.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 3
+level: 45
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: 3RdX0NaWSV_etkp5zqcIa1t8qGt1ySNf3wRjl0zvE-k=
+risk: 1
+text: |
+ The CC toolbox SHOULD store the generic Security Objectives defined by Article 51 of the CSA.
+type: F
+urgency: 1
+vm: T
diff --git a/docs/reqs/mrs/MRS-046.yml b/docs/reqs/mrs/MRS-046.yml
new file mode 100644
index 0000000..c1216fe
--- /dev/null
+++ b/docs/reqs/mrs/MRS-046.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 46
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: POkTStmeTpBjT_UVg6G9uMKvdSV7NPC2NKdtGYOQubk=
+risk: 1
+text: |
+ The C5-DEC software MAY provide a feature for cryptographically signing individual files and verifying digital signatures using GPG to verify the authenticity of a file, with an additional option to sign using a digital signature algorithm either from NIST PQC 2022 selected algorithms or the ENISA post-quantum cryptography integration study October 2022.
+type: F
+urgency: 3
+vm: T
diff --git a/docs/reqs/mrs/MRS-047.yml b/docs/reqs/mrs/MRS-047.yml
new file mode 100644
index 0000000..8436aa0
--- /dev/null
+++ b/docs/reqs/mrs/MRS-047.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 3
+level: 47
+links: []
+normative: true
+rationale: See Mission Analysis.
+ref: ''
+reviewed: fDMrtcZnvFmlCouSnQ7tDq7F-incJpyhp2GVnI_9EPI=
+risk: 4
+text: |
+ The C5-DEC software MAY provide a feature for public-key encryption using a PQC algorithm, selected either from the NIST PQC 2022 selected algorithms or the ENISA post-quantum cryptography integration study October 2022.
+type: F
+urgency: 2
+vm: T
diff --git a/docs/reqs/mrs/MRS-048.yml b/docs/reqs/mrs/MRS-048.yml
new file mode 100644
index 0000000..1eaa1f1
--- /dev/null
+++ b/docs/reqs/mrs/MRS-048.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 48
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: w2ckQTRSnPnUew94fO8Pp9Pa_6cGEkw2K1hkwuEgkzQ=
+risk: 1
+text: |
+ The C5-DEC knowledge base SHALL include a dedicated Software Development Plan Model (SDPM).
+type: C
+urgency: 5
+vm: R
diff --git a/docs/reqs/mrs/MRS-049.yml b/docs/reqs/mrs/MRS-049.yml
new file mode 100644
index 0000000..64c6113
--- /dev/null
+++ b/docs/reqs/mrs/MRS-049.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 49
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: I0obavCcsmjtIbGEhV17AWFdUyx9faiSNG-r7QFvxCw=
+risk: 1
+text: |
+ The C5-DEC knowledge base SHALL include a Verification & Validation Plan Model (VVPM).
+type: C
+urgency: 5
+vm: R
diff --git a/docs/reqs/mrs/MRS-050.yml b/docs/reqs/mrs/MRS-050.yml
new file mode 100644
index 0000000..307bd5f
--- /dev/null
+++ b/docs/reqs/mrs/MRS-050.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 50
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: frRX8lkpR1hccb0geqXLBeAeGylbAsJomR86cb8sKX4=
+risk: 1
+text: |
+ The C5-DEC knowledge base SHALL include a Software Project Management Model (SPMM).
+type: C
+urgency: 5
+vm: R
diff --git a/docs/reqs/mrs/MRS-051.yml b/docs/reqs/mrs/MRS-051.yml
new file mode 100644
index 0000000..0886c77
--- /dev/null
+++ b/docs/reqs/mrs/MRS-051.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 51
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: FAfTy_j7yUBUCRLL7LYtz-jnn2Z0Vy6Sjc7jirSGHXk=
+risk: 1
+text: |
+ The C5-DEC knowledge base SHALL include a secure SDLC (SSDLC) publication addressing secure software/system development.
+type: C
+urgency: 5
+vm: R
diff --git a/docs/reqs/mrs/MRS-052.yml b/docs/reqs/mrs/MRS-052.yml
new file mode 100644
index 0000000..fe9f45d
--- /dev/null
+++ b/docs/reqs/mrs/MRS-052.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 52
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: -hghp22TjZA6Vz3B_a6jgqJBGT5Xim4qxE8JHyfNfxA=
+risk: 1
+text: |
+ The CPSSA component of the C5-DEC knowledge base SHALL include a Common Criteria model (CCM) describing how the C5-DEC software approaches tool support for CC.
+type: C
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-053.yml b/docs/reqs/mrs/MRS-053.yml
new file mode 100644
index 0000000..96ac3c0
--- /dev/null
+++ b/docs/reqs/mrs/MRS-053.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 53
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: hH1BOxsxqL7gqcXVVQlq03aDkjjLO_6EB3F9g4I0Sy4=
+risk: 1
+text: |
+ The C5-DEC knowledge base SHALL include a CC-inspired Threat Modelling Model (CC-TMM).
+type: C
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-054.yml b/docs/reqs/mrs/MRS-054.yml
new file mode 100644
index 0000000..3e93070
--- /dev/null
+++ b/docs/reqs/mrs/MRS-054.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 54
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: hsrYhAEKcsZhJR4D-hnYN_MzhNbY5gOOmC_jtvdhhAY=
+risk: 1
+text: |
+ The CPSSA report of the C5-DEC knowledge base SHALL include a system/product-oriented (Cyber)Security Risk Management method and a Security Risk Assessment (SRA) Model.
+type: C
+urgency: 3
+vm: R
diff --git a/docs/reqs/mrs/MRS-055.yml b/docs/reqs/mrs/MRS-055.yml
new file mode 100644
index 0000000..63cbc88
--- /dev/null
+++ b/docs/reqs/mrs/MRS-055.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 4
+level: 55
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+reviewed: 170X_04gCc9dZmaqVWbxq6N4LfKUhgGniwmIs33xeVY=
+risk: 1
+text: |
+ The CCM SHALL define CC-related activities complementing the C5-DEC SSDLC.
+type: C
+urgency: 3
+vm: R
diff --git a/docs/reqs/mrs/MRS-056.yml b/docs/reqs/mrs/MRS-056.yml
new file mode 100644
index 0000000..9e91031
--- /dev/null
+++ b/docs/reqs/mrs/MRS-056.yml
@@ -0,0 +1,18 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 56
+links: []
+normative: true
+rationale: |
+ Portability, interoperability, easy & effective integration in version control
+ref: ''
+reviewed: Qcdudv5PMmbXc6_3wpWvJ-ZcFBroXhLQsGXnx3jUW8k=
+risk: 1
+text: |
+ The C5-DEC software SHALL use a persistent NoSQL, document-oriented data store for storing all artifacts created or imported using the C5-DEC software.
+type: A
+urgency: 5
+vm: T
diff --git a/docs/reqs/mrs/MRS-057.yml b/docs/reqs/mrs/MRS-057.yml
new file mode 100644
index 0000000..29a6663
--- /dev/null
+++ b/docs/reqs/mrs/MRS-057.yml
@@ -0,0 +1,18 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 57
+links: []
+normative: true
+rationale: |
+ To build on existing well-established solutions and cut unneeded effort
+ref: ''
+reviewed: ki_Un6O63lAkQgd1ZOOfELgp1cz4Mf7YMIW4nIzJIpw=
+risk: 1
+text: |
+ The C5-DEC software SHALL make use of a web-based software development platform (e.g., GitLab, GitHub) to enforce user management, access control, authentication, and authorization.
+type: A
+urgency: 5
+vm: R
diff --git a/docs/reqs/mrs/MRS-058.yml b/docs/reqs/mrs/MRS-058.yml
new file mode 100644
index 0000000..504df7c
--- /dev/null
+++ b/docs/reqs/mrs/MRS-058.yml
@@ -0,0 +1,32 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 58
+links: []
+normative: true
+rationale: See Mission Analysis
+ref: ''
+references:
+- path: docs/sdd/image/cad_context_diagram.png
+ type: file
+- path: docs/sdd/image/functional_tree.png
+ type: file
+- path: docs/sdd/image/subsystems.png
+ type: file
+- path: docs/sdd/image/system_architecture.png
+ type: file
+- path: docs/sdd/image/packages.png
+ type: file
+- path: docs/sdd/image/classes.png
+ type: file
+- path: docs/sdd/image/cct_class_diagram.png
+ type: file
+reviewed: nGVr3RqkuJpMNIrTPi_yWdJiYQlAxouR-yjhKWe2S5w=
+risk: 1
+text: |
+ The C5-DEC software SHOULD follow a modular design.
+type: A
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-059.yml b/docs/reqs/mrs/MRS-059.yml
new file mode 100644
index 0000000..fd2040e
--- /dev/null
+++ b/docs/reqs/mrs/MRS-059.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 5
+level: 59
+links: []
+normative: true
+rationale: See Mission Analysis.
+ref: ''
+reviewed: 3JmBbHebtuOyzq6j7ZRAT5MdhtkGYWHGnSvX2ngJ4M0=
+risk: 1
+text: |
+ The C5-DEC software SHALL enforce user management, access control, authentication, and authorization.
+type: S
+urgency: 4
+vm: R
diff --git a/docs/reqs/mrs/MRS-060.yml b/docs/reqs/mrs/MRS-060.yml
new file mode 100644
index 0000000..5776eec
--- /dev/null
+++ b/docs/reqs/mrs/MRS-060.yml
@@ -0,0 +1,17 @@
+active: true
+derived: false
+difficulty: N/A
+header: ''
+importance: 3
+level: 60
+links: []
+normative: true
+rationale: See Mission Analysis.
+ref: ''
+reviewed: IdD6XtSj4UcK6mkvXPp9Lp8-wLLCHZMMirkxX3wvWo8=
+risk: 1
+text: |
+ The C5-DEC software SHOULD store assets selected for security risk assessment in a format that can be imported by the TRICK Service risk management web application.
+type: I
+urgency: 2
+vm: T
diff --git a/docs/reqs/srs/.doorstop.yml b/docs/reqs/srs/.doorstop.yml
new file mode 100644
index 0000000..6e6e5e1
--- /dev/null
+++ b/docs/reqs/srs/.doorstop.yml
@@ -0,0 +1,46 @@
+settings:
+ digits: 3
+ parent: MRS
+ prefix: SRS
+ sep: '-'
+attributes:
+ defaults:
+ author: ''
+ acceptance: ''
+ date: 'DD.MM.YYYY'
+ dependence: []
+ status: ''
+ importance: ''
+ urgency: ''
+ difficulty: ''
+ risk: ''
+ outlay: ''
+ type: ''
+ rationale: ''
+ version: ''
+ reviewed:
+ - author
+ - acceptance
+ - date
+ - dependence
+ - status
+ - importance
+ - urgency
+ - risk
+ - outlay
+ - type
+ - rationale
+ - version
+ publish:
+ - author
+ - acceptance
+ - date
+ - dependence
+ - status
+ - importance
+ - urgency
+ - risk
+ - outlay
+ - type
+ - rationale
+ - version
diff --git a/docs/reqs/srs/SRS-001.yml b/docs/reqs/srs/SRS-001.yml
new file mode 100644
index 0000000..515c9c2
--- /dev/null
+++ b/docs/reqs/srs/SRS-001.yml
@@ -0,0 +1,51 @@
+acceptance: "- General User can access the database. \n- General User can view and\
+ \ traverse the Common Criteria Security Components in their hierarchical structure.\
+ \ \n- General User can view content of each Security Component element. \n- General\
+ \ User can access detailed information about each Security Component Element such\
+ \ as hierarchies, dependencies, and parent-child relations. \n- General User can\
+ \ exit the database at any time.\n"
+active: true
+author: Heinrich
+date: 13.09.2023
+dependence: []
+derived: false
+difficulty: '1'
+header: |
+ Access and Browse Database for CC Security Components
+importance: '5'
+level: 1.0
+links:
+- MRS-030: WD1oJQp095vxiYGs3qr31riG3NJviA8QU4IdXlf8gEk=
+- MRS-036: CxmX-BEQNEemhvaifcx9we-Nm6qRgHv4EsJ1WvKMGvg=
+normative: true
+outlay: '2'
+rationale: "Security Components are of core relevance in the CC process. Efficient\
+ \ browsing of these will \nsignificantly ease the process of identifying Security\
+ \ Components appropriate for the project.\n"
+ref: ''
+reviewed: TaH57zLbZ8QKrrB2-YRkaJ4FzgT4WUAspv55JA8dLQ8=
+risk: '1'
+status: In Progress
+text: |
+ As a General User, I want to access and browse the database so that I can identify Common Criteria
+ Security Components relevant to my project.
+
+ Assuming I am logged in as an authorized user:
+
+ 1. I access the database containing the CC Security Components
+ 2. Then I should be able to see the Security Class Types _Assurance_ and _Functional_.
+ 3. When I select a Security Class Type the list of all respective Security Classes is displayed.
+ 4. Then I should be able return to the Security Class Type selection (see Step 5) or to select a
+ Security Class (see Step 6).
+ 5. When I return to the Security Class Type selection, I resume to Step 2.
+ 6. When I select a Security Class, I should be able to see the content of the Security Class,
+ and the list of Security Families pertaining to that Security Class.
+ 7. Then I should be able to return to the list of Security Classes (see Step 8) or select a
+ Security Family (see Step 9).
+ 8. When I return to the list of Security Classes, I resume to Step 4.
+ 9. Repeat Steps 5 to 7 traversing the hierarchical structure until a Security Requirement is
+ reached.
+ 10. At any time I am able to exit the database.
+type: F
+urgency: '5'
+version: '0.1'
diff --git a/docs/reqs/srs/SRS-002.yml b/docs/reqs/srs/SRS-002.yml
new file mode 100644
index 0000000..38f7740
--- /dev/null
+++ b/docs/reqs/srs/SRS-002.yml
@@ -0,0 +1,44 @@
+acceptance: "- General User can access the database.\n- General User can define full-text\
+ \ and/or attributes queries to search the database. \n- General User is successfully\
+ \ presented with search matches in descending order, from best to worst. \n- General\
+ \ User can select a match to view the respective Security Component Element. \n\
+ - General User can traverse the Security Component structure. \n- General User can\
+ \ define a new query. \n- General User can exit the database at any time.\n"
+active: true
+author: Heinrich
+date: 13.09.2023
+dependence:
+- SRS-001
+derived: false
+difficulty: '1'
+header: |
+ Query the Database of Security Components.
+importance: '3'
+level: 18.1
+links:
+- MRS-028: 0wMvZpsI0k0abBN1wlwFJsYu7ztiq1DPVOWZXeE1SRs=
+- MRS-030: WD1oJQp095vxiYGs3qr31riG3NJviA8QU4IdXlf8gEk=
+- MRS-036: CxmX-BEQNEemhvaifcx9we-Nm6qRgHv4EsJ1WvKMGvg=
+normative: true
+outlay: '2'
+rationale: |
+ In addition to the browsing option, the General User should be able to query the database for keywords, further enhancing the identification process.
+ref: ''
+reviewed: 4eLOu-GinDrl6xM0qRM192G2j-JOZZItoJmnwkkdIbo=
+risk: '1'
+status: In Progress
+text: |
+ As a General User, I want to search and filter the database for Security Component Elements using full-text search and/or attributes.
+
+ Assuming I am logged in as an authorized user:
+
+ 1. I access the database containing the CC Security Components.
+ 2. Then I am able to define a query and search the database.
+ 3. When I query the database I am provided with best matching results in descending order, from best to worst.
+ 4. When I select a match, the respective Security Component Element is shown.
+ 5. Then I can traverse the Security Component structure as defined in SRS-001 or define a new query.
+ 6. When I define a new query, I resume to Step 3.
+ 7. At all times I am able to exit the database.
+type: F
+urgency: '3'
+version: '0.1'
diff --git a/docs/reqs/srs/SRS-003.yml b/docs/reqs/srs/SRS-003.yml
new file mode 100644
index 0000000..aa925db
--- /dev/null
+++ b/docs/reqs/srs/SRS-003.yml
@@ -0,0 +1,49 @@
+acceptance: |
+ - Developer can specify or select a set of Security Components
+ - Selection is automatically validated in terms of the components' hierarchical and dependency relationships.
+ - Respective Security Requirements are correctly exported according to the defined settings.
+active: true
+author: Heinrich
+date: 13.09.2023
+dependence:
+- SRS-001
+- SRS-002
+derived: false
+difficulty: ''
+header: |
+ Export Security Components
+importance: '3'
+level: 18.2
+links:
+- MRS-053: hH1BOxsxqL7gqcXVVQlq03aDkjjLO_6EB3F9g4I0Sy4=
+- MRS-055: 170X_04gCc9dZmaqVWbxq6N4LfKUhgGniwmIs33xeVY=
+normative: true
+outlay: ''
+rationale: ''
+ref: ''
+reviewed: 10hBEc1QLr_k1ONLRp9ETlmFYe0s6JvNjvk2xWXeOAs=
+risk: ''
+status: In Progress
+text: |
+ As a Developer, I want to be able to (select Security Components and) export (their respective)
+ Security Requirements into a file so that I can e.g. import them into my project's REM system.
+
+ Assuming that I am logged in as an authorized user:
+
+ 1. I access the database containing the CC Security Components
+ 2. Then I am able to specify or select a (set of) Security Component/s of type 'functional' and/or 'assurance'.
+ 3. When I specify or select a (set of) Security Component/s I expect the system to automatically assess the validatiy of
+ the selection in terms of consideration of hierarchical and dependency relationships and to display the result
+ 4. Then I am able to export the selected Security Components' Security Requirements.
+ 5. When I select the export option I expect the system to warn me in case of an invalid selection
+ 6. Then I am able to ignore the warning or adjust my selection.
+ 7. When I proceed I am able to (at least) define the
+ - filepath,
+ - filename,
+ - and format (csv, xlsx).
+ Additional customizability to ease export to project's REM system format is desirable.
+ 8. Then all Security Requirements of the selected Security Components are
+ exported to the defined filepath with the filename and in the defined format.
+type: F
+urgency: '3'
+version: '0.1'
diff --git a/docs/reqs/srs/SRS-004.yml b/docs/reqs/srs/SRS-004.yml
new file mode 100644
index 0000000..9ee213d
--- /dev/null
+++ b/docs/reqs/srs/SRS-004.yml
@@ -0,0 +1,56 @@
+acceptance: |
+ 1. The system successfully parses and validates Security Requirements against the DTD.
+ 2. The system allows manipulations of the requirement according to defined operations.
+ 3. The system provides options to select and edit operations as needed.
+ 6. The tailored requirement provides a detailed list of conducted operations and modifications.
+active: true
+author: Heinrich
+date: 13.09.2023
+dependence:
+- SRS-003
+derived: false
+difficulty: ''
+header: |
+ Tailor Security Requirements.
+importance: '3'
+level: 18.3
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-053: hH1BOxsxqL7gqcXVVQlq03aDkjjLO_6EB3F9g4I0Sy4=
+- MRS-055: 170X_04gCc9dZmaqVWbxq6N4LfKUhgGniwmIs33xeVY=
+normative: true
+outlay: ''
+rationale: |
+ Ensuring that the Security Requirements can be tailored in compliance with the Common Criteria is crucial for aligning the project’s needs with standardized security benchmarks. Facilitating a structured and traceable method of managing requirement modifications while maintaining an archival system of original requirements ensures auditability and adherence to the Common Criteria, particularly for PP/ST.
+ref: ''
+reviewed: 8Dyp5QQvq9ELXEZJbnFrw5XaUkKXDmu3Lwh99l7zFp0=
+risk: '1'
+status: Open
+text: |
+ As a Developer,
+ I want to tailor Security Requirements to my project's needs,
+ So that the tailoring process and the resultant Security Requirements comply with the Common Criteria.
+ Assuming I am logged in as an authorized user:
+
+ Option 1: Export tailoring
+
+ 1. I access the database containing the CC Security Components\n
+ 2. Then I am able to specify or select a (set of) Security Component/s of type 'functional' and/or 'assurance'.\n
+ 3. When I specify or select a (set of) Security Component/s I expect the system to automatically assess the validatiy of
+ the selection in terms of consideration of hierarchical and dependency relationships and to display the result\n
+ 4. Then I am able to export the selected Security Components' Security Requirements.\n
+ 5. When I proceed to export I will be able to iterate through all Security Requirements and tailor each\n
+ to my project's needs. \n
+ 6. Then the system tracks the changes made to the original Security Requirements and includes the Common Criteria \
+ required information in the exported file. \n
+
+ Option 2: Parse tailored Requirements
+
+ 1. I access the database containing the CC Security Components\n
+ 2. Then I am able to provide a (set of) tailored Security Requirement/s in (TBD) format\n
+ 3. When I provide a (set of) tailored Security Requirement/s the system is able to automatically validate made changes
+ and generate the Common Criteria required information for the tailored Security Requirement. \n
+ 4. Then I am able to export the provided (set of) tailored Security Requirement(s) with the additional information.\n
+type: F
+urgency: '3'
+version: '0.1'
diff --git a/docs/reqs/srs/SRS-014.yml b/docs/reqs/srs/SRS-014.yml
new file mode 100644
index 0000000..803028c
--- /dev/null
+++ b/docs/reqs/srs/SRS-014.yml
@@ -0,0 +1,41 @@
+acceptance: "- General User can access the Knowledge Base. \n- General User can view\
+ \ various sections or categories in the KB. \n- General User can view articles or\
+ \ topics under a selected section. \n- General User can navigate through articles\
+ \ and sections and exit at any time.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '2'
+header: |
+ Access and Navigation Through Knowledge Base
+importance: '4'
+level: 2.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-039: 8xhYVAyPmji-K5yhEpzeIKcrkqUI9ePplGaL5n2E-jo=
+normative: true
+outlay: '3'
+rationale: |
+ Facilitating smooth access and navigation through the KB ensures that users can
+ explore and understand the Common Criteria with ease, promoting effective usage
+ of the provided information.
+ref: ''
+reviewed: g-VGkH9mQsQKL7EyU6IQe9PWNga-Aqfhbeu5U-vTu6I=
+risk: '1'
+status: In Progress
+text: |
+ As a General User, I want to access and navigate through the Knowledge Base so
+ that I can effortlessly locate and explore information relevant to my needs.
+ Assuming I am on the Knowledge Base landing page:
+
+ 1. I access the Knowledge Base interface.
+ 2. Then I should see different sections/categories of the Knowledge Base.
+ 3. When I select a section, a list of relevant articles or topics is displayed.
+ 4. I can select an article or topic to view more details.
+ 5. I can navigate back to the previous article or to other sections at any point.
+ 6. At any time, I can exit the Knowledge Base.
+type: F
+urgency: '3'
+version: '0.2'
diff --git a/docs/reqs/srs/SRS-015.yml b/docs/reqs/srs/SRS-015.yml
new file mode 100644
index 0000000..cd0a208
--- /dev/null
+++ b/docs/reqs/srs/SRS-015.yml
@@ -0,0 +1,38 @@
+acceptance: "- Technical terms and acronyms within articles are clearly defined or\
+ \ explained. \n- Detailed explanation pages or dedicated pages are optionally available\
+ \ and accessible.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '2'
+header: |
+ Comprehensive and User-Friendly Explanations
+importance: '4'
+level: 3.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-039: 8xhYVAyPmji-K5yhEpzeIKcrkqUI9ePplGaL5n2E-jo=
+normative: true
+outlay: '2'
+rationale: "Providing user-friendly explanations will demystify the complex language\
+ \ of the \nCommon Criteria, making it accessible and understandable to a wider audience.\n"
+ref: ''
+reviewed: JZZnz4X5bXm3uE5559XAx-Foz8B1cRbwXFtXpnnMQ5Y=
+risk: '1'
+status: In Progress
+text: |
+ As a General User, I want to read comprehensive and user-friendly explanations of
+ technical terms and concepts so that I can understand the Common Criteria without
+ specialized prior knowledge.
+ Assuming I am viewing an Article in the Knowledge Base
+ 1. When I encounter a technical term or acronym, it should be clearly defined or
+ explained in layman’s terms.
+ 2. Optionally, a link to a detailed explanation or dedicated page for the term/acronym
+ is available.
+ 3. I can navigate to this detailed explanation Article, if available, and return to the
+ original content.
+type: F
+urgency: '3'
+version: '0.2'
diff --git a/docs/reqs/srs/SRS-016.yml b/docs/reqs/srs/SRS-016.yml
new file mode 100644
index 0000000..5d01906
--- /dev/null
+++ b/docs/reqs/srs/SRS-016.yml
@@ -0,0 +1,49 @@
+acceptance: |
+ - General User can navigate seamlessly between interconnected topics via cross-references
+ and hyperlinks, both in markdown and exported HTML format.
+ - No broken links are present, ensuring a consistent user experience and unhindered navigation.
+ - Links leading to not-yet-available content direct users to a standard placeholder article,
+ ensuring a consistent and clear message regarding upcoming content.
+ - User can return to the initial KA or navigate to related articles easily, with clear paths
+ to navigate back or explore further.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '2'
+header: |
+ Interconnected Framework and Seamless Navigation
+importance: '4'
+level: 4.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-039: 8xhYVAyPmji-K5yhEpzeIKcrkqUI9ePplGaL5n2E-jo=
+normative: true
+outlay: '3'
+rationale: |
+ A seamless and interconnected navigation system, which includes guidance to upcoming content
+ via a standard placeholder, ensures a clear, consistent, and enriching user experience
+ throughout the KB in both markdown and HTML formats.
+ref: ''
+reviewed: lriWlZXVN8RUO_EREjTIZmeR-NiwFiZzP959K7ZWTuY=
+risk: '1'
+status: In Progress
+text: |
+ As a General User, I want to traverse through interconnected Articles effortlessly via
+ cross-references and hyperlinks, in markdown or exported HTML format, so that I can
+ explore related concepts without difficulty.
+
+ Assuming I am viewing a Knowledge Article in the Knowledge Base:
+
+ 1. I see hyperlinks or cross-references that guide me to related topics or articles,
+ regardless of viewing format (markdown/HTML).
+ 2. Clicking a hyperlink navigates me to the related topic or article with no broken links
+ encountered.
+ 3. If a linked article is not available, the hyperlink directs me to a standard placeholder
+ article that communicates the upcoming availability of the desired content.
+ 4. I can easily navigate back to the initial article or to other interconnected topics,
+ with a clear and user-friendly navigation path.
+type: F
+urgency: '3'
+version: '0.3'
diff --git a/docs/reqs/srs/SRS-017.yml b/docs/reqs/srs/SRS-017.yml
new file mode 100644
index 0000000..34f1384
--- /dev/null
+++ b/docs/reqs/srs/SRS-017.yml
@@ -0,0 +1,37 @@
+acceptance: |
+ - Articles contain actionable guidance and best practices for implementing the Common Criteria.
+ - The guidance provided is pragmatic, offering step-by-step instructions or tangible advice for application.
+active: true
+author: Heinrich
+date: 13.09.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Availability of Pragmatic Guidance and Best Practices
+importance: '4'
+level: 5.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-039: 8xhYVAyPmji-K5yhEpzeIKcrkqUI9ePplGaL5n2E-jo=
+normative: true
+outlay: '3'
+rationale: |
+ Facilitating users with pragmatic guidance and best practices assists them in effectively implementing
+ the Common Criteria, bridging the gap between theory and practical application, and enhancing organizational
+ security practices.
+ref: ''
+reviewed: StjESDA5DqVYbRbH7PaF8pi8pxstkYTBK68VYe9AO0I=
+risk: '1'
+status: In Progress
+text: |
+ As a General User,
+ I want to access pragmatic guidance and best practices in the Knowledge Base
+ so that I can effectively implement the Common Criteria's requisites in a practical manner.
+ Assuming I am viewing an article or topic in the Knowledge Base
+ 1. The content includes actionable guidance and best practices related to the topic.
+ 2. The guidance is presented in a user-friendly manner, offering tangible steps or advice.
+ 3. I can navigate to related topics for additional information and guidance.
+type: F
+urgency: '3'
+version: '0.2'
diff --git a/docs/reqs/srs/SRS-018.yml b/docs/reqs/srs/SRS-018.yml
new file mode 100644
index 0000000..8fef1ce
--- /dev/null
+++ b/docs/reqs/srs/SRS-018.yml
@@ -0,0 +1,40 @@
+acceptance: "- The Knowledge Base articles are reviewed and updated with each new\
+ \ issuance of the Common Criteria.\n- A revision history or last-updated timestamp\
+ \ is visible to users to ensure transparency\n regarding the currency of the information.\n\
+ - Each article or general section of the Knowledge Base clearly states the version(s)\
+ \ of the \nCommon Criteria it is relevant to.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Continuous Updates and Assurance of Current Information
+importance: '4'
+level: 6.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-039: 8xhYVAyPmji-K5yhEpzeIKcrkqUI9ePplGaL5n2E-jo=
+normative: true
+outlay: '2'
+rationale: |
+ Ensuring that the Knowledge Base reflects the most recent information of the Common Criteria
+ guarantees users access to the most relevant and applicable insights.
+ref: ''
+reviewed: 7FrZtoLbeonRB-Ed0f3tt4NkBDUJutB17lPjh_750sI=
+risk: '1'
+status: In Progress
+text: |
+ As a General User, I want assurance that the information in the Knowledge Base is up-to-date
+ and relevant to specific CC versions, so that I can trust and effectively utilize the provided
+ insights.
+ Assuming I am viewing an article or topic in the Knowledge Base:
+ 1. I can see a timestamp or revision history indicating the last update or revision date.
+ 2. The content reflects the most current information of the Common Criteria.
+ 3. The articles or topics are reviewed and updated with each new release of the Common Criteria.
+ 4. The relevant CC version(s) are clearly indicated on the articles or within general sections
+ of the Knowledge Base.
+type: F
+urgency: '3'
+version: '0.2'
diff --git a/docs/reqs/srs/SRS-019.yml b/docs/reqs/srs/SRS-019.yml
new file mode 100644
index 0000000..4f31bf5
--- /dev/null
+++ b/docs/reqs/srs/SRS-019.yml
@@ -0,0 +1,38 @@
+acceptance: "- Multimedia elements such as images, videos, and interactive diagrams\
+ \ are embeddable in the\n Knowledge Articles.\n- Users can access and interact (if\
+ \ applicable) with the multimedia elements when viewing \nthrough markdown editors\
+ \ and in the exported HTML format.\n- Alternative descriptions for multimedia elements\
+ \ are present and accurately describe the \ncontent or function of the media.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-014
+derived: false
+difficulty: '3'
+header: |
+ Integration of Multimedia Elements in Knowledge Articles
+importance: '2'
+level: 7.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+normative: true
+outlay: '3'
+rationale: |
+ Embedding multimedia elements enhances learning experiences by catering to various learning styles and enriching textual content, thus increasing user engagement and understanding.
+ref: ''
+reviewed: 5HqsHP3GX5v3gV5IvzoMnBsTmy-j4RUHyD9Dxleozl8=
+risk: '1'
+status: Not Started
+text: |
+ As a Content Developer, I want to integrate multimedia elements in Knowledge Articles,
+ so that I can enhance the learning and user experience.
+ 1. When creating or editing a Knowledge Article, I should have the ability to embed multimedia
+ elements such as images, videos, and interactive diagrams.
+ 2. Then, these multimedia elements should be accessible and interactable (if applicable) when
+ viewing through markdown editors and in the exported HTML format.
+ 3. I should also be able to provide alternative descriptions for multimedia elements to ensure
+ accessibility.
+type: F
+urgency: '1'
+version: '0.1'
diff --git a/docs/reqs/srs/SRS-020.yml b/docs/reqs/srs/SRS-020.yml
new file mode 100644
index 0000000..dd5361c
--- /dev/null
+++ b/docs/reqs/srs/SRS-020.yml
@@ -0,0 +1,37 @@
+acceptance: "- Users can access an internal or external FAQ section via links embedded\
+ \ within the \nKnowledge Articles.\n- Links to the FAQ section are relevant, accurate,\
+ \ and guide users toward information pertinent\n to the Knowledge Article’s context.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-014
+derived: false
+difficulty: '2'
+header: |
+ Integrating Links to FAQ Section
+importance: '2'
+level: 8.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-040: jqwFH-P3Qx4REe8gp25Ql74vvsWy5f1n3U-K4vdW4BI=
+normative: true
+outlay: '2'
+rationale: "Providing direct links to an FAQ section allows users to quickly access\
+ \ concise, straightforward \nanswers to potential queries, enhancing user efficiency\
+ \ and satisfaction in interacting with the \nplatform.\n"
+ref: ''
+reviewed: O2QsKP_YQ_SkaMe8fFMUvBaKcaUnhTkFId06WufiltQ=
+risk: '1'
+status: Not Started
+text: |
+ As a General User, I want to have direct access to a relevant FAQ section from Knowledge Articles,
+ so that I can swiftly find concise answers to related questions.
+ 1. While reading a Knowledge Article, I should encounter links that direct me to an FAQ section.
+ 2. These links should be contextually relevant and provide additional, succinct information
+ pertaining to the content being read.
+ 3. Links should direct users to a placeholder page if the FAQ section is not yet developed or
+ available.
+type: F
+urgency: '2'
+version: '0.1'
diff --git a/docs/reqs/srs/SRS-021.yml b/docs/reqs/srs/SRS-021.yml
new file mode 100644
index 0000000..dd4a679
--- /dev/null
+++ b/docs/reqs/srs/SRS-021.yml
@@ -0,0 +1,39 @@
+acceptance: "- A prominently visible link to a CC-specific forum is available on the\
+ \ main page or navigation \n bar of the Knowledge Base.\n- Users can effortlessly\
+ \ navigate to the forum to participate in or view discussions related to \n CC\
+ \ topics.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-014
+derived: false
+difficulty: '1'
+header: |
+ Provision of General Link to a CC-Specific Forum
+importance: '2'
+level: 9.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-040: jqwFH-P3Qx4REe8gp25Ql74vvsWy5f1n3U-K4vdW4BI=
+normative: true
+outlay: '1'
+rationale: "A CC-specific forum enhances user engagement and community interaction\
+ \ by \nproviding a platform for discussions, knowledge-sharing, and collaborative\
+ \ problem-solving \nrelated to Common Criteria, without overcomplicating the navigation\
+ \ within the Knowledge Base.\n"
+ref: ''
+reviewed: 0DQkHEeHGY_PXaW1COOnIImhq8fn0nDIQ4nO2VvUwbE=
+risk: '1'
+status: Not Started
+text: |
+ As a General User, I want a straightforward way to access a CC-specific forum from the Knowledge Base,
+ so that I can explore, contribute to, and learn from discussions and interactions within a community
+ of CC practitioners and experts.
+ 1. When I am on the main page or any part of the Knowledge Base, I should easily identify and access
+ a link that navigates to a CC-specific forum.
+ 2. The link directs me to a forum where I can view and participate in discussions related to the
+ Common Criteria.
+type: F
+urgency: '2'
+version: '0.1'
diff --git a/docs/reqs/srs/SRS-022.yml b/docs/reqs/srs/SRS-022.yml
new file mode 100644
index 0000000..9aedd33
--- /dev/null
+++ b/docs/reqs/srs/SRS-022.yml
@@ -0,0 +1,36 @@
+acceptance: |
+ - The System is able to store the CC data model in a specific format.
+ - The stored format maintains a mapping to the available CC XML-file.
+ - The System can validate the stored data against the corresponding DTD file.
+ - The System preserves semantic relationships between CC concepts during storage and retrieval.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Data Storage and Format Mapping
+importance: '4'
+level: 10.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-037: sTsOMoKcRA4kWLCFswtK4SFJw0s7GRkTbYYZq6AueM4=
+normative: true
+outlay: '3'
+rationale: "Ensuring that the CC data model is stored and mapped accurately in a format\n\
+ that can be validated against the DTD file and maintains semantic relationships\n\
+ is critical for the integrity, reliability, and usability of the CC data. Accurate\n\
+ data storage and mapping are essential for ensuring that CC data retrieval, \nmodification,\
+ \ and usage within the system are correct and reliable.\n"
+ref: ''
+reviewed: E4mZDn_suHd6QyPkqGGF24D9F1CPM3M1NA_dsT32Uu8=
+risk: '3'
+status: In Progress
+text: |
+ As a System, ensure that the CC data model is stored in a format that maintains
+ a mapping to the available CC XML-file and can be validated against the
+ corresponding DTD file while preserving semantic relationships between CC concepts.
+type: F
+urgency: '1'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-023.yml b/docs/reqs/srs/SRS-023.yml
new file mode 100644
index 0000000..d19811d
--- /dev/null
+++ b/docs/reqs/srs/SRS-023.yml
@@ -0,0 +1,39 @@
+acceptance: "- The system can successfully transform content from CC defined XML format\
+ \ to an internal \nrepresentation.\n- The system can transform content from the\
+ \ internal representation back to the CC defined XML \nformat.\n- Consistency and\
+ \ coherence of the stored data and representations are maintained during \ntransformations.\n\
+ - Data transformations adhere to the defined mappings and respect the structural\
+ \ and semantic \nintegrity of the original CC XML format.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Bidirectional Transformation and Consistency
+importance: '3'
+level: 11.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-038: smY3JefrNiff-qIXQNAbGN5SM-7Ld1IQvC2baR25d18=
+normative: true
+outlay: '4'
+rationale: "The ability to perform bidirectional transformations between the internal\
+ \ data representation and \nthe CC defined XML format is crucial to facilitate data\
+ \ exchanges and modifications while \nmaintaining data integrity and consistency.\
+ \ Ensuring that the transformation processes are \naccurate and coherent safeguards\
+ \ the quality and reliability of the stored Common Criteria data,\nsupporting its\
+ \ effective usage and application.\n"
+ref: ''
+reviewed: 5nULUIO_HkkC13kNukabc_bejC_EqlELzUVNwyKcpRQ=
+risk: '3'
+status: In Progress
+text: |
+ As a Data Administrator/General User, I want the system to ensure the automatic transformation of content from and to the CC defined
+ XML format, so that I can trust that the data remains consistent and coherent across all stored data and
+ representations, ensuring that data retrievals, modifications, and other interactions with the
+ data are reliable and accurate.
+type: F
+urgency: '1'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-024.yml b/docs/reqs/srs/SRS-024.yml
new file mode 100644
index 0000000..d0faaf6
--- /dev/null
+++ b/docs/reqs/srs/SRS-024.yml
@@ -0,0 +1,39 @@
+acceptance: |
+ - The System provides a database that includes generic threats, risks, and countermeasures.
+ - The database can integrate content from BSI Grundschutz, ISO 27005, NIST SPs, and the CC.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Threats, Risks, and Countermeasures Database
+importance: '4'
+level: 12.0
+links:
+- MRS-041: FMqJAO209uF5E_OKNIXpfpbOWgQz9vS2EA-8lBf912A=
+- MRS-042: lCGZ1IFVqu017jWx0T9oYyu3E7uDBsQX-0oxL799P34=
+normative: true
+outlay: '4'
+rationale: "Maintaining a database that encompasses and integrates diverse and generic\
+ \ threats, risks, \nand countermeasures from different standardized sources (like\
+ \ BSI Grundschutz, ISO 27005, \nNIST SPs, and the CC) ensures that the system can\
+ \ provide a comprehensive and \nstandards-compliant set of data for users or other\
+ \ system components dealing with \nsecurity-related aspects. This centralized and\
+ \ integrated approach facilitates \nstreamlined, consistent, and efficient handling\
+ \ and mitigation of security-related concerns.\n"
+ref: ''
+reviewed: l3l4BQPjp03EuUuVG6QHu2s9FSiJ0PGAvp4T5janYTI=
+risk: '1'
+status: Open
+text: |
+ As a General User,I want the system to provide a database that encompasses generic threats,
+ risks, and countermeasures, so that I can leverage a comprehensive and integrated source of
+ security-related data that assimilates content from BSI Grundschutz, ISO 27005, NIST SPs, and
+ the CC, ensuring diverse and standards-compliant support for dealing with security
+ considerations in varied contexts.
+ 1. TBD
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-025.yml b/docs/reqs/srs/SRS-025.yml
new file mode 100644
index 0000000..d36a6ec
--- /dev/null
+++ b/docs/reqs/srs/SRS-025.yml
@@ -0,0 +1,39 @@
+acceptance: "- The System implements a mechanism that assists in generating additional\
+ \ evaluation evidence\n as required by the EUCC.\n- The System provides guides that\
+ \ assist in tailoring existing evaluation evidence to be \nconformant with EUCC\
+ \ requirements.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Support Mechanism for EUCC Additional Evaluation Evidence
+importance: '3'
+level: 13.0
+links:
+- MRS-044: 2lpi84S-DbG-OkdOMMQ39vgc2UhtM6PvjNhjY0Xsu3Y=
+normative: true
+outlay: '4'
+rationale: "Implementing a support mechanism that assists in generating additional\
+ \ evaluation evidence and \nguides for tailoring existing evidence to conform with\
+ \ EUCC requirements ensures that the system adheres to \nrelevant regulatory standards\
+ \ and efficiently navigates the EUCC evaluation process. This not only \nfosters\
+ \ compliance and mitigates regulatory risks but also enhances the robustness and\
+ \ credibility of \nthe system by aligning it with established European cybersecurity\
+ \ standards and practices.\n"
+ref: ''
+reviewed: ax5RJVN-TyHfMetOJWqI6EWKy7OT8bqsxeew3-dBb8w=
+risk: '1'
+status: Open
+text: |
+ As a Security Evaluator, I want the system to implement a support mechanism that assists in
+ generating additional evaluation evidence and provides guides for tailoring existing evaluation
+ evidence, so that I can ensure that all produced evidence is conformant with EUCC requirements and navigate
+ the EUCC evaluation process effectively and efficiently.
+
+ 1. TBA
+type: F
+urgency: '1'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-026.yml b/docs/reqs/srs/SRS-026.yml
new file mode 100644
index 0000000..9e10c4c
--- /dev/null
+++ b/docs/reqs/srs/SRS-026.yml
@@ -0,0 +1,38 @@
+acceptance: |
+ - The System stores generic Security Objectives as defined by Article 51 of the CSA.
+ - The stored Security Objectives are in a structured format.
+ - The stored Security Objectives are accessible and readable by both humans and machines.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Storing Generic Security Objectives of CSA Article 51
+importance: '3'
+level: 14.0
+links:
+- MRS-045: 3RdX0NaWSV_etkp5zqcIa1t8qGt1ySNf3wRjl0zvE-k=
+normative: true
+outlay: '3'
+rationale: "Ensuring the storage and accessibility of generic Security Objectives\
+ \ as defined by Article 51 of the CSA \nin a structured, human, and machine-readable\
+ \ format enables efficient retrieval, analysis, and utilization \nof the objectives\
+ \ for various purposes such as compliance checks, threat modeling, or security analysis.\
+ \ \nThis supports maintaining alignment with regulatory requirements and fosters\
+ \ a standardized approach towards \nhandling and considering CSA-defined security\
+ \ objectives in cybersecurity evaluation and management processes.\n"
+ref: ''
+reviewed: 1E1pcBWASnq1oCksjbgtkF89VoB0RYVdk1riKgAjSVM=
+risk: '1'
+status: Open
+text: |
+ As a Security Analyst,
+ I want the system to store and provide accessibility to the generic Security Objectives defined by Article 51 of the CSA,
+ So that I can efficiently retrieve, analyze, and utilize these objectives for compliance, evaluation, and management
+ processes in a manner that is interoperable with both human and automated (machine) activities and assessments.
+ 1. TBD.
+type: F
+urgency: '1'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-027.yml b/docs/reqs/srs/SRS-027.yml
new file mode 100644
index 0000000..f2507ed
--- /dev/null
+++ b/docs/reqs/srs/SRS-027.yml
@@ -0,0 +1,45 @@
+acceptance: "- User can store SFRs/SARs and all relevant CC artifacts and security\
+ \ elements in the CC toolbox.\n- All stored artifacts utilize the same open file\
+ \ format ensuring consistent data management.\n- Data for all elements (including\
+ \ Security Functional Classes, Security Assurance Classes, etc.) \nis stored in\
+ \ a structured, human and machine-readable format.\n- User can retrieve and manage\
+ \ the stored data efficiently without loss of integrity and structure.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Unified Storage Mechanism for CC Artifacts and Security Elements
+importance: '3'
+level: 15.0
+links:
+- MRS-030: WD1oJQp095vxiYGs3qr31riG3NJviA8QU4IdXlf8gEk=
+- MRS-036: CxmX-BEQNEemhvaifcx9we-Nm6qRgHv4EsJ1WvKMGvg=
+normative: true
+outlay: '4'
+rationale: "Implementing a unified and structured storage mechanism ensures that data\
+ \ related to SFRs/SARs \nand other CC elements is consistently stored and managed\
+ \ within the C5-DEC document-based data \nstore, facilitating efficient data retrieval,\
+ \ management, and overall system reliability.\n"
+ref: ''
+reviewed: 1aeEEqJSsIXOK8FEml_lGBKy4WNGtTsbc44ujmfqzw4=
+risk: '3'
+status: In Progress
+text: |
+ As a User, I want the CC toolbox within the C5-DEC software to enable consistent and structured
+ storage of various CC artifacts and security elements, ensuring ease of data management and
+ integrity.
+
+ 1. When I choose to store SFRs/SARs, Security Functional Classes, Security Assurance Classes,
+ Evaluation Activities, and Packages in the CC toolbox,
+ 2. I want the storage process to utilize the same open file format used for all artifacts
+ ensuring uniformity,
+ 3. And store all elements in a structured, human and machine-readable format within the C5-DEC
+ document-based data store, enabling efficient data retrieval and management.
+ 4. Thus, I can consistently and efficiently manage, access, and utilize the stored data in varied
+ formats without loss of integrity and structure.
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-028.yml b/docs/reqs/srs/SRS-028.yml
new file mode 100644
index 0000000..b6caeb9
--- /dev/null
+++ b/docs/reqs/srs/SRS-028.yml
@@ -0,0 +1,36 @@
+acceptance: "- For each created parent-child relationship a rationale is defined.\n\
+ - A traceability matrix between all parent-child elements of a given level is automatically\
+ \ \ngenerated.\n- A list of justifications, justifying each parent-child link, is\
+ \ automatically compiled.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Automated Rationale and Traceability Matrix Generation
+importance: '4'
+level: 16.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+normative: true
+outlay: '3'
+rationale: "To comply with the Common Criteria, ensuring that every parent-child link\
+ \ within the CC data model\nis justified and traceable is crucial. Automated generation\
+ \ of a traceability matrix and rationale compilation \nfacilitates consistent documentation\
+ \ and adherence to these requirements.\n"
+ref: ''
+reviewed: ipJeEqeqcQ3JMU_2sfntNfwlNhUuJPsXxw6WxdgO4js=
+risk: '1'
+status: Open
+text: |
+ As a Developer,
+ I want the system to automatically generate rationales as required by the CC, that captures and
+ justifies each parent-child relation,
+ so that documentation adheres to CC requirements and maintains a structured and justified linkage
+ throughout the development and evaluation processes.
+ 1. TBD
+type: F
+urgency: '3'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-029.yml b/docs/reqs/srs/SRS-029.yml
new file mode 100644
index 0000000..500aa35
--- /dev/null
+++ b/docs/reqs/srs/SRS-029.yml
@@ -0,0 +1,36 @@
+acceptance: |
+ - The system verifies that every parent-child relationship has an associated rationale.
+ - A traceability matrix is provided that covers all parent-child elements of a given level.
+ - An exhaustive list of justifications is available, ensuring full coverage of all parent-child
+ links.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Verification of Rationales and Traceability Matrices
+importance: '4'
+level: 17.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+normative: true
+outlay: '3'
+rationale: "For an Evaluator, ensuring that the provided rationales and traceability\
+ \ matrices comprehensively\ncover all elements and adhere to CC standards is paramount\
+ \ for validating the coherence and \ncomprehensiveness of the security documentation.\n"
+ref: ''
+reviewed: rHbhSbKOJavK7sYeN9m59VuU6jJIiWlNYAH-66IOXXU=
+risk: '1'
+status: Not Started
+text: |
+ As an Evaluator,
+ I want the system to validate that the generated rationales and traceability matrices
+ comprehensively cover all parent-child elements and are in strict adherence with CC requirements,
+ so that I can confidently validate and certify the coherence and completeness of the security
+ documentation.
+ 1. TBD.
+type: F
+urgency: '3'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-030.yml b/docs/reqs/srs/SRS-030.yml
new file mode 100644
index 0000000..8bed7ff
--- /dev/null
+++ b/docs/reqs/srs/SRS-030.yml
@@ -0,0 +1,35 @@
+acceptance: |
+ - Automated consistency checks validate relationships, attributes, and dependencies within the CC data.
+ - Automated completeness checks ensure all necessary data points are present and properly configured in the CC data.
+ - All data adheres to predefined standards, maintaining its integrity and quality.
+active: true
+author: Heinrich
+date: 03.01.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Detailed Consistency and Completeness Checks
+importance: '4'
+level: 18.0
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+normative: true
+outlay: '3'
+rationale: "Employing automated checks that validate relationships, attributes, and\
+ \ dependencies and ensure completeness \nin CC data not only safeguards the data's\
+ \ integrity and quality but also bolsters reliability and adherence \nto predefined\
+ \ standards.\n"
+ref: ''
+reviewed: Ho-ZTFWerGCHXF2y8XpmF7rlJYi_q8VgQGIPp185Lio=
+risk: '1'
+status: Open
+text: |
+ As an Administrator,
+ I want the system to perform detailed automated consistency and completeness checks on CC data,
+ specifically validating relationships, attributes, and dependencies,
+ so that the integrity, quality, and reliability of the stored data are ensured and maintained in adherence with predefined standards.
+ 1. TBD.
+type: F
+urgency: '3'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-031.yml b/docs/reqs/srs/SRS-031.yml
new file mode 100644
index 0000000..4b20dec
--- /dev/null
+++ b/docs/reqs/srs/SRS-031.yml
@@ -0,0 +1,38 @@
+acceptance: "- The system identifies and alerts to any inconsistencies or incomplete\
+ \ data entries within the CC\n data.\n- Relationships, attributes, and dependencies\
+ \ between data points are automatically validated by \nthe system.\n- A report/log\
+ \ can be generated to provide insights into the validation checks and any issues\
+ \ \nidentified.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Automated Validation of Relationships, Attributes, and Dependencies
+importance: '4'
+level: 18.5
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+normative: true
+outlay: '3'
+rationale: "Ensuring the validity of relationships, attributes, and dependencies and\
+ \ the completeness of CC data entries \nensures a robust and reliable data structure,\
+ \ which in turn streamlines development activities by reducing \nthe potential for\
+ \ errors and unnecessary rework, thus ensuring compliance and efficiency in adhering\
+ \ to CC.\n"
+ref: ''
+reviewed: -mdCO-75qmq37Vp9kqDwcESTjBOFhncGF7JNE5Trj14=
+risk: '1'
+status: Open
+text: |
+ As a Developer,
+ I want the system to automatically validate relationships, attributes, and dependencies between data points,
+ and ensure the completeness of all necessary data entries within the CC data,
+ so that development is guided by accurate, reliable, and complete data, thereby reducing the potential for
+ errors and rework.
+ 1. TBD
+type: F
+urgency: '3'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-032.yml b/docs/reqs/srs/SRS-032.yml
new file mode 100644
index 0000000..00f50cc
--- /dev/null
+++ b/docs/reqs/srs/SRS-032.yml
@@ -0,0 +1,40 @@
+acceptance: "- SARs and work units are accurately and seamlessly aggregated by the\
+ \ system.\n- The system displays SARs and work units in an organized manner, aligned\
+ \ with the respective \nsecurity assurance components.\n- Evaluators can easily\
+ \ navigate and interpret the aggregated data to assess the readiness \nand compliance\
+ \ of the TOE.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- MRS-030
+derived: false
+difficulty: '3'
+header: |
+ Seamless Aggregation and Presentation of SARs and Work Units
+importance: '4'
+level: 18.6
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+normative: true
+outlay: '3'
+rationale: "The efficient evaluation of the TOE’s readiness and compliance with relevant\
+ \ standards is vital for ensuring \nthe security and reliability of the developed\
+ \ system. By automatically aggregating and presenting SARs and \nwork units in alignment\
+ \ with respective security assurance components, evaluators can swiftly and accurately\
+ \ \nassess adherence to security assurance requirements, ensuring robust evaluation\
+ \ processes and confidence in \nthe TOE.\n"
+ref: ''
+reviewed: FxzRwUg-gRw8y5ZtLB13WB6NDZ7GFnLQHJOhJrB54AI=
+risk: '1'
+status: In Progress
+text: |
+ As an Evaluator, I want the system to seamlessly aggregate and present SARs and associated work units,
+ aligning them with specific security assurance components,
+ so that the process of evaluating the readiness and compliance of a Target of Evaluation (TOE) is
+ simplified and streamlined.
+
+ 1. When I select an SAR to assess the readiness or compliance of a TOE, I want to see the SAR description and
+ the associated Work Unit description.
+urgency: '3'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-033.yml b/docs/reqs/srs/SRS-033.yml
new file mode 100644
index 0000000..821e505
--- /dev/null
+++ b/docs/reqs/srs/SRS-033.yml
@@ -0,0 +1,34 @@
+acceptance: |
+ - APIs enable seamless importation of threats from MITRE ATT&CK and CVE.
+ - Imported threats are accurately represented within C5-DEC.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ API Provision for Threat Importation
+importance: '3'
+level: 18.7
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-041: FMqJAO209uF5E_OKNIXpfpbOWgQz9vS2EA-8lBf912A=
+normative: true
+outlay: '3'
+rationale: "Integrating external threat data from reputable sources like MITRE ATT&CK\
+ \ and CVE enriches \nthe C5-DEC database, providing a comprehensive threat landscape\
+ \ for better-informed security analysis \nand decision-making.\n"
+ref: ''
+reviewed: 0NNGpwDrxJiqlxDLdqzRCpEAejzbKgIR7ydHehgeNI4=
+risk: '1'
+status: Open
+text: |
+ As a Security Analyst,
+ I want the system to provide APIs for seamless importation of threats from external repositories
+ like MITRE ATT&CK and CVE,
+ so that I can efficiently integrate and utilize external threat data within C5-DEC.
+ 1. TBD.
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-034.yml b/docs/reqs/srs/SRS-034.yml
new file mode 100644
index 0000000..9b3c10b
--- /dev/null
+++ b/docs/reqs/srs/SRS-034.yml
@@ -0,0 +1,33 @@
+acceptance: |
+ - The system provides templates, guidelines, and custom mapping options for transforming imported threats.
+ - Transformed threats comply with CC standards and integrate with the C5-DEC CC data model.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Transformation of Imported Threats to CC-conformant Format
+importance: '3'
+level: 18.8
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-041: FMqJAO209uF5E_OKNIXpfpbOWgQz9vS2EA-8lBf912A=
+normative: true
+rationale: "Ensuring that all threats, whether internally defined or imported from\
+ \ external sources, adhere to CC standards \nand can be seamlessly integrated within\
+ \ the C5-DEC data model promotes consistency, traceability, and \ncompliance throughout\
+ \ the security evaluation and assurance processes.\n"
+ref: ''
+reviewed: UaUyRzvJ1r0-tX4O-SI4jcgpJA9hv7lLSYQK7unFMbo=
+risk: '1'
+status: Open
+text: |
+ As a Developer,
+ I want the system to provide transformation templates, guidelines, and custom mapping options for converting imported threats into a CC-conformant format,
+ so that all threats, native or imported, ensure compliance with CC standards and integration within the C5-DEC encoded CC data model.
+ 1. TBD.
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-035.yml b/docs/reqs/srs/SRS-035.yml
new file mode 100644
index 0000000..000843c
--- /dev/null
+++ b/docs/reqs/srs/SRS-035.yml
@@ -0,0 +1,47 @@
+acceptance: "- User can select and de-select security assurance components or assurance\
+ \ packages (augmentations also allowed)\n- Based on the (valid) selection, a checklist\
+ \ is generated that contains Evaluation Items that correspond to \nthe respective\
+ \ Work Units. \n- Each Evaluation Item contains all relevant information for the\
+ \ Work Unit, i.e., Evaluator Action Element, \nContent or Developer Element, and\
+ \ the Work Unit task. \n- Furthermore, the User must be able to assign each Evaluation\
+ \ Item an Evaluator, an Evaluation Date, \nthe Evaluation Evidence, and the Evaluation\
+ \ Verdict.\n- An index of required evaluation evidence documentation is created.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-034
+derived: false
+difficulty: N/A
+header: |
+ Automated Evaluation Checklist Creation
+importance: '3'
+level: 18.9
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-043: nUykKj5kzIjP2NUIFlvWFsfNR5Dk1bMI6Dchi_iIpRE=
+normative: true
+outlay: '3'
+rationale: "Enabling automated creation of Evaluation Checklists ensures that the\
+ \ evaluators can efficiently initialize \nthe evaluation process by quickly defining\
+ \ the scope and requirements of the evaluation, thereby ensuring \ncompliance and\
+ \ readiness from the project’s inception.\n"
+ref: ''
+reviewed: 1xXCYAuk02zO_xIrnasxyECX3q3uAJKDE99YZ5r1IMY=
+risk: '1'
+status: In Progress.
+text: |
+ As a Developer or Evaluator,
+ I want to select a set of Security Assurance Components or Assurance Package and have the system automatically
+ generate an Evaluation Checklist, so that I can efficiently assess the evaluation readiness of or evaluate
+ a Target of Evaluation.
+
+ 1. When I select a set of Security Assurance Components or a pre-defined Assurance Package (e.g. EAL 2)
+ to assess the readiness of or to evaluate a Target of Evaluation.
+ 2. Then I expect the system to automatically validate the selected set of components in terms of the consideration
+ of hierarchical and dependency relationships.
+ 3. When a valid set is selected I want the system to create an Evaluation Checklist based on the selected set.
+ 4. Then I want to have the option to start the evaluation using the created Evaluation Checklist.
+type: F
+urgency: '1'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-036.yml b/docs/reqs/srs/SRS-036.yml
new file mode 100644
index 0000000..7e00258
--- /dev/null
+++ b/docs/reqs/srs/SRS-036.yml
@@ -0,0 +1,44 @@
+acceptance: "- The overall evaluation progress is accurately and visually represented\
+ \ in the system, e.g., as\na percentage of 'passed' evaluation items.\n- The status\
+ \ of each Evaluation Item is accurately and visually represented, e.g., as [X],\
+ \ [O], or [ ]\nfor failed, passed, or inconclusive, respectively.\n- Both the overall\
+ \ evaluation progress and the Item's status are updated in real time, i.e., evaluation\
+ \ progess\nand status are immediately updated when changes are made. \n- At all\
+ \ times the evaluation progress as well as any Evaluation Item's status can be extracted.\n"
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-035: null
+derived: false
+difficulty: '1'
+header: |
+ Evaluation Progress Tracking
+importance: '3'
+level: '18.10'
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-043: nUykKj5kzIjP2NUIFlvWFsfNR5Dk1bMI6Dchi_iIpRE=
+normative: true
+outlay: '3'
+rationale: "Tracking the evaluation progress centrally and transparently supports\
+ \ project management by allowing \nall stakeholders to have a clear, real-time insight\
+ \ into the ongoing evaluation status, thereby enabling \ntimely decision-making\
+ \ and issue mitigation.\n"
+ref: ''
+reviewed: b1Aq2II0TECWSB-RzNbZ3hBthujvNSUn7e_QEOsvCuo=
+risk: '1'
+status: In Progress
+text: |
+ As a User,
+ I want the system to track and display the evaluation progress of the Evaluation, as well as the
+ evaluation status of individual Evaluation Items,
+ so that the ongoing status of the Evaluation is clear and easily accessible.
+
+ 1. When I load an Evaluation Checklist I expect to see the overall evaluation progress, as well as
+ the evaluation status (pass, fail, inconclusive) of each Evaluation Item.
+ 2. When I select and edit an Evaluation Item I expect the Item's status as well as the overall
+ evaluation progress to account for the changes in real time.
+type: F
+urgency: '1'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-037.yml b/docs/reqs/srs/SRS-037.yml
new file mode 100644
index 0000000..26abbf9
--- /dev/null
+++ b/docs/reqs/srs/SRS-037.yml
@@ -0,0 +1,57 @@
+acceptance: |
+ - Users can create, modify, and remove links between work units and applicable artifacts.
+ - Links are visibly represented and can be navigated within the system.
+ - Links are differentiated between internal and external links.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-035
+derived: false
+difficulty: '1'
+header: |
+ Work Unit Artifact Linking
+importance: '4'
+level: 18.11
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-043: nUykKj5kzIjP2NUIFlvWFsfNR5Dk1bMI6Dchi_iIpRE=
+normative: true
+outlay: '3'
+rationale: "Ensuring traceability between work units and related artifacts reinforces\
+ \ the transparency and verifiability \nof the evaluation process, thereby strengthening\
+ \ the credibility and compliance of the evaluation outcome.\n"
+ref: ''
+reviewed: ySBNmMjF1VvP2UG2xAFk3wAj_3JpTstKBQzb14Q6zJs=
+risk: '1'
+status: Open
+text: |
+ As a User,
+ I want to link work units within an Evaluation Checklist to applicable artifacts,
+ so that there is clear traceability between work units and related project artifacts.
+
+ 1. When I treat an Evaluation Item and hence the associated Work Unit and want to link
+ relevant artifacts to the Evaluation Item/Work Unit
+ 2. Then I want to be able to differentiate between linking internal (items stored in the same open file
+ format and managed by C5-DEC) and external artifacts.
+
+ 3.a When I want to link internal artifacts I can do so by providing the artifact's item UID.
+
+ 4.a Then I expect the system to acknowledge linking the artifact to the Evaluation Item or inform me
+ (visually) if the UID is invalid.
+
+ OPTIONAL:
+
+ 3.b When I want to link internal artifacts I want to be able to define queries to search for the
+ artifact.
+
+ 4.b Then I expect the system to provide potentially matching items with a preview of the item's content
+
+ 5.b When I select a match I want the system to link the Evaluation Item to the selected item.
+
+ 6. When I want to link external artifacts I can do so by providing the path to the external resource.
+ 7. When I select an Evaluation Item's link
+ 8. Then I want to be able to modify, remove, or open/preview the linked Item.
+type: F
+urgency: '3'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-038.yml b/docs/reqs/srs/SRS-038.yml
new file mode 100644
index 0000000..cf570c5
--- /dev/null
+++ b/docs/reqs/srs/SRS-038.yml
@@ -0,0 +1,36 @@
+acceptance: |
+ - The system gathers and compiles information related to failed work units.
+ - An OR is generated, summarizing issues encountered during the evaluation.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-037
+- SRS-036
+- SRS-035
+derived: false
+difficulty: '3'
+header: |
+ Automated OR Generation
+importance: '3'
+level: 18.12
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-043: nUykKj5kzIjP2NUIFlvWFsfNR5Dk1bMI6Dchi_iIpRE=
+normative: true
+outlay: '3'
+rationale: "Automated generation of Observation Reports (ORs) ensures that any discrepancies,\
+ \ issues, or failures during \nthe evaluation are systematically documented and\
+ \ communicated, which is vital for transparency and subsequent \nremediation activities.\n"
+ref: ''
+reviewed: _8PE-TXgIauxGJmA7eCXapVPjLTZ6txBI2G_fMFvwD4=
+risk: '1'
+status: Open
+text: |
+ As a User,
+ I want the system to generate Observation Reports (ORs),
+ so that issues encountered during the evaluation are summarized and communicated effectively.
+ 1. TBD.
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-039.yml b/docs/reqs/srs/SRS-039.yml
new file mode 100644
index 0000000..151e676
--- /dev/null
+++ b/docs/reqs/srs/SRS-039.yml
@@ -0,0 +1,38 @@
+acceptance: |
+ - All verdicts and evaluation results are summarized in the ETR.
+ - The overall verdict in the ETR is derived based on individual verdicts and predefined rules.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-035
+- SRS-036
+- SRS-037
+- SRS-038
+derived: false
+difficulty: '3'
+header: |
+ Automated ETR Generation
+importance: '3'
+level: 18.13
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-043: nUykKj5kzIjP2NUIFlvWFsfNR5Dk1bMI6Dchi_iIpRE=
+normative: true
+outlay: '3'
+rationale: "Streamlining the creation of the Evaluation Technical Report (ETR) by\
+ \ automating the compilation and \nderivation of overall verdicts ensures a swift,\
+ \ consistent, and objective consolidation of evaluation \noutcomes, which is crucial\
+ \ for substantiating evaluation claims and finalizing the evaluation process.\n"
+ref: ''
+reviewed: MIL2szzz8VCiomsA2ADuel8AgyavtvN-qK02qhkvCk8=
+risk: '1'
+status: Open
+text: |
+ As a User,
+ I want the system to generate the Evaluation Technical Report (ETR) upon completion of the evaluation,
+ so that all verdicts and evaluation results are summarized and the overall verdict is derived according to
+ predefined rules.
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-040.yml b/docs/reqs/srs/SRS-040.yml
new file mode 100644
index 0000000..c5d8f93
--- /dev/null
+++ b/docs/reqs/srs/SRS-040.yml
@@ -0,0 +1,40 @@
+acceptance: |
+ - Failed work units are visibly flagged.
+ - Items linked to the flagged work units are also flagged.
+ - Progress cannot continue until flagged items are addressed.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-037
+- SRS-036
+derived: false
+difficulty: '2'
+header: |
+ Flagging and Addressing Failed Work Units with Cascading Flags
+importance: '3'
+level: 18.4
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-043: nUykKj5kzIjP2NUIFlvWFsfNR5Dk1bMI6Dchi_iIpRE=
+normative: true
+outlay: '3'
+rationale: "Explicitly flagging failed work units and inhibiting progression until\
+ \ they are addressed ensures that \nissues are rectified promptly. Cascading these\
+ \ flags to linked items ensures a rigorous and thorough \nevaluation and validation\
+ \ process, maintaining the integrity and reliability of the evaluation and \ndevelopment\
+ \ process and ensuring that dependent elements are not overlooked.\n"
+ref: ''
+reviewed: OtP7TQoiHq7EnHyk6Ebg8NI4QD6udHv5xMbWVXWPeQg=
+risk: '1'
+status: Open
+text: |
+ As a User,
+ I want failed work units to be visibly flagged and to inhibit progression until resolved. Additionally,
+ I want all items linked to a flagged work unit to also be flagged,
+ so that all issues and potential dependent problems are duly addressed, ensuring a reliable, thorough,
+ and systematic evaluation and development process.
+ 1. TBD.
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-041.yml b/docs/reqs/srs/SRS-041.yml
new file mode 100644
index 0000000..3960295
--- /dev/null
+++ b/docs/reqs/srs/SRS-041.yml
@@ -0,0 +1,33 @@
+acceptance: |
+ - Evaluated work units are logged and stored as Doorstop items.
+ - Users can review the log of passed work units.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-036
+derived: false
+difficulty: '1'
+header: |
+ Logging evaluated Work Units
+importance: '3'
+level: 18.14
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-043: nUykKj5kzIjP2NUIFlvWFsfNR5Dk1bMI6Dchi_iIpRE=
+normative: true
+outlay: '3'
+rationale: "Systematically logging and archiving evaluated work units provides a clear\
+ \ record, \nwhich can be vital for future reviews, audits, and project insights,\
+ \ thereby supporting transparency and \nhistorical tracking of project evolution.\n"
+ref: ''
+reviewed: kgkIkbOv5valRGs3wpZ0-7bo5SKDxEaVtxup9JhqOBQ=
+risk: '1'
+status: In Progess
+text: |
+ As a User,
+ I want evaluated work units to be logged and stored,
+ so that a clear record of successful evaluations is maintained for future reference and auditing.
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-042.yml b/docs/reqs/srs/SRS-042.yml
new file mode 100644
index 0000000..af34702
--- /dev/null
+++ b/docs/reqs/srs/SRS-042.yml
@@ -0,0 +1,34 @@
+acceptance: |
+ - The data model encompasses all entities and documents within the CC ecosystem.
+ - Each entity in the CC ecosystem can be represented, related, and manipulated within the system.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Extend Data Model Across Entire CC Ecosystem
+importance: '3'
+level: 18.15
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+normative: true
+outlay: '3'
+rationale: "Extending the data model across the entire CC ecosystem ensures consistent\
+ \ and comprehensive management \nand manipulation of all CC entities and documents.\
+ \ It enables thorough adherence to CC standards \nand ensures all CC-relevant data\
+ \ can be accurately represented, related, and manipulated within the system.\n"
+ref: ''
+reviewed: q2g8j7MMXnN-YIYYuxRnZ7xPCY6w5yJlIv1s1Oc0stA=
+risk: '1'
+status: Open
+text: |
+ As a User,
+ I want the data model to accurately encompass and interrelate all entities and documents within the CC ecosystem,
+ so that I can efficiently navigate, manage, and derive insights from comprehensive, interconnected CC data,
+ ensuring that the manipulation, association, and interpretation of all CC-relevant entities are coherent and traceable.
+ 1. TBD
+type: N
+urgency: '1'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-043.yml b/docs/reqs/srs/SRS-043.yml
new file mode 100644
index 0000000..5dd27f4
--- /dev/null
+++ b/docs/reqs/srs/SRS-043.yml
@@ -0,0 +1,36 @@
+acceptance: |
+ - Templates for each type of CC document are available and adhere to CC standards.
+ - Users can select, utilize, and export templates to supported formats (e.g., .docx, .tex, .xml).
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence:
+- SRS-042
+derived: false
+difficulty: '2'
+header: |
+ Provide CC Document Templates
+importance: '3'
+level: 18.16
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+normative: true
+outlay: ''
+rationale: "Providing predefined templates for each type of CC document simplifies\
+ \ and standardizes the document \ncreation process. It ensures that users can efficiently\
+ \ create documents adhering to CC content and \nformatting standards without requiring\
+ \ detailed manual input, thus enhancing consistency and reducing \nthe potential\
+ \ for error across CC documentation.\n"
+ref: ''
+reviewed: PePLy449lwyt6lyQKPdxUhJrwgEbplkBBhUySjoMsh0=
+risk: '1'
+status: Open
+text: |
+ As a User,
+ I want access to predefined templates for each type of CC document,
+ so that I can efficiently create standardized, CC-compliant documents and optionally export them
+ to supported formats.
+ 1. TBD.
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/srs/SRS-044.yml b/docs/reqs/srs/SRS-044.yml
new file mode 100644
index 0000000..0eb2a7c
--- /dev/null
+++ b/docs/reqs/srs/SRS-044.yml
@@ -0,0 +1,48 @@
+acceptance: |
+ 1. The system enables the selection or provision of security components for a project.
+ 2. Upon selection, the system automatically validates the hierarchical and dependency relationships
+ among the chosen components, in accordance with CC guidelines.
+ 3. The system provides clear feedback about the validation status, highlighting any inconsistencies
+ or deviations from the CC guidelines.
+ 4. Adjustments made to the components are accurately reflected and can be re-validated by the system.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Validate Hierarchies and Dependencies in Security Components
+importance: '3'
+level: 18.17
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-053: hH1BOxsxqL7gqcXVVQlq03aDkjjLO_6EB3F9g4I0Sy4=
+- MRS-055: 170X_04gCc9dZmaqVWbxq6N4LfKUhgGniwmIs33xeVY=
+normative: true
+outlay: '3'
+rationale: "To ensure that the specified and selected security components are coherent\
+ \ and \nabide by the CC guidelines, all hierarchical and dependency relations among\
+ \ them \nmust be validated.\n"
+ref: ''
+reviewed: fgch3Dp-hukB1dOMjn9Pqg8vOLVEGUHEeC7VFqP_zvI=
+risk: '1'
+status: In Progress
+text: |
+ As a User,
+ I want the system to validate the hierarchies and dependencies among the selected
+ security components,
+ so that I can ensure that my set of components is coherent and conforms
+ to the CC.
+
+ 1. When I select or provide a set of Security Components
+ 2. Then I expect the system's validation mechanism to check whether the provided component set
+ meets the hierarchical and dependency requirements of each selected Security Component.
+ 3. When I provide an invalid set
+ 4. Then I expect the system to classify the set as 'invalid' and optionally to provide potential
+ valid sets based on the provided selection.
+ 5. When I provide a valid set
+ 6. Then I expect the system to classify the set as 'valid'
+type: F
+urgency: '3'
+version: 1.0
diff --git a/docs/reqs/srs/SRS-045.yml b/docs/reqs/srs/SRS-045.yml
new file mode 100644
index 0000000..1fa1389
--- /dev/null
+++ b/docs/reqs/srs/SRS-045.yml
@@ -0,0 +1,41 @@
+acceptance: |
+ 1. The system must identify and track changes in both code and documentation.
+ 2. The system must automatically infer the impacts of these changes.
+ 3. An Impact Analysis Report (IAR) is generated, summarizing the inferred impacts.
+ 4. The IAR must be comprehensible and encapsulate all necessary impact details.
+ 5. The IAR should be structured to support certification maintenance and incremental certification processes.
+active: true
+author: Heinrich
+date: 03.10.2023
+dependence: []
+derived: false
+difficulty: '3'
+header: |
+ Generate Impact Analysis Reports for Certification Maintenance.
+importance: '2'
+level: 18.18
+links:
+- MRS-032: zdmk414Ku_uKO9MC4dv6gH6-9PZsz3atEQm7cnls8UE=
+- MRS-053: hH1BOxsxqL7gqcXVVQlq03aDkjjLO_6EB3F9g4I0Sy4=
+- MRS-055: 170X_04gCc9dZmaqVWbxq6N4LfKUhgGniwmIs33xeVY=
+normative: true
+outlay: ''
+rationale: "To maintain existing certifications and facilitate incremental certification\
+ \ processes in the face of \nchanges, the system needs to automatically deduce and\
+ \ report the impacts stemming from alterations in \ncode and documentation. Impact\
+ \ Analysis Reports (IARs) crystallize these impacts in a structured format,\noffering\
+ \ a clear overview of potential repercussions and are a required evaluation evidence\
+ \ for certification\nmaintanence.\n"
+ref: ''
+reviewed: _paoDTL24ZLDBGz34E4JLA6F1SEDk88VKD3QL-cfH-A=
+risk: '2'
+status: Open
+text: |
+ As a Developer,
+ I want the system to automatically infer the impact of changes in both code and documentation,
+ So that these insights are summarized in comprehensive Impact Analysis Reports (IARs), ensuring effective
+ management of compliance and certification aspects throughout project alterations.
+ 1. TBD
+type: F
+urgency: '2'
+version: '1.0'
diff --git a/docs/reqs/trp/.doorstop.yml b/docs/reqs/trp/.doorstop.yml
new file mode 100644
index 0000000..5558713
--- /dev/null
+++ b/docs/reqs/trp/.doorstop.yml
@@ -0,0 +1,29 @@
+settings:
+ digits: 3
+ itemformat: yaml
+ parent: TST
+ prefix: TRP
+ sep: '-'
+
+attributes:
+ defaults:
+ test_date: '27-11-2023'
+ tester: 'IVS'
+ defect_category: '[0-4]'
+ defect_description: ''
+ comments: ''
+ text: 'Test execution results for the TST in the parent link.'
+
+ publish:
+ - test_date
+ - tester
+ - defect_category
+ - defect_description
+ - comments
+
+ # attributes to be considered for the item's fingerprint,
+ # the fingerprint is used to detect unreviewed changes to an item
+ reviewed:
+ - test_date
+ - defect_category
+ - defect_description
diff --git a/docs/reqs/trp/TRP-001.yml b/docs/reqs/trp/TRP-001.yml
new file mode 100644
index 0000000..2c67c0c
--- /dev/null
+++ b/docs/reqs/trp/TRP-001.yml
@@ -0,0 +1,21 @@
+active: true
+comments: |
+ The acceptance criteria in the parent SRS is satisfied. The data is mostly aligned to the description in the corresponding CC document (e.g. of an exception: for ACE, the info in MS-Introduction does not appear in the PDF). The reported defects affect readability.
+defect_category: '1'
+defect_description:
+- |
+ The links in the item preview are empty. E.g., see the preview of family FDP_ACC or of FAU_SAA.
+- |
+ In the item preview of components (e.g. FDP_RIP.2, FDP_ACC.2), the text shown as value for the field "Hierarchical to" is tokenized by characters. Instead, these should be words.
+derived: false
+header: ''
+level: 1.0
+links:
+- TST-001: OTLJuU0D0O5iHkVHKd-jKxPuuKzMnR-zS5xigcgLSos=
+normative: true
+ref: ''
+reviewed: BnAd2bqicDjnoYvA9__Azr_y2JqPAqLhlKOG5hTX0Ec=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-002.yml b/docs/reqs/trp/TRP-002.yml
new file mode 100644
index 0000000..0348605
--- /dev/null
+++ b/docs/reqs/trp/TRP-002.yml
@@ -0,0 +1,21 @@
+active: true
+comments: |
+ The acceptance criteria is satisfied. Yet, the defect described could render the browser view confusing.
+defect_category: '1'
+defect_description: |
+ When an element from an upper category in the hierarchy is selected, the children should be cleared to avoid confusion regarding to which element the item preview corresponds. An example of elements from different clases and families mixed in one screen is provided as a reference in the displayed pathfile.
+derived: false
+header: ''
+level: 1.1
+links:
+- TST-002: vdOU-838nuIwDu0HYxif-iUg6z3w3_1widgPVv8hKkc=
+normative: true
+ref: ''
+references:
+- path: docs/reqs/trp/evidence/trp-002-ev.png
+ type: file
+reviewed: bdIYu6T6s7l3pTc9N-wSHtakUwjpX10fNz2UbBDuXrY=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-003.yml b/docs/reqs/trp/TRP-003.yml
new file mode 100644
index 0000000..84394e7
--- /dev/null
+++ b/docs/reqs/trp/TRP-003.yml
@@ -0,0 +1,18 @@
+active: true
+comments: |
+ - Only export to markdown files implemented in the Alpha phase. - When giving a filepath that does not exist, the export does not create it. While this is ok, it would be better to display a message informing about the specific problem.
+defect_category: '1'
+defect_description: |
+ When files are exported, the links become unusable; for instance, when opened in VSCode, they open a browser pointing to a 'page not found'.
+derived: false
+header: ''
+level: 1.2
+links:
+- TST-003: 78a_XNTZ07g1S3PL2cvNh0E8yL8GgScG2B-K5PYcoXU=
+normative: true
+ref: ''
+reviewed: rhkr3tly59DAedHswAX1XtIF6JXRitfntcIJGq5c22g=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-004.yml b/docs/reqs/trp/TRP-004.yml
new file mode 100644
index 0000000..6c9aad7
--- /dev/null
+++ b/docs/reqs/trp/TRP-004.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not applicable to the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.3
+links:
+- TST-004: c4fLGnu5letM4faF3AW9eBuE-ZyGGn9YzqcvOEhPLAI=
+normative: true
+ref: ''
+reviewed: LTtafzsv4Uun12pttHwy6Goee_ikhKZjAXZBL7tpccE=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-005.yml b/docs/reqs/trp/TRP-005.yml
new file mode 100644
index 0000000..fba2102
--- /dev/null
+++ b/docs/reqs/trp/TRP-005.yml
@@ -0,0 +1,16 @@
+active: true
+comments: ''
+defect_category: '0'
+defect_description: ''
+derived: false
+header: ''
+level: 1.4
+links:
+- TST-005: Rczoq3j7wwUfvBRAN4X6iQmSZgggLXVvd9ww_fe5x5c=
+normative: true
+ref: ''
+reviewed: P___O7g_X_GYQfh0OE_RXstilr6hjs9zuYWJMu4phnY=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-006.yml b/docs/reqs/trp/TRP-006.yml
new file mode 100644
index 0000000..f0e6597
--- /dev/null
+++ b/docs/reqs/trp/TRP-006.yml
@@ -0,0 +1,16 @@
+active: true
+comments: null
+defect_category: '0'
+defect_description: ''
+derived: false
+header: ''
+level: 1.5
+links:
+- TST-006: EsYGxcQgqqqK_mO6VWUtKbKB2mdClYLvfoW8eDWDW-c=
+normative: true
+ref: ''
+reviewed: Vnl2UGOcUW4SFVWko1rOF1Hk3x8tWBqhQ39NpYWTdnQ=
+test_date: 28-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-007.yml b/docs/reqs/trp/TRP-007.yml
new file mode 100644
index 0000000..cf5335f
--- /dev/null
+++ b/docs/reqs/trp/TRP-007.yml
@@ -0,0 +1,17 @@
+active: true
+comments: A link to the table of contents in each page would be useful.
+defect_category: '2'
+defect_description: |
+ Some pages are missing, e.g., 'Terms and Definition Register'. For others, the links are missing, e.g., [Security Functional Requirements] and [Security Assurance Requirements]
+derived: false
+header: ''
+level: 1.6
+links:
+- TST-007: jPWoJvjiMPNiwlqlC5V-gFhtBnuekHvGZD2M1y991PA=
+normative: true
+ref: ''
+reviewed: hg0ZsQf9WY4KGZNIoqFubwkXLDzb7Qc5EH2e0Sg5Qeo=
+test_date: 28-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-008.yml b/docs/reqs/trp/TRP-008.yml
new file mode 100644
index 0000000..04b1266
--- /dev/null
+++ b/docs/reqs/trp/TRP-008.yml
@@ -0,0 +1,16 @@
+active: true
+comments: ''
+defect_category: '0'
+defect_description: ''
+derived: false
+header: ''
+level: 1.7
+links:
+- TST-008: MfgzCXcFUlzqq_HD4QjssVyjIBn_p4zXqZUwvmiBCC8=
+normative: true
+ref: ''
+reviewed: OAJ1RG68RaHbWdG19CznIObdJlidD7eATHRh3cRoVhs=
+test_date: 28-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-009.yml b/docs/reqs/trp/TRP-009.yml
new file mode 100644
index 0000000..13be12c
--- /dev/null
+++ b/docs/reqs/trp/TRP-009.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not applicable for the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.8
+links:
+- TST-009: jGaZL3yS2rVBNgqvrDUfTPhoL0w6vhO3dzdk-iRYmQ4=
+normative: true
+ref: ''
+reviewed: 82ADjBpu5gKI-qiHUPooUZp-Zpu7HsL5zNOR1q_qmXU=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-010.yml b/docs/reqs/trp/TRP-010.yml
new file mode 100644
index 0000000..05d9ad8
--- /dev/null
+++ b/docs/reqs/trp/TRP-010.yml
@@ -0,0 +1,18 @@
+active: true
+comments: |
+ The discrepancies found do not necessarily imply an incorrect mapping, yet, to determine the correctness of the mapping by this method, a deeper inspection to track the parsing of the XML file to classes and its relation with the DTD would require more time and perhaps splitting the test case. Given that the mapping can be tested with other functional tests, TST-010 will be considered not applicable for now.
+defect_category: n/a
+defect_description: |
+ Some of the verifications specified in the test steps are not observed in the code of `cct.py`. For instance, the attributes "part" and "patch" of the element 'xref' in the DTD are not present in the XRef class.
+derived: false
+header: ''
+level: 1.9
+links:
+- TST-010: 0nvIHsSyteA0DjvUFxpQBiG_5xpUauVaEPVqoAnr4iI=
+normative: true
+ref: ''
+reviewed: uzu5XazzfZqwLaldJLO4uQEDcoIiEmUl3fB--_WuKpU=
+test_date: 28-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-011.yml b/docs/reqs/trp/TRP-011.yml
new file mode 100644
index 0000000..973bd7c
--- /dev/null
+++ b/docs/reqs/trp/TRP-011.yml
@@ -0,0 +1,18 @@
+active: true
+comments: |
+ The correctness of the data for valid CC elements is already covered (and has been tested) in TST-001. The reported defect fails to inform the user about data not existing in the CC.
+defect_category: '2'
+defect_description: |
+ The CLI application crashes if an invalid for a CC element is provided. This defect has been reported as bug #18 in the CAD GitLab repository.
+derived: false
+header: ''
+level: '1.10'
+links:
+- TST-011: unry1JPOl_QPjlhZw5eJ1fVUZn5DVk1FSJvFU1JyF60=
+normative: true
+ref: ''
+reviewed: MSbeLxmECTPYCgYljbaLNoNEUTuCAQp74kHEmH6Egs4=
+test_date: 28-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-012.yml b/docs/reqs/trp/TRP-012.yml
new file mode 100644
index 0000000..f60c5ef
--- /dev/null
+++ b/docs/reqs/trp/TRP-012.yml
@@ -0,0 +1,17 @@
+active: true
+comments: |
+ The test steps are vague and do not provide enough details to perform this test.
+defect_category: ignored
+defect_description: ''
+derived: false
+header: ''
+level: 1.11
+links:
+- TST-012: QGWzx2_LnLIsseahSb57cK8MmvHpocPArOFUVtxJXn4=
+normative: true
+ref: ''
+reviewed: ep0jVep0aR59trtXU9cFdpwLVWq1T_UJXc7pL5qbxIw=
+test_date: 28-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-013.yml b/docs/reqs/trp/TRP-013.yml
new file mode 100644
index 0000000..7f5f56f
--- /dev/null
+++ b/docs/reqs/trp/TRP-013.yml
@@ -0,0 +1,17 @@
+active: true
+comments: |
+ Although the parent SRS requires an integrated source of security-related data with content from BSI Grundschutz, ISO 27005, NIST SPs, and the CC, the SRS is not mandatory. Therefore, having data only from CC is acceptable.
+defect_category: '0'
+defect_description: ''
+derived: false
+header: ''
+level: 1.12
+links:
+- TST-013: 3RtoTTYWNwSh2rXUfVR1l6TyfbYypOJqyQA8rGFpT8o=
+normative: true
+ref: ''
+reviewed: VzG96y2kxsmfgYfw0R3P_iZD8H0U3Y4udnDUuWUTkVQ=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-014.yml b/docs/reqs/trp/TRP-014.yml
new file mode 100644
index 0000000..86239ec
--- /dev/null
+++ b/docs/reqs/trp/TRP-014.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not applicable to the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.13
+links:
+- TST-014: z9UYI7i6DpFQuGCygQqw8wdhZnP1SUK82uvdfqlFTec=
+normative: true
+ref: ''
+reviewed: pQnQKHZhdD2W3aODPEoZRsOISXZylabQ7vwnSGxYekE=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-015.yml b/docs/reqs/trp/TRP-015.yml
new file mode 100644
index 0000000..7d16a63
--- /dev/null
+++ b/docs/reqs/trp/TRP-015.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not implemented for the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.14
+links:
+- TST-015: 9x6W8UG8B3MGTq3JM9SzIyjqx1ViiSRVwr_xTN0uMIQ=
+normative: true
+ref: ''
+reviewed: feroovRaOs2wxpxvL0k9Op7plfgp2QKdghQIr7-TGMU=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-016.yml b/docs/reqs/trp/TRP-016.yml
new file mode 100644
index 0000000..f6317d8
--- /dev/null
+++ b/docs/reqs/trp/TRP-016.yml
@@ -0,0 +1,17 @@
+active: true
+comments: |
+ The acceptance criteria are satisfied.
+defect_category: '0'
+defect_description: ''
+derived: false
+header: ''
+level: 1.15
+links:
+- TST-016: pUPrnn3SOodjTyUtbuBuspaZqBpzlJEZvmH-HkSo6cY=
+normative: true
+ref: ''
+reviewed: ZBtIk01RVyPGjzGHharzX8dmUvoe5Dm1hT6njIK9mdM=
+test_date: 30-11-2023
+tester: Arash
+text: |
+ TC passed.
diff --git a/docs/reqs/trp/TRP-017.yml b/docs/reqs/trp/TRP-017.yml
new file mode 100644
index 0000000..0795c77
--- /dev/null
+++ b/docs/reqs/trp/TRP-017.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not implemented for the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.16
+links:
+- TST-017: 1xcsPNkg8rPwLp4wuTsiepTVJVV7OdIyJ3W5A7knT0Y=
+normative: true
+ref: ''
+reviewed: XHxsEgejtNNkJ7PDDH0lkXcl7LpAsckA51EqrvSZl1I=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-018.yml b/docs/reqs/trp/TRP-018.yml
new file mode 100644
index 0000000..adee9fd
--- /dev/null
+++ b/docs/reqs/trp/TRP-018.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not implemented for the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.17
+links:
+- TST-018: SWO1h5J6uSGsDd1tgMcgwE3CMIdh5EL5TAHSI6zM3nU=
+normative: true
+ref: ''
+reviewed: YPzx_DNfS9E_YCdzfkWKhfBb45GerpVlUSrnsMW39to=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-019.yml b/docs/reqs/trp/TRP-019.yml
new file mode 100644
index 0000000..c0d4020
--- /dev/null
+++ b/docs/reqs/trp/TRP-019.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not implemented for the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.18
+links:
+- TST-019: THnx8oAn9RGi9w3OsNzeak07rq0gOrvpsOhvByWttsY=
+normative: true
+ref: ''
+reviewed: McKAEdTOqdmB-OniegNIzfly1SLER_VxPq-NMHBmNZU=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-020.yml b/docs/reqs/trp/TRP-020.yml
new file mode 100644
index 0000000..a1d6724
--- /dev/null
+++ b/docs/reqs/trp/TRP-020.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not implemented for the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.19
+links:
+- TST-020: 1WwgcEyuxcNd0IlrdN8A_sLh4S8W5lDSijvcqrDlHT0=
+normative: true
+ref: ''
+reviewed: QItQaSdFnCVUIkmCLuDWq1kBwJW4p7gK8wljX9pGf4M=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-021.yml b/docs/reqs/trp/TRP-021.yml
new file mode 100644
index 0000000..3a2fb9c
--- /dev/null
+++ b/docs/reqs/trp/TRP-021.yml
@@ -0,0 +1,21 @@
+active: true
+comments: |
+ The defect reported here is associated with issue #19 in the GitLab CAD repository.
+defect_category: '3'
+defect_description:
+- |
+ The CLI crashes when running the checklist command with 'tst' as evaluation checklist prefix (issue \#19)
+- |
+ The CLI crashes when running `$ poetry run c5dec checklist --edit ` due to vim not being installed. When adding the `--editor code` option, it runs as expected
+derived: false
+header: ''
+level: '1.20'
+links:
+- TST-021: C8V-hTNyJPJOYvwmNeEdmXgPkJAohBXTSoKP1DlDoVo=
+normative: true
+ref: ''
+reviewed: pqyfoQuAa8tHulssCuX1Py8q_XsmjjwKK4O-27-aVpE=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-022.yml b/docs/reqs/trp/TRP-022.yml
new file mode 100644
index 0000000..77eac15
--- /dev/null
+++ b/docs/reqs/trp/TRP-022.yml
@@ -0,0 +1,17 @@
+active: true
+comments: |
+ The associated requirement (SRS-033) has not been implemented for the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.21
+links:
+- TST-022: 8xDMM-Pq-FbwT21oYtWzGuXV7z7anwKWypxGdXbHII0=
+normative: true
+ref: ''
+reviewed: CjTBzeLz6CNG3jnxB1GHvWNHbTrD10xMWizxWAl1Cbo=
+test_date: 28-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-023.yml b/docs/reqs/trp/TRP-023.yml
new file mode 100644
index 0000000..e61e187
--- /dev/null
+++ b/docs/reqs/trp/TRP-023.yml
@@ -0,0 +1,17 @@
+active: true
+comments: |
+ The corresponding SRS (SRS-034) has not been implemented for the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.22
+links:
+- TST-023: FLCP8acTmQA4lOSRsmbNh_sWcQoO9puhTJ8AP4x_Ms4=
+normative: true
+ref: ''
+reviewed: m7YTNo0nfJ-48kyr2cbMhU6cYBTyZWMjAFal9hTj-Sg=
+test_date: 28-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-024.yml b/docs/reqs/trp/TRP-024.yml
new file mode 100644
index 0000000..b6d1e65
--- /dev/null
+++ b/docs/reqs/trp/TRP-024.yml
@@ -0,0 +1,17 @@
+active: true
+comments: The TUI works as expected. The reported defect affects the CLI.
+defect_category: '2'
+defect_description: |
+ The CLI crahses if an invalid component id is given. E.g.: `$ poetry run c5dec checklist -c evChck-tst-024 --id aco`
+derived: false
+header: ''
+level: 1.23
+links:
+- TST-024: oO07NQ7BNNe5awMmnVPh0UHDL7b9EITYXGTpqfneBN8=
+normative: true
+ref: ''
+reviewed: 6VBnVOkwoAbIAlePyANHWfk_GT-r5BpiS_4IOsKM9qo=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-025.yml b/docs/reqs/trp/TRP-025.yml
new file mode 100644
index 0000000..afdbb50
--- /dev/null
+++ b/docs/reqs/trp/TRP-025.yml
@@ -0,0 +1,18 @@
+active: true
+comments: |
+ This defects correspond to issues #20 and #22 in the GitLab CAD repository.
+defect_category: '4'
+defect_description: |
+ - The TUI crashes when an evaluation evidence is edited and revisited (issue #20). - The CLI crashes with the option `-s` if the input evaluation checklist does not exist (issue #22).
+derived: false
+header: ''
+level: 1.24
+links:
+- TST-025: stttvaumDsXZkO5Bex0yXi9T-Gsc1wojpXv9EvIMFG8=
+normative: true
+ref: ''
+reviewed: 9HXVaoEwdoysHKrshUfRc3DPIrgSTnnvpRyMAFjxWVA=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-026.yml b/docs/reqs/trp/TRP-026.yml
new file mode 100644
index 0000000..b86d764
--- /dev/null
+++ b/docs/reqs/trp/TRP-026.yml
@@ -0,0 +1,16 @@
+active: true
+comments: ''
+defect_category: '[0-4]'
+defect_description: ''
+derived: false
+header: ''
+level: 1.25
+links:
+- TST-026: sRJYL8ruh8ih5cZEcz9CjU9VaqXNS-u8emf9MXK7EC4=
+normative: true
+ref: ''
+reviewed: Zhg6hmfo_Yj3RSvrPamD84pa-xLu1wm4KjxZVNypu28=
+test_date: 27-11-2023
+tester: AAT
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-027.yml b/docs/reqs/trp/TRP-027.yml
new file mode 100644
index 0000000..276d1ee
--- /dev/null
+++ b/docs/reqs/trp/TRP-027.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not implemented for the Aplha version.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.26
+links:
+- TST-027: mk69LZaNtemlErTk8WTnQO_wYjnktPZ_eV34WhqCeA8=
+normative: true
+ref: ''
+reviewed: MkyQ8NHlf5PJrqLLaCxFszgn0PLRo2WYzKbG951x4q8=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-028.yml b/docs/reqs/trp/TRP-028.yml
new file mode 100644
index 0000000..edc7d2e
--- /dev/null
+++ b/docs/reqs/trp/TRP-028.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not implemented for the Alpha version.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.27
+links:
+- TST-028: ohprmL0D2Bov_eSjdBUamXgtjAqANs4_xocAzg5PJFI=
+normative: true
+ref: ''
+reviewed: flRqN2GSJ6GC5w6FdP_CGuaIIAYjFahVc7zfI3ghLNQ=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-029.yml b/docs/reqs/trp/TRP-029.yml
new file mode 100644
index 0000000..3aafe82
--- /dev/null
+++ b/docs/reqs/trp/TRP-029.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not addressed in the Alpha phase.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.28
+links:
+- TST-029: DKHByIZAoK8LXh7u566D8Zwev0tXebajKnIfc-F1IVo=
+normative: true
+ref: ''
+reviewed: vgMirlkCbkTA_57g0-de0oO1ugOIzYdrBPHoY0Jwmis=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-030.yml b/docs/reqs/trp/TRP-030.yml
new file mode 100644
index 0000000..44bcb5b
--- /dev/null
+++ b/docs/reqs/trp/TRP-030.yml
@@ -0,0 +1,16 @@
+active: true
+comments: ''
+defect_category: '0'
+defect_description: ''
+derived: false
+header: ''
+level: 1.29
+links:
+- TST-030: O6kA73mUefnZlfLf42-dkIY0d-zIyvQMs6ltyMTW3ek=
+normative: true
+ref: ''
+reviewed: i-zViep2P-3_0zmhRCQq9TvnP7FVQ_Lqlot9h78OBiE=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-031.yml b/docs/reqs/trp/TRP-031.yml
new file mode 100644
index 0000000..3aadafe
--- /dev/null
+++ b/docs/reqs/trp/TRP-031.yml
@@ -0,0 +1,17 @@
+active: true
+comments: |
+ Interpreted as c5dec capturing the CC concepts and showing them in a correct and coherent manner.
+defect_category: '0'
+defect_description: ''
+derived: false
+header: ''
+level: '1.30'
+links:
+- TST-031: 8vescwGks6BqYTsrdMnR9DUTJftorw4-bIfJryQ6UII=
+normative: true
+ref: ''
+reviewed: V9EN-2cnZG88ugiBvtRo5lPMzulDRuA_1_tItv4IE7k=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-032.yml b/docs/reqs/trp/TRP-032.yml
new file mode 100644
index 0000000..9d3a862
--- /dev/null
+++ b/docs/reqs/trp/TRP-032.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not implemented for the aplha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.31
+links:
+- TST-032: UlPQ0eHgP1l1J5wkKIaKhnPxlheMl8sWjPk6MEWhZdA=
+normative: true
+ref: ''
+reviewed: ZwXlePCxi5Z7v8Y0oTfPl99UvESO1QSEERQh-MzjY94=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-033.yml b/docs/reqs/trp/TRP-033.yml
new file mode 100644
index 0000000..b2096f8
--- /dev/null
+++ b/docs/reqs/trp/TRP-033.yml
@@ -0,0 +1,16 @@
+active: true
+comments: ''
+defect_category: '0'
+defect_description: ''
+derived: false
+header: ''
+level: 1.32
+links:
+- TST-033: NiYWo2IZNKnXJ1sWdad1C5BNraHyKb4a95M4wXAKZnk=
+normative: true
+ref: ''
+reviewed: Q8CUZ72PWgO7jP5XTQhrX91PkKKyK4oPh4FAgmckp5o=
+test_date: 29-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/TRP-034.yml b/docs/reqs/trp/TRP-034.yml
new file mode 100644
index 0000000..c7d781a
--- /dev/null
+++ b/docs/reqs/trp/TRP-034.yml
@@ -0,0 +1,16 @@
+active: true
+comments: Not implemented for the Alpha release.
+defect_category: n/a
+defect_description: ''
+derived: false
+header: ''
+level: 1.33
+links:
+- TST-034: DqHYPEYpgyPIk4WqQdsHd_g16tERnbgY02RQ-NoTC0g=
+normative: true
+ref: ''
+reviewed: _b3sXlFlJ0P4NejpeeUjiGdKsZIAPMQr4QKe6D_aLUE=
+test_date: 27-11-2023
+tester: IVS
+text: |
+ Test execution results for the TST in the parent link.
diff --git a/docs/reqs/trp/evidence/testReport001.md b/docs/reqs/trp/evidence/testReport001.md
new file mode 100644
index 0000000..1810ed3
--- /dev/null
+++ b/docs/reqs/trp/evidence/testReport001.md
@@ -0,0 +1,81 @@
+
+
+# FDP User data protection
+
+
+
+## FC-INTRODUCTION
+
+This class contains families specifying requirements related to protecting user data. [fdp]() is split into four groups of families (listed below) that address user data within a TOE, during import, export, and storage as well as security attributes directly related to user data.
+The families in this class are organised into four groups:
+1. User data protection security function policies:
+- [fdp_acc]() ; and
+- [fdp_ifc]() .
+Components in these families permit the PP/ST author to name the user data protection security function policies and define the scope of control of the policy, necessary to address the security objectives. The names of these policies are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an "access control SFP" or an "information flow control SFP". The rules that define the functionality of the named access control and information flow control SFPs will be defined in the [fdp_acf]() and [fdp_iff]() families (respectively).
+2. Forms of user data protection:
+- [fdp_acf]() ;
+- [fdp_iff]() ;
+- [fdp_itt]() ;
+- [fdp_rip]() ;
+- [fdp_rol]() ; and
+- [fdp_sdi]() .
+
+3. Off-line storage, import and export:
+- [fdp_dau]() ;
+- [fdp_etc]() ;
+- [fdp_itc]() .
+Components in these families address the trustworthy transfer into or out of the TOE.
+4. Inter-TSF communication:
+- [fdp_uct]() ; and
+- [fdp_uit]() .
+Components in these families address communication between the TSF of the TOE and another trusted IT product.
+
+
+
+## FC-INFORMATIVE-NOTES
+
+This class contains families specifying requirements related to protecting user data. This class differs from FIA and FPT in that [fdp]() specifies components to protect user data, FIA specifies components to protect attributes associated with the user, and FPT specifies components to protect TSF information.
+The class does not contain explicit requirements for traditional Mandatory Access Controls (MAC) or traditional Discretionary Access Controls (DAC); however, such requirements may be constructed using components from this class.
+ [fdp]() does not explicitly deal with confidentiality, integrity, or availability, as all three are most often intertwined in the policy and mechanisms. However, the TOE security policy must adequately cover these three objectives in the PP/ST.
+A final aspect of this class is that it specifies access control in terms of ``operations''. An operation is defined as a specific type of access on a specific object. It depends on the level of abstraction of the PP/ST author whether these operations are described as ``read'' and/or ``write'' operations, or as more complex operations such as ``update the database''.
+The access control policies are policies that control access to the information container. The attributes represent attributes of the container. Once the information is out of the container, the accessor is free to modify that information, including writing the information into a different container with different attributes. By contrast, an information flow policies controls access to the information, independent of the container. The attributes of the information, which may be associated with the attributes of the container (or may not, as in the case of a multi-level database) stay with the information as it moves. The accessor does not have the ability, in the absence of an explicit authorisation, to change the attributes of the information.
+This class is not meant to be a complete taxonomy of IT access policies, as others can be imagined. Those policies included here are simply those for which current experience with actual systems provides a basis for specifying requirements. There may be other forms of intent that are not captured in the definitions here.
+For example, one could imagine a goal of having user-imposed (and user-defined) controls on information flow (e.g. an automated implementation of the NO FOREIGN handling caveat). Such concepts could be handled as refinements of, or extensions to the [fdp]() components.
+Finally, it is important when looking at the components in [fdp]() to remember that these components are requirements for functions that may be implemented by a mechanism that also serves or could serve another purpose. For example, it is possible to build an access control policy ( [fdp_acc]() ) that uses labels ( [fdp_iff.1]() ) as the basis of the access control mechanism.
+A set of SFRs may encompass many security function policies (SFPs), each to be identified by the two policy oriented components [fdp_acc]() , and [fdp_ifc]() . These policies will typically take confidentiality, integrity, and availability aspects into consideration as required, to satisfy the TOE requirements. Care should be taken to ensure that all objects are covered by at least one SFP and that there are no conflicts arising from implementing the multiple SFPs.
+When building a PP/ST using components from the [fdp]() class, the following information provides guidance on where to look and what to select from the class.
+The requirements in the [fdp]() class are defined in terms of a set of SFRs that will implement a SFP. Since a TOE may implement multiple SFPs simultaneously, the PP/ST author must specify the name for each SFP, so it can be referenced in other families. This name will then be used in each component selected to indicate that it is being used as part of the definition of requirements for that SFP. This allows the author to easily indicate the scope for operations such as objects covered, operations covered, authorised users, etc.
+Each instantiation of a component can apply to only one SFP. Therefore if an SFP is specified in a component then this SFP will apply to all the elements in this component. The components may be instantiated multiple times within a PP/ST to account for different policies if so desired.
+The key to selecting components from this family is to have a well defined set of TOE security objectives to enable proper selection of the components from the two policy components; [fdp_acc]() and [fdp_ifc]() . In [fdp_acc]() and [fdp_ifc]() respectively, all access control policies and all information flow control policies are named. Furthermore the scope of control of these components in terms of the subjects, objects and operations covered by this security functionality. The names of these policies are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an ``access control SFP'' or an ``information flow control SFP''. The rules that define the functionality of the named access control and information flow control SFPs will be defined in the [fdp_acf]() and [fdp_iff]() families (respectively).
+The following steps are guidance on how this class is applied in the construction of a PP/ST:
+1. Identify the policies to be enforced from the [fdp_acc]() , and [fdp_ifc]() families. These families define scope of control for the policy, granularity of control and may identify some rules to go with the policy.
+2. Identify the components and perform any applicable operations in the policy components. The assignment operations may be performed generally (such as with a statement ``All files'') or specifically (``The files ``A'', ``B'', etc.) depending upon the level of detail known.
+3. Identify any applicable function components from the [fdp_acf]() and [fdp_iff]() families to address the named policy families from [fdp_acc]() and [fdp_ifc]() . Perform the operations to make the components define the rules to be enforced by the named policies. This should make the components fit the requirements of the selected function envisioned or to be built.
+4. Identify who will have the ability to control and change security attributes under the function, such as only a security administrator, only the owner of the object, etc. Select the appropriate components from [fmt]() and perform the operations. Refinements may be useful here to identify missing features, such as that some or all changes must be done via trusted path.
+5. Identify any appropriate components from the [fmt]() for initial values for new objects and subjects.
+6. Identify any applicable rollback components from the [fdp_rol]() family.
+7. Identify any applicable residual information protection requirements from the [fdp_rip]() family.
+8. Identify any applicable import or export components, and how security attributes should be handled during import and export, from the [fdp_itc]() and [fdp_etc]() families.
+9. Identify any applicable internal TOE communication components from the [fdp_itt]() family.
+10. Identify any requirements for integrity protection of stored information from the [fdp_sdi]() .
+11. Identify any applicable inter-TSF communication components from the [fdp_uct]() or [fdp_uit]() families.
+
+
+
+## FDP_ACC Access control policy
+
+
+
+### FF-BEHAVIOUR
+
+This family identifies the access control SFPs (by name) and defines the scope of control of the policies that form the identified access control portion of the SFRs related to the SFP. This scope of control is characterised by three sets: the subjects under control of the policy, the objects under control of the policy, and the operations among controlled subjects and controlled objects that are covered by the policy. The criteria allows multiple policies to exist, each having a unique name. This is accomplished by iterating components from this family once for each named access control policy. The rules that define the functionality of an access control SFP will be defined by other families such as [fdp_acf]() and [fdp_etc]() . The names of the access control SFPs identified here in [fdp_acc]() are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an ``access control SFP.''
+
+
+### FF-USER-NOTES
+
+This family is based upon the concept of arbitrary controls on the interaction of subjects and objects. The scope and purpose of the controls is based upon the attributes of the accessor (subject), the attributes of the container being accessed (object), the actions (operations) and any associated access control rules.
+The components in this family are capable of identifying the access control SFPs (by name) to be enforced by the traditional Discretionary Access Control (DAC) mechanisms. It further defines the subjects, objects and operations that are covered by identified access control SFPs. The rules that define the functionality of an access control SFP will be defined by other families, such as [fdp_acf]() and [fdp_etc]() . The names of the access control SFPs defined in [fdp_acc]() are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an ``access control SFP.''
+The access control SFP covers a set of triplets: subject, object, and operations. Therefore a subject can be covered by multiple access control SFPs but only with respect to a different operation or a different object. Of course the same applies to objects and operations.
+A critical aspect of an access control function that enforces an access control SFP is the ability for users to modify the attributes involved in access control decisions. The [fdp_acc]() family does not address these aspects. Some of these requirements are left undefined, but can be added as refinements, while others are covered elsewhere in other families and classes such as [fmt]() .
+There are no audit requirements in [fdp_acc]() as this family specifies access control SFP requirements. Audit requirements will be found in families specifying functions to satisfy the access control SFPs identified in this family.
+This family provides a PP/ST author the capability to specify several policies, for example, a fixed access control SFP to be applied to one scope of control, and a flexible access control SFP to be defined for a different scope of control. To specify more than one access control policy, the components from this family can be iterated multiple times in a PP/ST to different subsets of operations and objects. This will accommodate TOEs that contain multiple policies, each addressing a particular set of operations and objects. In other words, the PP/ST author should specify the required information in the ACC component for each of the access control SFPs that the TSF will enforce. For example, a TOE incorporating three access control SFPs, each covering only a subset of the objects, subjects, and operations within the TOE, will contain one [fdp_acc.1]() component for each of the three access control SFPs, necessitating a total of three [fdp_acc.1]() components.
diff --git a/docs/reqs/trp/evidence/trp-002-ev.png b/docs/reqs/trp/evidence/trp-002-ev.png
new file mode 100644
index 0000000..1787e2f
Binary files /dev/null and b/docs/reqs/trp/evidence/trp-002-ev.png differ
diff --git a/docs/reqs/tst/.doorstop.yml b/docs/reqs/tst/.doorstop.yml
new file mode 100644
index 0000000..875fee8
--- /dev/null
+++ b/docs/reqs/tst/.doorstop.yml
@@ -0,0 +1,32 @@
+attributes:
+ defaults:
+ platform: 'WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04'
+ roles: ''
+ authors: ''
+ precondition: ''
+ expected_outcome: 'None'
+ verification_method: ''
+ success_criteria: 'SRS acceptance criteria fulfilled and expected outcome observed.'
+ text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+ publish:
+ platform: 'Windows'
+ roles: ''
+ authors: ''
+ precondition: ''
+ expected_outcome: ''
+ verification_method: ''
+ reviewed:
+ - authors
+ - precondition
+ - expected_outcome
+ - verification_method
+settings:
+ digits: 3
+ itemformat: yaml
+ parent: SRS
+ prefix: TST
+ sep: '-'
diff --git a/docs/reqs/tst/TST-001.yml b/docs/reqs/tst/TST-001.yml
new file mode 100644
index 0000000..ad938d0
--- /dev/null
+++ b/docs/reqs/tst/TST-001.yml
@@ -0,0 +1,31 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: |
+ - No errors encountered while browsing the database.
+ - Randomly sampled selection data corresponds to description in the respective Common Criteria PDF.
+header: |
+ Test accessing and browsing the CC Database
+level: 1.0
+links:
+- SRS-001: dCx_-csCEJzWtIkSBNzFqVdxq3TCZ3CF-bAxGPqVDss=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: c5dec installed
+ref: ''
+reference:
+- path: c5dec/assets/database/KnowledgeBase/0_MapofContent.md
+ type: file
+reviewed: fTtVrZP5ou5-ojL9NEHb4SXkX31-RI3HlPQMmUXmtc8=
+roles: None
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. boot C5-DEC CAD
+ 2. navigate to '3 - CCT: Common Criteria toolbox' > 'Browse Common Criteria'
+ ## Test Steps
+ 1. follow steps in SRS
+ 2. on a random basis check (for at least 3 elements) that the displayed data corresponds to the
+ associated Common Criteria element in the official PDFs of version 3.1 R5: [CC Part 2](https://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R5.pdf) or [CC Part 3](https://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf).
+verification_method: Test
diff --git a/docs/reqs/tst/TST-002.yml b/docs/reqs/tst/TST-002.yml
new file mode 100644
index 0000000..a74250e
--- /dev/null
+++ b/docs/reqs/tst/TST-002.yml
@@ -0,0 +1,29 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test query the CC Database
+level: 1.1
+links:
+- SRS-002: SnlNBh-f9Yik8w5FiTFN4sTpG7GromzSCSEshVfS7W8=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: C5Dec installed
+ref: ''
+reference:
+- path: c5dec/assets/database/KnowledgeBase/0_MapofContent.md
+ type: file
+reviewed: pFip8DcsY-Ms554dYV1jZwBwHAYdrBKTRAB0CFAmQPk=
+roles: None
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. boot C5-DEC CAD
+ 2. navigate to '3 - CCT: Common Criteria toolbox' > 'Common Criteria Browser'
+ ## Test Steps:
+ 1. follow the steps in SRS
+ 2. repeat steps multiple times for different queries (at least 5) and match displayed content
+ with respective Common Criteria PDF (version 3R5).
+verification_method: Test
diff --git a/docs/reqs/tst/TST-003.yml b/docs/reqs/tst/TST-003.yml
new file mode 100644
index 0000000..364139c
--- /dev/null
+++ b/docs/reqs/tst/TST-003.yml
@@ -0,0 +1,33 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: |
+ File containing respective Security Requirements correctly\ \ exported according to specified settings
+header: |
+ Test exporting Security Components
+level: 1.2
+links:
+- SRS-003: GxAi28c9B25ZAeY4Ur1ZxEEr32jK5Z_87LvRU0TnKqs=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: |
+ - a working doorstop repository
+ref: ''
+reference:
+- path: c5dec/assets/database/KnowledgeBase/0_MapofContent.md
+ type: file
+reviewed: qS5QsBpyDPKBgKFdFpPdR2JSGkRLzkib9a3hSVXWka8=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. In the TUI, go to '3 - CCT: Common Criteria toolbox'
+ 2. Select 'Browse Common Criteria' or 'Create Evaluation Checklist'
+
+ ## Test Steps
+ 1. follow steps in SRS
+ 2. repeat multiple times and change selection and export settings.
+ 3. on a random basis check that the exported Security Requirements match respective Security Requirements
+ in Common Criteria PDF (version 3R5).
+verification_method: Test
diff --git a/docs/reqs/tst/TST-004.yml b/docs/reqs/tst/TST-004.yml
new file mode 100644
index 0000000..fc64490
--- /dev/null
+++ b/docs/reqs/tst/TST-004.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test tailoring Security Requirements
+level: 1.3
+links:
+- SRS-004: GoMpr-Orqy_F_iiXk2mntn8G-9geOhBFBqLVU9DIcvA=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reference:
+- path: c5dec/assets/database/KnowledgeBase/0_MapofContent.md
+ type: file
+reviewed: _-FwjX1gLLZXzJtGbSvsddZ_M0OXJ2hGz3-OE8JB_kI=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ TBD
+verification_method: ''
diff --git a/docs/reqs/tst/TST-005.yml b/docs/reqs/tst/TST-005.yml
new file mode 100644
index 0000000..14e19c9
--- /dev/null
+++ b/docs/reqs/tst/TST-005.yml
@@ -0,0 +1,27 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test navigating the Knowledge Base
+level: 1.4
+links:
+- SRS-014: RoD7_A5sGPfmsFgccJUmQYPQ3_v6_PZQ9Gc9l_4bW4o=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reference:
+- path: c5dec/assets/database/KnowledgeBase/0_MapofContent.md
+ type: file
+reviewed: Uxgykcbo5o-gM44ggsdH_d23v70CD2vBRV9LN2jv-hs=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ - None
+ ## Test steps
+ 1. follow steps in SRS
+ 2. repeat for multiple Knowledge Articles
+verification_method: Review
diff --git a/docs/reqs/tst/TST-006.yml b/docs/reqs/tst/TST-006.yml
new file mode 100644
index 0000000..79b749a
--- /dev/null
+++ b/docs/reqs/tst/TST-006.yml
@@ -0,0 +1,27 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test comprehensiveness of Knowledge Base
+level: 1.5
+links:
+- SRS-016: 8XfEjPWLBs3Z3FXaJ6T3v4h2cv3kPgqb2LvQw4xRKHE=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reference:
+- path: c5dec/assets/database/KnowledgeBase/0_MapofContent.md
+ type: file
+reviewed: i6OvspOOcMzIWPd2T2c5c8IzBrFX0vtQ8tuNSEBnyjw=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ - None
+ ## Test steps
+ 1. follow steps in SRS
+ 2. repeat for multiple Knowledge Articles
+verification_method: Review
diff --git a/docs/reqs/tst/TST-007.yml b/docs/reqs/tst/TST-007.yml
new file mode 100644
index 0000000..e92d9db
--- /dev/null
+++ b/docs/reqs/tst/TST-007.yml
@@ -0,0 +1,27 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test interconnection of Knowledge Base
+level: 1.6
+links:
+- SRS-016: 8XfEjPWLBs3Z3FXaJ6T3v4h2cv3kPgqb2LvQw4xRKHE=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reference:
+- path: c5dec/assets/database/KnowledgeBase/0_MapofContent.md
+ type: file
+reviewed: ETtOs7bLPlHk5UJxj4gwqFmkl29e5TpiXTiF97YI40E=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS
+ 2. repeat for multiple Knowledge Articles
+verification_method: Review
diff --git a/docs/reqs/tst/TST-008.yml b/docs/reqs/tst/TST-008.yml
new file mode 100644
index 0000000..5188ea5
--- /dev/null
+++ b/docs/reqs/tst/TST-008.yml
@@ -0,0 +1,27 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test currency of Knowledge Base
+level: 1.7
+links:
+- SRS-017: lkpaGqulUhQdwJa3_iwDJ97s8VcmZZZBKRUGL5iL0Wo=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reference:
+- path: c5dec/assets/database/KnowledgeBase/0_MapofContent.md
+ type: file
+reviewed: BR9Iz1WnyoYw7dWxCr65GDfqz98wLzVQW-nxdkXehvc=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS
+ 2. repeat for multiple Knowledge Articles
+verification_method: Review
diff --git a/docs/reqs/tst/TST-009.yml b/docs/reqs/tst/TST-009.yml
new file mode 100644
index 0000000..c7c3096
--- /dev/null
+++ b/docs/reqs/tst/TST-009.yml
@@ -0,0 +1,29 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test cosmetic features of Knowledge Base
+level: 1.8
+links:
+- SRS-019: hjpgGBRUFMCBiLs1Yx-ejz9_I8XGJ7PNvMwMfuHROMw=
+- SRS-020: hg2fieiPR901RGxPs3GQ1RCfmpdylHiXbTDRZLsk38g=
+- SRS-021: 1W4cAnCfpoYv2NPH6Xr9PZ3Vb7aci2T2U9kYBmYFg00=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reference:
+- path: c5dec/assets/database/KnowledgeBase/0_MapofContent.md
+ type: file
+reviewed: U3MDJM1tHSR9t-xE1np2VbH9qO9I7dtxOKh8khio6Tk=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS'
+ 2. repeat for multiple Knowledge Articles
+verification_method: ''
diff --git a/docs/reqs/tst/TST-010.yml b/docs/reqs/tst/TST-010.yml
new file mode 100644
index 0000000..f2dfe41
--- /dev/null
+++ b/docs/reqs/tst/TST-010.yml
@@ -0,0 +1,40 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Inspect CC Database-DTD mapping
+level: 1.9
+links:
+- SRS-022: hsyVqqzuUw4TiipPek_omXOypBZnP6hcqHAC5sILBXg=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+references:
+- keyword: TST-010
+ path: c5dec/core/cct.py
+ type: file
+- path: c5dec/assets/database/SecurityControls/cc3R5.xml
+ type: file
+reviewed: 4nZhUfu_ttBzXJPXKNFRn0RnkoHbaW2ExAsWI9xa5KQ=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. Inspect source code 'cct.py' and verify that each '!ELEMENT' in the CC DTD is correctly implemented,
+ i.e, verify that:
+
+ - each '!ELEMENT' is implemented as a class object,
+ - '#REQUIRED' attributes are implemented as object attributes and populated
+ with the object's _build_attributes() method.
+ - child elements of each '!ELEMENT' are implemented as object attributes and populated with the object's
+ _build_children() method.
+ - each object's is_valid() method validates that the required attributes (labelled as
+ '#REQUIRED' in the DTD) are (correctly) populated.
+ - semantic relationships between CC concepts are preserved in the implementation, i.e., hierarchical and
+ dependency relationships between CC concepts are appropriately implemented, e.g., as parent-child relations.
+verification_method: Inspection
diff --git a/docs/reqs/tst/TST-011.yml b/docs/reqs/tst/TST-011.yml
new file mode 100644
index 0000000..95674e9
--- /dev/null
+++ b/docs/reqs/tst/TST-011.yml
@@ -0,0 +1,34 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: |
+ Exported or viewed data correctly reflects content and relationships as defined in the CC PDF.
+header: |
+ Test correctness of CC Database
+level: '1.10'
+links:
+- SRS-022: hsyVqqzuUw4TiipPek_omXOypBZnP6hcqHAC5sILBXg=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: h2nTYC5RBf5QU-r_w-B-EoCXFkuO5YDDh3hBJmdo0hw=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. Use the CLI to export CC objects using
+
+ `$ poetry run c5dec view #to print to console`
+
+ `$ poetry run c5dec view > /.md # to export to markdown`
+
+ 2. Use the TUI to view CC objects
+
+ - navigate to '3 - CCT: Common Criteria Toolbox' > 'Common Criteria Browser'
+
+ ## Test steps
+ 1. Export or view mulitple CC objects either via CLI or TUI and check that content and relationships
+ correspond to the Common Criteria PDF.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-012.yml b/docs/reqs/tst/TST-012.yml
new file mode 100644
index 0000000..4a8eba0
--- /dev/null
+++ b/docs/reqs/tst/TST-012.yml
@@ -0,0 +1,38 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: All exported CC XML files are valid and identical.
+header: |
+ Test validity and conistency of bidirectional transformation
+level: 1.11
+links:
+- SRS-022: hsyVqqzuUw4TiipPek_omXOypBZnP6hcqHAC5sILBXg=
+- SRS-023: po_uqA52zR1C6Iw7xGtURFZiEyEv6diJTDBJz-EFWaY=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: |
+ Validate any/all CC XML independently against the DTD file \ (./c5dec/assets/database/SecurityControls/cc3.xml)
+ref: ''
+reference:
+- path: c5dec/assets/database/SecurityControls/cc3R5.dtd
+ type: file
+- path: c5dec/assets/database/SecurityControls/cc3R5.xml
+ type: file
+reviewed: DpTWevcvTWRQEovj5pNLsbs13oI0yaej4HtsRegRsaA=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup:
+ 1. None
+ ## Test steps:
+ 1. Export CC Document stored in the internal data representation to XML (cc_export1.xml)
+ 2. Validate the exported XML against the CC DTD.
+ 3. Load the exported and validated XML into the internal data representation.
+ 4. Again export the loaded CC Document to XML (cc_export2.xml) and validate against the CC DTD.
+ 5. Repeat if desired.
+ 6. Verify that all _exported_ XMLs are identical.
+
+ Note: Exported XML files will differ from the official CC XML since irrelevant information (e.g., patchinfos
+ legalnotice, pagebreaks, biblioentries, glossentries, etc.) are ignored.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-013.yml b/docs/reqs/tst/TST-013.yml
new file mode 100644
index 0000000..2129e1c
--- /dev/null
+++ b/docs/reqs/tst/TST-013.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test threats, risks, and countermeasures database
+level: 1.12
+links:
+- SRS-024: 7xdUBEWVbLPamiSERNZDv6Vww5nTmT_tSXozVFFJKbM=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: ABbKof9ExiQknCgFWtvjoo15w5oQJiXCXIcXJnL0cDg=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-014.yml b/docs/reqs/tst/TST-014.yml
new file mode 100644
index 0000000..c3245d3
--- /dev/null
+++ b/docs/reqs/tst/TST-014.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test EUCC support
+level: 1.13
+links:
+- SRS-025: IUXCzx1E8awGA1BXH2yJfbXd0_5R4HVmwYBHxNi-2ZE=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: R4pblsuJrebNuzzogARRHCwmkC4tY0_oYTYjGyhzXzs=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-015.yml b/docs/reqs/tst/TST-015.yml
new file mode 100644
index 0000000..e1060ca
--- /dev/null
+++ b/docs/reqs/tst/TST-015.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test availabilty of CSA Article 51 defined Security Objectives
+level: 1.14
+links:
+- SRS-026: Xo4a9HqO6d_NO-mzXv8OGUXFWIDJ2byPLxeC_tGra5c=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: jFDEprqLM_xo0jFlPCjP23SI9HkytMXJsom0JCP7y6o=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-016.yml b/docs/reqs/tst/TST-016.yml
new file mode 100644
index 0000000..9a013bd
--- /dev/null
+++ b/docs/reqs/tst/TST-016.yml
@@ -0,0 +1,25 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: |
+ All internally stored CC artefacts are stored in C5-DEC's document-based data storage format and can be managed centrally.
+header: |
+ Test uniformity of storage mechanisms in CCT module
+level: 1.15
+links:
+- SRS-027: RP9s9-Up362V_vczpcdWWcSdGdfFMIghwmR-rhVNuD8=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: dVnkrQm91uhRk6VvcQspiZGRhw1MYEhQbBjik1XWn00=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS
+ 2. repeat for multiple items.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-017.yml b/docs/reqs/tst/TST-017.yml
new file mode 100644
index 0000000..817f472
--- /dev/null
+++ b/docs/reqs/tst/TST-017.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test automated rationale and traceability matrix generation
+level: 1.16
+links:
+- SRS-028: WKBWkkI3zun60jKbQwufr0kvN5AgLBl8lNB_A0ELPAw=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: 1Xnyd8tiNByuJMigb8VG47o4l_BjnIHS-Tb_RJgToZY=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-018.yml b/docs/reqs/tst/TST-018.yml
new file mode 100644
index 0000000..ad16f73
--- /dev/null
+++ b/docs/reqs/tst/TST-018.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test verificaiton of rationales and traceability matrices
+level: 1.17
+links:
+- SRS-029: GCZ978A0xDicJRZNS-e2iDyqq3YFBDTTdcfniX8QD4Q=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: h_f-vQa3YLg4x8o6DCtZdckdyADKEUgHebKN7NshFe0=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS
+verification_method: Test
diff --git a/docs/reqs/tst/TST-019.yml b/docs/reqs/tst/TST-019.yml
new file mode 100644
index 0000000..ce08c2f
--- /dev/null
+++ b/docs/reqs/tst/TST-019.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test automated consistency and completeness checks
+level: 1.18
+links:
+- SRS-030: eK1g58chyNHYp5DdO5exafOMQv1IRfFH-uIeEz6ouYU=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: SSa0aMpVw5ycOIQf81ZynEW5-i0UBbbIgo0NORC27wA=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS
+verification_method: Test
diff --git a/docs/reqs/tst/TST-020.yml b/docs/reqs/tst/TST-020.yml
new file mode 100644
index 0000000..847432a
--- /dev/null
+++ b/docs/reqs/tst/TST-020.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test automated validation
+level: 1.19
+links:
+- SRS-031: tTQmzrLV437b8znwrn58ga6Bm3SQaevXchwOi-QPeoc=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: QhcWuw5L4ov1vFQ-rBH9PezrD_FEq9G55Q2Jv28kCcg=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-021.yml b/docs/reqs/tst/TST-021.yml
new file mode 100644
index 0000000..c615dfd
--- /dev/null
+++ b/docs/reqs/tst/TST-021.yml
@@ -0,0 +1,33 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test aggregation of SARs and Work Units
+level: '1.20'
+links:
+- SRS-032: u3Hy6ebLC2IcGYPMxQFeP1tjI5G3F4EF7BMSYa0e-Lw=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: Evaluation checklist created and stored.
+ref: ''
+reviewed: Um0xGdTbxh88cjlaF67Ts9U6WJx6dwU2ZdeyaMw_N2c=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1.a Using the TUI navigate to '3 - CCT: Common Criteria toolbox' > 'Evaluation Checklist'
+ and load an Evaluation Checklist.
+
+ 1.b Using the CLI run the following command to list all Evaluation items.
+
+ `$ poetry run c5dec checklist -l`
+
+ To select an Item run:
+ `$ poetry run c5dec checklist --edit [--editor code]`
+
+ ## Test steps
+ 1. Follow steps in SRS.
+ 2. Repeat for multiple SARs.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-022.yml b/docs/reqs/tst/TST-022.yml
new file mode 100644
index 0000000..1bc4625
--- /dev/null
+++ b/docs/reqs/tst/TST-022.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test API provision for threat import
+level: 1.21
+links:
+- SRS-033: Oc5SHAwIDg460JzE2MYq02h2EGCvzwUU8Qgl4ctcTZ4=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: g9VPiY95CUkFSJVNe708x4QjC4YGsVpxICiqt_qdNYE=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-023.yml b/docs/reqs/tst/TST-023.yml
new file mode 100644
index 0000000..8999be4
--- /dev/null
+++ b/docs/reqs/tst/TST-023.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test transforming imported threats to CC-conformant format
+level: 1.22
+links:
+- SRS-034: I8riA7dHoEfrDS8LaY733xlz46tXo9GEIVtzV1I5Mfc=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: sAcxS28wCGRU38fzOTe5dh4Jp3Q9lBCdHMtZGduppCI=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-024.yml b/docs/reqs/tst/TST-024.yml
new file mode 100644
index 0000000..9f5ac12
--- /dev/null
+++ b/docs/reqs/tst/TST-024.yml
@@ -0,0 +1,35 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: |
+ - Successfully created Evaluation Checklist for the 'valid set'- 'Invalid set' successfully detected to be invalid.- Successfully created Evaluation Checklist for the 'augmented set' - Evaluation Evidence Documentation Index created for valid sets and stored under './evaluations/'
+header: |
+ Test automated creation of Evaluation Checklist
+level: 1.23
+links:
+- SRS-035: gv3htUnEjsI8BY8MF04gnxOu1FKsPteuyHlWbFpig-k=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: Q1wEe2aG_NKR1Ku45M8nB3ydnbrsnWgZsmogbviJObs=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. when using the TUI navigate to '3 - CCT: Common Criteria Toolbox' > 'Create Evaluation Checklist'
+ 2. when using the CLI run the following command
+
+ `foo@bar$ poetry run c5dec checklist -c --id `
+
+ Valid set: ACO_COR.1, ACO_DEV.1, ACO_REL.1, ALC_CMC.1, ALC_CMS.1
+
+ Invalid Set: ACO_COR.1, ACO_DEV.1, ALC_CMC.1, ALC_CMS.1
+
+ Augmented Set: EAL 1, ACO_DEV.1, ACO_REL.1
+
+ ## Test steps
+ 1. follow steps in SRS for the selections above.
+ 2. OPTIONAL: follow steps in SRS for a randomly selected set of components.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-025.yml b/docs/reqs/tst/TST-025.yml
new file mode 100644
index 0000000..098c436
--- /dev/null
+++ b/docs/reqs/tst/TST-025.yml
@@ -0,0 +1,32 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test evaluation progress tracking
+level: 1.24
+links:
+- SRS-036: bKXI2jic62eAYgemB-XXSs5wd8C_2cECvAcq5iKlEJ8=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: Run TST-024 prior to have access to an Evaluation Checklist.
+ref: ''
+reviewed: f_WcJUTovKa2FzYlqElg_cv6ok2C0XySgwNodlKhO_g=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. when using the TUI navigate to '3 - CCT: Common Criteria Toolbox' > 'Evaluation Checklist'
+ 2. when using the CLI run the following commands
+
+ `$ poetry run c5dec checklist -s` # returns current status
+
+ `$ poetry run c5dec checklist -l` # returns list of Evaluation items.
+
+ `$ poetry run c5dec checklist --edit ` # edit Evaluation Item
+
+ ## Test steps
+ 1. follow steps in SRS.
+ 2. repeat for multiple Evaluation Items.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-026.yml b/docs/reqs/tst/TST-026.yml
new file mode 100644
index 0000000..99ed442
--- /dev/null
+++ b/docs/reqs/tst/TST-026.yml
@@ -0,0 +1,33 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test Work Unit-Artifact linking
+level: 1.25
+links:
+- SRS-037: 2RZWZluL1Q4u_B6n0QGYX0Z3oQu1hTOmkEa9xs3w0_M=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: Run TST-024 prior to have access to an Evaluation Checklist.
+ref: ''
+reviewed: TW5nCndXj6Lyx2hfDcSftiDQN8xgrn4OOsmO7gjCJXs=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. when using the TUI navigate to '3 - CCT: Common Criteria Toolbox' > 'Evaluation Checklist'
+ 2. when using the CLI run the following commands
+
+ `$ poetry run c5dec checklist -s` # returns current status
+
+ `$ poetry run c5dec checklist -l` # returns list of Evaluation items.
+
+ `$ poetry run c5dec checklist --edit ` # edit Evaluation Item
+
+ `$ poetry run c5dec view `
+
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-027.yml b/docs/reqs/tst/TST-027.yml
new file mode 100644
index 0000000..dcb077f
--- /dev/null
+++ b/docs/reqs/tst/TST-027.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test automated generation of Observation Reports
+level: 1.26
+links:
+- SRS-038: rCjZhb-4GRBbWnF60Y0Z3jaLWc1wYfVj9bh3jrCHxI8=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: Run TST-024 prior to have access to an Evaluation Checklist.
+ref: ''
+reviewed: jveUIdhotZGcsIQImS9avIy9IjwyolqG36aM1mG4-xM=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-028.yml b/docs/reqs/tst/TST-028.yml
new file mode 100644
index 0000000..5209963
--- /dev/null
+++ b/docs/reqs/tst/TST-028.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test automated generation of Evaluation Technical Report
+level: 1.27
+links:
+- SRS-039: BREaK5CnJUWPw5DKec9dTponU6yZ1SIR1FnUSjh_-Os=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: Run TST-024 prior to have access to an Evaluation Checklist.
+ref: ''
+reviewed: iwfgoeB6ibKq_W3YZt1UPbGhft-jONguqEQQjws0PMU=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-029.yml b/docs/reqs/tst/TST-029.yml
new file mode 100644
index 0000000..ba10966
--- /dev/null
+++ b/docs/reqs/tst/TST-029.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test flagging failed Work Units and affected artifacts
+level: 1.28
+links:
+- SRS-040: 9BsBkRnTunnS_hIHhvE6jVuldokGJAZuMrWjFWZOfHY=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: Run TST-024 prior to have access to an Evaluation Checklist.
+ref: ''
+reviewed: AeAOuHMC9m4yjva_MF80r38Q84WDujVJPHzTnGZiwek=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-030.yml b/docs/reqs/tst/TST-030.yml
new file mode 100644
index 0000000..168e4cc
--- /dev/null
+++ b/docs/reqs/tst/TST-030.yml
@@ -0,0 +1,38 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test auditability of Evaluation Items
+level: 1.29
+links:
+- SRS-041: xxpIxB0VtEWO0ZxYm_tQJwdAWofYIdMDQQHqhY5KyKQ=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: Run TST-024 prior to have access to an Evaluation Checklist.
+ref: ''
+reviewed: QHheu9OYvLPx1MQ0gjMMuzjgg2kv01XprEYR_i6WzD4=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ - when using the TUI navigate to '3 - CCT: Common Criteria Toolbox' > 'Evaluation Checklist'
+ 1. Load Evaluation Checklist
+ 2. randomly select Evaluation Items and edit these to set a verdict.
+
+ - when using the CLI
+ 1. run the following command for several Evaluation Items and edit their verdicts
+
+ `$ poetry run c5dec checklist --edit [--editor code]`
+
+ 2. manually update the Evaluation Checklist with
+ `$ poetry run c5dec checklist --update`
+
+ ## Test steps
+ 1. Verify that index.json `./evaluations//index.json` correctly reflects the changes, i.e.,
+ hash value and verdict matches the 'reviewed' and 'verdict' value of the corresponding item.
+ 2. Verify that changes are correctly reflected in corresponding Doorstop items.
+ 3. Logging inherently covered by git, e.g., by using
+ `$ git log --follow -p -- ./path/to/file.ext`
+verification_method: Test
diff --git a/docs/reqs/tst/TST-031.yml b/docs/reqs/tst/TST-031.yml
new file mode 100644
index 0000000..c70f18f
--- /dev/null
+++ b/docs/reqs/tst/TST-031.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test extended data model
+level: '1.30'
+links:
+- SRS-042: EhaZ4l1m8OFg6C5nev3s4f_wBZnn7LKoY-DS7W7B0hs=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: 6ZJ1FMlSlIboZMRVpYNh9KLFqCDtHKqXtJWT8qTIrvI=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-032.yml b/docs/reqs/tst/TST-032.yml
new file mode 100644
index 0000000..176f02c
--- /dev/null
+++ b/docs/reqs/tst/TST-032.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test CC templates
+level: 1.31
+links:
+- SRS-043: 27TZF9KlOlUfF-UzrvAF_D2QMlfz5XpwHq4nGXaKaY0=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: QkJKuS_FhfW3nMv5uqRpeBOSkYf3jjAbQUFX01_5S7w=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/reqs/tst/TST-033.yml b/docs/reqs/tst/TST-033.yml
new file mode 100644
index 0000000..f85ad98
--- /dev/null
+++ b/docs/reqs/tst/TST-033.yml
@@ -0,0 +1,31 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: |
+ - Valid selections are detected as valid selections.\n - invalid selection are detected to be invalid and the potentially valid set matches the\ respective corrected set
+header: |
+ Test validation of hierarchies and dependencies of Security Component sets
+level: 1.32
+links:
+- SRS-044: eJtIRK6nH7V5KuV5Rb_IbhZ4opTQxOfmPaBjr8yVplo=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: 5FZiJWeyCbQFFku43wVrI1fO8ZytYbOQEdhYqW0b8Js=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. In the TUI navigate to '3 - CCT: Common Criteria Toolbox' > 'Create Evaluation Checklist'
+
+ ## Test steps
+ 1. Select items from the following component sets and validate that the expectations in the SRS are met:
+ - valid: ACO_COR.1 ACO_DEV.1 ACO_REL.1 ALC_CMS.1 ALC_CMC.1
+ - valid (EAL2): ADV_ARC.1 ADV_FSP.2 ADV_TDS.1 AGD_OPE.1 AGD_PRE.1 ALC_CMC.2 ALC_DEL.1 ASE_INT.1 ASE_CCL.1 ASE_SPD.1 ASE_OBJ.2 ASE_ECD.1 ASE_REQ.2 ASE_TSS.1 ATE_COV.1 ATE_FUN.1 ATE_IND.2 AVA_VAN.2
+ - invalid: ADV_ARC.1 ADV_FSP.2 ADV_TDS.1 AGD_OPE.1 AVA_VAN.2
+ corrected: ADV_ARC.1 ADV_FSP.2 ADV_TDS.1 AGD_OPE.1 AGD_PRE.1 AVA_VAN.2
+ - invalid: ACO_COR.1 ACO_DEV.1 ACO_REL.1
+ corrected: see first set
+verification_method: Test
diff --git a/docs/reqs/tst/TST-034.yml b/docs/reqs/tst/TST-034.yml
new file mode 100644
index 0000000..3b8360e
--- /dev/null
+++ b/docs/reqs/tst/TST-034.yml
@@ -0,0 +1,23 @@
+active: true
+authors: Heinrich
+derived: false
+expected_outcome: None
+header: |
+ Test generation of Impact Analysis Report
+level: 1.33
+links:
+- SRS-045: 1EYh6IXxfvN4HUdy9PAJQVs9Mkr4gqvvLPA2onPBqiw=
+normative: true
+platform: WSL/GNU/Linux Ubuntu 20/Linux Ubuntu 22.04
+precondition: ''
+ref: ''
+reviewed: B3oXqnKAKDdsXpUv8oNvbBQFGpBkFVrAp63mkQhK2-I=
+roles: ''
+success_criteria: |
+ SRS acceptance criteria fulfilled and expected outcome observed.
+text: |
+ ## Setup
+ 1. None
+ ## Test steps
+ 1. follow steps in SRS.
+verification_method: Test
diff --git a/docs/sdd/image/cad_context_diagram.png b/docs/sdd/image/cad_context_diagram.png
new file mode 100644
index 0000000..4cd1ad3
Binary files /dev/null and b/docs/sdd/image/cad_context_diagram.png differ
diff --git a/docs/sdd/image/cct_class_diagram.png b/docs/sdd/image/cct_class_diagram.png
new file mode 100644
index 0000000..36b1b5c
Binary files /dev/null and b/docs/sdd/image/cct_class_diagram.png differ
diff --git a/docs/sdd/image/classes.png b/docs/sdd/image/classes.png
new file mode 100644
index 0000000..4afa1e1
Binary files /dev/null and b/docs/sdd/image/classes.png differ
diff --git a/docs/sdd/image/functional_tree.png b/docs/sdd/image/functional_tree.png
new file mode 100644
index 0000000..a59b035
Binary files /dev/null and b/docs/sdd/image/functional_tree.png differ
diff --git a/docs/sdd/image/packages.png b/docs/sdd/image/packages.png
new file mode 100644
index 0000000..e70c375
Binary files /dev/null and b/docs/sdd/image/packages.png differ
diff --git a/docs/sdd/image/subsystems.png b/docs/sdd/image/subsystems.png
new file mode 100644
index 0000000..ab1dbea
Binary files /dev/null and b/docs/sdd/image/subsystems.png differ
diff --git a/docs/sdd/image/system_architecture.png b/docs/sdd/image/system_architecture.png
new file mode 100644
index 0000000..24ff359
Binary files /dev/null and b/docs/sdd/image/system_architecture.png differ
diff --git a/docs/sdd/plantUML/baseclasses.puml b/docs/sdd/plantUML/baseclasses.puml
new file mode 100644
index 0000000..b086af9
--- /dev/null
+++ b/docs/sdd/plantUML/baseclasses.puml
@@ -0,0 +1,370 @@
+@startuml classes
+set namespaceSeparator none
+
+
+skinparam linetype ortho
+skinparam dpi 300
+skinparam nodesep 50
+skinparam ranksep 50
+
+left to right direction
+
+title "c5dec.core.cct"
+
+note right of BaseClass {
+ "If not explicitly indicated otherwise all Classes presented here inherit from BaseClass"
+}
+
+class "BaseClass" as BaseClass {
+ attrib
+ children : list
+ container : list
+ parent : NoneType
+ text : str
+ clone()
+ collector(target, mode)
+ contains(element)
+ get_ancestors()
+ get_child_by_id(child_id)
+ get_children()
+ get_descendants(visited)
+ get_formatted_text(level)
+ get_item_tree(pretty_print)
+ get_parent()
+ get_siblings()
+ has_valid_id()
+ has_valid_name()
+ is_empty()
+ is_valid()
+}
+rectangle "Assurance" {
+ class "AClass" as AClass {
+ ac_application_notes : NoneType
+ ac_introduction : NoneType
+ ac_overview : NoneType
+ family : list
+ ma_application_note : NoneType
+ ma_introduction : NoneType
+ ma_objectives : NoneType
+ is_valid()
+ }
+ class "AFamily" as AFamily {
+ af_application_notes : NoneType
+ af_levelling_criteria : NoneType
+ af_objectives : NoneType
+ af_overview : NoneType
+
+ is_valid()
+ }
+ class "AComponent" as AComponent {
+ aco_application_notes : NoneType
+ aco_objectives : NoneType
+ dependencies : list
+ elements : list
+ hierarchical : list
+ input
+ msa_application_notes : NoneType
+ msa_input : NoneType
+ msa_objectives : NoneType
+ get_dependency_pool(d_pool, visited)
+ get_formatted_text(level)
+ get_hierarchical_tree(h_tree, visited)
+ is_valid()
+ }
+ class "AElement" as AElement {
+ VALID_TYPES : list
+ list : list
+ operation : list
+ requirement : str
+ type : NoneType
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "WorkUnit" as WorkUnit {
+ dc_element : list[DCElement]
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "DCElement" as DCElement {
+ }
+
+}
+
+rectangle "Functional" {
+ class "FClass" as FClass {
+ family
+ fc_informative_notes : NoneType
+ fc_introduction : NoneType
+ is_valid()
+ }
+ class "FFamily" as FFamily {
+
+ ff_application_notes : NoneType
+ ff_behaviour : NoneType
+ ff_evaluator_notes : NoneType
+ ff_user_notes : NoneType
+ is_valid()
+ }
+ class "FComponent" as FComponent {
+ audit : NoneType
+ dependencies : list
+ element
+ fco_evaluator_notes : NoneType
+ fco_levelling : NoneType
+ fco_rationale : NoneType
+ fco_user_notes : NoneType
+ hierarchical : list
+ management : NoneType
+ get_dependency_pool(d_pool, visited)
+ get_formatted_text(level)
+ get_hierarchical_tree(h_tree, visited)
+ is_valid()
+ }
+ class "FCoAudit" as FCoAudit {
+ VALID_LEVEL : list
+ isequal : NoneType
+ level : str
+ text : str
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "FCoManagement" as FCoManagement {
+ isequal : NoneType
+ text : str
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "FElement" as FElement {
+ list : NoneType
+ operation : list
+ requirement : str
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "Operation" as Operation {
+ VALID_TYPES : list
+ exclusive : str
+ item : list
+ note : NoneType
+ type : NoneType
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "FEItem" as FEItem {
+ list : list
+ operation : list
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "FEList" as FEList {
+ item : list
+ get_formatted_text(level)
+ is_valid()
+ }
+}
+
+rectangle "Common" {
+ class "ParaSequence" as ParaSequence {
+ acronym : list
+ attrib
+ biblioentry : list
+ container : list
+ example : list
+ figure : list
+ glossentry : list
+ original_tag : NoneType
+ para : list
+ parent : NoneType
+ subclause : list
+ table : list
+ text : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ class "Clause" as Clause {
+ VALID_CATEGORY : list
+ VALID_TYPES : list
+ attrib
+ category : str
+ original_tagname_
+ parent : NoneType
+ patch : NoneType
+ title : NoneType
+ type : str
+ get_formatted_text(level)
+ }
+ class "SubClause" as SubClause {
+ attrib
+ parent : NoneType
+ patch : NoneType
+ title : NoneType
+ get_formatted_text(level)
+ }
+ class "Para" as Para {
+ VALID_TYPES : tuple
+ attrib
+ container : list
+ level : str
+ parent : NoneType
+ patch : NoneType
+ text : str
+ title : NoneType
+ type : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ class "List" as List {
+ VALID_TYPE : list
+ container : list
+ item : list
+ parent : NoneType
+ text : str
+ type : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ class "Item" as Item {
+ container : list
+ parent : NoneType
+ text : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ class "Table" as Table {
+ container : list
+ original_tag
+ parent : NoneType
+ tgroup : list
+ title : NoneType
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ class "TGroup" as TGroup {
+ cols : int
+ original_tag
+ parent : NoneType
+ tbody : NoneType, list
+ tfoot : list, NoneType
+ thead : list, NoneType
+ build(node, parent_obj)
+ get_formatted_text()
+ }
+ class "TEntry" as TEntry {
+ align : str
+ columnspan : int
+ container : list
+ original_tag
+ parent : NoneType
+ rowspan : int
+ style : NoneType
+ width : int
+ build(node, parent_obj)
+ get_formatted_text()
+ }
+ class "TRow" as TRow {
+ entry : list
+ original_tag
+ parent : NoneType
+ build(node, parent_obj)
+ get_formatted_text(columns)
+ }
+ class "Example" as Example {
+ exampledef : NoneType
+ exampleterm : NoneType
+ original_tag
+ parent : NoneType
+ build(node, parent_obj)
+ }
+ class "Text" as Text {
+ text : NoneType
+ empty_text()
+ get_formatted_text(level)
+ is_valid()
+ set_text(value)
+ }
+
+ Clause -down-|> ParaSequence
+ SubClause -up-|> ParaSequence
+}
+
+
+Assurance -left- BaseClass
+Functional -right- BaseClass
+Common -up- BaseClass
+
+
+
+class "Bold" as Bold {
+ text : str
+ get_formatted_text(level)
+}
+
+class "CCDocument" as CCDocument {
+ a_class : list
+ cap : list
+ clause : list
+ eal : list
+ f_class : list
+ lang : str
+ revision : NoneType
+ version : NoneType
+ is_valid()
+}
+
+
+class "Italic" as Italic {
+ text : str
+ get_formatted_text(level)
+}
+
+
+class "Math" as Math {
+ text : NoneType
+ get_formatted_text(level)
+}
+
+class "Package" as Package {
+ acronym : NoneType
+ assurance_s : NoneType
+ children : list
+ s
+ objectives : NoneType
+ type : str
+ get_descendants(visited)
+ get_formatted_text(level)
+ is_valid()
+ link_s()
+}
+class "URL" as URL {
+ attrib
+ parent : NoneType
+ text : str
+ title : NoneType
+ build(node, parent_obj)
+ get_formatted_text(level)
+}
+
+class "XRef" as XRef {
+ VALID_SHOW : list
+ container : list
+ fakeid : NoneType
+ parent : NoneType
+ show : str
+ tail : NoneType
+ text : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+}
+
+
+
+
+
+
+
+
+@enduml
diff --git a/docs/sdd/plantUML/cad_context_diagram.png b/docs/sdd/plantUML/cad_context_diagram.png
new file mode 100644
index 0000000..4cd1ad3
Binary files /dev/null and b/docs/sdd/plantUML/cad_context_diagram.png differ
diff --git a/docs/sdd/plantUML/cad_context_diagram.puml b/docs/sdd/plantUML/cad_context_diagram.puml
new file mode 100644
index 0000000..05e312b
--- /dev/null
+++ b/docs/sdd/plantUML/cad_context_diagram.puml
@@ -0,0 +1,41 @@
+@startuml
+skinparam componentStyle rectangle
+skinparam linetype ortho
+
+[\n\n\nC5-DEC CAD\n front-end\n (CLI,TUI,GUI)\n\n\n] as cad
+
+[Developer] --> cad
+[Analyst] --> cad
+[Tester] --> cad
+[Project\nManager] --> cad
+
+
+[Open data store] -left-> [git]
+[Transformer] -down-> [Open data store]
+cad -up-> [Transformer]
+cad -up-> [Open data store]
+cad -right-> [REM]
+cad -right-> [V&V]
+cad -right-> [CC Toolbox]
+cad -right-> [Cryptography]
+cad -right-> [PM]
+cad -right-> [ISMS]
+cad -down-> [System artifact\nmanagement]
+
+[System artifact\nmanagement] -right-> [Open data store]
+[System artifact\nmanagement] -right-> [Cyber-physical\nsystem security\nanalysis]
+[System artifact\nmanagement] -right-> [REM]
+[System artifact\nmanagement] -r-> [V&V]
+[System artifact\nmanagement] -r-> [ISMS]
+[System artifact\nmanagement] -r-> [PM]
+[System artifact\nmanagement] -r-> [Cryptography]
+[System artifact\nmanagement] -r-> [CC Toolbox]
+[System artifact\nmanagement] --> [Cloud-based SW\ndev platforms\n(GitHub, GitLab)]
+
+[Threat\nmodelling and\nanalysis] --> [Open data store]
+[Cyber-physical\nsystem security\nanalysis] --> [Threat\nmodelling and\nanalysis]
+[Cyber-physical\nsystem security\nanalysis] --> [Risk management\nand assessment]
+[Risk management\nand assessment] --> [Open data store]
+
+
+@enduml
\ No newline at end of file
diff --git a/docs/sdd/plantUML/cct_class_diagram.puml b/docs/sdd/plantUML/cct_class_diagram.puml
new file mode 100644
index 0000000..3033e7a
--- /dev/null
+++ b/docs/sdd/plantUML/cct_class_diagram.puml
@@ -0,0 +1,516 @@
+@startuml cct
+set namespaceSeparator none
+
+
+skinparam WrapWidth 200
+skinparam linetype ortho
+skinparam dpi 300
+skinparam nodesep 5
+skinparam ranksep 30
+
+left to right direction
+
+
+title "Class Diagram: c5dec.core.cct"
+
+rectangle "Base Classes" as Base {
+ class "BaseClass" as BaseClass {
+ attrib
+ children : list
+ container : list
+ parent : NoneType
+ text : str
+ clone()
+ collector(target, mode)
+ contains(element)
+ get_ancestors()
+ get_child_by_id(child_id)
+ get_children()
+ get_descendants(visited)
+ get_formatted_text(level)
+ get_item_tree(pretty_print)
+ get_parent()
+ get_siblings()
+ has_valid_id()
+ has_valid_name()
+ is_empty()
+ is_valid()
+ }
+ class "BaseBuilder" as BaseBuilder {
+ instance
+ build(node, parent_obj)
+ }
+
+ BaseClass -[hidden]down- BaseBuilder
+}
+
+rectangle "Support Classes" as Support {
+ class "Index" as Index {
+ clear()
+ get(key)
+ keys()
+ update(key, value)
+ yield_obj(obj_type)
+ }
+ class "UniqueIDManager" as UniqueIDManager {
+ next(prefix)
+ reset()
+ }
+ class "CLIChecklistHandler" as CLIChecklistHandler {
+ create(version, item_ids, prefix, info, silence)
+ edit(prefix, _id)
+ list(prefix)
+ publish(prefix, path, template)
+ status(prefix)
+ update(prefix)
+ validate(prefix)
+ }
+ Index -[hidden]down- CLIChecklistHandler
+}
+
+
+rectangle "Common Criteria" {
+ together {
+ class "CCDocument" as CCDocument <> {
+ clause : list
+ a_class : list
+ f_class : list
+ cap : list
+ eal : list
+ lang : str
+ revision : NoneType
+ version : NoneType
+ is_valid()
+ }
+ class "CCDocumentBuilder" as CCDocumentBuilder <> {
+ build(node, parent_obj)
+ }
+ }
+ together {
+ class "Package" as Package <> {
+ acronym : NoneType
+ assurance_components : NoneType
+ objectives : NoneType
+ type : str
+ link_components()
+ get_descendants(visited)
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "PackageBuilder" as PackageBuilder <> {
+ }
+ }
+
+ CCDocument -[hidden]down- Package
+
+ rectangle "Assurance Components" {
+ together {
+ class "AClass" as AClass <> {
+ ac_application_notes : ParaSequence
+ ac_introduction : ParaSequence
+ ac_overview : ParaSequence
+ family : list[FFamily]
+ ma_application_note : ParaSequence
+ ma_introduction : ParaSequence
+ ma_objectives : ParaSequence
+ is_valid()
+ }
+ class "AClassBuilder" as AClassBuilder <>
+ }
+ together {
+ class "AFamily" as AFamily <> {
+ af_application_notes : ParaSequence
+ af_levelling_criteria : ParaSequence
+ af_objectives : ParaSequence
+ af_overview : ParaSequence
+ component: list[FComponent]
+ is_valid()
+ }
+ class "AFamilyBuilder" as AFamilyBuilder <>
+ }
+ together {
+ class "AComponent" as AComponent <> {
+ aco_application_notes : ParaSequence
+ aco_objectives : ParaSequence
+ dependencies : list[str]
+ elements : list[FElement]
+ hierarchical : list[str]
+ input
+ msa_application_notes : ParaSequence
+ msa_input : ParaSequence
+ msa_objectives : ParaSequence
+ get_dependency_pool(d_pool, visited)
+ get_formatted_text(level)
+ get_hierarchical_tree(h_tree, visited)
+ is_valid()
+ }
+ class "AComponentBuilder" as AComponentBuilder <>
+ }
+ together {
+ class "AElement" as AElement <> {
+ VALID_TYPES : list
+ list : list[List]
+ operation : list[Operation]
+ requirement : str
+ type : NoneType
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "AElementBuilder" as AElementBuilder <> {
+ build(node, parent_obj)
+ }
+ }
+ together {
+ class "WorkUnit" as WorkUnit <> {
+ dc_element : list[DCElement]
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "WorkUnitBuilder" as WorkUnitBuilder <>
+ class "DCElement" as DCElement {
+ _id : str
+ }
+ }
+
+ AClass -[hidden]- AFamily
+ AFamily -[hidden]- AComponent
+ AComponent -[hidden]- AElement
+ AElement -[hidden]- WorkUnit
+ }
+
+ rectangle "Functional Components" {
+ together {
+ class "FClass" as FClass <> {
+ family : list[FFamily]
+ fc_informative_notes : ParaSequence
+ fc_introduction : ParaSequence
+ is_valid()
+ }
+ class "FClassBuilder" as FClassBuilder <>
+ }
+ together {
+ class "FFamily" as FFamily <> {
+
+ ff_application_notes : ParaSequence
+ ff_behaviour : ParaSequence
+ ff_evaluator_notes : ParaSequence
+ ff_user_notes : ParaSequence
+ is_valid()
+ }
+ class "FFamilyBuilder" as FFamilyBuilder <>
+ }
+ together {
+ class "FComponent" as FComponent <> {
+ audit : FCoAudit
+ dependencies : list[str]
+ element : list[FElement]
+ fco_evaluator_notes : ParaSequence
+ fco_levelling : ParaSequence
+ fco_rationale : ParaSequence
+ fco_user_notes : ParaSequence
+ hierarchical : list[str]
+ management : FCoManagement
+ get_dependency_pool(d_pool, visited)
+ get_formatted_text(level)
+ get_hierarchical_tree(h_tree, visited)
+ is_valid()
+ }
+ class "FComponentBuilder" as FComponentBuilder <>
+ }
+ together {
+ class "FCoAudit" as FCoAudit <> {
+ VALID_LEVEL : list
+ isequal : NoneType
+ level : str
+ text : str
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "FCoAuditBuilder" as FCoAuditBuilder <> {
+ build(node, parent_obj)
+ }
+ }
+ together {
+ class "FCoManagement" as FCoManagement <> {
+ isequal : NoneType
+ text : str
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "FCoManagementBuilder" as FCoManagementBuilder <> {
+ build(node, parent_obj)
+ }
+ }
+ together {
+ class "FElement" as FElement <> {
+ list : list[FEList]
+ operation : list[Operation]
+ requirement : str
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "FElementBuilder" as FElementBuilder <> {
+ build(node, parent_obj)
+ }
+ }
+ together {
+ class "Operation" as Operation <> {
+ VALID_TYPES : list
+ exclusive : str
+ item : list[FEItem]
+ note : ParaSequence
+ type : NoneType
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "OperationBuilder" as OperationBuilder <> {
+ build(node, parent_obj)
+ }
+ }
+ together {
+ class "FEItem" as FEItem <> {
+ list : list[FEList]
+ operation : list[Operation]
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "FEItemBuilder" as FEItemBuilder <> {
+ build(node, parent_obj)
+ }
+ }
+ together {
+ class "FEList" as FEList <> {
+ item : list[FEItem]
+ get_formatted_text(level)
+ is_valid()
+ }
+ class "FEListBuilder" as FEListBuilder <> {
+ build(node, parent_obj)
+ }
+ }
+ FClass -[hidden]- FFamily
+ FFamily -[hidden]- FComponent
+ FComponent -[hidden]- FElement
+ FElement -[hidden]- Operation
+ Operation -[hidden]right- FEItem
+ Operation -[hidden]left- FEList
+
+ FCoAudit -[hidden]- FCoManagement
+ FEList -[hidden]- FEItem
+ }
+
+
+ rectangle "Common Components" {
+ class "ParaSequence" as ParaSequence <> {
+ acronym : list
+ attrib
+ biblioentry : list
+ container : list
+ example : list[Example]
+ figure : list
+ glossentry : list
+ original_tag : NoneType
+ para : list[Para]
+ parent : NoneType
+ subclause : list[SubClause]
+ table : list[Table]
+ text : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ class "Clause" as Clause <> {
+ VALID_CATEGORY : list
+ VALID_TYPES : list
+ attrib
+ category : str
+ original_tagname_
+ parent : NoneType
+ patch : NoneType
+ title : NoneType
+ type : str
+ get_formatted_text(level)
+ }
+ class "SubClause" as SubClause <> {
+ attrib
+ parent : NoneType
+ patch : NoneType
+ title : NoneType
+ get_formatted_text(level)
+ }
+ class "Para" as Para <> {
+ VALID_TYPES : tuple
+ attrib
+ container : list
+ level : str
+ parent : NoneType
+ patch : NoneType
+ text : str
+ title : NoneType
+ type : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ class "List" as List <> {
+ VALID_TYPE : list
+ container : list
+ item : list[Item]
+ parent : NoneType
+ text : str
+ type : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ class "Item" as Item <> {
+ container : list
+ parent : NoneType
+ text : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ together {
+ class "Table" as Table <> {
+ container : list
+ original_tag
+ parent : NoneType
+ tgroup : list[TGroup]
+ title : NoneType
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ class "TGroup" as TGroup <> {
+ cols : int
+ original_tag
+ parent : NoneType
+ tbody : list[TRow]
+ tfoot : list[TRow]
+ thead : list[TRow]
+ build(node, parent_obj)
+ get_formatted_text()
+ }
+ class "TRow" as TRow <> {
+ entry : list[TEntry]
+ original_tag
+ parent : NoneType
+ build(node, parent_obj)
+ get_formatted_text(columns)
+ }
+ class "TEntry" as TEntry <> {
+ align : str
+ columnspan : int
+ container : list
+ original_tag
+ parent : NoneType
+ rowspan : int
+ style : NoneType
+ width : int
+ build(node, parent_obj)
+ get_formatted_text()
+ }
+ }
+ class "Example" as Example <> {
+ exampledef : Para()
+ exampleterm : Para()
+ original_tag
+ parent : NoneType
+ build(node, parent_obj)
+ }
+ together {
+ class "Text" as Text <> {
+ text : NoneType
+ empty_text()
+ get_formatted_text(level)
+ is_valid()
+ set_text(value)
+ }
+ class "Bold" as Bold <> {
+ text : str
+ get_formatted_text(level)
+ }
+ class "Italic" as Italic <> {
+ text : str
+ get_formatted_text(level)
+ }
+ class "Math" as Math <> {
+ text : NoneType
+ get_formatted_text(level)
+ }
+ }
+
+ together {
+ class "URL" as URL <> {
+ attrib
+ parent : NoneType
+ text : str
+ title : NoneType
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+
+ class "XRef" as XRef <> {
+ VALID_SHOW : list
+ container : list
+ fakeid : NoneType
+ parent : NoneType
+ show : str
+ tail : NoneType
+ text : str
+ build(node, parent_obj)
+ get_formatted_text(level)
+ }
+ }
+
+ Clause -down-|> ParaSequence
+ SubClause -up-|> ParaSequence
+
+ ParaSequence -[hidden]left- Para
+ Para -[hidden]down- URL
+ Clause -[hidden]left- Example
+ SubClause -[hidden]down- List
+ List -[hidden]left- Item
+ Italic -[hidden]down- Table
+ Table -[hidden]down- TGroup
+ TGroup -[hidden]down-TRow
+
+ Text <|-down- Bold
+ Text <|-- Italic
+ Text <|-- Math
+ }
+}
+
+
+
+!procedure $create_icon($node, $text, $font_size, $icon_color, $bkg_color, $scale)
+ {{\nscale $scale\nleft to right direction\nskinparam BackgroundColor $bkg_color\nskinparam $node {\nBackgroundColor $icon_color\nFontSize $font_size\n}\n$node "$text"\n}}
+!endprocedure
+
+map Legend {
+'{{\nscale 0.5\nleft to right direction\nskinparam BackgroundColor azure\nskinparam ClassBackgroundColor lightblue\nskinparam ClassFontSize 10\nclass "BaseClass"\n}} => \nBaseClass\n
+$create_icon(class, BaseClass, 15, lightblue, azure, "0.4") => \nBaseClass Class\n
+$create_icon(class, BaseBuilder, 15, business, azure, "0.4") => \nBaseBuilder Class\n
+}
+
+BaseBuilder -[hidden]- UniqueIDManager
+CLIChecklistHandler -[hidden]- Legend
+@enduml
diff --git a/docs/sdd/plantUML/classes.puml b/docs/sdd/plantUML/classes.puml
new file mode 100644
index 0000000..1317060
--- /dev/null
+++ b/docs/sdd/plantUML/classes.puml
@@ -0,0 +1,280 @@
+@startuml classes
+set namespaceSeparator none
+
+skinparam linetype ortho
+skinparam dpi 300
+skinparam nodesep 40
+skinparam ranksep 10
+
+title "Class Diagram"
+
+together {
+ rectangle "c5dec.core" {
+ rectangle "isms" {
+ class ActivityReport {
+ activity_report : dict
+ author : str
+ authors
+ beginning_date : int
+ folders : dict
+ path : str
+ get_activity_report()
+ get_authors()
+ get_date_and_event(folder, file)
+ get_days_in_month(month, year)
+ get_user(filename)
+ save_to_csv(csv_file)
+ scandir()
+ set_date(months, days, hours)
+ }
+ class WordTagProcessor {
+ csv_path
+ default_link : str
+ doc
+ doc_path
+ ignore_missing_tag_mapping : bool
+ keep_style : bool
+ output_name : str
+ params_are_set : bool
+ paras
+ regex_text : str
+ tag_dictionary : NoneType
+ tag_regex
+ convert_tags_to_hyperlinks(keep_style)
+ create_hyperlink_element(p, link)
+ create_hyperlink_run(hyperlink_element, link_text, para, run)
+ create_run_element()
+ create_text_element(text)
+ delete_para(p)
+ extend_para(p, text, tag, link, skip_tag)
+ process_paras_for_tags()
+ read_csv_into_dict(filepath)
+ rebuild_para(p, text1, tag, text2, link)
+ rebuild_paras_for_tags()
+ set_params(doc_path, csv_path, regex_text, ignore_missing_tag)
+ }
+ class DocListAssistant {
+ doc_scan_path : str
+ doclist : list
+ doclist_path : str
+ folders : dict
+ unlisted_docs : list
+ used_filename_column_name : str
+ get_unlisted_docs()
+ save_to_csv(csv_file)
+ scandir()
+ }
+ ActivityReport -[hidden]- WordTagProcessor
+ }
+
+ rectangle "pm" {
+ class TimeReportAssistant {
+ apply_filters : bool
+ consolidated_tsh_df : NoneType
+ df : NoneType
+ filter_field : str
+ filter_field_value : str
+ from_date : NoneType
+ input_file_path : str
+ to_date : NoneType
+ tsh_folder_path : str
+ add_missing_columns(df)
+ clean_consolidated_dataframe()
+ consolidate_timesheets()
+ convert_openproject_time_report_to_IAL_format()
+ extract_time_interval(df, start_col_name, end_col_name, duration_col_name)
+ get_staff_acronyms_dictionary()
+ get_timerep_fields()
+ make_date_field(row)
+ read_csv_to_df(csv_path) -> pd.DataFrame
+ read_tshparams_config_into_dict()
+ replace_key_with_value_in_df_column(dataframe, df_col_name, key_list, value_list)
+ save_consolidated_tsh_df_to_excel() -> None
+ save_processed_timerep_df_to_excel() -> None
+ set_timerep_parameters(source_folder, apply_filters, from_date, to_date, filter_field, filter_field_value)
+ set_tsh_folder_path(path)
+ }
+ }
+
+ rectangle "cct" {
+ note right of cct {
+ "See 'Class Diagram: c5dec.core.cct"
+ }
+ }
+
+ pm -[hidden]down- cct
+ cct -[hidden]right- isms
+ }
+
+ rectangle "c5dec.frontend" {
+
+ rectangle "tui" as TUI {
+ rectangle "foundation" {
+ rectangle "menu" {
+ class BaseView {
+ builder : NoneType
+ controller
+ data_model
+ menu_title : str
+ root_menu
+ assemble()
+ back()
+ clear_text_fields(field_list)
+ get_data_model()
+ get_menu_title()
+ get_value_from_json(key, default_value)
+ quit()
+ setController(controller)
+ set_data_model(model)
+ set_menu_title(title)
+ }
+ class Menu {
+ functions : dict
+ name
+ root_menu : NoneType
+ submenus : dict
+ add_function(name, classtype, data_model)
+ add_menu(name)
+ get_all_submenus()
+ get_functions()
+ get_nested_submenu(list)
+ get_path()
+ get_ref_to_app()
+ get_submenu(name)
+ get_submenus()
+ }
+ class MenuView {
+ builder
+ functions
+ listbox_functions : ListBox
+ listbox_submenus : ListBox
+ model
+ submenus
+ insert(widget, options)
+ launch_function()
+ launch_scene(widget_name, scene_list)
+ launch_submenu()
+ set_options()
+ }
+ class PopUpMenu {
+ builder : NoneType
+ palette : dict
+ assemble()
+ }
+ }
+ rectangle "builder" {
+ class Builder {
+ title
+ widgets : list
+ addButton(text, on_click, position, gap, gap_height, name)
+ addChoose(name, options, on_change, position, gap, gap_height)
+ addCopyButton(text_field, position)
+ addDivider(draw_line, height, position)
+ addDropdownList(label, name, options, on_change, position, gap, gap_height)
+ addLayout(list, fill_frame)
+ addListBox(name, height, options, parser, on_change, on_select, position)
+ addPath(label, name, position)
+ addResult(label, name, copyButton)
+ addStatusBar(span)
+ addTable(height, titles, options, columns, position, name)
+ addText(label, name, on_change, position, validator, gap, gap_height, disabled)
+ addTickBox(label, name, on_change, position)
+ addWidget(widget, position, span)
+ add_date_picker(name, label, on_change)
+ add_label(label, position, gap, gap_height, disabled)
+ add_textbox(label, name, height, on_change, position, gap, gap_height, readonly, disabled)
+ build()
+ copyToClipboard(text)
+ disable(widget)
+ enable(widget)
+ update(frame)
+ zipOfList(options)
+ }
+ }
+ }
+ rectangle "application" {
+ class Application {
+ data_models : dict
+ menu_view : NoneType
+ demo(screen, scene, menu)
+ get_data_model(name)
+ get_value_from_json(key, default_value)
+ run()
+ setLanguage(lang)
+ set_data_model(name, model)
+ }
+ }
+ }
+
+ rectangle "cli" {
+
+ }
+ }
+}
+
+
+rectangle "c5dec.common" {
+ class C5decError {
+ }
+ class C5decInfo {
+ }
+ class C5decWarning {
+ }
+ class Capture {
+ catch : bool
+ }
+ together {
+ class HelpFormatter {
+ }
+ class WarningFormatter {
+ default_format
+ verbose_format
+ format(record)
+ }
+ }
+ C5decInfo -up|> C5decWarning
+ C5decWarning -up|> C5decError
+
+}
+
+rectangle "c5dec.psi" {
+ rectangle "security" {
+ class InputValidation {
+ validate_input_with_regex(input, regex)
+ validate_integer_input(input)
+ }
+ }
+}
+
+c5dec.psi -[hidden]up- c5dec.common
+
+
+
+Application --|> Menu
+MenuView --|> BaseView
+Builder --* MenuView : builder
+MenuView --* Application : menu_view
+
+@enduml
diff --git a/docs/sdd/plantUML/functional_tree.puml b/docs/sdd/plantUML/functional_tree.puml
new file mode 100644
index 0000000..faab13f
--- /dev/null
+++ b/docs/sdd/plantUML/functional_tree.puml
@@ -0,0 +1,68 @@
+@startuml
+skinparam componentStyle rectangle
+skinparam linetype ortho
+skinparam {
+ defaultTextAlignment center
+ defaultFontSize 36
+ defaultFontName Corbel
+}
+
+
+[\nC5-DEC\n(Common Criteria for Cybersecurity, Crypto, Clouds - Design\nEvaluation and Certification)\n] as c5dec
+[\nC5-DEC CAD\n(C5-DEC Computer-Aided Design and Development)\n] as cad
+[\nC5-DEC KB\n(C5-DEC Knowledge Base)\n] as kb
+
+c5dec -down- cad
+c5dec -down- kb
+
+[\nDesign, Analysis & Development\n(Specifications, Modelling, and \nEvaluation)\n] as dad
+[\nCrypto\n(PQC, sign, PGP,\n secret sharing)\n] as crypto
+[\nCC Toolbox\n(SFR, SAR, ISO DBs,\n PP, ST, ETR)\n] as cct
+[\nPM\n(Project\n Management)\n] as pm
+[\n\nISMS\n\n] as isms
+[Transformer\n(Import/Export:\ncsv, xlsx, ReqIF,\nXML, md, TeX,\ndocx)] as trafo
+
+cad -down- dad
+cad -down- crypto
+cad -down- cct
+cad -down- pm
+cad -down- isms
+cad -down- trafo
+
+[\nSSDLC\n(Secure Software Development\nLife Cycle)\n] as ssdlc
+[\nSVVM\n(Software Verification and\nValidation Model)\n] as svvm
+[\nCPSSA\n(Cyber-Physical System\nSecurity Assessment)\n] as cpssa
+
+kb -down- ssdlc
+kb -down- svvm
+kb -down- cpssa
+
+[REM\n(Requirement\nEngineering\nand Management)\n] as rem
+[\nV&V\n(Verification and\nValidation)\n] as vandv
+[Specification\n(Diagrams, code,\nannotations,\nbinaries)\n] as spec
+[\nSecurity Analysis\n(Modelling and\nEvaluation)\n] as secana
+[\nGeneration Tools\n(Specificaiton,\nKB wiki)\n] as gen
+[CC: CEM\n(Tools for\nEvaluation\nMethodology)\n] as cccem
+[Resource\nManagement\n(time reports\nconversion,\nconsolidation)] as rm
+
+dad -down- rem
+dad -down- vandv
+dad -down- spec
+dad -down- secana
+cct -down- gen
+cct -down- cccem
+pm -down- rm
+
+[Test Management\n(Test cases,\ntest report,\nlinking to\nrequirements)] as tm
+[\nTraceability\n(Verification\nmatrix, RTM)\n] as trace
+[\nThreat Modelling\n& Analysis\n] as tma
+[\nRisk\nManagement\n] as risk
+
+vandv -down- tm
+vandv -down- trace
+secana -down- tma
+secana -down- risk
+
+
+
+@enduml
\ No newline at end of file
diff --git a/docs/sdd/plantUML/packages.plantuml b/docs/sdd/plantUML/packages.plantuml
new file mode 100644
index 0000000..fef9aab
--- /dev/null
+++ b/docs/sdd/plantUML/packages.plantuml
@@ -0,0 +1,150 @@
+@startuml packages
+set namespaceSeparator none
+
+skinparam linetype ortho
+skinparam dpi 300
+skinparam nodesep 50
+skinparam ranksep 50
+
+
+title "Packages"
+
+package "c5dec" as c5dec {
+}
+package "c5dec.common" as c5dec.common {
+}
+package "c5dec.settings" as c5dec.settings {
+}
+
+package "c5dec.core" as c5dec.core {
+}
+package "c5dec.core.cct" as c5dec.core.cct {
+}
+package "c5dec.core.cpssa" as c5dec.core.cpssa {
+}
+package "c5dec.core.cryptography" as c5dec.core.cryptography {
+}
+package "c5dec.core.cysecanalysis" as c5dec.core.cysecanalysis {
+}
+package "c5dec.core.isms" as c5dec.core.isms {
+}
+package "c5dec.core.pm" as c5dec.core.pm {
+}
+package "c5dec.core.settings" as c5dec.core.settings {
+}
+package "c5dec.core.ssdlc" as c5dec.core.ssdlc {
+}
+package "c5dec.core.transformer" as c5dec.core.transformer {
+}
+
+package "c5dec.frontend" as c5dec.frontend {
+}
+package "c5dec.frontend.cli" as c5dec.frontend.cli {
+}
+package "c5dec.frontend.cli.commands" as c5dec.frontend.cli.commands {
+}
+package "c5dec.frontend.cli.main" as c5dec.frontend.cli.main {
+}
+package "c5dec.frontend.cli.utils" as c5dec.frontend.cli.utils {
+}
+
+package "c5dec.frontend.tui" as c5dec.frontend.tui {
+}
+package "c5dec.frontend.tui.application" as c5dec.frontend.tui.application {
+}
+package "c5dec.frontend.tui.foundation" as c5dec.frontend.tui.foundation {
+}
+package "c5dec.frontend.tui.foundation.builder" as c5dec.frontend.tui.foundation.builder {
+}
+package "c5dec.frontend.tui.foundation.menu" as c5dec.frontend.tui.foundation.menu {
+}
+package "c5dec.frontend.tui.miniapps" as c5dec.frontend.tui.miniapps {
+}
+package "c5dec.frontend.tui.miniapps.cctapp" as c5dec.frontend.tui.miniapps.cctapp {
+}
+package "c5dec.frontend.tui.miniapps.cpssaapp" as c5dec.frontend.tui.miniapps.cpssaapp {
+}
+package "c5dec.frontend.tui.miniapps.cryptographyapp" as c5dec.frontend.tui.miniapps.cryptographyapp {
+}
+package "c5dec.frontend.tui.miniapps.cysecanalysisapp" as c5dec.frontend.tui.miniapps.cysecanalysisapp {
+}
+package "c5dec.frontend.tui.miniapps.ismsapp" as c5dec.frontend.tui.miniapps.ismsapp {
+}
+package "c5dec.frontend.tui.miniapps.pmapps" as c5dec.frontend.tui.miniapps.pmapp {
+}
+package "c5dec.frontend.tui.miniapps.settingsapp" as c5dec.frontend.tui.miniapps.settingsapp {
+}
+package "c5dec.frontend.tui.miniapps.ssdlcapp" as c5dec.frontend.tui.miniapps.ssdlcapp {
+}
+package "c5dec.frontend.tui.miniapps.transformerapp" as c5dec.frontend.tui.miniapps.transformerapp {
+}
+package "c5dec.frontend.tui.main" as c5dec.frontend.tui.main {
+}
+
+package "c5dec.psi" as c5dec.psi {
+}
+package "c5dec.psi.graph" as c5dec.psi.graph {
+}
+package "c5dec.psi.search" as c5dec.psi.search {
+}
+package "c5dec.psi.security" as c5dec.psi.security {
+}
+
+c5dec *-down- c5dec.common
+c5dec *-down- c5dec.settings
+c5dec *-down- c5dec.core
+c5dec *-down- c5dec.frontend
+c5dec *-down- c5dec.psi
+
+c5dec.core *-- c5dec.core.cct
+c5dec.core *-- c5dec.core.cpssa
+c5dec.core *-- c5dec.core.cryptography
+c5dec.core *-- c5dec.core.cysecanalysis
+c5dec.core *-- c5dec.core.isms
+c5dec.core *-- c5dec.core.pm
+c5dec.core *-- c5dec.core.ssdlc
+c5dec.core *-- c5dec.core.transformer
+c5dec.core *-- c5dec.core.settings
+
+c5dec.frontend *-- c5dec.frontend.cli
+c5dec.frontend *-- c5dec.frontend.tui
+
+c5dec.frontend.cli *-- c5dec.frontend.cli.commands
+c5dec.frontend.cli *-- c5dec.frontend.cli.main
+c5dec.frontend.cli *-- c5dec.frontend.cli.utils
+
+c5dec.frontend.tui *-- c5dec.frontend.tui.application
+c5dec.frontend.tui *-- c5dec.frontend.tui.main
+c5dec.frontend.tui *-- c5dec.frontend.tui.foundation
+c5dec.frontend.tui *-- c5dec.frontend.tui.miniapps
+
+c5dec.frontend.tui.foundation *-- c5dec.frontend.tui.foundation.builder
+c5dec.frontend.tui.foundation *-- c5dec.frontend.tui.foundation.menu
+
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.cctapp
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.cpssaapp
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.cryptographyapp
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.cysecanalysisapp
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.ismsapp
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.pmapp
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.settingsapp
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.ssdlcapp
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.transformerapp
+
+c5dec.psi *-down- c5dec.psi.graph
+c5dec.psi *-down- c5dec.psi.search
+c5dec.psi *-down- c5dec.psi.security
+
+
+
+c5dec.core.cct --> c5dec.common
+c5dec.core.cct --> c5dec.settings
+
+
+
+
+@enduml
diff --git a/docs/sdd/plantUML/packages.puml b/docs/sdd/plantUML/packages.puml
new file mode 100644
index 0000000..5feef80
--- /dev/null
+++ b/docs/sdd/plantUML/packages.puml
@@ -0,0 +1,268 @@
+@startuml packages
+set namespaceSeparator none
+hide stereotype
+skinparam title {
+ FontSize 80
+}
+skinparam map {
+ FontSize 35
+ BackgroundColor azure
+}
+skinparam package {
+ FontSize 35
+ BackgroundColor<> LightBlue
+ BackgroundColor<> PaleGreen
+ BackgroundColor<> DarkGrey
+ BackgroundColor<> BUSINESS
+}
+skinparam arrow<> {
+ Color Red
+}
+skinparam linetype ortho
+skinparam dpi 300
+skinparam nodesep 50
+skinparam ranksep 30
+left to right direction
+
+title "Packages"
+
+package "c5dec" <> as c5dec {
+}
+package "c5dec.common" <> as c5dec.common {
+}
+package "c5dec.settings" <> as c5dec.settings {
+}
+
+'---- CORE ----
+package "c5dec.core" <> as c5dec.core {
+}
+package "c5dec.core.cct" <> as c5dec.core.cct {
+}
+package "c5dec.core.cpssa" <> as c5dec.core.cpssa {
+}
+package "c5dec.core.cryptography" <> as c5dec.core.cryptography {
+}
+package "c5dec.core.cysecanalysis" <> as c5dec.core.cysecanalysis {
+}
+package "c5dec.core.isms" <> as c5dec.core.isms {
+}
+package "c5dec.core.pm" <> as c5dec.core.pm {
+}
+package "c5dec.core.settings" <> as c5dec.core.settings {
+}
+package "c5dec.core.ssdlc" <> as c5dec.core.ssdlc {
+}
+package "c5dec.core.transformer" <> as c5dec.core.transformer {
+}
+
+'---- FRONTEND ----
+package "c5dec.frontend" <> as c5dec.frontend {
+}
+'---- CLI ----
+package "c5dec.frontend.cli" <> as c5dec.frontend.cli {
+}
+package "c5dec.frontend.cli.commands" <> as c5dec.frontend.cli.commands {
+}
+package "c5dec.frontend.cli.main" <> as c5dec.frontend.cli.main {
+}
+package "c5dec.frontend.cli.utils" <> as c5dec.frontend.cli.utils {
+}
+
+'---- TUI ----
+package "c5dec.frontend.tui" <> as c5dec.frontend.tui {
+}
+package "c5dec.frontend.tui.application" <> as c5dec.frontend.tui.application {
+}
+package "c5dec.frontend.tui.foundation" <> as c5dec.frontend.tui.foundation {
+}
+package "c5dec.frontend.tui.foundation.builder" <> as c5dec.frontend.tui.foundation.builder {
+}
+package "c5dec.frontend.tui.foundation.menu" <> as c5dec.frontend.tui.foundation.menu {
+}
+package "c5dec.frontend.tui.miniapps" <> as c5dec.frontend.tui.miniapps {
+}
+package "c5dec.frontend.tui.miniapps.cctapp" <> as c5dec.frontend.tui.miniapps.cctapp {
+}
+package "c5dec.frontend.tui.miniapps.cpssaapp" <> as c5dec.frontend.tui.miniapps.cpssaapp {
+}
+package "c5dec.frontend.tui.miniapps.cryptographyapp" <> as c5dec.frontend.tui.miniapps.cryptographyapp {
+}
+package "c5dec.frontend.tui.miniapps.cysecanalysisapp" <> as c5dec.frontend.tui.miniapps.cysecanalysisapp {
+}
+package "c5dec.frontend.tui.miniapps.ismsapp" <> as c5dec.frontend.tui.miniapps.ismsapp {
+}
+package "c5dec.frontend.tui.miniapps.pmapps" <> as c5dec.frontend.tui.miniapps.pmapp {
+}
+package "c5dec.frontend.tui.miniapps.settingsapp" <> as c5dec.frontend.tui.miniapps.settingsapp {
+}
+package "c5dec.frontend.tui.miniapps.ssdlcapp" <> as c5dec.frontend.tui.miniapps.ssdlcapp {
+}
+package "c5dec.frontend.tui.miniapps.transformerapp" <> as c5dec.frontend.tui.miniapps.transformerapp {
+}
+package "c5dec.frontend.tui.main" <> as c5dec.frontend.tui.main {
+}
+
+'---- PSI ----
+package "c5dec.psi" <> as c5dec.psi {
+}
+package "c5dec.psi.graph" <> as c5dec.psi.graph {
+}
+package "c5dec.psi.search" <> as c5dec.psi.search {
+}
+package "c5dec.psi.security" <> as c5dec.psi.security {
+}
+
+'---- COMPOSITIONS ----
+'---- 1st LAYER ----
+c5dec *-down- c5dec.common <>
+c5dec *-down- c5dec.settings <>
+c5dec *-down- c5dec.core <>
+c5dec *-down- c5dec.frontend <>
+c5dec *-down- c5dec.psi <>
+'---- 2nd Layer - CORE ----
+c5dec.core *-- c5dec.core.cct <>
+c5dec.core *-- c5dec.core.cpssa <>
+c5dec.core *-- c5dec.core.cryptography <>
+c5dec.core *-- c5dec.core.cysecanalysis <>
+c5dec.core *-- c5dec.core.isms <>
+c5dec.core *-- c5dec.core.pm <>
+c5dec.core *-- c5dec.core.ssdlc <>
+c5dec.core *-- c5dec.core.transformer <>
+c5dec.core *-- c5dec.core.settings <>
+
+'---- 2nd Layer - FRONTEND ----
+c5dec.frontend *-- c5dec.frontend.cli <>
+c5dec.frontend *-- c5dec.frontend.tui <>
+
+'---- 2nd Layer - PSI ----
+c5dec.psi *-down- c5dec.psi.graph <>
+c5dec.psi *-down- c5dec.psi.search <>
+c5dec.psi *-down- c5dec.psi.security <>
+
+'---- 3rd Layer - FRONTEND/CLI ----
+c5dec.frontend.cli *-- c5dec.frontend.cli.commands <>
+c5dec.frontend.cli *-- c5dec.frontend.cli.main <>
+c5dec.frontend.cli *-- c5dec.frontend.cli.utils <>
+'---- 3rd Layer - FRONTEND/TUI ----
+c5dec.frontend.tui *-- c5dec.frontend.tui.application <>
+c5dec.frontend.tui *-- c5dec.frontend.tui.main <>
+c5dec.frontend.tui *-- c5dec.frontend.tui.foundation <>
+c5dec.frontend.tui *-- c5dec.frontend.tui.miniapps <>
+'---- 3rd Layer - FRONTEND/FOUNDATION ----
+c5dec.frontend.tui.foundation *-- c5dec.frontend.tui.foundation.builder <>
+c5dec.frontend.tui.foundation *-- c5dec.frontend.tui.foundation.menu <>
+'---- 3rd Layer - FRONTEND/MINIAPPS ----
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.cctapp <>
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.cpssaapp <>
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.cryptographyapp <>
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.cysecanalysisapp <>
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.ismsapp <>
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.pmapp <>
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.settingsapp <>
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.ssdlcapp <>
+c5dec.frontend.tui.miniapps *-- c5dec.frontend.tui.miniapps.transformerapp <>
+
+'---- DEPENDENCIES - CORE----
+c5dec.core.cct --> c5dec.common
+c5dec.core.cct --> c5dec.settings
+
+c5dec.core.isms --> c5dec.settings
+
+c5dec.core.pm --> c5dec.common
+c5dec.core.pm --> c5dec.settings
+
+c5dec.core.ssdlc --> c5dec.common
+c5dec.core.ssdlc --> c5dec.settings
+
+c5dec.core.transformer --> c5dec.common
+c5dec.core.transformer --> c5dec.settings
+
+'---- DEPENDENCIES - CLI ----
+c5dec.frontend.cli.main --> c5dec.common
+c5dec.frontend.cli.main --> c5dec.settings
+c5dec.frontend.cli.main --> c5dec.frontend.cli.commands
+c5dec.frontend.cli.main --> c5dec.frontend.cli.utils
+
+c5dec.frontend.cli.utils --> c5dec.common
+c5dec.frontend.cli.utils --> c5dec.settings
+
+c5dec.frontend.cli.commands --> c5dec.common
+c5dec.frontend.cli.commands --> c5dec.settings
+c5dec.frontend.cli.commands --> c5dec.core.ssdlc
+c5dec.frontend.cli.commands --> c5dec.core.pm
+c5dec.frontend.cli.commands --> c5dec.core.cct
+c5dec.frontend.cli.commands --> c5dec.frontend.tui.main
+
+'---- DEPENDENCIES - TUI/MAIN ----
+c5dec.frontend.tui.main --> c5dec.frontend.tui.application
+c5dec.frontend.tui.main --> c5dec.frontend.tui.miniapps.ssdlcapp
+c5dec.frontend.tui.main --> c5dec.frontend.tui.miniapps.transformerapp
+c5dec.frontend.tui.main --> c5dec.frontend.tui.miniapps.cryptographyapp
+c5dec.frontend.tui.main --> c5dec.frontend.tui.miniapps.ismsapp
+c5dec.frontend.tui.main --> c5dec.frontend.tui.miniapps.pmapp
+c5dec.frontend.tui.main --> c5dec.frontend.tui.miniapps.cctapp
+c5dec.frontend.tui.main --> c5dec.common
+c5dec.frontend.tui.main --> c5dec.settings
+'---- DEPENDENCIES - TUI/APPLICATION ----
+c5dec.frontend.tui.application --> c5dec.frontend.tui
+c5dec.frontend.tui.application --> c5dec.frontend.tui.foundation.menu
+c5dec.frontend.tui.application --> c5dec.settings
+'---- DEPENDENCIES - TUI/MENU ----
+c5dec.frontend.tui.foundation.menu --> c5dec.settings
+c5dec.frontend.tui.foundation.menu --> c5dec.common
+c5dec.frontend.tui.foundation.menu --> c5dec.frontend.tui.foundation.builder
+c5dec.frontend.tui.foundation.menu --> c5dec.frontend.tui.application
+'---- DEPENDENCIES - TUI/CCTAPP ----
+c5dec.frontend.tui.miniapps.cctapp --> c5dec.frontend.tui.foundation.menu
+c5dec.frontend.tui.miniapps.cctapp --> c5dec.frontend.tui.foundation.builder
+c5dec.frontend.tui.miniapps.cctapp --> c5dec.frontend.tui.application
+c5dec.frontend.tui.miniapps.cctapp --> c5dec.settings
+c5dec.frontend.tui.miniapps.cctapp --> c5dec.common
+c5dec.frontend.tui.miniapps.cctapp --> c5dec.core.cct
+'---- DEPENDENCIES - TUI/CRYPTOGRAPHYAPP ----
+c5dec.frontend.tui.miniapps.cryptographyapp --> c5dec.frontend.tui.foundation.menu
+c5dec.frontend.tui.miniapps.cryptographyapp --> c5dec.frontend.tui.foundation.builder
+c5dec.frontend.tui.miniapps.cryptographyapp --> c5dec.core.cryptography
+c5dec.frontend.tui.miniapps.cryptographyapp --> c5dec.settings
+c5dec.frontend.tui.miniapps.cryptographyapp --> c5dec.common
+'---- DEPENDENCIES - TUI/ISMSAPP ----
+c5dec.frontend.tui.miniapps.ismsapp --> c5dec.frontend.tui.foundation.menu
+c5dec.frontend.tui.miniapps.ismsapp --> c5dec.core.isms
+c5dec.frontend.tui.miniapps.ismsapp --> c5dec.frontend.tui.foundation.builder
+'---- DEPENDENCIES - TUI/PMAPP ----
+c5dec.frontend.tui.miniapps.pmapp --> c5dec.frontend.tui.foundation.menu
+c5dec.frontend.tui.miniapps.pmapp --> c5dec.frontend.tui.foundation.builder
+c5dec.frontend.tui.miniapps.pmapp --> c5dec.core.pm
+'---- DEPENDENCIES - TUI/SSDLCAPP ----
+c5dec.frontend.tui.miniapps.ssdlcapp --> c5dec.frontend.tui.foundation.menu
+c5dec.frontend.tui.miniapps.ssdlcapp --> c5dec.frontend.tui.foundation.builder
+c5dec.frontend.tui.miniapps.ssdlcapp --> c5dec.frontend.tui.foundation.menu
+c5dec.frontend.tui.miniapps.ssdlcapp --> c5dec.frontend.tui.application
+c5dec.frontend.tui.miniapps.ssdlcapp --> c5dec.core.ssdlc
+c5dec.frontend.tui.miniapps.ssdlcapp --> c5dec.settings
+c5dec.frontend.tui.miniapps.ssdlcapp --> c5dec.common
+'---- DEPENDENCIES - TUI/TRANSFORMERAPP ----
+c5dec.frontend.tui.miniapps.transformerapp --> c5dec.frontend.tui.foundation.menu
+c5dec.frontend.tui.miniapps.transformerapp --> c5dec.frontend.tui.foundation.builder
+c5dec.frontend.tui.miniapps.transformerapp --> c5dec.frontend.tui.application
+c5dec.frontend.tui.miniapps.transformerapp --> c5dec.core.transformer
+c5dec.frontend.tui.miniapps.transformerapp --> c5dec.core.ssdlc
+c5dec.frontend.tui.miniapps.transformerapp --> c5dec.settings
+c5dec.frontend.tui.miniapps.transformerapp --> c5dec.common
+
+
+!procedure $create_icon($node, $text, $font_size, $icon_color, $bkg_color, $scale)
+ {{\nscale $scale\nleft to right direction\nskinparam BackgroundColor $bkg_color\nskinparam $node {\nBackgroundColor $icon_color\nFontSize $font_size\n}\n$node "$text"\n}}
+!endprocedure
+
+map Legend {
+$create_icon(package, Pkg, 15, lightblue, azure, "0.5") => \nCore Module\n
+$create_icon(package, Pkg, 15, palegreen, azure, "0.5") => \nFrontend Module\n
+$create_icon(Package, Pkg, 15, darkgrey, azure, "0.5") => \nPsi Module\n
+$create_icon(package, Pkg, 15, business, azure, "0.5") => \nCommon Module\n
+\n{{\nscale 0.6\nleft to right direction\nskinparam BackgroundColor azure\nskinparam ArrowColor red\nlabel " " as A\nlabel " " as B\nA --* B\n}} => \nComposition\n
+\n{{\nscale 0.6\nleft to right direction\nskinparam BackgroundColor azure\nskinparam ArrowColor black\nlabel " " as A\nlabel " " as B\nA --> B\n}} => \nDependency\n
+
+}
+
+@enduml
\ No newline at end of file
diff --git a/docs/sdd/plantUML/subsystems.puml b/docs/sdd/plantUML/subsystems.puml
new file mode 100644
index 0000000..9be1040
--- /dev/null
+++ b/docs/sdd/plantUML/subsystems.puml
@@ -0,0 +1,79 @@
+@startuml
+skinparam componentStyle uml1
+skinparam linetype ortho
+
+component Core {
+ component doorstop {
+ component [doorstop core (API)] <>
+ component [doorstop CLI] <>
+ }
+ [CCSAP] --> [SSDLC (artifacts, REM, V&V)]
+ [CC Toolbox] --> doorstop
+ [CC Toolbox] <--> [SSDLC (artifacts, REM, V&V)]
+ [SSDLC (artifacts, REM, V&V)] --> doorstop
+
+
+ [Cryptography] --> doorstop
+ [Transformer] --> [SSDLC (artifacts, REM, V&V)]
+
+ [Transformer] -[hidden]left- doorstop
+ [Transformer] -[hidden]left- [SSDLC (artifacts, REM, V&V)]
+ [CC Toolbox] -[hidden]right- [SSDLC (artifacts, REM, V&V)]
+ [CC Toolbox] -[hidden]left- [Cryptography]
+}
+
+database DataStore {
+ component [Flat-file, NoSQL] <>
+ component [git] <>
+}
+
+component FrontEnd {
+ component CLI {
+ }
+ component TUI {
+ component [C5-DEC Mini Apps] <>
+ component [asciimatics] <>
+
+ }
+ component GUI {
+ component [Open-source viewer\n and editor (VS Code,\n web browser, Zettlr)] <>
+ }
+}
+component ψ {
+ [Search]
+ [Graph]
+ [Security]
+ [Graph] -[hidden]right- [Security]
+}
+
+component Foundations {
+ [Common]
+ [Settings]
+}
+
+'--intercomponent relations--
+Transformer -down-> DataStore
+doorstop -down-> DataStore
+GUI -up-> DataStore
+
+interface "" as MVC
+interface "" as PSIint
+interface "" as Fint
+
+Core -- MVC
+MVC -- FrontEnd
+MVC -- FrontEnd
+
+Core -right- PSIint
+PSIint -right- ψ
+PSIint -[hidden]right- [Graph]
+
+Core -down- Fint
+Fint -left- Foundations
+
+
+'---Force Layout---
+ψ -[hidden]down- Foundations
+Foundations -[hidden]left- DataStore
+
+@enduml
diff --git a/docs/sdd/plantUML/system_architecture.puml b/docs/sdd/plantUML/system_architecture.puml
new file mode 100644
index 0000000..a21de55
--- /dev/null
+++ b/docs/sdd/plantUML/system_architecture.puml
@@ -0,0 +1,128 @@
+@startuml
+
+hide stereotype
+skinparam linetype ortho
+skinparam dpi 300
+skinparam nodesep 10
+skinparam ranksep 10
+skinparam {
+ DefaultTextAlignment center
+}
+skinparam map {
+ BackgroundColor lightblue
+ FontStyle italic
+}
+skinparam rectangle {
+ BackgroundColor<> CornflowerBlue
+ BackgroundColor<> CornflowerBlue
+ BorderStyle<> dashed
+ BackgroundColor<> Yellow
+ BackgroundColor<> Yellow
+ BorderStyle<> dashed
+ BackgroundColor<> LightGreen
+ BackgroundColor<> Orange
+ BackgroundColor<> Orange
+ BorderStyle<> dashed
+ BackgroundColor<> Beige
+}
+
+top to bottom direction
+together {
+rectangle "C5-DEC Cad Architecture" as all {
+ together "upper" {
+ rectangle "Front-end layer" <> as FrontEnd {
+ rectangle "Command-Line Interface (CLI)" <> as CLI
+ rectangle "Textual User Interface (TUI)" <> as TUI
+ rectangle "Open-source GUI\nVS Code, web browser, Zettlr" <> as GUI
+
+ CLI -[hidden]right-> TUI
+ TUI -[hidden]right-> GUI
+ }
+
+ rectangle "Core mission logic layer" <> as Core {
+ rectangle "SSDLC\nartifacts, design specs, REM, V&V" <> as SSDLC
+ rectangle "CPSSA\nthreat modelling, risk management" <> as CPSSA
+ rectangle "Crptography" <> as CRYPTO
+ rectangle "PM" <> as PM
+ rectangle "ISMS" <> as ISMS
+ rectangle "CCT\nSFR and SAR DB, PP/ST/CEM assistant" <> as CCT
+ rectangle "Transformer\nimport, export, publish, template engine" <> as TRAFO
+
+ SSDLC -[hidden]down- CPSSA
+ SSDLC -[hidden]right- CRYPTO
+ CPSSA -[hidden]right- PM
+ PM -[hidden]right- ISMS
+ CRYPTO -[hidden]down- PM
+ CRYPTO -[hidden]right- CCT
+ CCT -[hidden]down- TRAFO
+ }
+
+ rectangle "Processing, Security & Intelligence layer ψ" <> as Psi {
+ rectangle "Mathematical\noptimization\nAI/ML, NLP, LLM\n" <> as MATH
+ rectangle "Search\nFull-text,\nfilters, tag-based\n" <> as SEARCH
+ rectangle "Graph\nVisualization,\n properites \n" <> as GRAPH
+ rectangle "Security\nValidation,\nintegrity, crypto\n" <> as SEC
+ rectangle "Simulation\nRes. planning,\ncost estimation\n" <> as SIM
+
+ MATH -[hidden]right- SEARCH
+ SEARCH -[hidden]right- GRAPH
+ GRAPH -[hidden]right- SEC
+ SEC -[hidden]right- SIM
+ }
+ }
+ together "lower" {
+ rectangle "Foundations layer" <> as Foundation {
+ rectangle "Common\nFile system, utilities,helper classes/functions,\nlogging, exceptions" <> as COMMON
+ rectangle "Settings\n Project parameters, application configuration \n" <> as SETTINGS
+ }
+
+ rectangle "Data Layer\n NoSQL, document-oriented and version controlled, based on open formats and specifications \n(Markdown, XML, JSON, CSV, YAML, TOML, LaTeX, Makefile, Git, etc.)" <> as Data
+
+ rectangle "Collaborative web/cload-based software development platform layer\nGitHub, GitLab, Azure DevOps, BitBucket, GForge\n (User management, authentication, authorization, access control, DevSecOps, sharing, CI/CD) " <> as Collab
+ }
+ }
+
+ hide Hidden
+ rectangle Hidden
+ FrontEnd -[hidden]down- Hidden
+ CLI -[hidden]down- SSDLC
+ GUI -[hidden]down- CCT
+ Core -[hidden]up- FrontEnd
+
+ CPSSA -[hidden]down- MATH
+ TRAFO -[hidden]down- SIM
+ PM -[hidden]down- GRAPH
+
+ Psi -[hidden]down- Foundation
+ SETTINGS -[hidden]down- Data
+ COMMON -[hidden]down- Data
+ Data -[hidden]down- Collab
+}
+
+!procedure $create_icon($node, $text, $font_size, $icon_color, $style, $bkg_color, $scale)
+ {{\nscale $scale\nleft to right direction\nskinparam BackgroundColor $bkg_color\nskinparam $node {\nBackgroundColor $icon_color\nFontSize $font_size\nBorderStyle $style\n}\n$node "$text"\n}}
+!endprocedure
+
+map Legend {
+ SSDLC => Secure Software Development Life Cycle
+ REM => Requirement Engineering & management
+ V&V => Verification and nValidation
+ CCT => Common Criteria Toolbox
+ CPSSA => Cyber-Physical System Security Analysis
+ PM => Project management
+ ISMS => Information Security Management System
+ $create_icon(rectangle, " User-facing module ", 15, yellow, normal, lightblue, "0.25") => User-facing Module
+ $create_icon(rectangle, " 3rd party ", 15, yellow, dashed, lightblue, "0.25") => 3rd party
+ $create_icon(rectangle, "Independent functional module", 15, lightgreen, normal, lightblue, "0.25") => Independent functional module
+ $create_icon(rectangle, " Planned module ", 15, orange, normal, lightblue, "0.25") => Planned ψ module
+ $create_icon(rectangle, " Experimental Low-priority ", 15, orange, Dashed, lightblue, "0.25") => Experimental Low-priority
+ $create_icon(rectangle, "Shared and glue code & config", 15, beige, normal, lightblue, "0.25") => Shared and glue code & config
+ $create_icon(rectangle, " Third-party software ", 15, cornflowerblue, dashed, lightblue, "0.25") => Third-party software
+}
+
+all -[norank]- Legend
+FrontEnd -[hidden]right- Legend
+Core -[hidden]right- Legend
+Psi -[hidden]right- Legend
+
+@enduml
diff --git a/poetry.lock b/poetry.lock
new file mode 100644
index 0000000..50e52df
--- /dev/null
+++ b/poetry.lock
@@ -0,0 +1,1423 @@
+# This file is automatically @generated by Poetry 1.5.0 and should not be changed by hand.
+
+[[package]]
+name = "asciimatics"
+version = "1.15.0"
+description = "A cross-platform package to replace curses (mouse/keyboard input & text colours/positioning) and create ASCII animations"
+optional = false
+python-versions = ">= 3.8"
+files = [
+ {file = "asciimatics-1.15.0-py3-none-any.whl", hash = "sha256:0fe068a6bed522929bd04bb5b8a2fb6ebf0aef1b7a9b3843cf71030a34bc38d5"},
+ {file = "asciimatics-1.15.0.tar.gz", hash = "sha256:cfdd398042727519d8b73e62b8ef82c0becfed4eb420899c3b96c98d0b96821a"},
+]
+
+[package.dependencies]
+Pillow = ">=2.7.0"
+pyfiglet = ">=0.7.2"
+pywin32 = {version = "*", markers = "sys_platform == \"win32\""}
+wcwidth = "*"
+
+[[package]]
+name = "astroid"
+version = "2.15.8"
+description = "An abstract syntax tree for Python with inference support."
+optional = false
+python-versions = ">=3.7.2"
+files = [
+ {file = "astroid-2.15.8-py3-none-any.whl", hash = "sha256:1aa149fc5c6589e3d0ece885b4491acd80af4f087baafa3fb5203b113e68cd3c"},
+ {file = "astroid-2.15.8.tar.gz", hash = "sha256:6c107453dffee9055899705de3c9ead36e74119cee151e5a9aaf7f0b0e020a6a"},
+]
+
+[package.dependencies]
+lazy-object-proxy = ">=1.4.0"
+typing-extensions = {version = ">=4.0.0", markers = "python_version < \"3.11\""}
+wrapt = [
+ {version = ">=1.11,<2", markers = "python_version < \"3.11\""},
+ {version = ">=1.14,<2", markers = "python_version >= \"3.11\""},
+]
+
+[[package]]
+name = "blockdiag"
+version = "3.0.0"
+description = "blockdiag generates block-diagram image from text"
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "blockdiag-3.0.0-py3-none-any.whl", hash = "sha256:4031bfae6a7f36071d733dec639987346e10f7871356ee2c7a221961c64961d8"},
+ {file = "blockdiag-3.0.0.tar.gz", hash = "sha256:dee4195bb87d23654546ba2bf5091480dbf253b409891fce2cd527c91d00a3e2"},
+]
+
+[package.dependencies]
+funcparserlib = ">=1.0.0a0"
+Pillow = ">3.0"
+setuptools = "*"
+webcolors = "*"
+
+[package.extras]
+pdf = ["reportlab"]
+rst = ["docutils"]
+testing = ["docutils", "flake8", "flake8-coding", "flake8-copyright", "flake8-isort", "nose", "reportlab"]
+
+[[package]]
+name = "bottle"
+version = "0.12.25"
+description = "Fast and simple WSGI-framework for small web-applications."
+optional = false
+python-versions = "*"
+files = [
+ {file = "bottle-0.12.25-py3-none-any.whl", hash = "sha256:d6f15f9d422670b7c073d63bd8d287b135388da187a0f3e3c19293626ce034ea"},
+ {file = "bottle-0.12.25.tar.gz", hash = "sha256:e1a9c94970ae6d710b3fb4526294dfeb86f2cb4a81eff3a4b98dc40fb0e5e021"},
+]
+
+[[package]]
+name = "certifi"
+version = "2023.11.17"
+description = "Python package for providing Mozilla's CA Bundle."
+optional = false
+python-versions = ">=3.6"
+files = [
+ {file = "certifi-2023.11.17-py3-none-any.whl", hash = "sha256:e036ab49d5b79556f99cfc2d9320b34cfbe5be05c5871b51de9329f0603b0474"},
+ {file = "certifi-2023.11.17.tar.gz", hash = "sha256:9b469f3a900bf28dc19b8cfbf8019bf47f7fdd1a65a1d4ffb98fc14166beb4d1"},
+]
+
+[[package]]
+name = "cffi"
+version = "1.16.0"
+description = "Foreign Function Interface for Python calling C code."
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "cffi-1.16.0-cp310-cp310-macosx_10_9_x86_64.whl", hash = "sha256:6b3d6606d369fc1da4fd8c357d026317fbb9c9b75d36dc16e90e84c26854b088"},
+ {file = "cffi-1.16.0-cp310-cp310-macosx_11_0_arm64.whl", hash = "sha256:ac0f5edd2360eea2f1daa9e26a41db02dd4b0451b48f7c318e217ee092a213e9"},
+ {file = "cffi-1.16.0-cp310-cp310-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:7e61e3e4fa664a8588aa25c883eab612a188c725755afff6289454d6362b9673"},
+ {file = "cffi-1.16.0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:a72e8961a86d19bdb45851d8f1f08b041ea37d2bd8d4fd19903bc3083d80c896"},
+ {file = "cffi-1.16.0-cp310-cp310-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:5b50bf3f55561dac5438f8e70bfcdfd74543fd60df5fa5f62d94e5867deca684"},
+ {file = "cffi-1.16.0-cp310-cp310-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:7651c50c8c5ef7bdb41108b7b8c5a83013bfaa8a935590c5d74627c047a583c7"},
+ {file = "cffi-1.16.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:e4108df7fe9b707191e55f33efbcb2d81928e10cea45527879a4749cbe472614"},
+ {file = "cffi-1.16.0-cp310-cp310-musllinux_1_1_i686.whl", hash = "sha256:32c68ef735dbe5857c810328cb2481e24722a59a2003018885514d4c09af9743"},
+ {file = "cffi-1.16.0-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:673739cb539f8cdaa07d92d02efa93c9ccf87e345b9a0b556e3ecc666718468d"},
+ {file = "cffi-1.16.0-cp310-cp310-win32.whl", hash = "sha256:9f90389693731ff1f659e55c7d1640e2ec43ff725cc61b04b2f9c6d8d017df6a"},
+ {file = "cffi-1.16.0-cp310-cp310-win_amd64.whl", hash = "sha256:e6024675e67af929088fda399b2094574609396b1decb609c55fa58b028a32a1"},
+ {file = "cffi-1.16.0-cp311-cp311-macosx_10_9_x86_64.whl", hash = "sha256:b84834d0cf97e7d27dd5b7f3aca7b6e9263c56308ab9dc8aae9784abb774d404"},
+ {file = "cffi-1.16.0-cp311-cp311-macosx_11_0_arm64.whl", hash = "sha256:1b8ebc27c014c59692bb2664c7d13ce7a6e9a629be20e54e7271fa696ff2b417"},
+ {file = "cffi-1.16.0-cp311-cp311-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:ee07e47c12890ef248766a6e55bd38ebfb2bb8edd4142d56db91b21ea68b7627"},
+ {file = "cffi-1.16.0-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:d8a9d3ebe49f084ad71f9269834ceccbf398253c9fac910c4fd7053ff1386936"},
+ {file = "cffi-1.16.0-cp311-cp311-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:e70f54f1796669ef691ca07d046cd81a29cb4deb1e5f942003f401c0c4a2695d"},
+ {file = "cffi-1.16.0-cp311-cp311-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:5bf44d66cdf9e893637896c7faa22298baebcd18d1ddb6d2626a6e39793a1d56"},
+ {file = "cffi-1.16.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:7b78010e7b97fef4bee1e896df8a4bbb6712b7f05b7ef630f9d1da00f6444d2e"},
+ {file = "cffi-1.16.0-cp311-cp311-musllinux_1_1_i686.whl", hash = "sha256:c6a164aa47843fb1b01e941d385aab7215563bb8816d80ff3a363a9f8448a8dc"},
+ {file = "cffi-1.16.0-cp311-cp311-musllinux_1_1_x86_64.whl", hash = "sha256:e09f3ff613345df5e8c3667da1d918f9149bd623cd9070c983c013792a9a62eb"},
+ {file = "cffi-1.16.0-cp311-cp311-win32.whl", hash = "sha256:2c56b361916f390cd758a57f2e16233eb4f64bcbeee88a4881ea90fca14dc6ab"},
+ {file = "cffi-1.16.0-cp311-cp311-win_amd64.whl", hash = "sha256:db8e577c19c0fda0beb7e0d4e09e0ba74b1e4c092e0e40bfa12fe05b6f6d75ba"},
+ {file = "cffi-1.16.0-cp312-cp312-macosx_10_9_x86_64.whl", hash = "sha256:fa3a0128b152627161ce47201262d3140edb5a5c3da88d73a1b790a959126956"},
+ {file = "cffi-1.16.0-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:68e7c44931cc171c54ccb702482e9fc723192e88d25a0e133edd7aff8fcd1f6e"},
+ {file = "cffi-1.16.0-cp312-cp312-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:abd808f9c129ba2beda4cfc53bde801e5bcf9d6e0f22f095e45327c038bfe68e"},
+ {file = "cffi-1.16.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:88e2b3c14bdb32e440be531ade29d3c50a1a59cd4e51b1dd8b0865c54ea5d2e2"},
+ {file = "cffi-1.16.0-cp312-cp312-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:fcc8eb6d5902bb1cf6dc4f187ee3ea80a1eba0a89aba40a5cb20a5087d961357"},
+ {file = "cffi-1.16.0-cp312-cp312-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:b7be2d771cdba2942e13215c4e340bfd76398e9227ad10402a8767ab1865d2e6"},
+ {file = "cffi-1.16.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:e715596e683d2ce000574bae5d07bd522c781a822866c20495e52520564f0969"},
+ {file = "cffi-1.16.0-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:2d92b25dbf6cae33f65005baf472d2c245c050b1ce709cc4588cdcdd5495b520"},
+ {file = "cffi-1.16.0-cp312-cp312-win32.whl", hash = "sha256:b2ca4e77f9f47c55c194982e10f058db063937845bb2b7a86c84a6cfe0aefa8b"},
+ {file = "cffi-1.16.0-cp312-cp312-win_amd64.whl", hash = "sha256:68678abf380b42ce21a5f2abde8efee05c114c2fdb2e9eef2efdb0257fba1235"},
+ {file = "cffi-1.16.0-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:0c9ef6ff37e974b73c25eecc13952c55bceed9112be2d9d938ded8e856138bcc"},
+ {file = "cffi-1.16.0-cp38-cp38-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:a09582f178759ee8128d9270cd1344154fd473bb77d94ce0aeb2a93ebf0feaf0"},
+ {file = "cffi-1.16.0-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:e760191dd42581e023a68b758769e2da259b5d52e3103c6060ddc02c9edb8d7b"},
+ {file = "cffi-1.16.0-cp38-cp38-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:80876338e19c951fdfed6198e70bc88f1c9758b94578d5a7c4c91a87af3cf31c"},
+ {file = "cffi-1.16.0-cp38-cp38-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:a6a14b17d7e17fa0d207ac08642c8820f84f25ce17a442fd15e27ea18d67c59b"},
+ {file = "cffi-1.16.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:6602bc8dc6f3a9e02b6c22c4fc1e47aa50f8f8e6d3f78a5e16ac33ef5fefa324"},
+ {file = "cffi-1.16.0-cp38-cp38-win32.whl", hash = "sha256:131fd094d1065b19540c3d72594260f118b231090295d8c34e19a7bbcf2e860a"},
+ {file = "cffi-1.16.0-cp38-cp38-win_amd64.whl", hash = "sha256:31d13b0f99e0836b7ff893d37af07366ebc90b678b6664c955b54561fc36ef36"},
+ {file = "cffi-1.16.0-cp39-cp39-macosx_10_9_x86_64.whl", hash = "sha256:582215a0e9adbe0e379761260553ba11c58943e4bbe9c36430c4ca6ac74b15ed"},
+ {file = "cffi-1.16.0-cp39-cp39-macosx_11_0_arm64.whl", hash = "sha256:b29ebffcf550f9da55bec9e02ad430c992a87e5f512cd63388abb76f1036d8d2"},
+ {file = "cffi-1.16.0-cp39-cp39-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:dc9b18bf40cc75f66f40a7379f6a9513244fe33c0e8aa72e2d56b0196a7ef872"},
+ {file = "cffi-1.16.0-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:9cb4a35b3642fc5c005a6755a5d17c6c8b6bcb6981baf81cea8bfbc8903e8ba8"},
+ {file = "cffi-1.16.0-cp39-cp39-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:b86851a328eedc692acf81fb05444bdf1891747c25af7529e39ddafaf68a4f3f"},
+ {file = "cffi-1.16.0-cp39-cp39-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:c0f31130ebc2d37cdd8e44605fb5fa7ad59049298b3f745c74fa74c62fbfcfc4"},
+ {file = "cffi-1.16.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:8f8e709127c6c77446a8c0a8c8bf3c8ee706a06cd44b1e827c3e6a2ee6b8c098"},
+ {file = "cffi-1.16.0-cp39-cp39-musllinux_1_1_i686.whl", hash = "sha256:748dcd1e3d3d7cd5443ef03ce8685043294ad6bd7c02a38d1bd367cfd968e000"},
+ {file = "cffi-1.16.0-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:8895613bcc094d4a1b2dbe179d88d7fb4a15cee43c052e8885783fac397d91fe"},
+ {file = "cffi-1.16.0-cp39-cp39-win32.whl", hash = "sha256:ed86a35631f7bfbb28e108dd96773b9d5a6ce4811cf6ea468bb6a359b256b1e4"},
+ {file = "cffi-1.16.0-cp39-cp39-win_amd64.whl", hash = "sha256:3686dffb02459559c74dd3d81748269ffb0eb027c39a6fc99502de37d501faa8"},
+ {file = "cffi-1.16.0.tar.gz", hash = "sha256:bcb3ef43e58665bbda2fb198698fcae6776483e0c4a631aa5647806c25e02cc0"},
+]
+
+[package.dependencies]
+pycparser = "*"
+
+[[package]]
+name = "charset-normalizer"
+version = "3.3.2"
+description = "The Real First Universal Charset Detector. Open, modern and actively maintained alternative to Chardet."
+optional = false
+python-versions = ">=3.7.0"
+files = [
+ {file = "charset-normalizer-3.3.2.tar.gz", hash = "sha256:f30c3cb33b24454a82faecaf01b19c18562b1e89558fb6c56de4d9118a032fd5"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-macosx_10_9_universal2.whl", hash = "sha256:25baf083bf6f6b341f4121c2f3c548875ee6f5339300e08be3f2b2ba1721cdd3"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-macosx_10_9_x86_64.whl", hash = "sha256:06435b539f889b1f6f4ac1758871aae42dc3a8c0e24ac9e60c2384973ad73027"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-macosx_11_0_arm64.whl", hash = "sha256:9063e24fdb1e498ab71cb7419e24622516c4a04476b17a2dab57e8baa30d6e03"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:6897af51655e3691ff853668779c7bad41579facacf5fd7253b0133308cf000d"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:1d3193f4a680c64b4b6a9115943538edb896edc190f0b222e73761716519268e"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:cd70574b12bb8a4d2aaa0094515df2463cb429d8536cfb6c7ce983246983e5a6"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:8465322196c8b4d7ab6d1e049e4c5cb460d0394da4a27d23cc242fbf0034b6b5"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:a9a8e9031d613fd2009c182b69c7b2c1ef8239a0efb1df3f7c8da66d5dd3d537"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-musllinux_1_1_aarch64.whl", hash = "sha256:beb58fe5cdb101e3a055192ac291b7a21e3b7ef4f67fa1d74e331a7f2124341c"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-musllinux_1_1_i686.whl", hash = "sha256:e06ed3eb3218bc64786f7db41917d4e686cc4856944f53d5bdf83a6884432e12"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-musllinux_1_1_ppc64le.whl", hash = "sha256:2e81c7b9c8979ce92ed306c249d46894776a909505d8f5a4ba55b14206e3222f"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-musllinux_1_1_s390x.whl", hash = "sha256:572c3763a264ba47b3cf708a44ce965d98555f618ca42c926a9c1616d8f34269"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:fd1abc0d89e30cc4e02e4064dc67fcc51bd941eb395c502aac3ec19fab46b519"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-win32.whl", hash = "sha256:3d47fa203a7bd9c5b6cee4736ee84ca03b8ef23193c0d1ca99b5089f72645c73"},
+ {file = "charset_normalizer-3.3.2-cp310-cp310-win_amd64.whl", hash = "sha256:10955842570876604d404661fbccbc9c7e684caf432c09c715ec38fbae45ae09"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-macosx_10_9_universal2.whl", hash = "sha256:802fe99cca7457642125a8a88a084cef28ff0cf9407060f7b93dca5aa25480db"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-macosx_10_9_x86_64.whl", hash = "sha256:573f6eac48f4769d667c4442081b1794f52919e7edada77495aaed9236d13a96"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-macosx_11_0_arm64.whl", hash = "sha256:549a3a73da901d5bc3ce8d24e0600d1fa85524c10287f6004fbab87672bf3e1e"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:f27273b60488abe721a075bcca6d7f3964f9f6f067c8c4c605743023d7d3944f"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:1ceae2f17a9c33cb48e3263960dc5fc8005351ee19db217e9b1bb15d28c02574"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:65f6f63034100ead094b8744b3b97965785388f308a64cf8d7c34f2f2e5be0c4"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:753f10e867343b4511128c6ed8c82f7bec3bd026875576dfd88483c5c73b2fd8"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:4a78b2b446bd7c934f5dcedc588903fb2f5eec172f3d29e52a9096a43722adfc"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-musllinux_1_1_aarch64.whl", hash = "sha256:e537484df0d8f426ce2afb2d0f8e1c3d0b114b83f8850e5f2fbea0e797bd82ae"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-musllinux_1_1_i686.whl", hash = "sha256:eb6904c354526e758fda7167b33005998fb68c46fbc10e013ca97f21ca5c8887"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-musllinux_1_1_ppc64le.whl", hash = "sha256:deb6be0ac38ece9ba87dea880e438f25ca3eddfac8b002a2ec3d9183a454e8ae"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-musllinux_1_1_s390x.whl", hash = "sha256:4ab2fe47fae9e0f9dee8c04187ce5d09f48eabe611be8259444906793ab7cbce"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-musllinux_1_1_x86_64.whl", hash = "sha256:80402cd6ee291dcb72644d6eac93785fe2c8b9cb30893c1af5b8fdd753b9d40f"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-win32.whl", hash = "sha256:7cd13a2e3ddeed6913a65e66e94b51d80a041145a026c27e6bb76c31a853c6ab"},
+ {file = "charset_normalizer-3.3.2-cp311-cp311-win_amd64.whl", hash = "sha256:663946639d296df6a2bb2aa51b60a2454ca1cb29835324c640dafb5ff2131a77"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-macosx_10_9_universal2.whl", hash = "sha256:0b2b64d2bb6d3fb9112bafa732def486049e63de9618b5843bcdd081d8144cd8"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-macosx_10_9_x86_64.whl", hash = "sha256:ddbb2551d7e0102e7252db79ba445cdab71b26640817ab1e3e3648dad515003b"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:55086ee1064215781fff39a1af09518bc9255b50d6333f2e4c74ca09fac6a8f6"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:8f4a014bc36d3c57402e2977dada34f9c12300af536839dc38c0beab8878f38a"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:a10af20b82360ab00827f916a6058451b723b4e65030c5a18577c8b2de5b3389"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:8d756e44e94489e49571086ef83b2bb8ce311e730092d2c34ca8f7d925cb20aa"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:90d558489962fd4918143277a773316e56c72da56ec7aa3dc3dbbe20fdfed15b"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:6ac7ffc7ad6d040517be39eb591cac5ff87416c2537df6ba3cba3bae290c0fed"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:7ed9e526742851e8d5cc9e6cf41427dfc6068d4f5a3bb03659444b4cabf6bc26"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-musllinux_1_1_i686.whl", hash = "sha256:8bdb58ff7ba23002a4c5808d608e4e6c687175724f54a5dade5fa8c67b604e4d"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-musllinux_1_1_ppc64le.whl", hash = "sha256:6b3251890fff30ee142c44144871185dbe13b11bab478a88887a639655be1068"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-musllinux_1_1_s390x.whl", hash = "sha256:b4a23f61ce87adf89be746c8a8974fe1c823c891d8f86eb218bb957c924bb143"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:efcb3f6676480691518c177e3b465bcddf57cea040302f9f4e6e191af91174d4"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-win32.whl", hash = "sha256:d965bba47ddeec8cd560687584e88cf699fd28f192ceb452d1d7ee807c5597b7"},
+ {file = "charset_normalizer-3.3.2-cp312-cp312-win_amd64.whl", hash = "sha256:96b02a3dc4381e5494fad39be677abcb5e6634bf7b4fa83a6dd3112607547001"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-macosx_10_9_x86_64.whl", hash = "sha256:95f2a5796329323b8f0512e09dbb7a1860c46a39da62ecb2324f116fa8fdc85c"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:c002b4ffc0be611f0d9da932eb0f704fe2602a9a949d1f738e4c34c75b0863d5"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:a981a536974bbc7a512cf44ed14938cf01030a99e9b3a06dd59578882f06f985"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:3287761bc4ee9e33561a7e058c72ac0938c4f57fe49a09eae428fd88aafe7bb6"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:42cb296636fcc8b0644486d15c12376cb9fa75443e00fb25de0b8602e64c1714"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:0a55554a2fa0d408816b3b5cedf0045f4b8e1a6065aec45849de2d6f3f8e9786"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-musllinux_1_1_aarch64.whl", hash = "sha256:c083af607d2515612056a31f0a8d9e0fcb5876b7bfc0abad3ecd275bc4ebc2d5"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-musllinux_1_1_i686.whl", hash = "sha256:87d1351268731db79e0f8e745d92493ee2841c974128ef629dc518b937d9194c"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-musllinux_1_1_ppc64le.whl", hash = "sha256:bd8f7df7d12c2db9fab40bdd87a7c09b1530128315d047a086fa3ae3435cb3a8"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-musllinux_1_1_s390x.whl", hash = "sha256:c180f51afb394e165eafe4ac2936a14bee3eb10debc9d9e4db8958fe36afe711"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-musllinux_1_1_x86_64.whl", hash = "sha256:8c622a5fe39a48f78944a87d4fb8a53ee07344641b0562c540d840748571b811"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-win32.whl", hash = "sha256:db364eca23f876da6f9e16c9da0df51aa4f104a972735574842618b8c6d999d4"},
+ {file = "charset_normalizer-3.3.2-cp37-cp37m-win_amd64.whl", hash = "sha256:86216b5cee4b06df986d214f664305142d9c76df9b6512be2738aa72a2048f99"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-macosx_10_9_universal2.whl", hash = "sha256:6463effa3186ea09411d50efc7d85360b38d5f09b870c48e4600f63af490e56a"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:6c4caeef8fa63d06bd437cd4bdcf3ffefe6738fb1b25951440d80dc7df8c03ac"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-macosx_11_0_arm64.whl", hash = "sha256:37e55c8e51c236f95b033f6fb391d7d7970ba5fe7ff453dad675e88cf303377a"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:fb69256e180cb6c8a894fee62b3afebae785babc1ee98b81cdf68bbca1987f33"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:ae5f4161f18c61806f411a13b0310bea87f987c7d2ecdbdaad0e94eb2e404238"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:b2b0a0c0517616b6869869f8c581d4eb2dd83a4d79e0ebcb7d373ef9956aeb0a"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:45485e01ff4d3630ec0d9617310448a8702f70e9c01906b0d0118bdf9d124cf2"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:eb00ed941194665c332bf8e078baf037d6c35d7c4f3102ea2d4f16ca94a26dc8"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-musllinux_1_1_aarch64.whl", hash = "sha256:2127566c664442652f024c837091890cb1942c30937add288223dc895793f898"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-musllinux_1_1_i686.whl", hash = "sha256:a50aebfa173e157099939b17f18600f72f84eed3049e743b68ad15bd69b6bf99"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-musllinux_1_1_ppc64le.whl", hash = "sha256:4d0d1650369165a14e14e1e47b372cfcb31d6ab44e6e33cb2d4e57265290044d"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-musllinux_1_1_s390x.whl", hash = "sha256:923c0c831b7cfcb071580d3f46c4baf50f174be571576556269530f4bbd79d04"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-musllinux_1_1_x86_64.whl", hash = "sha256:06a81e93cd441c56a9b65d8e1d043daeb97a3d0856d177d5c90ba85acb3db087"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-win32.whl", hash = "sha256:6ef1d82a3af9d3eecdba2321dc1b3c238245d890843e040e41e470ffa64c3e25"},
+ {file = "charset_normalizer-3.3.2-cp38-cp38-win_amd64.whl", hash = "sha256:eb8821e09e916165e160797a6c17edda0679379a4be5c716c260e836e122f54b"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-macosx_10_9_universal2.whl", hash = "sha256:c235ebd9baae02f1b77bcea61bce332cb4331dc3617d254df3323aa01ab47bd4"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-macosx_10_9_x86_64.whl", hash = "sha256:5b4c145409bef602a690e7cfad0a15a55c13320ff7a3ad7ca59c13bb8ba4d45d"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-macosx_11_0_arm64.whl", hash = "sha256:68d1f8a9e9e37c1223b656399be5d6b448dea850bed7d0f87a8311f1ff3dabb0"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:22afcb9f253dac0696b5a4be4a1c0f8762f8239e21b99680099abd9b2b1b2269"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:e27ad930a842b4c5eb8ac0016b0a54f5aebbe679340c26101df33424142c143c"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:1f79682fbe303db92bc2b1136016a38a42e835d932bab5b3b1bfcfbf0640e519"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:b261ccdec7821281dade748d088bb6e9b69e6d15b30652b74cbbac25e280b796"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:122c7fa62b130ed55f8f285bfd56d5f4b4a5b503609d181f9ad85e55c89f4185"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-musllinux_1_1_aarch64.whl", hash = "sha256:d0eccceffcb53201b5bfebb52600a5fb483a20b61da9dbc885f8b103cbe7598c"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-musllinux_1_1_i686.whl", hash = "sha256:9f96df6923e21816da7e0ad3fd47dd8f94b2a5ce594e00677c0013018b813458"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-musllinux_1_1_ppc64le.whl", hash = "sha256:7f04c839ed0b6b98b1a7501a002144b76c18fb1c1850c8b98d458ac269e26ed2"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-musllinux_1_1_s390x.whl", hash = "sha256:34d1c8da1e78d2e001f363791c98a272bb734000fcef47a491c1e3b0505657a8"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:ff8fa367d09b717b2a17a052544193ad76cd49979c805768879cb63d9ca50561"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-win32.whl", hash = "sha256:aed38f6e4fb3f5d6bf81bfa990a07806be9d83cf7bacef998ab1a9bd660a581f"},
+ {file = "charset_normalizer-3.3.2-cp39-cp39-win_amd64.whl", hash = "sha256:b01b88d45a6fcb69667cd6d2f7a9aeb4bf53760d7fc536bf679ec94fe9f3ff3d"},
+ {file = "charset_normalizer-3.3.2-py3-none-any.whl", hash = "sha256:3e4d1f6587322d2788836a99c69062fbb091331ec940e02d12d179c1d53e25fc"},
+]
+
+[[package]]
+name = "colorama"
+version = "0.4.6"
+description = "Cross-platform colored terminal text."
+optional = false
+python-versions = "!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*,!=3.5.*,!=3.6.*,>=2.7"
+files = [
+ {file = "colorama-0.4.6-py2.py3-none-any.whl", hash = "sha256:4f1d9991f5acc0ca119f9d443620b77f9d6b33703e51011c16baf57afb285fc6"},
+ {file = "colorama-0.4.6.tar.gz", hash = "sha256:08695f5cb7ed6e0531a20572697297273c47b8cae5a63ffc6d6ed5c201be6e44"},
+]
+
+[[package]]
+name = "dill"
+version = "0.3.7"
+description = "serialize all of Python"
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "dill-0.3.7-py3-none-any.whl", hash = "sha256:76b122c08ef4ce2eedcd4d1abd8e641114bfc6c2867f49f3c41facf65bf19f5e"},
+ {file = "dill-0.3.7.tar.gz", hash = "sha256:cc1c8b182eb3013e24bd475ff2e9295af86c1a38eb1aff128dac8962a9ce3c03"},
+]
+
+[package.extras]
+graph = ["objgraph (>=1.7.2)"]
+
+[[package]]
+name = "doorstop"
+version = "3.0b9"
+description = "Requirements management using version control."
+optional = false
+python-versions = ">=3.8,<4.0"
+files = [
+ {file = "doorstop-3.0b9-py3-none-any.whl", hash = "sha256:2415edf5f04598f00379e73aaefb453c68c3d2b37fc62b8c904654b9859acdf3"},
+ {file = "doorstop-3.0b9.tar.gz", hash = "sha256:f779706d03705a934faffdf8783a71592b42f3669c294cc0ead26c83118ba31b"},
+]
+
+[package.dependencies]
+bottle = ">=0.12.13,<0.13.0"
+markdown = ">=3.3.6,<4.0.0"
+openpyxl = ">=3.0.7"
+plantuml-markdown = ">=3.4.2,<4.0.0"
+python-frontmatter = ">=1.0,<2.0"
+python-markdown-math = ">=0.6,<0.7"
+pyyaml = ">=5.1,<6.0"
+requests = ">=2.0,<3.0"
+six = "*"
+
+[[package]]
+name = "et-xmlfile"
+version = "1.1.0"
+description = "An implementation of lxml.xmlfile for the standard library"
+optional = false
+python-versions = ">=3.6"
+files = [
+ {file = "et_xmlfile-1.1.0-py3-none-any.whl", hash = "sha256:a2ba85d1d6a74ef63837eed693bcb89c3f752169b0e3e7ae5b16ca5e1b3deada"},
+ {file = "et_xmlfile-1.1.0.tar.gz", hash = "sha256:8eb9e2bc2f8c97e37a2dc85a09ecdcdec9d8a396530a6d5a33b30b9a92da0c5c"},
+]
+
+[[package]]
+name = "funcparserlib"
+version = "1.0.1"
+description = "Recursive descent parsing library based on functional combinators"
+optional = false
+python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, !=3.5.*, !=3.6.*"
+files = [
+ {file = "funcparserlib-1.0.1-py2.py3-none-any.whl", hash = "sha256:95da15d3f0d00b9b6f4bf04005c708af3faa115f7b45692ace064ebe758c68e8"},
+ {file = "funcparserlib-1.0.1.tar.gz", hash = "sha256:a2c4a0d7942f7a0e7635c369d921066c8d4cae7f8b5bf7914466bec3c69837f4"},
+]
+
+[[package]]
+name = "graphviz"
+version = "0.20.1"
+description = "Simple Python interface for Graphviz"
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "graphviz-0.20.1-py3-none-any.whl", hash = "sha256:587c58a223b51611c0cf461132da386edd896a029524ca61a1462b880bf97977"},
+ {file = "graphviz-0.20.1.zip", hash = "sha256:8c58f14adaa3b947daf26c19bc1e98c4e0702cdc31cf99153e6f06904d492bf8"},
+]
+
+[package.extras]
+dev = ["flake8", "pep8-naming", "tox (>=3)", "twine", "wheel"]
+docs = ["sphinx (>=5)", "sphinx-autodoc-typehints", "sphinx-rtd-theme"]
+test = ["coverage", "mock (>=4)", "pytest (>=7)", "pytest-cov", "pytest-mock (>=3)"]
+
+[[package]]
+name = "idna"
+version = "3.6"
+description = "Internationalized Domain Names in Applications (IDNA)"
+optional = false
+python-versions = ">=3.5"
+files = [
+ {file = "idna-3.6-py3-none-any.whl", hash = "sha256:c05567e9c24a6b9faaa835c4821bad0590fbb9d5779e7caa6e1cc4978e7eb24f"},
+ {file = "idna-3.6.tar.gz", hash = "sha256:9ecdbbd083b06798ae1e86adcbfe8ab1479cf864e4ee30fe4e46a003d12491ca"},
+]
+
+[[package]]
+name = "importlib-metadata"
+version = "6.8.0"
+description = "Read metadata from Python packages"
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "importlib_metadata-6.8.0-py3-none-any.whl", hash = "sha256:3ebb78df84a805d7698245025b975d9d67053cd94c79245ba4b3eb694abe68bb"},
+ {file = "importlib_metadata-6.8.0.tar.gz", hash = "sha256:dbace7892d8c0c4ac1ad096662232f831d4e64f4c4545bd53016a3e9d4654743"},
+]
+
+[package.dependencies]
+zipp = ">=0.5"
+
+[package.extras]
+docs = ["furo", "jaraco.packaging (>=9)", "jaraco.tidelift (>=1.4)", "rst.linker (>=1.9)", "sphinx (>=3.5)", "sphinx-lint"]
+perf = ["ipython"]
+testing = ["flufl.flake8", "importlib-resources (>=1.3)", "packaging", "pyfakefs", "pytest (>=6)", "pytest-black (>=0.3.7)", "pytest-checkdocs (>=2.4)", "pytest-cov", "pytest-enabler (>=2.2)", "pytest-mypy (>=0.9.1)", "pytest-perf (>=0.9.2)", "pytest-ruff"]
+
+[[package]]
+name = "isort"
+version = "5.12.0"
+description = "A Python utility / library to sort Python imports."
+optional = false
+python-versions = ">=3.8.0"
+files = [
+ {file = "isort-5.12.0-py3-none-any.whl", hash = "sha256:f84c2818376e66cf843d497486ea8fed8700b340f308f076c6fb1229dff318b6"},
+ {file = "isort-5.12.0.tar.gz", hash = "sha256:8bef7dde241278824a6d83f44a544709b065191b95b6e50894bdc722fcba0504"},
+]
+
+[package.extras]
+colors = ["colorama (>=0.4.3)"]
+pipfile-deprecated-finder = ["pip-shims (>=0.5.2)", "pipreqs", "requirementslib"]
+plugins = ["setuptools"]
+requirements-deprecated-finder = ["pip-api", "pipreqs"]
+
+[[package]]
+name = "lazy-object-proxy"
+version = "1.9.0"
+description = "A fast and thorough lazy object proxy."
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "lazy-object-proxy-1.9.0.tar.gz", hash = "sha256:659fb5809fa4629b8a1ac5106f669cfc7bef26fbb389dda53b3e010d1ac4ebae"},
+ {file = "lazy_object_proxy-1.9.0-cp310-cp310-macosx_10_9_x86_64.whl", hash = "sha256:b40387277b0ed2d0602b8293b94d7257e17d1479e257b4de114ea11a8cb7f2d7"},
+ {file = "lazy_object_proxy-1.9.0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:e8c6cfb338b133fbdbc5cfaa10fe3c6aeea827db80c978dbd13bc9dd8526b7d4"},
+ {file = "lazy_object_proxy-1.9.0-cp310-cp310-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:721532711daa7db0d8b779b0bb0318fa87af1c10d7fe5e52ef30f8eff254d0cd"},
+ {file = "lazy_object_proxy-1.9.0-cp310-cp310-musllinux_1_1_aarch64.whl", hash = "sha256:66a3de4a3ec06cd8af3f61b8e1ec67614fbb7c995d02fa224813cb7afefee701"},
+ {file = "lazy_object_proxy-1.9.0-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:1aa3de4088c89a1b69f8ec0dcc169aa725b0ff017899ac568fe44ddc1396df46"},
+ {file = "lazy_object_proxy-1.9.0-cp310-cp310-win32.whl", hash = "sha256:f0705c376533ed2a9e5e97aacdbfe04cecd71e0aa84c7c0595d02ef93b6e4455"},
+ {file = "lazy_object_proxy-1.9.0-cp310-cp310-win_amd64.whl", hash = "sha256:ea806fd4c37bf7e7ad82537b0757999264d5f70c45468447bb2b91afdbe73a6e"},
+ {file = "lazy_object_proxy-1.9.0-cp311-cp311-macosx_10_9_x86_64.whl", hash = "sha256:946d27deaff6cf8452ed0dba83ba38839a87f4f7a9732e8f9fd4107b21e6ff07"},
+ {file = "lazy_object_proxy-1.9.0-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:79a31b086e7e68b24b99b23d57723ef7e2c6d81ed21007b6281ebcd1688acb0a"},
+ {file = "lazy_object_proxy-1.9.0-cp311-cp311-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:f699ac1c768270c9e384e4cbd268d6e67aebcfae6cd623b4d7c3bfde5a35db59"},
+ {file = "lazy_object_proxy-1.9.0-cp311-cp311-musllinux_1_1_aarch64.whl", hash = "sha256:bfb38f9ffb53b942f2b5954e0f610f1e721ccebe9cce9025a38c8ccf4a5183a4"},
+ {file = "lazy_object_proxy-1.9.0-cp311-cp311-musllinux_1_1_x86_64.whl", hash = "sha256:189bbd5d41ae7a498397287c408617fe5c48633e7755287b21d741f7db2706a9"},
+ {file = "lazy_object_proxy-1.9.0-cp311-cp311-win32.whl", hash = "sha256:81fc4d08b062b535d95c9ea70dbe8a335c45c04029878e62d744bdced5141586"},
+ {file = "lazy_object_proxy-1.9.0-cp311-cp311-win_amd64.whl", hash = "sha256:f2457189d8257dd41ae9b434ba33298aec198e30adf2dcdaaa3a28b9994f6adb"},
+ {file = "lazy_object_proxy-1.9.0-cp37-cp37m-macosx_10_9_x86_64.whl", hash = "sha256:d9e25ef10a39e8afe59a5c348a4dbf29b4868ab76269f81ce1674494e2565a6e"},
+ {file = "lazy_object_proxy-1.9.0-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:cbf9b082426036e19c6924a9ce90c740a9861e2bdc27a4834fd0a910742ac1e8"},
+ {file = "lazy_object_proxy-1.9.0-cp37-cp37m-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:9f5fa4a61ce2438267163891961cfd5e32ec97a2c444e5b842d574251ade27d2"},
+ {file = "lazy_object_proxy-1.9.0-cp37-cp37m-musllinux_1_1_aarch64.whl", hash = "sha256:8fa02eaab317b1e9e03f69aab1f91e120e7899b392c4fc19807a8278a07a97e8"},
+ {file = "lazy_object_proxy-1.9.0-cp37-cp37m-musllinux_1_1_x86_64.whl", hash = "sha256:e7c21c95cae3c05c14aafffe2865bbd5e377cfc1348c4f7751d9dc9a48ca4bda"},
+ {file = "lazy_object_proxy-1.9.0-cp37-cp37m-win32.whl", hash = "sha256:f12ad7126ae0c98d601a7ee504c1122bcef553d1d5e0c3bfa77b16b3968d2734"},
+ {file = "lazy_object_proxy-1.9.0-cp37-cp37m-win_amd64.whl", hash = "sha256:edd20c5a55acb67c7ed471fa2b5fb66cb17f61430b7a6b9c3b4a1e40293b1671"},
+ {file = "lazy_object_proxy-1.9.0-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:2d0daa332786cf3bb49e10dc6a17a52f6a8f9601b4cf5c295a4f85854d61de63"},
+ {file = "lazy_object_proxy-1.9.0-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:9cd077f3d04a58e83d04b20e334f678c2b0ff9879b9375ed107d5d07ff160171"},
+ {file = "lazy_object_proxy-1.9.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:660c94ea760b3ce47d1855a30984c78327500493d396eac4dfd8bd82041b22be"},
+ {file = "lazy_object_proxy-1.9.0-cp38-cp38-musllinux_1_1_aarch64.whl", hash = "sha256:212774e4dfa851e74d393a2370871e174d7ff0ebc980907723bb67d25c8a7c30"},
+ {file = "lazy_object_proxy-1.9.0-cp38-cp38-musllinux_1_1_x86_64.whl", hash = "sha256:f0117049dd1d5635bbff65444496c90e0baa48ea405125c088e93d9cf4525b11"},
+ {file = "lazy_object_proxy-1.9.0-cp38-cp38-win32.whl", hash = "sha256:0a891e4e41b54fd5b8313b96399f8b0e173bbbfc03c7631f01efbe29bb0bcf82"},
+ {file = "lazy_object_proxy-1.9.0-cp38-cp38-win_amd64.whl", hash = "sha256:9990d8e71b9f6488e91ad25f322898c136b008d87bf852ff65391b004da5e17b"},
+ {file = "lazy_object_proxy-1.9.0-cp39-cp39-macosx_10_9_x86_64.whl", hash = "sha256:9e7551208b2aded9c1447453ee366f1c4070602b3d932ace044715d89666899b"},
+ {file = "lazy_object_proxy-1.9.0-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:5f83ac4d83ef0ab017683d715ed356e30dd48a93746309c8f3517e1287523ef4"},
+ {file = "lazy_object_proxy-1.9.0-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:7322c3d6f1766d4ef1e51a465f47955f1e8123caee67dd641e67d539a534d006"},
+ {file = "lazy_object_proxy-1.9.0-cp39-cp39-musllinux_1_1_aarch64.whl", hash = "sha256:18b78ec83edbbeb69efdc0e9c1cb41a3b1b1ed11ddd8ded602464c3fc6020494"},
+ {file = "lazy_object_proxy-1.9.0-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:09763491ce220c0299688940f8dc2c5d05fd1f45af1e42e636b2e8b2303e4382"},
+ {file = "lazy_object_proxy-1.9.0-cp39-cp39-win32.whl", hash = "sha256:9090d8e53235aa280fc9239a86ae3ea8ac58eff66a705fa6aa2ec4968b95c821"},
+ {file = "lazy_object_proxy-1.9.0-cp39-cp39-win_amd64.whl", hash = "sha256:db1c1722726f47e10e0b5fdbf15ac3b8adb58c091d12b3ab713965795036985f"},
+]
+
+[[package]]
+name = "lxml"
+version = "4.9.3"
+description = "Powerful and Pythonic XML processing library combining libxml2/libxslt with the ElementTree API."
+optional = false
+python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, != 3.4.*"
+files = [
+ {file = "lxml-4.9.3-cp27-cp27m-macosx_11_0_x86_64.whl", hash = "sha256:b0a545b46b526d418eb91754565ba5b63b1c0b12f9bd2f808c852d9b4b2f9b5c"},
+ {file = "lxml-4.9.3-cp27-cp27m-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:075b731ddd9e7f68ad24c635374211376aa05a281673ede86cbe1d1b3455279d"},
+ {file = "lxml-4.9.3-cp27-cp27m-manylinux_2_5_x86_64.manylinux1_x86_64.whl", hash = "sha256:1e224d5755dba2f4a9498e150c43792392ac9b5380aa1b845f98a1618c94eeef"},
+ {file = "lxml-4.9.3-cp27-cp27m-win32.whl", hash = "sha256:2c74524e179f2ad6d2a4f7caf70e2d96639c0954c943ad601a9e146c76408ed7"},
+ {file = "lxml-4.9.3-cp27-cp27m-win_amd64.whl", hash = "sha256:4f1026bc732b6a7f96369f7bfe1a4f2290fb34dce00d8644bc3036fb351a4ca1"},
+ {file = "lxml-4.9.3-cp27-cp27mu-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:c0781a98ff5e6586926293e59480b64ddd46282953203c76ae15dbbbf302e8bb"},
+ {file = "lxml-4.9.3-cp27-cp27mu-manylinux_2_5_x86_64.manylinux1_x86_64.whl", hash = "sha256:cef2502e7e8a96fe5ad686d60b49e1ab03e438bd9123987994528febd569868e"},
+ {file = "lxml-4.9.3-cp310-cp310-macosx_11_0_x86_64.whl", hash = "sha256:b86164d2cff4d3aaa1f04a14685cbc072efd0b4f99ca5708b2ad1b9b5988a991"},
+ {file = "lxml-4.9.3-cp310-cp310-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl", hash = "sha256:42871176e7896d5d45138f6d28751053c711ed4d48d8e30b498da155af39aebd"},
+ {file = "lxml-4.9.3-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:ae8b9c6deb1e634ba4f1930eb67ef6e6bf6a44b6eb5ad605642b2d6d5ed9ce3c"},
+ {file = "lxml-4.9.3-cp310-cp310-manylinux_2_28_aarch64.whl", hash = "sha256:411007c0d88188d9f621b11d252cce90c4a2d1a49db6c068e3c16422f306eab8"},
+ {file = "lxml-4.9.3-cp310-cp310-manylinux_2_28_x86_64.whl", hash = "sha256:cd47b4a0d41d2afa3e58e5bf1f62069255aa2fd6ff5ee41604418ca925911d76"},
+ {file = "lxml-4.9.3-cp310-cp310-musllinux_1_1_aarch64.whl", hash = "sha256:0e2cb47860da1f7e9a5256254b74ae331687b9672dfa780eed355c4c9c3dbd23"},
+ {file = "lxml-4.9.3-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:1247694b26342a7bf47c02e513d32225ededd18045264d40758abeb3c838a51f"},
+ {file = "lxml-4.9.3-cp310-cp310-win32.whl", hash = "sha256:cdb650fc86227eba20de1a29d4b2c1bfe139dc75a0669270033cb2ea3d391b85"},
+ {file = "lxml-4.9.3-cp310-cp310-win_amd64.whl", hash = "sha256:97047f0d25cd4bcae81f9ec9dc290ca3e15927c192df17331b53bebe0e3ff96d"},
+ {file = "lxml-4.9.3-cp311-cp311-macosx_11_0_universal2.whl", hash = "sha256:1f447ea5429b54f9582d4b955f5f1985f278ce5cf169f72eea8afd9502973dd5"},
+ {file = "lxml-4.9.3-cp311-cp311-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl", hash = "sha256:57d6ba0ca2b0c462f339640d22882acc711de224d769edf29962b09f77129cbf"},
+ {file = "lxml-4.9.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:9767e79108424fb6c3edf8f81e6730666a50feb01a328f4a016464a5893f835a"},
+ {file = "lxml-4.9.3-cp311-cp311-manylinux_2_28_aarch64.whl", hash = "sha256:71c52db65e4b56b8ddc5bb89fb2e66c558ed9d1a74a45ceb7dcb20c191c3df2f"},
+ {file = "lxml-4.9.3-cp311-cp311-manylinux_2_28_x86_64.whl", hash = "sha256:d73d8ecf8ecf10a3bd007f2192725a34bd62898e8da27eb9d32a58084f93962b"},
+ {file = "lxml-4.9.3-cp311-cp311-musllinux_1_1_aarch64.whl", hash = "sha256:0a3d3487f07c1d7f150894c238299934a2a074ef590b583103a45002035be120"},
+ {file = "lxml-4.9.3-cp311-cp311-musllinux_1_1_x86_64.whl", hash = "sha256:9e28c51fa0ce5674be9f560c6761c1b441631901993f76700b1b30ca6c8378d6"},
+ {file = "lxml-4.9.3-cp311-cp311-win32.whl", hash = "sha256:0bfd0767c5c1de2551a120673b72e5d4b628737cb05414f03c3277bf9bed3305"},
+ {file = "lxml-4.9.3-cp311-cp311-win_amd64.whl", hash = "sha256:25f32acefac14ef7bd53e4218fe93b804ef6f6b92ffdb4322bb6d49d94cad2bc"},
+ {file = "lxml-4.9.3-cp312-cp312-macosx_11_0_universal2.whl", hash = "sha256:d3ff32724f98fbbbfa9f49d82852b159e9784d6094983d9a8b7f2ddaebb063d4"},
+ {file = "lxml-4.9.3-cp312-cp312-manylinux_2_28_aarch64.whl", hash = "sha256:48d6ed886b343d11493129e019da91d4039826794a3e3027321c56d9e71505be"},
+ {file = "lxml-4.9.3-cp312-cp312-manylinux_2_28_x86_64.whl", hash = "sha256:9a92d3faef50658dd2c5470af249985782bf754c4e18e15afb67d3ab06233f13"},
+ {file = "lxml-4.9.3-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:b4e4bc18382088514ebde9328da057775055940a1f2e18f6ad2d78aa0f3ec5b9"},
+ {file = "lxml-4.9.3-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:fc9b106a1bf918db68619fdcd6d5ad4f972fdd19c01d19bdb6bf63f3589a9ec5"},
+ {file = "lxml-4.9.3-cp312-cp312-win_amd64.whl", hash = "sha256:d37017287a7adb6ab77e1c5bee9bcf9660f90ff445042b790402a654d2ad81d8"},
+ {file = "lxml-4.9.3-cp35-cp35m-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:56dc1f1ebccc656d1b3ed288f11e27172a01503fc016bcabdcbc0978b19352b7"},
+ {file = "lxml-4.9.3-cp35-cp35m-manylinux_2_5_x86_64.manylinux1_x86_64.whl", hash = "sha256:578695735c5a3f51569810dfebd05dd6f888147a34f0f98d4bb27e92b76e05c2"},
+ {file = "lxml-4.9.3-cp35-cp35m-win32.whl", hash = "sha256:704f61ba8c1283c71b16135caf697557f5ecf3e74d9e453233e4771d68a1f42d"},
+ {file = "lxml-4.9.3-cp35-cp35m-win_amd64.whl", hash = "sha256:c41bfca0bd3532d53d16fd34d20806d5c2b1ace22a2f2e4c0008570bf2c58833"},
+ {file = "lxml-4.9.3-cp36-cp36m-macosx_11_0_x86_64.whl", hash = "sha256:64f479d719dc9f4c813ad9bb6b28f8390360660b73b2e4beb4cb0ae7104f1c12"},
+ {file = "lxml-4.9.3-cp36-cp36m-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl", hash = "sha256:dd708cf4ee4408cf46a48b108fb9427bfa00b9b85812a9262b5c668af2533ea5"},
+ {file = "lxml-4.9.3-cp36-cp36m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:5c31c7462abdf8f2ac0577d9f05279727e698f97ecbb02f17939ea99ae8daa98"},
+ {file = "lxml-4.9.3-cp36-cp36m-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:e3cd95e10c2610c360154afdc2f1480aea394f4a4f1ea0a5eacce49640c9b190"},
+ {file = "lxml-4.9.3-cp36-cp36m-manylinux_2_28_x86_64.whl", hash = "sha256:4930be26af26ac545c3dffb662521d4e6268352866956672231887d18f0eaab2"},
+ {file = "lxml-4.9.3-cp36-cp36m-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:4aec80cde9197340bc353d2768e2a75f5f60bacda2bab72ab1dc499589b3878c"},
+ {file = "lxml-4.9.3-cp36-cp36m-manylinux_2_5_x86_64.manylinux1_x86_64.whl", hash = "sha256:14e019fd83b831b2e61baed40cab76222139926b1fb5ed0e79225bc0cae14584"},
+ {file = "lxml-4.9.3-cp36-cp36m-musllinux_1_1_aarch64.whl", hash = "sha256:0c0850c8b02c298d3c7006b23e98249515ac57430e16a166873fc47a5d549287"},
+ {file = "lxml-4.9.3-cp36-cp36m-musllinux_1_1_x86_64.whl", hash = "sha256:aca086dc5f9ef98c512bac8efea4483eb84abbf926eaeedf7b91479feb092458"},
+ {file = "lxml-4.9.3-cp36-cp36m-win32.whl", hash = "sha256:50baa9c1c47efcaef189f31e3d00d697c6d4afda5c3cde0302d063492ff9b477"},
+ {file = "lxml-4.9.3-cp36-cp36m-win_amd64.whl", hash = "sha256:bef4e656f7d98aaa3486d2627e7d2df1157d7e88e7efd43a65aa5dd4714916cf"},
+ {file = "lxml-4.9.3-cp37-cp37m-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl", hash = "sha256:46f409a2d60f634fe550f7133ed30ad5321ae2e6630f13657fb9479506b00601"},
+ {file = "lxml-4.9.3-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.manylinux_2_24_aarch64.whl", hash = "sha256:4c28a9144688aef80d6ea666c809b4b0e50010a2aca784c97f5e6bf143d9f129"},
+ {file = "lxml-4.9.3-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:141f1d1a9b663c679dc524af3ea1773e618907e96075262726c7612c02b149a4"},
+ {file = "lxml-4.9.3-cp37-cp37m-manylinux_2_28_x86_64.whl", hash = "sha256:53ace1c1fd5a74ef662f844a0413446c0629d151055340e9893da958a374f70d"},
+ {file = "lxml-4.9.3-cp37-cp37m-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:17a753023436a18e27dd7769e798ce302963c236bc4114ceee5b25c18c52c693"},
+ {file = "lxml-4.9.3-cp37-cp37m-manylinux_2_5_x86_64.manylinux1_x86_64.whl", hash = "sha256:7d298a1bd60c067ea75d9f684f5f3992c9d6766fadbc0bcedd39750bf344c2f4"},
+ {file = "lxml-4.9.3-cp37-cp37m-musllinux_1_1_aarch64.whl", hash = "sha256:081d32421db5df44c41b7f08a334a090a545c54ba977e47fd7cc2deece78809a"},
+ {file = "lxml-4.9.3-cp37-cp37m-musllinux_1_1_x86_64.whl", hash = "sha256:23eed6d7b1a3336ad92d8e39d4bfe09073c31bfe502f20ca5116b2a334f8ec02"},
+ {file = "lxml-4.9.3-cp37-cp37m-win32.whl", hash = "sha256:1509dd12b773c02acd154582088820893109f6ca27ef7291b003d0e81666109f"},
+ {file = "lxml-4.9.3-cp37-cp37m-win_amd64.whl", hash = "sha256:120fa9349a24c7043854c53cae8cec227e1f79195a7493e09e0c12e29f918e52"},
+ {file = "lxml-4.9.3-cp38-cp38-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl", hash = "sha256:4d2d1edbca80b510443f51afd8496be95529db04a509bc8faee49c7b0fb6d2cc"},
+ {file = "lxml-4.9.3-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.manylinux_2_24_aarch64.whl", hash = "sha256:8d7e43bd40f65f7d97ad8ef5c9b1778943d02f04febef12def25f7583d19baac"},
+ {file = "lxml-4.9.3-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:71d66ee82e7417828af6ecd7db817913cb0cf9d4e61aa0ac1fde0583d84358db"},
+ {file = "lxml-4.9.3-cp38-cp38-manylinux_2_28_x86_64.whl", hash = "sha256:6fc3c450eaa0b56f815c7b62f2b7fba7266c4779adcf1cece9e6deb1de7305ce"},
+ {file = "lxml-4.9.3-cp38-cp38-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:65299ea57d82fb91c7f019300d24050c4ddeb7c5a190e076b5f48a2b43d19c42"},
+ {file = "lxml-4.9.3-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.whl", hash = "sha256:eadfbbbfb41b44034a4c757fd5d70baccd43296fb894dba0295606a7cf3124aa"},
+ {file = "lxml-4.9.3-cp38-cp38-musllinux_1_1_aarch64.whl", hash = "sha256:3e9bdd30efde2b9ccfa9cb5768ba04fe71b018a25ea093379c857c9dad262c40"},
+ {file = "lxml-4.9.3-cp38-cp38-musllinux_1_1_x86_64.whl", hash = "sha256:fcdd00edfd0a3001e0181eab3e63bd5c74ad3e67152c84f93f13769a40e073a7"},
+ {file = "lxml-4.9.3-cp38-cp38-win32.whl", hash = "sha256:57aba1bbdf450b726d58b2aea5fe47c7875f5afb2c4a23784ed78f19a0462574"},
+ {file = "lxml-4.9.3-cp38-cp38-win_amd64.whl", hash = "sha256:92af161ecbdb2883c4593d5ed4815ea71b31fafd7fd05789b23100d081ecac96"},
+ {file = "lxml-4.9.3-cp39-cp39-macosx_11_0_x86_64.whl", hash = "sha256:9bb6ad405121241e99a86efff22d3ef469024ce22875a7ae045896ad23ba2340"},
+ {file = "lxml-4.9.3-cp39-cp39-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl", hash = "sha256:8ed74706b26ad100433da4b9d807eae371efaa266ffc3e9191ea436087a9d6a7"},
+ {file = "lxml-4.9.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:fbf521479bcac1e25a663df882c46a641a9bff6b56dc8b0fafaebd2f66fb231b"},
+ {file = "lxml-4.9.3-cp39-cp39-manylinux_2_28_aarch64.whl", hash = "sha256:303bf1edce6ced16bf67a18a1cf8339d0db79577eec5d9a6d4a80f0fb10aa2da"},
+ {file = "lxml-4.9.3-cp39-cp39-manylinux_2_28_x86_64.whl", hash = "sha256:5515edd2a6d1a5a70bfcdee23b42ec33425e405c5b351478ab7dc9347228f96e"},
+ {file = "lxml-4.9.3-cp39-cp39-manylinux_2_5_i686.manylinux1_i686.whl", hash = "sha256:690dafd0b187ed38583a648076865d8c229661ed20e48f2335d68e2cf7dc829d"},
+ {file = "lxml-4.9.3-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.whl", hash = "sha256:b6420a005548ad52154c8ceab4a1290ff78d757f9e5cbc68f8c77089acd3c432"},
+ {file = "lxml-4.9.3-cp39-cp39-musllinux_1_1_aarch64.whl", hash = "sha256:bb3bb49c7a6ad9d981d734ef7c7193bc349ac338776a0360cc671eaee89bcf69"},
+ {file = "lxml-4.9.3-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:d27be7405547d1f958b60837dc4c1007da90b8b23f54ba1f8b728c78fdb19d50"},
+ {file = "lxml-4.9.3-cp39-cp39-win32.whl", hash = "sha256:8df133a2ea5e74eef5e8fc6f19b9e085f758768a16e9877a60aec455ed2609b2"},
+ {file = "lxml-4.9.3-cp39-cp39-win_amd64.whl", hash = "sha256:4dd9a263e845a72eacb60d12401e37c616438ea2e5442885f65082c276dfb2b2"},
+ {file = "lxml-4.9.3-pp310-pypy310_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:6689a3d7fd13dc687e9102a27e98ef33730ac4fe37795d5036d18b4d527abd35"},
+ {file = "lxml-4.9.3-pp37-pypy37_pp73-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl", hash = "sha256:f6bdac493b949141b733c5345b6ba8f87a226029cbabc7e9e121a413e49441e0"},
+ {file = "lxml-4.9.3-pp37-pypy37_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:05186a0f1346ae12553d66df1cfce6f251589fea3ad3da4f3ef4e34b2d58c6a3"},
+ {file = "lxml-4.9.3-pp37-pypy37_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:c2006f5c8d28dee289f7020f721354362fa304acbaaf9745751ac4006650254b"},
+ {file = "lxml-4.9.3-pp38-pypy38_pp73-macosx_11_0_x86_64.whl", hash = "sha256:5c245b783db29c4e4fbbbfc9c5a78be496c9fea25517f90606aa1f6b2b3d5f7b"},
+ {file = "lxml-4.9.3-pp38-pypy38_pp73-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl", hash = "sha256:4fb960a632a49f2f089d522f70496640fdf1218f1243889da3822e0a9f5f3ba7"},
+ {file = "lxml-4.9.3-pp38-pypy38_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:50670615eaf97227d5dc60de2dc99fb134a7130d310d783314e7724bf163f75d"},
+ {file = "lxml-4.9.3-pp38-pypy38_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:9719fe17307a9e814580af1f5c6e05ca593b12fb7e44fe62450a5384dbf61b4b"},
+ {file = "lxml-4.9.3-pp38-pypy38_pp73-win_amd64.whl", hash = "sha256:3331bece23c9ee066e0fb3f96c61322b9e0f54d775fccefff4c38ca488de283a"},
+ {file = "lxml-4.9.3-pp39-pypy39_pp73-macosx_11_0_x86_64.whl", hash = "sha256:ed667f49b11360951e201453fc3967344d0d0263aa415e1619e85ae7fd17b4e0"},
+ {file = "lxml-4.9.3-pp39-pypy39_pp73-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl", hash = "sha256:8b77946fd508cbf0fccd8e400a7f71d4ac0e1595812e66025bac475a8e811694"},
+ {file = "lxml-4.9.3-pp39-pypy39_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:e4da8ca0c0c0aea88fd46be8e44bd49716772358d648cce45fe387f7b92374a7"},
+ {file = "lxml-4.9.3-pp39-pypy39_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:fe4bda6bd4340caa6e5cf95e73f8fea5c4bfc55763dd42f1b50a94c1b4a2fbd4"},
+ {file = "lxml-4.9.3-pp39-pypy39_pp73-win_amd64.whl", hash = "sha256:f3df3db1d336b9356dd3112eae5f5c2b8b377f3bc826848567f10bfddfee77e9"},
+ {file = "lxml-4.9.3.tar.gz", hash = "sha256:48628bd53a426c9eb9bc066a923acaa0878d1e86129fd5359aee99285f4eed9c"},
+]
+
+[package.extras]
+cssselect = ["cssselect (>=0.7)"]
+html5 = ["html5lib"]
+htmlsoup = ["BeautifulSoup4"]
+source = ["Cython (>=0.29.35)"]
+
+[[package]]
+name = "mako"
+version = "1.3.0"
+description = "A super-fast templating language that borrows the best ideas from the existing templating languages."
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "Mako-1.3.0-py3-none-any.whl", hash = "sha256:57d4e997349f1a92035aa25c17ace371a4213f2ca42f99bee9a602500cfd54d9"},
+ {file = "Mako-1.3.0.tar.gz", hash = "sha256:e3a9d388fd00e87043edbe8792f45880ac0114e9c4adc69f6e9bfb2c55e3b11b"},
+]
+
+[package.dependencies]
+MarkupSafe = ">=0.9.2"
+
+[package.extras]
+babel = ["Babel"]
+lingua = ["lingua"]
+testing = ["pytest"]
+
+[[package]]
+name = "markdown"
+version = "3.5.1"
+description = "Python implementation of John Gruber's Markdown."
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "Markdown-3.5.1-py3-none-any.whl", hash = "sha256:5874b47d4ee3f0b14d764324d2c94c03ea66bee56f2d929da9f2508d65e722dc"},
+ {file = "Markdown-3.5.1.tar.gz", hash = "sha256:b65d7beb248dc22f2e8a31fb706d93798093c308dc1aba295aedeb9d41a813bd"},
+]
+
+[package.dependencies]
+importlib-metadata = {version = ">=4.4", markers = "python_version < \"3.10\""}
+
+[package.extras]
+docs = ["mdx-gh-links (>=0.2)", "mkdocs (>=1.5)", "mkdocs-gen-files", "mkdocs-literate-nav", "mkdocs-nature (>=0.6)", "mkdocs-section-index", "mkdocstrings[python]"]
+testing = ["coverage", "pyyaml"]
+
+[[package]]
+name = "markupsafe"
+version = "2.1.3"
+description = "Safely add untrusted strings to HTML/XML markup."
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "MarkupSafe-2.1.3-cp310-cp310-macosx_10_9_universal2.whl", hash = "sha256:cd0f502fe016460680cd20aaa5a76d241d6f35a1c3350c474bac1273803893fa"},
+ {file = "MarkupSafe-2.1.3-cp310-cp310-macosx_10_9_x86_64.whl", hash = "sha256:e09031c87a1e51556fdcb46e5bd4f59dfb743061cf93c4d6831bf894f125eb57"},
+ {file = "MarkupSafe-2.1.3-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:68e78619a61ecf91e76aa3e6e8e33fc4894a2bebe93410754bd28fce0a8a4f9f"},
+ {file = "MarkupSafe-2.1.3-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:65c1a9bcdadc6c28eecee2c119465aebff8f7a584dd719facdd9e825ec61ab52"},
+ {file = "MarkupSafe-2.1.3-cp310-cp310-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:525808b8019e36eb524b8c68acdd63a37e75714eac50e988180b169d64480a00"},
+ {file = "MarkupSafe-2.1.3-cp310-cp310-musllinux_1_1_aarch64.whl", hash = "sha256:962f82a3086483f5e5f64dbad880d31038b698494799b097bc59c2edf392fce6"},
+ {file = "MarkupSafe-2.1.3-cp310-cp310-musllinux_1_1_i686.whl", hash = "sha256:aa7bd130efab1c280bed0f45501b7c8795f9fdbeb02e965371bbef3523627779"},
+ {file = "MarkupSafe-2.1.3-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:c9c804664ebe8f83a211cace637506669e7890fec1b4195b505c214e50dd4eb7"},
+ {file = "MarkupSafe-2.1.3-cp310-cp310-win32.whl", hash = "sha256:10bbfe99883db80bdbaff2dcf681dfc6533a614f700da1287707e8a5d78a8431"},
+ {file = "MarkupSafe-2.1.3-cp310-cp310-win_amd64.whl", hash = "sha256:1577735524cdad32f9f694208aa75e422adba74f1baee7551620e43a3141f559"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-macosx_10_9_universal2.whl", hash = "sha256:ad9e82fb8f09ade1c3e1b996a6337afac2b8b9e365f926f5a61aacc71adc5b3c"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-macosx_10_9_x86_64.whl", hash = "sha256:3c0fae6c3be832a0a0473ac912810b2877c8cb9d76ca48de1ed31e1c68386575"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:b076b6226fb84157e3f7c971a47ff3a679d837cf338547532ab866c57930dbee"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:bfce63a9e7834b12b87c64d6b155fdd9b3b96191b6bd334bf37db7ff1fe457f2"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:338ae27d6b8745585f87218a3f23f1512dbf52c26c28e322dbe54bcede54ccb9"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-musllinux_1_1_aarch64.whl", hash = "sha256:e4dd52d80b8c83fdce44e12478ad2e85c64ea965e75d66dbeafb0a3e77308fcc"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-musllinux_1_1_i686.whl", hash = "sha256:df0be2b576a7abbf737b1575f048c23fb1d769f267ec4358296f31c2479db8f9"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-musllinux_1_1_x86_64.whl", hash = "sha256:5bbe06f8eeafd38e5d0a4894ffec89378b6c6a625ff57e3028921f8ff59318ac"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-win32.whl", hash = "sha256:dd15ff04ffd7e05ffcb7fe79f1b98041b8ea30ae9234aed2a9168b5797c3effb"},
+ {file = "MarkupSafe-2.1.3-cp311-cp311-win_amd64.whl", hash = "sha256:134da1eca9ec0ae528110ccc9e48041e0828d79f24121a1a146161103c76e686"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-macosx_10_9_universal2.whl", hash = "sha256:f698de3fd0c4e6972b92290a45bd9b1536bffe8c6759c62471efaa8acb4c37bc"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-macosx_10_9_x86_64.whl", hash = "sha256:aa57bd9cf8ae831a362185ee444e15a93ecb2e344c8e52e4d721ea3ab6ef1823"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:ffcc3f7c66b5f5b7931a5aa68fc9cecc51e685ef90282f4a82f0f5e9b704ad11"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:47d4f1c5f80fc62fdd7777d0d40a2e9dda0a05883ab11374334f6c4de38adffd"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:1f67c7038d560d92149c060157d623c542173016c4babc0c1913cca0564b9939"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:9aad3c1755095ce347e26488214ef77e0485a3c34a50c5a5e2471dff60b9dd9c"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-musllinux_1_1_i686.whl", hash = "sha256:14ff806850827afd6b07a5f32bd917fb7f45b046ba40c57abdb636674a8b559c"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:8f9293864fe09b8149f0cc42ce56e3f0e54de883a9de90cd427f191c346eb2e1"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-win32.whl", hash = "sha256:715d3562f79d540f251b99ebd6d8baa547118974341db04f5ad06d5ea3eb8007"},
+ {file = "MarkupSafe-2.1.3-cp312-cp312-win_amd64.whl", hash = "sha256:1b8dd8c3fd14349433c79fa8abeb573a55fc0fdd769133baac1f5e07abf54aeb"},
+ {file = "MarkupSafe-2.1.3-cp37-cp37m-macosx_10_9_x86_64.whl", hash = "sha256:8e254ae696c88d98da6555f5ace2279cf7cd5b3f52be2b5cf97feafe883b58d2"},
+ {file = "MarkupSafe-2.1.3-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:cb0932dc158471523c9637e807d9bfb93e06a95cbf010f1a38b98623b929ef2b"},
+ {file = "MarkupSafe-2.1.3-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:9402b03f1a1b4dc4c19845e5c749e3ab82d5078d16a2a4c2cd2df62d57bb0707"},
+ {file = "MarkupSafe-2.1.3-cp37-cp37m-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:ca379055a47383d02a5400cb0d110cef0a776fc644cda797db0c5696cfd7e18e"},
+ {file = "MarkupSafe-2.1.3-cp37-cp37m-musllinux_1_1_aarch64.whl", hash = "sha256:b7ff0f54cb4ff66dd38bebd335a38e2c22c41a8ee45aa608efc890ac3e3931bc"},
+ {file = "MarkupSafe-2.1.3-cp37-cp37m-musllinux_1_1_i686.whl", hash = "sha256:c011a4149cfbcf9f03994ec2edffcb8b1dc2d2aede7ca243746df97a5d41ce48"},
+ {file = "MarkupSafe-2.1.3-cp37-cp37m-musllinux_1_1_x86_64.whl", hash = "sha256:56d9f2ecac662ca1611d183feb03a3fa4406469dafe241673d521dd5ae92a155"},
+ {file = "MarkupSafe-2.1.3-cp37-cp37m-win32.whl", hash = "sha256:8758846a7e80910096950b67071243da3e5a20ed2546e6392603c096778d48e0"},
+ {file = "MarkupSafe-2.1.3-cp37-cp37m-win_amd64.whl", hash = "sha256:787003c0ddb00500e49a10f2844fac87aa6ce977b90b0feaaf9de23c22508b24"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-macosx_10_9_universal2.whl", hash = "sha256:2ef12179d3a291be237280175b542c07a36e7f60718296278d8593d21ca937d4"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:2c1b19b3aaacc6e57b7e25710ff571c24d6c3613a45e905b1fde04d691b98ee0"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:8afafd99945ead6e075b973fefa56379c5b5c53fd8937dad92c662da5d8fd5ee"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:8c41976a29d078bb235fea9b2ecd3da465df42a562910f9022f1a03107bd02be"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:d080e0a5eb2529460b30190fcfcc4199bd7f827663f858a226a81bc27beaa97e"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-musllinux_1_1_aarch64.whl", hash = "sha256:69c0f17e9f5a7afdf2cc9fb2d1ce6aabdb3bafb7f38017c0b77862bcec2bbad8"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-musllinux_1_1_i686.whl", hash = "sha256:504b320cd4b7eff6f968eddf81127112db685e81f7e36e75f9f84f0df46041c3"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-musllinux_1_1_x86_64.whl", hash = "sha256:42de32b22b6b804f42c5d98be4f7e5e977ecdd9ee9b660fda1a3edf03b11792d"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-win32.whl", hash = "sha256:ceb01949af7121f9fc39f7d27f91be8546f3fb112c608bc4029aef0bab86a2a5"},
+ {file = "MarkupSafe-2.1.3-cp38-cp38-win_amd64.whl", hash = "sha256:1b40069d487e7edb2676d3fbdb2b0829ffa2cd63a2ec26c4938b2d34391b4ecc"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-macosx_10_9_universal2.whl", hash = "sha256:8023faf4e01efadfa183e863fefde0046de576c6f14659e8782065bcece22198"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-macosx_10_9_x86_64.whl", hash = "sha256:6b2b56950d93e41f33b4223ead100ea0fe11f8e6ee5f641eb753ce4b77a7042b"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:9dcdfd0eaf283af041973bff14a2e143b8bd64e069f4c383416ecd79a81aab58"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:05fb21170423db021895e1ea1e1f3ab3adb85d1c2333cbc2310f2a26bc77272e"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:282c2cb35b5b673bbcadb33a585408104df04f14b2d9b01d4c345a3b92861c2c"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-musllinux_1_1_aarch64.whl", hash = "sha256:ab4a0df41e7c16a1392727727e7998a467472d0ad65f3ad5e6e765015df08636"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-musllinux_1_1_i686.whl", hash = "sha256:7ef3cb2ebbf91e330e3bb937efada0edd9003683db6b57bb108c4001f37a02ea"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:0a4e4a1aff6c7ac4cd55792abf96c915634c2b97e3cc1c7129578aa68ebd754e"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-win32.whl", hash = "sha256:fec21693218efe39aa7f8599346e90c705afa52c5b31ae019b2e57e8f6542bb2"},
+ {file = "MarkupSafe-2.1.3-cp39-cp39-win_amd64.whl", hash = "sha256:3fd4abcb888d15a94f32b75d8fd18ee162ca0c064f35b11134be77050296d6ba"},
+ {file = "MarkupSafe-2.1.3.tar.gz", hash = "sha256:af598ed32d6ae86f1b747b82783958b1a4ab8f617b06fe68795c7f026abbdcad"},
+]
+
+[[package]]
+name = "mccabe"
+version = "0.7.0"
+description = "McCabe checker, plugin for flake8"
+optional = false
+python-versions = ">=3.6"
+files = [
+ {file = "mccabe-0.7.0-py2.py3-none-any.whl", hash = "sha256:6c2d30ab6be0e4a46919781807b4f0d834ebdd6c6e3dca0bda5a15f863427b6e"},
+ {file = "mccabe-0.7.0.tar.gz", hash = "sha256:348e0240c33b60bbdf4e523192ef919f28cb2c3d7d5c7794f74009290f236325"},
+]
+
+[[package]]
+name = "numpy"
+version = "1.24.4"
+description = "Fundamental package for array computing in Python"
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "numpy-1.24.4-cp310-cp310-macosx_10_9_x86_64.whl", hash = "sha256:c0bfb52d2169d58c1cdb8cc1f16989101639b34c7d3ce60ed70b19c63eba0b64"},
+ {file = "numpy-1.24.4-cp310-cp310-macosx_11_0_arm64.whl", hash = "sha256:ed094d4f0c177b1b8e7aa9cba7d6ceed51c0e569a5318ac0ca9a090680a6a1b1"},
+ {file = "numpy-1.24.4-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:79fc682a374c4a8ed08b331bef9c5f582585d1048fa6d80bc6c35bc384eee9b4"},
+ {file = "numpy-1.24.4-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:7ffe43c74893dbf38c2b0a1f5428760a1a9c98285553c89e12d70a96a7f3a4d6"},
+ {file = "numpy-1.24.4-cp310-cp310-win32.whl", hash = "sha256:4c21decb6ea94057331e111a5bed9a79d335658c27ce2adb580fb4d54f2ad9bc"},
+ {file = "numpy-1.24.4-cp310-cp310-win_amd64.whl", hash = "sha256:b4bea75e47d9586d31e892a7401f76e909712a0fd510f58f5337bea9572c571e"},
+ {file = "numpy-1.24.4-cp311-cp311-macosx_10_9_x86_64.whl", hash = "sha256:f136bab9c2cfd8da131132c2cf6cc27331dd6fae65f95f69dcd4ae3c3639c810"},
+ {file = "numpy-1.24.4-cp311-cp311-macosx_11_0_arm64.whl", hash = "sha256:e2926dac25b313635e4d6cf4dc4e51c8c0ebfed60b801c799ffc4c32bf3d1254"},
+ {file = "numpy-1.24.4-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:222e40d0e2548690405b0b3c7b21d1169117391c2e82c378467ef9ab4c8f0da7"},
+ {file = "numpy-1.24.4-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:7215847ce88a85ce39baf9e89070cb860c98fdddacbaa6c0da3ffb31b3350bd5"},
+ {file = "numpy-1.24.4-cp311-cp311-win32.whl", hash = "sha256:4979217d7de511a8d57f4b4b5b2b965f707768440c17cb70fbf254c4b225238d"},
+ {file = "numpy-1.24.4-cp311-cp311-win_amd64.whl", hash = "sha256:b7b1fc9864d7d39e28f41d089bfd6353cb5f27ecd9905348c24187a768c79694"},
+ {file = "numpy-1.24.4-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:1452241c290f3e2a312c137a9999cdbf63f78864d63c79039bda65ee86943f61"},
+ {file = "numpy-1.24.4-cp38-cp38-macosx_11_0_arm64.whl", hash = "sha256:04640dab83f7c6c85abf9cd729c5b65f1ebd0ccf9de90b270cd61935eef0197f"},
+ {file = "numpy-1.24.4-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:a5425b114831d1e77e4b5d812b69d11d962e104095a5b9c3b641a218abcc050e"},
+ {file = "numpy-1.24.4-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:dd80e219fd4c71fc3699fc1dadac5dcf4fd882bfc6f7ec53d30fa197b8ee22dc"},
+ {file = "numpy-1.24.4-cp38-cp38-win32.whl", hash = "sha256:4602244f345453db537be5314d3983dbf5834a9701b7723ec28923e2889e0bb2"},
+ {file = "numpy-1.24.4-cp38-cp38-win_amd64.whl", hash = "sha256:692f2e0f55794943c5bfff12b3f56f99af76f902fc47487bdfe97856de51a706"},
+ {file = "numpy-1.24.4-cp39-cp39-macosx_10_9_x86_64.whl", hash = "sha256:2541312fbf09977f3b3ad449c4e5f4bb55d0dbf79226d7724211acc905049400"},
+ {file = "numpy-1.24.4-cp39-cp39-macosx_11_0_arm64.whl", hash = "sha256:9667575fb6d13c95f1b36aca12c5ee3356bf001b714fc354eb5465ce1609e62f"},
+ {file = "numpy-1.24.4-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:f3a86ed21e4f87050382c7bc96571755193c4c1392490744ac73d660e8f564a9"},
+ {file = "numpy-1.24.4-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:d11efb4dbecbdf22508d55e48d9c8384db795e1b7b51ea735289ff96613ff74d"},
+ {file = "numpy-1.24.4-cp39-cp39-win32.whl", hash = "sha256:6620c0acd41dbcb368610bb2f4d83145674040025e5536954782467100aa8835"},
+ {file = "numpy-1.24.4-cp39-cp39-win_amd64.whl", hash = "sha256:befe2bf740fd8373cf56149a5c23a0f601e82869598d41f8e188a0e9869926f8"},
+ {file = "numpy-1.24.4-pp38-pypy38_pp73-macosx_10_9_x86_64.whl", hash = "sha256:31f13e25b4e304632a4619d0e0777662c2ffea99fcae2029556b17d8ff958aef"},
+ {file = "numpy-1.24.4-pp38-pypy38_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:95f7ac6540e95bc440ad77f56e520da5bf877f87dca58bd095288dce8940532a"},
+ {file = "numpy-1.24.4-pp38-pypy38_pp73-win_amd64.whl", hash = "sha256:e98f220aa76ca2a977fe435f5b04d7b3470c0a2e6312907b37ba6068f26787f2"},
+ {file = "numpy-1.24.4.tar.gz", hash = "sha256:80f5e3a4e498641401868df4208b74581206afbee7cf7b8329daae82676d9463"},
+]
+
+[[package]]
+name = "numpy"
+version = "1.26.2"
+description = "Fundamental package for array computing in Python"
+optional = false
+python-versions = ">=3.9"
+files = [
+ {file = "numpy-1.26.2-cp310-cp310-macosx_10_9_x86_64.whl", hash = "sha256:3703fc9258a4a122d17043e57b35e5ef1c5a5837c3db8be396c82e04c1cf9b0f"},
+ {file = "numpy-1.26.2-cp310-cp310-macosx_11_0_arm64.whl", hash = "sha256:cc392fdcbd21d4be6ae1bb4475a03ce3b025cd49a9be5345d76d7585aea69440"},
+ {file = "numpy-1.26.2-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:36340109af8da8805d8851ef1d74761b3b88e81a9bd80b290bbfed61bd2b4f75"},
+ {file = "numpy-1.26.2-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:bcc008217145b3d77abd3e4d5ef586e3bdfba8fe17940769f8aa09b99e856c00"},
+ {file = "numpy-1.26.2-cp310-cp310-musllinux_1_1_aarch64.whl", hash = "sha256:3ced40d4e9e18242f70dd02d739e44698df3dcb010d31f495ff00a31ef6014fe"},
+ {file = "numpy-1.26.2-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:b272d4cecc32c9e19911891446b72e986157e6a1809b7b56518b4f3755267523"},
+ {file = "numpy-1.26.2-cp310-cp310-win32.whl", hash = "sha256:22f8fc02fdbc829e7a8c578dd8d2e15a9074b630d4da29cda483337e300e3ee9"},
+ {file = "numpy-1.26.2-cp310-cp310-win_amd64.whl", hash = "sha256:26c9d33f8e8b846d5a65dd068c14e04018d05533b348d9eaeef6c1bd787f9919"},
+ {file = "numpy-1.26.2-cp311-cp311-macosx_10_9_x86_64.whl", hash = "sha256:b96e7b9c624ef3ae2ae0e04fa9b460f6b9f17ad8b4bec6d7756510f1f6c0c841"},
+ {file = "numpy-1.26.2-cp311-cp311-macosx_11_0_arm64.whl", hash = "sha256:aa18428111fb9a591d7a9cc1b48150097ba6a7e8299fb56bdf574df650e7d1f1"},
+ {file = "numpy-1.26.2-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:06fa1ed84aa60ea6ef9f91ba57b5ed963c3729534e6e54055fc151fad0423f0a"},
+ {file = "numpy-1.26.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:96ca5482c3dbdd051bcd1fce8034603d6ebfc125a7bd59f55b40d8f5d246832b"},
+ {file = "numpy-1.26.2-cp311-cp311-musllinux_1_1_aarch64.whl", hash = "sha256:854ab91a2906ef29dc3925a064fcd365c7b4da743f84b123002f6139bcb3f8a7"},
+ {file = "numpy-1.26.2-cp311-cp311-musllinux_1_1_x86_64.whl", hash = "sha256:f43740ab089277d403aa07567be138fc2a89d4d9892d113b76153e0e412409f8"},
+ {file = "numpy-1.26.2-cp311-cp311-win32.whl", hash = "sha256:a2bbc29fcb1771cd7b7425f98b05307776a6baf43035d3b80c4b0f29e9545186"},
+ {file = "numpy-1.26.2-cp311-cp311-win_amd64.whl", hash = "sha256:2b3fca8a5b00184828d12b073af4d0fc5fdd94b1632c2477526f6bd7842d700d"},
+ {file = "numpy-1.26.2-cp312-cp312-macosx_10_9_x86_64.whl", hash = "sha256:a4cd6ed4a339c21f1d1b0fdf13426cb3b284555c27ac2f156dfdaaa7e16bfab0"},
+ {file = "numpy-1.26.2-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:5d5244aabd6ed7f312268b9247be47343a654ebea52a60f002dc70c769048e75"},
+ {file = "numpy-1.26.2-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:6a3cdb4d9c70e6b8c0814239ead47da00934666f668426fc6e94cce869e13fd7"},
+ {file = "numpy-1.26.2-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:aa317b2325f7aa0a9471663e6093c210cb2ae9c0ad824732b307d2c51983d5b6"},
+ {file = "numpy-1.26.2-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:174a8880739c16c925799c018f3f55b8130c1f7c8e75ab0a6fa9d41cab092fd6"},
+ {file = "numpy-1.26.2-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:f79b231bf5c16b1f39c7f4875e1ded36abee1591e98742b05d8a0fb55d8a3eec"},
+ {file = "numpy-1.26.2-cp312-cp312-win32.whl", hash = "sha256:4a06263321dfd3598cacb252f51e521a8cb4b6df471bb12a7ee5cbab20ea9167"},
+ {file = "numpy-1.26.2-cp312-cp312-win_amd64.whl", hash = "sha256:b04f5dc6b3efdaab541f7857351aac359e6ae3c126e2edb376929bd3b7f92d7e"},
+ {file = "numpy-1.26.2-cp39-cp39-macosx_10_9_x86_64.whl", hash = "sha256:4eb8df4bf8d3d90d091e0146f6c28492b0be84da3e409ebef54349f71ed271ef"},
+ {file = "numpy-1.26.2-cp39-cp39-macosx_11_0_arm64.whl", hash = "sha256:1a13860fdcd95de7cf58bd6f8bc5a5ef81c0b0625eb2c9a783948847abbef2c2"},
+ {file = "numpy-1.26.2-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:64308ebc366a8ed63fd0bf426b6a9468060962f1a4339ab1074c228fa6ade8e3"},
+ {file = "numpy-1.26.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:baf8aab04a2c0e859da118f0b38617e5ee65d75b83795055fb66c0d5e9e9b818"},
+ {file = "numpy-1.26.2-cp39-cp39-musllinux_1_1_aarch64.whl", hash = "sha256:d73a3abcac238250091b11caef9ad12413dab01669511779bc9b29261dd50210"},
+ {file = "numpy-1.26.2-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:b361d369fc7e5e1714cf827b731ca32bff8d411212fccd29ad98ad622449cc36"},
+ {file = "numpy-1.26.2-cp39-cp39-win32.whl", hash = "sha256:bd3f0091e845164a20bd5a326860c840fe2af79fa12e0469a12768a3ec578d80"},
+ {file = "numpy-1.26.2-cp39-cp39-win_amd64.whl", hash = "sha256:2beef57fb031dcc0dc8fa4fe297a742027b954949cabb52a2a376c144e5e6060"},
+ {file = "numpy-1.26.2-pp39-pypy39_pp73-macosx_10_9_x86_64.whl", hash = "sha256:1cc3d5029a30fb5f06704ad6b23b35e11309491c999838c31f124fee32107c79"},
+ {file = "numpy-1.26.2-pp39-pypy39_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:94cc3c222bb9fb5a12e334d0479b97bb2df446fbe622b470928f5284ffca3f8d"},
+ {file = "numpy-1.26.2-pp39-pypy39_pp73-win_amd64.whl", hash = "sha256:fe6b44fb8fcdf7eda4ef4461b97b3f63c466b27ab151bec2366db8b197387841"},
+ {file = "numpy-1.26.2.tar.gz", hash = "sha256:f65738447676ab5777f11e6bbbdb8ce11b785e105f690bc45966574816b6d3ea"},
+]
+
+[[package]]
+name = "openpyxl"
+version = "3.1.2"
+description = "A Python library to read/write Excel 2010 xlsx/xlsm files"
+optional = false
+python-versions = ">=3.6"
+files = [
+ {file = "openpyxl-3.1.2-py2.py3-none-any.whl", hash = "sha256:f91456ead12ab3c6c2e9491cf33ba6d08357d802192379bb482f1033ade496f5"},
+ {file = "openpyxl-3.1.2.tar.gz", hash = "sha256:a6f5977418eff3b2d5500d54d9db50c8277a368436f4e4f8ddb1be3422870184"},
+]
+
+[package.dependencies]
+et-xmlfile = "*"
+
+[[package]]
+name = "pandas"
+version = "2.0.3"
+description = "Powerful data structures for data analysis, time series, and statistics"
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "pandas-2.0.3-cp310-cp310-macosx_10_9_x86_64.whl", hash = "sha256:e4c7c9f27a4185304c7caf96dc7d91bc60bc162221152de697c98eb0b2648dd8"},
+ {file = "pandas-2.0.3-cp310-cp310-macosx_11_0_arm64.whl", hash = "sha256:f167beed68918d62bffb6ec64f2e1d8a7d297a038f86d4aed056b9493fca407f"},
+ {file = "pandas-2.0.3-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:ce0c6f76a0f1ba361551f3e6dceaff06bde7514a374aa43e33b588ec10420183"},
+ {file = "pandas-2.0.3-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:ba619e410a21d8c387a1ea6e8a0e49bb42216474436245718d7f2e88a2f8d7c0"},
+ {file = "pandas-2.0.3-cp310-cp310-win32.whl", hash = "sha256:3ef285093b4fe5058eefd756100a367f27029913760773c8bf1d2d8bebe5d210"},
+ {file = "pandas-2.0.3-cp310-cp310-win_amd64.whl", hash = "sha256:9ee1a69328d5c36c98d8e74db06f4ad518a1840e8ccb94a4ba86920986bb617e"},
+ {file = "pandas-2.0.3-cp311-cp311-macosx_10_9_x86_64.whl", hash = "sha256:b084b91d8d66ab19f5bb3256cbd5ea661848338301940e17f4492b2ce0801fe8"},
+ {file = "pandas-2.0.3-cp311-cp311-macosx_11_0_arm64.whl", hash = "sha256:37673e3bdf1551b95bf5d4ce372b37770f9529743d2498032439371fc7b7eb26"},
+ {file = "pandas-2.0.3-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:b9cb1e14fdb546396b7e1b923ffaeeac24e4cedd14266c3497216dd4448e4f2d"},
+ {file = "pandas-2.0.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:d9cd88488cceb7635aebb84809d087468eb33551097d600c6dad13602029c2df"},
+ {file = "pandas-2.0.3-cp311-cp311-win32.whl", hash = "sha256:694888a81198786f0e164ee3a581df7d505024fbb1f15202fc7db88a71d84ebd"},
+ {file = "pandas-2.0.3-cp311-cp311-win_amd64.whl", hash = "sha256:6a21ab5c89dcbd57f78d0ae16630b090eec626360085a4148693def5452d8a6b"},
+ {file = "pandas-2.0.3-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:9e4da0d45e7f34c069fe4d522359df7d23badf83abc1d1cef398895822d11061"},
+ {file = "pandas-2.0.3-cp38-cp38-macosx_11_0_arm64.whl", hash = "sha256:32fca2ee1b0d93dd71d979726b12b61faa06aeb93cf77468776287f41ff8fdc5"},
+ {file = "pandas-2.0.3-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:258d3624b3ae734490e4d63c430256e716f488c4fcb7c8e9bde2d3aa46c29089"},
+ {file = "pandas-2.0.3-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:9eae3dc34fa1aa7772dd3fc60270d13ced7346fcbcfee017d3132ec625e23bb0"},
+ {file = "pandas-2.0.3-cp38-cp38-win32.whl", hash = "sha256:f3421a7afb1a43f7e38e82e844e2bca9a6d793d66c1a7f9f0ff39a795bbc5e02"},
+ {file = "pandas-2.0.3-cp38-cp38-win_amd64.whl", hash = "sha256:69d7f3884c95da3a31ef82b7618af5710dba95bb885ffab339aad925c3e8ce78"},
+ {file = "pandas-2.0.3-cp39-cp39-macosx_10_9_x86_64.whl", hash = "sha256:5247fb1ba347c1261cbbf0fcfba4a3121fbb4029d95d9ef4dc45406620b25c8b"},
+ {file = "pandas-2.0.3-cp39-cp39-macosx_11_0_arm64.whl", hash = "sha256:81af086f4543c9d8bb128328b5d32e9986e0c84d3ee673a2ac6fb57fd14f755e"},
+ {file = "pandas-2.0.3-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:1994c789bf12a7c5098277fb43836ce090f1073858c10f9220998ac74f37c69b"},
+ {file = "pandas-2.0.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:5ec591c48e29226bcbb316e0c1e9423622bc7a4eaf1ef7c3c9fa1a3981f89641"},
+ {file = "pandas-2.0.3-cp39-cp39-win32.whl", hash = "sha256:04dbdbaf2e4d46ca8da896e1805bc04eb85caa9a82e259e8eed00254d5e0c682"},
+ {file = "pandas-2.0.3-cp39-cp39-win_amd64.whl", hash = "sha256:1168574b036cd8b93abc746171c9b4f1b83467438a5e45909fed645cf8692dbc"},
+ {file = "pandas-2.0.3.tar.gz", hash = "sha256:c02f372a88e0d17f36d3093a644c73cfc1788e876a7c4bcb4020a77512e2043c"},
+]
+
+[package.dependencies]
+numpy = [
+ {version = ">=1.20.3", markers = "python_version < \"3.10\""},
+ {version = ">=1.21.0", markers = "python_version >= \"3.10\""},
+ {version = ">=1.23.2", markers = "python_version >= \"3.11\""},
+]
+python-dateutil = ">=2.8.2"
+pytz = ">=2020.1"
+tzdata = ">=2022.1"
+
+[package.extras]
+all = ["PyQt5 (>=5.15.1)", "SQLAlchemy (>=1.4.16)", "beautifulsoup4 (>=4.9.3)", "bottleneck (>=1.3.2)", "brotlipy (>=0.7.0)", "fastparquet (>=0.6.3)", "fsspec (>=2021.07.0)", "gcsfs (>=2021.07.0)", "html5lib (>=1.1)", "hypothesis (>=6.34.2)", "jinja2 (>=3.0.0)", "lxml (>=4.6.3)", "matplotlib (>=3.6.1)", "numba (>=0.53.1)", "numexpr (>=2.7.3)", "odfpy (>=1.4.1)", "openpyxl (>=3.0.7)", "pandas-gbq (>=0.15.0)", "psycopg2 (>=2.8.6)", "pyarrow (>=7.0.0)", "pymysql (>=1.0.2)", "pyreadstat (>=1.1.2)", "pytest (>=7.3.2)", "pytest-asyncio (>=0.17.0)", "pytest-xdist (>=2.2.0)", "python-snappy (>=0.6.0)", "pyxlsb (>=1.0.8)", "qtpy (>=2.2.0)", "s3fs (>=2021.08.0)", "scipy (>=1.7.1)", "tables (>=3.6.1)", "tabulate (>=0.8.9)", "xarray (>=0.21.0)", "xlrd (>=2.0.1)", "xlsxwriter (>=1.4.3)", "zstandard (>=0.15.2)"]
+aws = ["s3fs (>=2021.08.0)"]
+clipboard = ["PyQt5 (>=5.15.1)", "qtpy (>=2.2.0)"]
+compression = ["brotlipy (>=0.7.0)", "python-snappy (>=0.6.0)", "zstandard (>=0.15.2)"]
+computation = ["scipy (>=1.7.1)", "xarray (>=0.21.0)"]
+excel = ["odfpy (>=1.4.1)", "openpyxl (>=3.0.7)", "pyxlsb (>=1.0.8)", "xlrd (>=2.0.1)", "xlsxwriter (>=1.4.3)"]
+feather = ["pyarrow (>=7.0.0)"]
+fss = ["fsspec (>=2021.07.0)"]
+gcp = ["gcsfs (>=2021.07.0)", "pandas-gbq (>=0.15.0)"]
+hdf5 = ["tables (>=3.6.1)"]
+html = ["beautifulsoup4 (>=4.9.3)", "html5lib (>=1.1)", "lxml (>=4.6.3)"]
+mysql = ["SQLAlchemy (>=1.4.16)", "pymysql (>=1.0.2)"]
+output-formatting = ["jinja2 (>=3.0.0)", "tabulate (>=0.8.9)"]
+parquet = ["pyarrow (>=7.0.0)"]
+performance = ["bottleneck (>=1.3.2)", "numba (>=0.53.1)", "numexpr (>=2.7.1)"]
+plot = ["matplotlib (>=3.6.1)"]
+postgresql = ["SQLAlchemy (>=1.4.16)", "psycopg2 (>=2.8.6)"]
+spss = ["pyreadstat (>=1.1.2)"]
+sql-other = ["SQLAlchemy (>=1.4.16)"]
+test = ["hypothesis (>=6.34.2)", "pytest (>=7.3.2)", "pytest-asyncio (>=0.17.0)", "pytest-xdist (>=2.2.0)"]
+xml = ["lxml (>=4.6.3)"]
+
+[[package]]
+name = "pdoc3"
+version = "0.10.0"
+description = "Auto-generate API documentation for Python projects."
+optional = false
+python-versions = ">= 3.6"
+files = [
+ {file = "pdoc3-0.10.0-py3-none-any.whl", hash = "sha256:ba45d1ada1bd987427d2bf5cdec30b2631a3ff5fb01f6d0e77648a572ce6028b"},
+ {file = "pdoc3-0.10.0.tar.gz", hash = "sha256:5f22e7bcb969006738e1aa4219c75a32f34c2d62d46dc9d2fb2d3e0b0287e4b7"},
+]
+
+[package.dependencies]
+mako = "*"
+markdown = ">=3.0"
+
+[[package]]
+name = "pillow"
+version = "10.1.0"
+description = "Python Imaging Library (Fork)"
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "Pillow-10.1.0-cp310-cp310-macosx_10_10_x86_64.whl", hash = "sha256:1ab05f3db77e98f93964697c8efc49c7954b08dd61cff526b7f2531a22410106"},
+ {file = "Pillow-10.1.0-cp310-cp310-macosx_11_0_arm64.whl", hash = "sha256:6932a7652464746fcb484f7fc3618e6503d2066d853f68a4bd97193a3996e273"},
+ {file = "Pillow-10.1.0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:a5f63b5a68daedc54c7c3464508d8c12075e56dcfbd42f8c1bf40169061ae666"},
+ {file = "Pillow-10.1.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:c0949b55eb607898e28eaccb525ab104b2d86542a85c74baf3a6dc24002edec2"},
+ {file = "Pillow-10.1.0-cp310-cp310-manylinux_2_28_aarch64.whl", hash = "sha256:ae88931f93214777c7a3aa0a8f92a683f83ecde27f65a45f95f22d289a69e593"},
+ {file = "Pillow-10.1.0-cp310-cp310-manylinux_2_28_x86_64.whl", hash = "sha256:b0eb01ca85b2361b09480784a7931fc648ed8b7836f01fb9241141b968feb1db"},
+ {file = "Pillow-10.1.0-cp310-cp310-musllinux_1_1_aarch64.whl", hash = "sha256:d27b5997bdd2eb9fb199982bb7eb6164db0426904020dc38c10203187ae2ff2f"},
+ {file = "Pillow-10.1.0-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:7df5608bc38bd37ef585ae9c38c9cd46d7c81498f086915b0f97255ea60c2818"},
+ {file = "Pillow-10.1.0-cp310-cp310-win_amd64.whl", hash = "sha256:41f67248d92a5e0a2076d3517d8d4b1e41a97e2df10eb8f93106c89107f38b57"},
+ {file = "Pillow-10.1.0-cp311-cp311-macosx_10_10_x86_64.whl", hash = "sha256:1fb29c07478e6c06a46b867e43b0bcdb241b44cc52be9bc25ce5944eed4648e7"},
+ {file = "Pillow-10.1.0-cp311-cp311-macosx_11_0_arm64.whl", hash = "sha256:2cdc65a46e74514ce742c2013cd4a2d12e8553e3a2563c64879f7c7e4d28bce7"},
+ {file = "Pillow-10.1.0-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:50d08cd0a2ecd2a8657bd3d82c71efd5a58edb04d9308185d66c3a5a5bed9610"},
+ {file = "Pillow-10.1.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:062a1610e3bc258bff2328ec43f34244fcec972ee0717200cb1425214fe5b839"},
+ {file = "Pillow-10.1.0-cp311-cp311-manylinux_2_28_aarch64.whl", hash = "sha256:61f1a9d247317fa08a308daaa8ee7b3f760ab1809ca2da14ecc88ae4257d6172"},
+ {file = "Pillow-10.1.0-cp311-cp311-manylinux_2_28_x86_64.whl", hash = "sha256:a646e48de237d860c36e0db37ecaecaa3619e6f3e9d5319e527ccbc8151df061"},
+ {file = "Pillow-10.1.0-cp311-cp311-musllinux_1_1_aarch64.whl", hash = "sha256:47e5bf85b80abc03be7455c95b6d6e4896a62f6541c1f2ce77a7d2bb832af262"},
+ {file = "Pillow-10.1.0-cp311-cp311-musllinux_1_1_x86_64.whl", hash = "sha256:a92386125e9ee90381c3369f57a2a50fa9e6aa8b1cf1d9c4b200d41a7dd8e992"},
+ {file = "Pillow-10.1.0-cp311-cp311-win_amd64.whl", hash = "sha256:0f7c276c05a9767e877a0b4c5050c8bee6a6d960d7f0c11ebda6b99746068c2a"},
+ {file = "Pillow-10.1.0-cp312-cp312-macosx_10_10_x86_64.whl", hash = "sha256:a89b8312d51715b510a4fe9fc13686283f376cfd5abca8cd1c65e4c76e21081b"},
+ {file = "Pillow-10.1.0-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:00f438bb841382b15d7deb9a05cc946ee0f2c352653c7aa659e75e592f6fa17d"},
+ {file = "Pillow-10.1.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:3d929a19f5469b3f4df33a3df2983db070ebb2088a1e145e18facbc28cae5b27"},
+ {file = "Pillow-10.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:9a92109192b360634a4489c0c756364c0c3a2992906752165ecb50544c251312"},
+ {file = "Pillow-10.1.0-cp312-cp312-manylinux_2_28_aarch64.whl", hash = "sha256:0248f86b3ea061e67817c47ecbe82c23f9dd5d5226200eb9090b3873d3ca32de"},
+ {file = "Pillow-10.1.0-cp312-cp312-manylinux_2_28_x86_64.whl", hash = "sha256:9882a7451c680c12f232a422730f986a1fcd808da0fd428f08b671237237d651"},
+ {file = "Pillow-10.1.0-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:1c3ac5423c8c1da5928aa12c6e258921956757d976405e9467c5f39d1d577a4b"},
+ {file = "Pillow-10.1.0-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:806abdd8249ba3953c33742506fe414880bad78ac25cc9a9b1c6ae97bedd573f"},
+ {file = "Pillow-10.1.0-cp312-cp312-win_amd64.whl", hash = "sha256:eaed6977fa73408b7b8a24e8b14e59e1668cfc0f4c40193ea7ced8e210adf996"},
+ {file = "Pillow-10.1.0-cp38-cp38-macosx_10_10_x86_64.whl", hash = "sha256:fe1e26e1ffc38be097f0ba1d0d07fcade2bcfd1d023cda5b29935ae8052bd793"},
+ {file = "Pillow-10.1.0-cp38-cp38-macosx_11_0_arm64.whl", hash = "sha256:7a7e3daa202beb61821c06d2517428e8e7c1aab08943e92ec9e5755c2fc9ba5e"},
+ {file = "Pillow-10.1.0-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:24fadc71218ad2b8ffe437b54876c9382b4a29e030a05a9879f615091f42ffc2"},
+ {file = "Pillow-10.1.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:fa1d323703cfdac2036af05191b969b910d8f115cf53093125e4058f62012c9a"},
+ {file = "Pillow-10.1.0-cp38-cp38-manylinux_2_28_aarch64.whl", hash = "sha256:912e3812a1dbbc834da2b32299b124b5ddcb664ed354916fd1ed6f193f0e2d01"},
+ {file = "Pillow-10.1.0-cp38-cp38-manylinux_2_28_x86_64.whl", hash = "sha256:7dbaa3c7de82ef37e7708521be41db5565004258ca76945ad74a8e998c30af8d"},
+ {file = "Pillow-10.1.0-cp38-cp38-musllinux_1_1_aarch64.whl", hash = "sha256:9d7bc666bd8c5a4225e7ac71f2f9d12466ec555e89092728ea0f5c0c2422ea80"},
+ {file = "Pillow-10.1.0-cp38-cp38-musllinux_1_1_x86_64.whl", hash = "sha256:baada14941c83079bf84c037e2d8b7506ce201e92e3d2fa0d1303507a8538212"},
+ {file = "Pillow-10.1.0-cp38-cp38-win_amd64.whl", hash = "sha256:2ef6721c97894a7aa77723740a09547197533146fba8355e86d6d9a4a1056b14"},
+ {file = "Pillow-10.1.0-cp39-cp39-macosx_10_10_x86_64.whl", hash = "sha256:0a026c188be3b443916179f5d04548092e253beb0c3e2ee0a4e2cdad72f66099"},
+ {file = "Pillow-10.1.0-cp39-cp39-macosx_11_0_arm64.whl", hash = "sha256:04f6f6149f266a100374ca3cc368b67fb27c4af9f1cc8cb6306d849dcdf12616"},
+ {file = "Pillow-10.1.0-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:bb40c011447712d2e19cc261c82655f75f32cb724788df315ed992a4d65696bb"},
+ {file = "Pillow-10.1.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:1a8413794b4ad9719346cd9306118450b7b00d9a15846451549314a58ac42219"},
+ {file = "Pillow-10.1.0-cp39-cp39-manylinux_2_28_aarch64.whl", hash = "sha256:c9aeea7b63edb7884b031a35305629a7593272b54f429a9869a4f63a1bf04c34"},
+ {file = "Pillow-10.1.0-cp39-cp39-manylinux_2_28_x86_64.whl", hash = "sha256:b4005fee46ed9be0b8fb42be0c20e79411533d1fd58edabebc0dd24626882cfd"},
+ {file = "Pillow-10.1.0-cp39-cp39-musllinux_1_1_aarch64.whl", hash = "sha256:4d0152565c6aa6ebbfb1e5d8624140a440f2b99bf7afaafbdbf6430426497f28"},
+ {file = "Pillow-10.1.0-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:d921bc90b1defa55c9917ca6b6b71430e4286fc9e44c55ead78ca1a9f9eba5f2"},
+ {file = "Pillow-10.1.0-cp39-cp39-win_amd64.whl", hash = "sha256:cfe96560c6ce2f4c07d6647af2d0f3c54cc33289894ebd88cfbb3bcd5391e256"},
+ {file = "Pillow-10.1.0-pp310-pypy310_pp73-macosx_10_10_x86_64.whl", hash = "sha256:937bdc5a7f5343d1c97dc98149a0be7eb9704e937fe3dc7140e229ae4fc572a7"},
+ {file = "Pillow-10.1.0-pp310-pypy310_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:b1c25762197144e211efb5f4e8ad656f36c8d214d390585d1d21281f46d556ba"},
+ {file = "Pillow-10.1.0-pp310-pypy310_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:afc8eef765d948543a4775f00b7b8c079b3321d6b675dde0d02afa2ee23000b4"},
+ {file = "Pillow-10.1.0-pp310-pypy310_pp73-win_amd64.whl", hash = "sha256:883f216eac8712b83a63f41b76ddfb7b2afab1b74abbb413c5df6680f071a6b9"},
+ {file = "Pillow-10.1.0-pp39-pypy39_pp73-macosx_10_10_x86_64.whl", hash = "sha256:b920e4d028f6442bea9a75b7491c063f0b9a3972520731ed26c83e254302eb1e"},
+ {file = "Pillow-10.1.0-pp39-pypy39_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:1c41d960babf951e01a49c9746f92c5a7e0d939d1652d7ba30f6b3090f27e412"},
+ {file = "Pillow-10.1.0-pp39-pypy39_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:1fafabe50a6977ac70dfe829b2d5735fd54e190ab55259ec8aea4aaea412fa0b"},
+ {file = "Pillow-10.1.0-pp39-pypy39_pp73-win_amd64.whl", hash = "sha256:3b834f4b16173e5b92ab6566f0473bfb09f939ba14b23b8da1f54fa63e4b623f"},
+ {file = "Pillow-10.1.0.tar.gz", hash = "sha256:e6bf8de6c36ed96c86ea3b6e1d5273c53f46ef518a062464cd7ef5dd2cf92e38"},
+]
+
+[package.extras]
+docs = ["furo", "olefile", "sphinx (>=2.4)", "sphinx-copybutton", "sphinx-inline-tabs", "sphinx-removed-in", "sphinxext-opengraph"]
+tests = ["check-manifest", "coverage", "defusedxml", "markdown2", "olefile", "packaging", "pyroma", "pytest", "pytest-cov", "pytest-timeout"]
+
+[[package]]
+name = "plantuml-markdown"
+version = "3.9.2"
+description = "A PlantUML plugin for Markdown"
+optional = false
+python-versions = "*"
+files = [
+ {file = "plantuml_markdown-3.9.2-py3-none-any.whl", hash = "sha256:5adbe2de83beb94e300ff026f2469b007166bccd2c1da882181ee3defc08326d"},
+]
+
+[package.dependencies]
+Markdown = "*"
+requests = "*"
+six = "*"
+
+[[package]]
+name = "platformdirs"
+version = "4.0.0"
+description = "A small Python package for determining appropriate platform-specific dirs, e.g. a \"user data dir\"."
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "platformdirs-4.0.0-py3-none-any.whl", hash = "sha256:118c954d7e949b35437270383a3f2531e99dd93cf7ce4dc8340d3356d30f173b"},
+ {file = "platformdirs-4.0.0.tar.gz", hash = "sha256:cb633b2bcf10c51af60beb0ab06d2f1d69064b43abf4c185ca6b28865f3f9731"},
+]
+
+[package.extras]
+docs = ["furo (>=2023.7.26)", "proselint (>=0.13)", "sphinx (>=7.1.1)", "sphinx-autodoc-typehints (>=1.24)"]
+test = ["appdirs (==1.4.4)", "covdefaults (>=2.3)", "pytest (>=7.4)", "pytest-cov (>=4.1)", "pytest-mock (>=3.11.1)"]
+
+[[package]]
+name = "pycparser"
+version = "2.21"
+description = "C parser in Python"
+optional = false
+python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*"
+files = [
+ {file = "pycparser-2.21-py2.py3-none-any.whl", hash = "sha256:8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9"},
+ {file = "pycparser-2.21.tar.gz", hash = "sha256:e644fdec12f7872f86c58ff790da456218b10f863970249516d60a5eaca77206"},
+]
+
+[[package]]
+name = "pycryptodome"
+version = "3.19.0"
+description = "Cryptographic library for Python"
+optional = false
+python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*"
+files = [
+ {file = "pycryptodome-3.19.0-cp27-cp27m-macosx_10_9_x86_64.whl", hash = "sha256:3006c44c4946583b6de24fe0632091c2653d6256b99a02a3db71ca06472ea1e4"},
+ {file = "pycryptodome-3.19.0-cp27-cp27m-manylinux2010_i686.whl", hash = "sha256:7c760c8a0479a4042111a8dd2f067d3ae4573da286c53f13cf6f5c53a5c1f631"},
+ {file = "pycryptodome-3.19.0-cp27-cp27m-manylinux2010_x86_64.whl", hash = "sha256:08ce3558af5106c632baf6d331d261f02367a6bc3733086ae43c0f988fe042db"},
+ {file = "pycryptodome-3.19.0-cp27-cp27m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:45430dfaf1f421cf462c0dd824984378bef32b22669f2635cb809357dbaab405"},
+ {file = "pycryptodome-3.19.0-cp27-cp27m-musllinux_1_1_aarch64.whl", hash = "sha256:a9bcd5f3794879e91970f2bbd7d899780541d3ff439d8f2112441769c9f2ccea"},
+ {file = "pycryptodome-3.19.0-cp27-cp27m-win32.whl", hash = "sha256:190c53f51e988dceb60472baddce3f289fa52b0ec38fbe5fd20dd1d0f795c551"},
+ {file = "pycryptodome-3.19.0-cp27-cp27m-win_amd64.whl", hash = "sha256:22e0ae7c3a7f87dcdcf302db06ab76f20e83f09a6993c160b248d58274473bfa"},
+ {file = "pycryptodome-3.19.0-cp27-cp27mu-manylinux2010_i686.whl", hash = "sha256:7822f36d683f9ad7bc2145b2c2045014afdbbd1d9922a6d4ce1cbd6add79a01e"},
+ {file = "pycryptodome-3.19.0-cp27-cp27mu-manylinux2010_x86_64.whl", hash = "sha256:05e33267394aad6db6595c0ce9d427fe21552f5425e116a925455e099fdf759a"},
+ {file = "pycryptodome-3.19.0-cp27-cp27mu-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:829b813b8ee00d9c8aba417621b94bc0b5efd18c928923802ad5ba4cf1ec709c"},
+ {file = "pycryptodome-3.19.0-cp27-cp27mu-musllinux_1_1_aarch64.whl", hash = "sha256:fc7a79590e2b5d08530175823a242de6790abc73638cc6dc9d2684e7be2f5e49"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-macosx_10_9_universal2.whl", hash = "sha256:542f99d5026ac5f0ef391ba0602f3d11beef8e65aae135fa5b762f5ebd9d3bfb"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-macosx_10_9_x86_64.whl", hash = "sha256:61bb3ccbf4bf32ad9af32da8badc24e888ae5231c617947e0f5401077f8b091f"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:d49a6c715d8cceffedabb6adb7e0cbf41ae1a2ff4adaeec9432074a80627dea1"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:e249a784cc98a29c77cea9df54284a44b40cafbfae57636dd2f8775b48af2434"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:d033947e7fd3e2ba9a031cb2d267251620964705a013c5a461fa5233cc025270"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-musllinux_1_1_aarch64.whl", hash = "sha256:84c3e4fffad0c4988aef0d5591be3cad4e10aa7db264c65fadbc633318d20bde"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-musllinux_1_1_i686.whl", hash = "sha256:139ae2c6161b9dd5d829c9645d781509a810ef50ea8b657e2257c25ca20efe33"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-musllinux_1_1_x86_64.whl", hash = "sha256:5b1986c761258a5b4332a7f94a83f631c1ffca8747d75ab8395bf2e1b93283d9"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-win32.whl", hash = "sha256:536f676963662603f1f2e6ab01080c54d8cd20f34ec333dcb195306fa7826997"},
+ {file = "pycryptodome-3.19.0-cp35-abi3-win_amd64.whl", hash = "sha256:04dd31d3b33a6b22ac4d432b3274588917dcf850cc0c51c84eca1d8ed6933810"},
+ {file = "pycryptodome-3.19.0-pp27-pypy_73-manylinux2010_x86_64.whl", hash = "sha256:8999316e57abcbd8085c91bc0ef75292c8618f41ca6d2b6132250a863a77d1e7"},
+ {file = "pycryptodome-3.19.0-pp27-pypy_73-win32.whl", hash = "sha256:a0ab84755f4539db086db9ba9e9f3868d2e3610a3948cbd2a55e332ad83b01b0"},
+ {file = "pycryptodome-3.19.0-pp310-pypy310_pp73-macosx_10_9_x86_64.whl", hash = "sha256:0101f647d11a1aae5a8ce4f5fad6644ae1b22bb65d05accc7d322943c69a74a6"},
+ {file = "pycryptodome-3.19.0-pp310-pypy310_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:8c1601e04d32087591d78e0b81e1e520e57a92796089864b20e5f18c9564b3fa"},
+ {file = "pycryptodome-3.19.0-pp310-pypy310_pp73-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:506c686a1eee6c00df70010be3b8e9e78f406af4f21b23162bbb6e9bdf5427bc"},
+ {file = "pycryptodome-3.19.0-pp310-pypy310_pp73-win_amd64.whl", hash = "sha256:7919ccd096584b911f2a303c593280869ce1af9bf5d36214511f5e5a1bed8c34"},
+ {file = "pycryptodome-3.19.0-pp39-pypy39_pp73-macosx_10_9_x86_64.whl", hash = "sha256:560591c0777f74a5da86718f70dfc8d781734cf559773b64072bbdda44b3fc3e"},
+ {file = "pycryptodome-3.19.0-pp39-pypy39_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:c1cc2f2ae451a676def1a73c1ae9120cd31af25db3f381893d45f75e77be2400"},
+ {file = "pycryptodome-3.19.0-pp39-pypy39_pp73-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:17940dcf274fcae4a54ec6117a9ecfe52907ed5e2e438fe712fe7ca502672ed5"},
+ {file = "pycryptodome-3.19.0-pp39-pypy39_pp73-win_amd64.whl", hash = "sha256:d04f5f623a280fbd0ab1c1d8ecbd753193ab7154f09b6161b0f857a1a676c15f"},
+ {file = "pycryptodome-3.19.0.tar.gz", hash = "sha256:bc35d463222cdb4dbebd35e0784155c81e161b9284e567e7e933d722e533331e"},
+]
+
+[[package]]
+name = "pyfiglet"
+version = "0.8.post1"
+description = "Pure-python FIGlet implementation"
+optional = false
+python-versions = "*"
+files = [
+ {file = "pyfiglet-0.8.post1-py2.py3-none-any.whl", hash = "sha256:d555bcea17fbeaf70eaefa48bb119352487e629c9b56f30f383e2c62dd67a01c"},
+ {file = "pyfiglet-0.8.post1.tar.gz", hash = "sha256:c6c2321755d09267b438ec7b936825a4910fec696292139e664ca8670e103639"},
+]
+
+[[package]]
+name = "pylint"
+version = "2.17.7"
+description = "python code static checker"
+optional = false
+python-versions = ">=3.7.2"
+files = [
+ {file = "pylint-2.17.7-py3-none-any.whl", hash = "sha256:27a8d4c7ddc8c2f8c18aa0050148f89ffc09838142193fdbe98f172781a3ff87"},
+ {file = "pylint-2.17.7.tar.gz", hash = "sha256:f4fcac7ae74cfe36bc8451e931d8438e4a476c20314b1101c458ad0f05191fad"},
+]
+
+[package.dependencies]
+astroid = ">=2.15.8,<=2.17.0-dev0"
+colorama = {version = ">=0.4.5", markers = "sys_platform == \"win32\""}
+dill = [
+ {version = ">=0.2", markers = "python_version < \"3.11\""},
+ {version = ">=0.3.6", markers = "python_version >= \"3.11\""},
+]
+isort = ">=4.2.5,<6"
+mccabe = ">=0.6,<0.8"
+platformdirs = ">=2.2.0"
+tomli = {version = ">=1.1.0", markers = "python_version < \"3.11\""}
+tomlkit = ">=0.10.1"
+typing-extensions = {version = ">=3.10.0", markers = "python_version < \"3.10\""}
+
+[package.extras]
+spelling = ["pyenchant (>=3.2,<4.0)"]
+testutils = ["gitpython (>3)"]
+
+[[package]]
+name = "pynacl"
+version = "1.5.0"
+description = "Python binding to the Networking and Cryptography (NaCl) library"
+optional = false
+python-versions = ">=3.6"
+files = [
+ {file = "PyNaCl-1.5.0-cp36-abi3-macosx_10_10_universal2.whl", hash = "sha256:401002a4aaa07c9414132aaed7f6836ff98f59277a234704ff66878c2ee4a0d1"},
+ {file = "PyNaCl-1.5.0-cp36-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.manylinux_2_24_aarch64.whl", hash = "sha256:52cb72a79269189d4e0dc537556f4740f7f0a9ec41c1322598799b0bdad4ef92"},
+ {file = "PyNaCl-1.5.0-cp36-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:a36d4a9dda1f19ce6e03c9a784a2921a4b726b02e1c736600ca9c22029474394"},
+ {file = "PyNaCl-1.5.0-cp36-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl", hash = "sha256:0c84947a22519e013607c9be43706dd42513f9e6ae5d39d3613ca1e142fba44d"},
+ {file = "PyNaCl-1.5.0-cp36-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:06b8f6fa7f5de8d5d2f7573fe8c863c051225a27b61e6860fd047b1775807858"},
+ {file = "PyNaCl-1.5.0-cp36-abi3-musllinux_1_1_aarch64.whl", hash = "sha256:a422368fc821589c228f4c49438a368831cb5bbc0eab5ebe1d7fac9dded6567b"},
+ {file = "PyNaCl-1.5.0-cp36-abi3-musllinux_1_1_x86_64.whl", hash = "sha256:61f642bf2378713e2c2e1de73444a3778e5f0a38be6fee0fe532fe30060282ff"},
+ {file = "PyNaCl-1.5.0-cp36-abi3-win32.whl", hash = "sha256:e46dae94e34b085175f8abb3b0aaa7da40767865ac82c928eeb9e57e1ea8a543"},
+ {file = "PyNaCl-1.5.0-cp36-abi3-win_amd64.whl", hash = "sha256:20f42270d27e1b6a29f54032090b972d97f0a1b0948cc52392041ef7831fee93"},
+ {file = "PyNaCl-1.5.0.tar.gz", hash = "sha256:8ac7448f09ab85811607bdd21ec2464495ac8b7c66d146bf545b0f08fb9220ba"},
+]
+
+[package.dependencies]
+cffi = ">=1.4.1"
+
+[package.extras]
+docs = ["sphinx (>=1.6.5)", "sphinx-rtd-theme"]
+tests = ["hypothesis (>=3.27.0)", "pytest (>=3.2.1,!=3.3.0)"]
+
+[[package]]
+name = "pyperclip"
+version = "1.8.2"
+description = "A cross-platform clipboard module for Python. (Only handles plain text for now.)"
+optional = false
+python-versions = "*"
+files = [
+ {file = "pyperclip-1.8.2.tar.gz", hash = "sha256:105254a8b04934f0bc84e9c24eb360a591aaf6535c9def5f29d92af107a9bf57"},
+]
+
+[[package]]
+name = "python-dateutil"
+version = "2.8.2"
+description = "Extensions to the standard Python datetime module"
+optional = false
+python-versions = "!=3.0.*,!=3.1.*,!=3.2.*,>=2.7"
+files = [
+ {file = "python-dateutil-2.8.2.tar.gz", hash = "sha256:0123cacc1627ae19ddf3c27a5de5bd67ee4586fbdd6440d9748f8abb483d3e86"},
+ {file = "python_dateutil-2.8.2-py2.py3-none-any.whl", hash = "sha256:961d03dc3453ebbc59dbdea9e4e11c5651520a876d0f4db161e8674aae935da9"},
+]
+
+[package.dependencies]
+six = ">=1.5"
+
+[[package]]
+name = "python-docx"
+version = "0.8.11"
+description = "Create and update Microsoft Word .docx files."
+optional = false
+python-versions = "*"
+files = [
+ {file = "python-docx-0.8.11.tar.gz", hash = "sha256:1105d233a0956dd8dd1e710d20b159e2d72ac3c301041b95f4d4ceb3e0ebebc4"},
+]
+
+[package.dependencies]
+lxml = ">=2.3.2"
+
+[[package]]
+name = "python-frontmatter"
+version = "1.0.1"
+description = "Parse and manage posts with YAML (or other) frontmatter"
+optional = false
+python-versions = "*"
+files = [
+ {file = "python-frontmatter-1.0.1.tar.gz", hash = "sha256:a6a082844fc601f34e4dd576bed8fcb5ef19112166e087629e4d6ba9bf4f7c35"},
+ {file = "python_frontmatter-1.0.1-py3-none-any.whl", hash = "sha256:0599198cc01b445e5d0be74ff35be0a6c7442dddbdb0803e018be4e055397f6a"},
+]
+
+[package.dependencies]
+PyYAML = "*"
+
+[package.extras]
+docs = ["sphinx"]
+test = ["pyaml", "pytest", "toml"]
+
+[[package]]
+name = "python-i18n"
+version = "0.3.9"
+description = "Translation library for Python"
+optional = false
+python-versions = "*"
+files = [
+ {file = "python-i18n-0.3.9.tar.gz", hash = "sha256:df97f3d2364bf3a7ebfbd6cbefe8e45483468e52a9e30b909c6078f5f471e4e8"},
+ {file = "python_i18n-0.3.9-py3-none-any.whl", hash = "sha256:bda5b8d889ebd51973e22e53746417bd32783c9bd6780fd27cadbb733915651d"},
+]
+
+[package.extras]
+yaml = ["pyyaml (>=3.10)"]
+
+[[package]]
+name = "python-markdown-math"
+version = "0.6"
+description = "Math extension for Python-Markdown"
+optional = false
+python-versions = "*"
+files = [
+ {file = "python-markdown-math-0.6.tar.gz", hash = "sha256:c68d8cb9695cb7b435484403dc18941d1bad0ff148e4166d9417046a0d5d3022"},
+ {file = "python_markdown_math-0.6-py2.py3-none-any.whl", hash = "sha256:d443e264cf063623a5f02b0c9730867e5172b31d49967da424ed3457c25b2848"},
+]
+
+[[package]]
+name = "pytz"
+version = "2023.3.post1"
+description = "World timezone definitions, modern and historical"
+optional = false
+python-versions = "*"
+files = [
+ {file = "pytz-2023.3.post1-py2.py3-none-any.whl", hash = "sha256:ce42d816b81b68506614c11e8937d3aa9e41007ceb50bfdcb0749b921bf646c7"},
+ {file = "pytz-2023.3.post1.tar.gz", hash = "sha256:7b4fddbeb94a1eba4b557da24f19fdf9db575192544270a9101d8509f9f43d7b"},
+]
+
+[[package]]
+name = "pywin32"
+version = "306"
+description = "Python for Window Extensions"
+optional = false
+python-versions = "*"
+files = [
+ {file = "pywin32-306-cp310-cp310-win32.whl", hash = "sha256:06d3420a5155ba65f0b72f2699b5bacf3109f36acbe8923765c22938a69dfc8d"},
+ {file = "pywin32-306-cp310-cp310-win_amd64.whl", hash = "sha256:84f4471dbca1887ea3803d8848a1616429ac94a4a8d05f4bc9c5dcfd42ca99c8"},
+ {file = "pywin32-306-cp311-cp311-win32.whl", hash = "sha256:e65028133d15b64d2ed8f06dd9fbc268352478d4f9289e69c190ecd6818b6407"},
+ {file = "pywin32-306-cp311-cp311-win_amd64.whl", hash = "sha256:a7639f51c184c0272e93f244eb24dafca9b1855707d94c192d4a0b4c01e1100e"},
+ {file = "pywin32-306-cp311-cp311-win_arm64.whl", hash = "sha256:70dba0c913d19f942a2db25217d9a1b726c278f483a919f1abfed79c9cf64d3a"},
+ {file = "pywin32-306-cp312-cp312-win32.whl", hash = "sha256:383229d515657f4e3ed1343da8be101000562bf514591ff383ae940cad65458b"},
+ {file = "pywin32-306-cp312-cp312-win_amd64.whl", hash = "sha256:37257794c1ad39ee9be652da0462dc2e394c8159dfd913a8a4e8eb6fd346da0e"},
+ {file = "pywin32-306-cp312-cp312-win_arm64.whl", hash = "sha256:5821ec52f6d321aa59e2db7e0a35b997de60c201943557d108af9d4ae1ec7040"},
+ {file = "pywin32-306-cp37-cp37m-win32.whl", hash = "sha256:1c73ea9a0d2283d889001998059f5eaaba3b6238f767c9cf2833b13e6a685f65"},
+ {file = "pywin32-306-cp37-cp37m-win_amd64.whl", hash = "sha256:72c5f621542d7bdd4fdb716227be0dd3f8565c11b280be6315b06ace35487d36"},
+ {file = "pywin32-306-cp38-cp38-win32.whl", hash = "sha256:e4c092e2589b5cf0d365849e73e02c391c1349958c5ac3e9d5ccb9a28e017b3a"},
+ {file = "pywin32-306-cp38-cp38-win_amd64.whl", hash = "sha256:e8ac1ae3601bee6ca9f7cb4b5363bf1c0badb935ef243c4733ff9a393b1690c0"},
+ {file = "pywin32-306-cp39-cp39-win32.whl", hash = "sha256:e25fd5b485b55ac9c057f67d94bc203f3f6595078d1fb3b458c9c28b7153a802"},
+ {file = "pywin32-306-cp39-cp39-win_amd64.whl", hash = "sha256:39b61c15272833b5c329a2989999dcae836b1eed650252ab1b7bfbe1d59f30f4"},
+]
+
+[[package]]
+name = "pyyaml"
+version = "5.3.1"
+description = "YAML parser and emitter for Python"
+optional = false
+python-versions = "*"
+files = [
+ {file = "PyYAML-5.3.1-cp27-cp27m-win32.whl", hash = "sha256:74809a57b329d6cc0fdccee6318f44b9b8649961fa73144a98735b0aaf029f1f"},
+ {file = "PyYAML-5.3.1-cp27-cp27m-win_amd64.whl", hash = "sha256:240097ff019d7c70a4922b6869d8a86407758333f02203e0fc6ff79c5dcede76"},
+ {file = "PyYAML-5.3.1-cp35-cp35m-win32.whl", hash = "sha256:4f4b913ca1a7319b33cfb1369e91e50354d6f07a135f3b901aca02aa95940bd2"},
+ {file = "PyYAML-5.3.1-cp35-cp35m-win_amd64.whl", hash = "sha256:cc8955cfbfc7a115fa81d85284ee61147059a753344bc51098f3ccd69b0d7e0c"},
+ {file = "PyYAML-5.3.1-cp36-cp36m-win32.whl", hash = "sha256:7739fc0fa8205b3ee8808aea45e968bc90082c10aef6ea95e855e10abf4a37b2"},
+ {file = "PyYAML-5.3.1-cp36-cp36m-win_amd64.whl", hash = "sha256:69f00dca373f240f842b2931fb2c7e14ddbacd1397d57157a9b005a6a9942648"},
+ {file = "PyYAML-5.3.1-cp37-cp37m-win32.whl", hash = "sha256:d13155f591e6fcc1ec3b30685d50bf0711574e2c0dfffd7644babf8b5102ca1a"},
+ {file = "PyYAML-5.3.1-cp37-cp37m-win_amd64.whl", hash = "sha256:73f099454b799e05e5ab51423c7bcf361c58d3206fa7b0d555426b1f4d9a3eaf"},
+ {file = "PyYAML-5.3.1-cp38-cp38-win32.whl", hash = "sha256:06a0d7ba600ce0b2d2fe2e78453a470b5a6e000a985dd4a4e54e436cc36b0e97"},
+ {file = "PyYAML-5.3.1-cp38-cp38-win_amd64.whl", hash = "sha256:95f71d2af0ff4227885f7a6605c37fd53d3a106fcab511b8860ecca9fcf400ee"},
+ {file = "PyYAML-5.3.1-cp39-cp39-win32.whl", hash = "sha256:ad9c67312c84def58f3c04504727ca879cb0013b2517c85a9a253f0cb6380c0a"},
+ {file = "PyYAML-5.3.1-cp39-cp39-win_amd64.whl", hash = "sha256:6034f55dab5fea9e53f436aa68fa3ace2634918e8b5994d82f3621c04ff5ed2e"},
+ {file = "PyYAML-5.3.1.tar.gz", hash = "sha256:b8eac752c5e14d3eca0e6dd9199cd627518cb5ec06add0de9d32baeee6fe645d"},
+]
+
+[[package]]
+name = "requests"
+version = "2.31.0"
+description = "Python HTTP for Humans."
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "requests-2.31.0-py3-none-any.whl", hash = "sha256:58cd2187c01e70e6e26505bca751777aa9f2ee0b7f4300988b709f44e013003f"},
+ {file = "requests-2.31.0.tar.gz", hash = "sha256:942c5a758f98d790eaed1a29cb6eefc7ffb0d1cf7af05c3d2791656dbd6ad1e1"},
+]
+
+[package.dependencies]
+certifi = ">=2017.4.17"
+charset-normalizer = ">=2,<4"
+idna = ">=2.5,<4"
+urllib3 = ">=1.21.1,<3"
+
+[package.extras]
+socks = ["PySocks (>=1.5.6,!=1.5.7)"]
+use-chardet-on-py3 = ["chardet (>=3.0.2,<6)"]
+
+[[package]]
+name = "setuptools"
+version = "69.0.2"
+description = "Easily download, build, install, upgrade, and uninstall Python packages"
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "setuptools-69.0.2-py3-none-any.whl", hash = "sha256:1e8fdff6797d3865f37397be788a4e3cba233608e9b509382a2777d25ebde7f2"},
+ {file = "setuptools-69.0.2.tar.gz", hash = "sha256:735896e78a4742605974de002ac60562d286fa8051a7e2299445e8e8fbb01aa6"},
+]
+
+[package.extras]
+docs = ["furo", "jaraco.packaging (>=9.3)", "jaraco.tidelift (>=1.4)", "pygments-github-lexers (==0.0.5)", "rst.linker (>=1.9)", "sphinx (<7.2.5)", "sphinx (>=3.5)", "sphinx-favicon", "sphinx-inline-tabs", "sphinx-lint", "sphinx-notfound-page (>=1,<2)", "sphinx-reredirects", "sphinxcontrib-towncrier"]
+testing = ["build[virtualenv]", "filelock (>=3.4.0)", "flake8-2020", "ini2toml[lite] (>=0.9)", "jaraco.develop (>=7.21)", "jaraco.envs (>=2.2)", "jaraco.path (>=3.2.0)", "pip (>=19.1)", "pytest (>=6)", "pytest-black (>=0.3.7)", "pytest-checkdocs (>=2.4)", "pytest-cov", "pytest-enabler (>=2.2)", "pytest-mypy (>=0.9.1)", "pytest-perf", "pytest-ruff", "pytest-timeout", "pytest-xdist", "tomli-w (>=1.0.0)", "virtualenv (>=13.0.0)", "wheel"]
+testing-integration = ["build[virtualenv] (>=1.0.3)", "filelock (>=3.4.0)", "jaraco.envs (>=2.2)", "jaraco.path (>=3.2.0)", "packaging (>=23.1)", "pytest", "pytest-enabler", "pytest-xdist", "tomli", "virtualenv (>=13.0.0)", "wheel"]
+
+[[package]]
+name = "six"
+version = "1.16.0"
+description = "Python 2 and 3 compatibility utilities"
+optional = false
+python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*"
+files = [
+ {file = "six-1.16.0-py2.py3-none-any.whl", hash = "sha256:8abb2f1d86890a2dfb989f9a77cfcfd3e47c2a354b01111771326f8aa26e0254"},
+ {file = "six-1.16.0.tar.gz", hash = "sha256:1e61c37477a1626458e36f7b1d82aa5c9b094fa4802892072e49de9c60c4c926"},
+]
+
+[[package]]
+name = "tomli"
+version = "2.0.1"
+description = "A lil' TOML parser"
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "tomli-2.0.1-py3-none-any.whl", hash = "sha256:939de3e7a6161af0c887ef91b7d41a53e7c5a1ca976325f429cb46ea9bc30ecc"},
+ {file = "tomli-2.0.1.tar.gz", hash = "sha256:de526c12914f0c550d15924c62d72abc48d6fe7364aa87328337a31007fe8a4f"},
+]
+
+[[package]]
+name = "tomlkit"
+version = "0.12.3"
+description = "Style preserving TOML library"
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "tomlkit-0.12.3-py3-none-any.whl", hash = "sha256:b0a645a9156dc7cb5d3a1f0d4bab66db287fcb8e0430bdd4664a095ea16414ba"},
+ {file = "tomlkit-0.12.3.tar.gz", hash = "sha256:75baf5012d06501f07bee5bf8e801b9f343e7aac5a92581f20f80ce632e6b5a4"},
+]
+
+[[package]]
+name = "typing-extensions"
+version = "4.8.0"
+description = "Backported and Experimental Type Hints for Python 3.8+"
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "typing_extensions-4.8.0-py3-none-any.whl", hash = "sha256:8f92fc8806f9a6b641eaa5318da32b44d401efaac0f6678c9bc448ba3605faa0"},
+ {file = "typing_extensions-4.8.0.tar.gz", hash = "sha256:df8e4339e9cb77357558cbdbceca33c303714cf861d1eef15e1070055ae8b7ef"},
+]
+
+[[package]]
+name = "tzdata"
+version = "2023.3"
+description = "Provider of IANA time zone data"
+optional = false
+python-versions = ">=2"
+files = [
+ {file = "tzdata-2023.3-py2.py3-none-any.whl", hash = "sha256:7e65763eef3120314099b6939b5546db7adce1e7d6f2e179e3df563c70511eda"},
+ {file = "tzdata-2023.3.tar.gz", hash = "sha256:11ef1e08e54acb0d4f95bdb1be05da659673de4acbd21bf9c69e94cc5e907a3a"},
+]
+
+[[package]]
+name = "urllib3"
+version = "2.1.0"
+description = "HTTP library with thread-safe connection pooling, file post, and more."
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "urllib3-2.1.0-py3-none-any.whl", hash = "sha256:55901e917a5896a349ff771be919f8bd99aff50b79fe58fec595eb37bbc56bb3"},
+ {file = "urllib3-2.1.0.tar.gz", hash = "sha256:df7aa8afb0148fa78488e7899b2c59b5f4ffcfa82e6c54ccb9dd37c1d7b52d54"},
+]
+
+[package.extras]
+brotli = ["brotli (>=1.0.9)", "brotlicffi (>=0.8.0)"]
+socks = ["pysocks (>=1.5.6,!=1.5.7,<2.0)"]
+zstd = ["zstandard (>=0.18.0)"]
+
+[[package]]
+name = "wcwidth"
+version = "0.2.12"
+description = "Measures the displayed width of unicode strings in a terminal"
+optional = false
+python-versions = "*"
+files = [
+ {file = "wcwidth-0.2.12-py2.py3-none-any.whl", hash = "sha256:f26ec43d96c8cbfed76a5075dac87680124fa84e0855195a6184da9c187f133c"},
+ {file = "wcwidth-0.2.12.tar.gz", hash = "sha256:f01c104efdf57971bcb756f054dd58ddec5204dd15fa31d6503ea57947d97c02"},
+]
+
+[[package]]
+name = "webcolors"
+version = "1.13"
+description = "A library for working with the color formats defined by HTML and CSS."
+optional = false
+python-versions = ">=3.7"
+files = [
+ {file = "webcolors-1.13-py3-none-any.whl", hash = "sha256:29bc7e8752c0a1bd4a1f03c14d6e6a72e93d82193738fa860cbff59d0fcc11bf"},
+ {file = "webcolors-1.13.tar.gz", hash = "sha256:c225b674c83fa923be93d235330ce0300373d02885cef23238813b0d5668304a"},
+]
+
+[package.extras]
+docs = ["furo", "sphinx", "sphinx-copybutton", "sphinx-inline-tabs", "sphinx-notfound-page", "sphinxext-opengraph"]
+tests = ["pytest", "pytest-cov"]
+
+[[package]]
+name = "wrapt"
+version = "1.16.0"
+description = "Module for decorators, wrappers and monkey patching."
+optional = false
+python-versions = ">=3.6"
+files = [
+ {file = "wrapt-1.16.0-cp310-cp310-macosx_10_9_x86_64.whl", hash = "sha256:ffa565331890b90056c01db69c0fe634a776f8019c143a5ae265f9c6bc4bd6d4"},
+ {file = "wrapt-1.16.0-cp310-cp310-macosx_11_0_arm64.whl", hash = "sha256:e4fdb9275308292e880dcbeb12546df7f3e0f96c6b41197e0cf37d2826359020"},
+ {file = "wrapt-1.16.0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:bb2dee3874a500de01c93d5c71415fcaef1d858370d405824783e7a8ef5db440"},
+ {file = "wrapt-1.16.0-cp310-cp310-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:2a88e6010048489cda82b1326889ec075a8c856c2e6a256072b28eaee3ccf487"},
+ {file = "wrapt-1.16.0-cp310-cp310-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:ac83a914ebaf589b69f7d0a1277602ff494e21f4c2f743313414378f8f50a4cf"},
+ {file = "wrapt-1.16.0-cp310-cp310-musllinux_1_1_aarch64.whl", hash = "sha256:73aa7d98215d39b8455f103de64391cb79dfcad601701a3aa0dddacf74911d72"},
+ {file = "wrapt-1.16.0-cp310-cp310-musllinux_1_1_i686.whl", hash = "sha256:807cc8543a477ab7422f1120a217054f958a66ef7314f76dd9e77d3f02cdccd0"},
+ {file = "wrapt-1.16.0-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:bf5703fdeb350e36885f2875d853ce13172ae281c56e509f4e6eca049bdfb136"},
+ {file = "wrapt-1.16.0-cp310-cp310-win32.whl", hash = "sha256:f6b2d0c6703c988d334f297aa5df18c45e97b0af3679bb75059e0e0bd8b1069d"},
+ {file = "wrapt-1.16.0-cp310-cp310-win_amd64.whl", hash = "sha256:decbfa2f618fa8ed81c95ee18a387ff973143c656ef800c9f24fb7e9c16054e2"},
+ {file = "wrapt-1.16.0-cp311-cp311-macosx_10_9_x86_64.whl", hash = "sha256:1a5db485fe2de4403f13fafdc231b0dbae5eca4359232d2efc79025527375b09"},
+ {file = "wrapt-1.16.0-cp311-cp311-macosx_11_0_arm64.whl", hash = "sha256:75ea7d0ee2a15733684badb16de6794894ed9c55aa5e9903260922f0482e687d"},
+ {file = "wrapt-1.16.0-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:a452f9ca3e3267cd4d0fcf2edd0d035b1934ac2bd7e0e57ac91ad6b95c0c6389"},
+ {file = "wrapt-1.16.0-cp311-cp311-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:43aa59eadec7890d9958748db829df269f0368521ba6dc68cc172d5d03ed8060"},
+ {file = "wrapt-1.16.0-cp311-cp311-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:72554a23c78a8e7aa02abbd699d129eead8b147a23c56e08d08dfc29cfdddca1"},
+ {file = "wrapt-1.16.0-cp311-cp311-musllinux_1_1_aarch64.whl", hash = "sha256:d2efee35b4b0a347e0d99d28e884dfd82797852d62fcd7ebdeee26f3ceb72cf3"},
+ {file = "wrapt-1.16.0-cp311-cp311-musllinux_1_1_i686.whl", hash = "sha256:6dcfcffe73710be01d90cae08c3e548d90932d37b39ef83969ae135d36ef3956"},
+ {file = "wrapt-1.16.0-cp311-cp311-musllinux_1_1_x86_64.whl", hash = "sha256:eb6e651000a19c96f452c85132811d25e9264d836951022d6e81df2fff38337d"},
+ {file = "wrapt-1.16.0-cp311-cp311-win32.whl", hash = "sha256:66027d667efe95cc4fa945af59f92c5a02c6f5bb6012bff9e60542c74c75c362"},
+ {file = "wrapt-1.16.0-cp311-cp311-win_amd64.whl", hash = "sha256:aefbc4cb0a54f91af643660a0a150ce2c090d3652cf4052a5397fb2de549cd89"},
+ {file = "wrapt-1.16.0-cp312-cp312-macosx_10_9_x86_64.whl", hash = "sha256:5eb404d89131ec9b4f748fa5cfb5346802e5ee8836f57d516576e61f304f3b7b"},
+ {file = "wrapt-1.16.0-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:9090c9e676d5236a6948330e83cb89969f433b1943a558968f659ead07cb3b36"},
+ {file = "wrapt-1.16.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:94265b00870aa407bd0cbcfd536f17ecde43b94fb8d228560a1e9d3041462d73"},
+ {file = "wrapt-1.16.0-cp312-cp312-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:f2058f813d4f2b5e3a9eb2eb3faf8f1d99b81c3e51aeda4b168406443e8ba809"},
+ {file = "wrapt-1.16.0-cp312-cp312-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:98b5e1f498a8ca1858a1cdbffb023bfd954da4e3fa2c0cb5853d40014557248b"},
+ {file = "wrapt-1.16.0-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:14d7dc606219cdd7405133c713f2c218d4252f2a469003f8c46bb92d5d095d81"},
+ {file = "wrapt-1.16.0-cp312-cp312-musllinux_1_1_i686.whl", hash = "sha256:49aac49dc4782cb04f58986e81ea0b4768e4ff197b57324dcbd7699c5dfb40b9"},
+ {file = "wrapt-1.16.0-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:418abb18146475c310d7a6dc71143d6f7adec5b004ac9ce08dc7a34e2babdc5c"},
+ {file = "wrapt-1.16.0-cp312-cp312-win32.whl", hash = "sha256:685f568fa5e627e93f3b52fda002c7ed2fa1800b50ce51f6ed1d572d8ab3e7fc"},
+ {file = "wrapt-1.16.0-cp312-cp312-win_amd64.whl", hash = "sha256:dcdba5c86e368442528f7060039eda390cc4091bfd1dca41e8046af7c910dda8"},
+ {file = "wrapt-1.16.0-cp36-cp36m-macosx_10_9_x86_64.whl", hash = "sha256:d462f28826f4657968ae51d2181a074dfe03c200d6131690b7d65d55b0f360f8"},
+ {file = "wrapt-1.16.0-cp36-cp36m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:a33a747400b94b6d6b8a165e4480264a64a78c8a4c734b62136062e9a248dd39"},
+ {file = "wrapt-1.16.0-cp36-cp36m-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:b3646eefa23daeba62643a58aac816945cadc0afaf21800a1421eeba5f6cfb9c"},
+ {file = "wrapt-1.16.0-cp36-cp36m-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:3ebf019be5c09d400cf7b024aa52b1f3aeebeff51550d007e92c3c1c4afc2a40"},
+ {file = "wrapt-1.16.0-cp36-cp36m-musllinux_1_1_aarch64.whl", hash = "sha256:0d2691979e93d06a95a26257adb7bfd0c93818e89b1406f5a28f36e0d8c1e1fc"},
+ {file = "wrapt-1.16.0-cp36-cp36m-musllinux_1_1_i686.whl", hash = "sha256:1acd723ee2a8826f3d53910255643e33673e1d11db84ce5880675954183ec47e"},
+ {file = "wrapt-1.16.0-cp36-cp36m-musllinux_1_1_x86_64.whl", hash = "sha256:bc57efac2da352a51cc4658878a68d2b1b67dbe9d33c36cb826ca449d80a8465"},
+ {file = "wrapt-1.16.0-cp36-cp36m-win32.whl", hash = "sha256:da4813f751142436b075ed7aa012a8778aa43a99f7b36afe9b742d3ed8bdc95e"},
+ {file = "wrapt-1.16.0-cp36-cp36m-win_amd64.whl", hash = "sha256:6f6eac2360f2d543cc875a0e5efd413b6cbd483cb3ad7ebf888884a6e0d2e966"},
+ {file = "wrapt-1.16.0-cp37-cp37m-macosx_10_9_x86_64.whl", hash = "sha256:a0ea261ce52b5952bf669684a251a66df239ec6d441ccb59ec7afa882265d593"},
+ {file = "wrapt-1.16.0-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:7bd2d7ff69a2cac767fbf7a2b206add2e9a210e57947dd7ce03e25d03d2de292"},
+ {file = "wrapt-1.16.0-cp37-cp37m-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:9159485323798c8dc530a224bd3ffcf76659319ccc7bbd52e01e73bd0241a0c5"},
+ {file = "wrapt-1.16.0-cp37-cp37m-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:a86373cf37cd7764f2201b76496aba58a52e76dedfaa698ef9e9688bfd9e41cf"},
+ {file = "wrapt-1.16.0-cp37-cp37m-musllinux_1_1_aarch64.whl", hash = "sha256:73870c364c11f03ed072dda68ff7aea6d2a3a5c3fe250d917a429c7432e15228"},
+ {file = "wrapt-1.16.0-cp37-cp37m-musllinux_1_1_i686.whl", hash = "sha256:b935ae30c6e7400022b50f8d359c03ed233d45b725cfdd299462f41ee5ffba6f"},
+ {file = "wrapt-1.16.0-cp37-cp37m-musllinux_1_1_x86_64.whl", hash = "sha256:db98ad84a55eb09b3c32a96c576476777e87c520a34e2519d3e59c44710c002c"},
+ {file = "wrapt-1.16.0-cp37-cp37m-win32.whl", hash = "sha256:9153ed35fc5e4fa3b2fe97bddaa7cbec0ed22412b85bcdaf54aeba92ea37428c"},
+ {file = "wrapt-1.16.0-cp37-cp37m-win_amd64.whl", hash = "sha256:66dfbaa7cfa3eb707bbfcd46dab2bc6207b005cbc9caa2199bcbc81d95071a00"},
+ {file = "wrapt-1.16.0-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:1dd50a2696ff89f57bd8847647a1c363b687d3d796dc30d4dd4a9d1689a706f0"},
+ {file = "wrapt-1.16.0-cp38-cp38-macosx_11_0_arm64.whl", hash = "sha256:44a2754372e32ab315734c6c73b24351d06e77ffff6ae27d2ecf14cf3d229202"},
+ {file = "wrapt-1.16.0-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:8e9723528b9f787dc59168369e42ae1c3b0d3fadb2f1a71de14531d321ee05b0"},
+ {file = "wrapt-1.16.0-cp38-cp38-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:dbed418ba5c3dce92619656802cc5355cb679e58d0d89b50f116e4a9d5a9603e"},
+ {file = "wrapt-1.16.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:941988b89b4fd6b41c3f0bfb20e92bd23746579736b7343283297c4c8cbae68f"},
+ {file = "wrapt-1.16.0-cp38-cp38-musllinux_1_1_aarch64.whl", hash = "sha256:6a42cd0cfa8ffc1915aef79cb4284f6383d8a3e9dcca70c445dcfdd639d51267"},
+ {file = "wrapt-1.16.0-cp38-cp38-musllinux_1_1_i686.whl", hash = "sha256:1ca9b6085e4f866bd584fb135a041bfc32cab916e69f714a7d1d397f8c4891ca"},
+ {file = "wrapt-1.16.0-cp38-cp38-musllinux_1_1_x86_64.whl", hash = "sha256:d5e49454f19ef621089e204f862388d29e6e8d8b162efce05208913dde5b9ad6"},
+ {file = "wrapt-1.16.0-cp38-cp38-win32.whl", hash = "sha256:c31f72b1b6624c9d863fc095da460802f43a7c6868c5dda140f51da24fd47d7b"},
+ {file = "wrapt-1.16.0-cp38-cp38-win_amd64.whl", hash = "sha256:490b0ee15c1a55be9c1bd8609b8cecd60e325f0575fc98f50058eae366e01f41"},
+ {file = "wrapt-1.16.0-cp39-cp39-macosx_10_9_x86_64.whl", hash = "sha256:9b201ae332c3637a42f02d1045e1d0cccfdc41f1f2f801dafbaa7e9b4797bfc2"},
+ {file = "wrapt-1.16.0-cp39-cp39-macosx_11_0_arm64.whl", hash = "sha256:2076fad65c6736184e77d7d4729b63a6d1ae0b70da4868adeec40989858eb3fb"},
+ {file = "wrapt-1.16.0-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:c5cd603b575ebceca7da5a3a251e69561bec509e0b46e4993e1cac402b7247b8"},
+ {file = "wrapt-1.16.0-cp39-cp39-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:b47cfad9e9bbbed2339081f4e346c93ecd7ab504299403320bf85f7f85c7d46c"},
+ {file = "wrapt-1.16.0-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:f8212564d49c50eb4565e502814f694e240c55551a5f1bc841d4fcaabb0a9b8a"},
+ {file = "wrapt-1.16.0-cp39-cp39-musllinux_1_1_aarch64.whl", hash = "sha256:5f15814a33e42b04e3de432e573aa557f9f0f56458745c2074952f564c50e664"},
+ {file = "wrapt-1.16.0-cp39-cp39-musllinux_1_1_i686.whl", hash = "sha256:db2e408d983b0e61e238cf579c09ef7020560441906ca990fe8412153e3b291f"},
+ {file = "wrapt-1.16.0-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:edfad1d29c73f9b863ebe7082ae9321374ccb10879eeabc84ba3b69f2579d537"},
+ {file = "wrapt-1.16.0-cp39-cp39-win32.whl", hash = "sha256:ed867c42c268f876097248e05b6117a65bcd1e63b779e916fe2e33cd6fd0d3c3"},
+ {file = "wrapt-1.16.0-cp39-cp39-win_amd64.whl", hash = "sha256:eb1b046be06b0fce7249f1d025cd359b4b80fc1c3e24ad9eca33e0dcdb2e4a35"},
+ {file = "wrapt-1.16.0-py3-none-any.whl", hash = "sha256:6906c4100a8fcbf2fa735f6059214bb13b97f75b1a61777fcf6432121ef12ef1"},
+ {file = "wrapt-1.16.0.tar.gz", hash = "sha256:5f370f952971e7d17c7d1ead40e49f32345a7f7a5373571ef44d800d06b1899d"},
+]
+
+[[package]]
+name = "xlrd"
+version = "2.0.1"
+description = "Library for developers to extract data from Microsoft Excel (tm) .xls spreadsheet files"
+optional = false
+python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, !=3.5.*"
+files = [
+ {file = "xlrd-2.0.1-py2.py3-none-any.whl", hash = "sha256:6a33ee89877bd9abc1158129f6e94be74e2679636b8a205b43b85206c3f0bbdd"},
+ {file = "xlrd-2.0.1.tar.gz", hash = "sha256:f72f148f54442c6b056bf931dbc34f986fd0c3b0b6b5a58d013c9aef274d0c88"},
+]
+
+[package.extras]
+build = ["twine", "wheel"]
+docs = ["sphinx"]
+test = ["pytest", "pytest-cov"]
+
+[[package]]
+name = "zipp"
+version = "3.17.0"
+description = "Backport of pathlib-compatible object wrapper for zip files"
+optional = false
+python-versions = ">=3.8"
+files = [
+ {file = "zipp-3.17.0-py3-none-any.whl", hash = "sha256:0e923e726174922dce09c53c59ad483ff7bbb8e572e00c7f7c46b88556409f31"},
+ {file = "zipp-3.17.0.tar.gz", hash = "sha256:84e64a1c28cf7e91ed2078bb8cc8c259cb19b76942096c8d7b84947690cabaf0"},
+]
+
+[package.extras]
+docs = ["furo", "jaraco.packaging (>=9.3)", "jaraco.tidelift (>=1.4)", "rst.linker (>=1.9)", "sphinx (<7.2.5)", "sphinx (>=3.5)", "sphinx-lint"]
+testing = ["big-O", "jaraco.functools", "jaraco.itertools", "more-itertools", "pytest (>=6)", "pytest-black (>=0.3.7)", "pytest-checkdocs (>=2.4)", "pytest-cov", "pytest-enabler (>=2.2)", "pytest-ignore-flaky", "pytest-mypy (>=0.9.1)", "pytest-ruff"]
+
+[metadata]
+lock-version = "2.0"
+python-versions = ">=3.8,<3.12"
+content-hash = "9aa0874e78c2b76713955b0badc25eadab14b5ccfe62aaf50fcc6b747ba10dfd"
diff --git a/pyproject.toml b/pyproject.toml
new file mode 100644
index 0000000..8536530
--- /dev/null
+++ b/pyproject.toml
@@ -0,0 +1,32 @@
+[tool.poetry]
+name = "c5dec"
+version = "0.1"
+description = "This is the main repository of the software component of C5-DEC for computer-assisted design and development (CAD), i.e., C5-DEC CAD."
+authors = ["Arash Atashpendar ", "Heinrich Fries ", "Itzel Vazquez Sandoval ", "Sven Angel"]
+readme = "README.md"
+
+[tool.poetry.dependencies]
+python = ">=3.8,<3.12"
+asciimatics = "^1.14.0"
+python-i18n = "^0.3.9"
+PyNaCl = "^1.5.0"
+pyperclip = "^1.8.2"
+pycryptodome = "^3.18.0"
+python-docx = "^0.8.11"
+doorstop = "3.0b9"
+pandas = "^2.0.2"
+blockdiag = "^3.0.0"
+xlrd = "^2.0.1"
+pylint = "^2.17.4"
+graphviz = "^0.20.1"
+pyyaml = "5.3.1"
+
+[tool.poetry.group.dev.dependencies]
+pdoc3 = "^0.10.0"
+
+[build-system]
+requires = ["poetry-core>=1.5.0"]
+build-backend = "poetry.core.masonry.api"
+
+[tool.poetry.scripts]
+c5dec = "c5dec.frontend.cli.main:run"
\ No newline at end of file
diff --git a/setup.py b/setup.py
new file mode 100644
index 0000000..e69de29
diff --git a/tests/__init__.py b/tests/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/tests/cct_assurance_test.py b/tests/cct_assurance_test.py
new file mode 100644
index 0000000..f06fa90
--- /dev/null
+++ b/tests/cct_assurance_test.py
@@ -0,0 +1,474 @@
+import unittest
+from unittest.mock import MagicMock, patch
+import sys
+import os
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+
+from lxml import etree
+import c5dec.core.cct as cct
+from c5dec.common import C5decError
+
+
+class TestDCElement(unittest.TestCase):
+ """not necessary"""
+
+
+class TestWorkUnit(unittest.TestCase):
+
+ def setUp(self):
+ self.work_unit = cct.WorkUnit(_id="unit_id", _name="unit_name")
+ self.work_unit.dc_element = "elem_id"
+
+ def test_is_valid_with_valid_instance(self):
+ self.work_unit.container = [MagicMock(cct.Text())]
+ self.assertTrue(self.work_unit.is_valid())
+
+ def test_is_valid_with_invalid_instance(self):
+ with self.assertRaises(C5decError):
+ self.work_unit.is_valid()
+
+class TestWorkUnitBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.work_unit = cct.WorkUnit(_id="unit_id", _name="unit_name")
+ self.builder = cct.WorkUnitBuilder(self.work_unit)
+
+ def test_initialization(self):
+ self.assertEqual(self.builder.instance, self.work_unit)
+
+ def test_initialization_wrong_instance_type(self):
+ with self.assertRaises(C5decError):
+ cct.WorkUnitBuilder("NotAWorkUnitInstance")
+
+ def test_build_attributes_with_id(self):
+ node = MagicMock(etree._Element)
+ node.get.return_value = "new_id"
+ parent_obj = MagicMock()
+ self.builder._build_attributes(node, parent_obj)
+
+ self.assertEqual(self.work_unit._id, "new_id")
+
+ def test_build_attributes_without_id(self):
+ node = MagicMock(etree._Element)
+ node.get.return_value = None
+ parent_obj = MagicMock()
+ parent_obj._id = "AVA_VAN.1.1"
+ self.builder._build_attributes(node, parent_obj)
+ self.assertEqual(self.work_unit._id, "AVA_VAN.1-1")
+
+ def test_build_children_ae_dc_element(self):
+ xml_string = ""
+ child = etree.fromstring(xml_string)
+ self.builder._build_children(child)
+ self.assertEqual(self.work_unit.dc_element[0]._id, "elem_id")
+
+ @patch.object(cct.Para, "build")
+ def test_build_children_para(self, mock_para_build):
+ xml_string = " Para Text."
+ child = etree.fromstring(xml_string)
+ self.builder._build_children(child)
+ para = mock_para_build(child)
+
+ self.assertIn(para, self.work_unit.container)
+
+ @patch.object(cct.SubClause, "build")
+ def test_build_children_subclause(self, mock_subclause_build):
+ xml_string = " Subclause Text."
+ child = etree.fromstring(xml_string)
+ self.builder._build_children(child)
+ subclause = mock_subclause_build(child)
+
+ self.assertIn(subclause, self.work_unit.container)
+
+
+class TestAElement(unittest.TestCase):
+
+ def setUp(self):
+ self.aelement = cct.AElement(_id="AE1", el_type="evaluator")
+ self.aelement.container = [MagicMock(cct.Operation(op_type="selection")),
+ MagicMock(cct.Operation(op_type="assurance"))]
+
+ def test_is_valid_success(self):
+ # Test: Check is_valid returns True for proper FElement instance
+ self.assertTrue(self.aelement.is_valid())
+
+ def test_is_valid_invalid_type(self):
+ self.aelement.type = "InvalidType"
+ with self.assertRaises(C5decError):
+ self.aelement.is_valid()
+
+ def test_is_valid_fail_on_empty(self):
+ # Test: Check is_valid raises C5decError when instance is empty
+ self.aelement.container = [] # Assume it is empty now
+ with self.assertRaises(C5decError):
+ self.aelement.is_valid()
+
+class TestAElementBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.aelement = cct.AElement(_id='valid_id', el_type='developer')
+ self.builder = cct.AElementBuilder(self.aelement)
+
+ def test_init_with_valid_aelement(self):
+ self.assertIsInstance(self.builder, cct.AElementBuilder)
+
+ def test_init_with_invalid_aelement_raises_value_error(self):
+ with self.assertRaises(C5decError):
+ cct.AElementBuilder("INVALIDELEMENT")
+
+ def test_build_attributes_sets_id(self):
+ node = MagicMock()
+ node.attrib = {"id": "new_id"}
+ node.get.return_value = node.attrib["id"]
+ self.builder._build_attributes(node)
+ self.assertEqual(self.aelement._id, "new_id")
+
+ @patch.object(cct.List, "build")
+ def test_build_children_list(self, mock_build):
+ node = MagicMock()
+ node.tag = 'list'
+ self.builder._build_children(node)
+ mocked= mock_build(node)
+ self.assertEqual(self.aelement.list[0], mocked)
+
+ @patch.object(cct.OperationBuilder, "build")
+ def test_build_children_operation(self, mock_build):
+ node = MagicMock()
+ node.tag = 'selection'
+ self.builder._build_children(node)
+ mocked = mock_build(node)
+ self.assertEqual(self.aelement.operation[0], mocked)
+
+ @patch.object(cct.XRef, "build")
+ def test_build_children_operation(self, mock_build):
+ node = MagicMock()
+ node.tag = 'xref'
+ self.builder._build_children(node)
+ mocked = mock_build(node)
+ self.assertIn(mocked, self.aelement.container)
+
+ @patch.object(cct.WorkUnitBuilder, "build")
+ def test_build_children_operation(self, mock_build):
+ node = MagicMock()
+ node.tag = 'm-workunit'
+ self.builder._build_children(node)
+ mocked = mock_build(node)
+ self.assertIn(mocked, self.aelement.children)
+
+ def test_build_attributes_is_called(self):
+ self.builder._build_attributes = MagicMock()
+ node = MagicMock(etree._Element)
+ node.text = "SOME NODE TEXT."
+ self.builder.build(node)
+ self.builder._build_attributes.assert_called_once_with(node, None)
+
+ def test_build_children_is_called_for_each_child(self):
+ self.builder._build_children = MagicMock()
+ node = MagicMock(etree._Element)
+ node.text = "SOME NODE TEXT."
+ child1 = MagicMock(etree._Element)
+ child1.text = "SOME CHILD NODE TEXT."
+ child2 = MagicMock(etree._Element)
+ child2.text = "SOME CHILD NODE TEXT."
+ node.__iter__.return_value = iter([child1, child2])
+ self.builder.build(node)
+ self.assertEqual(self.builder._build_children.call_count, 2)
+
+ def test_requirement_is_updated_with_text(self):
+ node = MagicMock(etree._Element)
+ node.text = "SOME NODE TEXT."
+ self.builder.build(node)
+ self.assertNotEqual(self.aelement.requirement, "SOME NODE TEXT.")
+
+ def test_text_is_added_to_container(self):
+ node = MagicMock(etree._Element)
+ node.text = "SOME NODE TEXT."
+ self.builder.build(node)
+ self.assertGreater(len(self.aelement.container), 0)
+ self.assertIsInstance(self.aelement.container[-1], cct.Text)
+
+ def test_returns_instance(self):
+ node = MagicMock(etree._Element)
+ node.text = "SOME NODE TEXT."
+ instance = self.builder.build(node)
+ self.assertEqual(instance, self.aelement)
+
+ def tearDown(self):
+ cct.Index.clear()
+
+class TestAComponent(unittest.TestCase):
+
+ def setUp(self):
+ self.acomponent = cct.AComponent(_id="test_id", _name="test_name")
+ self.acomponent.children = [MagicMock(cct.AElement())]
+
+ def test_valid_child_type(self):
+ self.assertTrue(self.acomponent.is_valid())
+
+ def test_invalid_child_type_raises_error(self):
+ self.acomponent.children.append("InvalidChildType")
+ with self.assertRaises(C5decError):
+ self.acomponent.is_valid()
+
+class TestAComponentBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.acomponent = cct.AComponent(_id='valid_id', _name='valid_name')
+ self.builder = cct.AComponentBuilder(self.acomponent)
+
+ def test_initialization(self):
+ self.assertIsInstance(self.builder.instance, cct.AComponent)
+
+ def test_initialization_wrong_instance_type(self):
+ with self.assertRaises(C5decError):
+ cct.AComponentBuilder("INVALIDELEMENT")
+
+ @patch.object(cct.ParaSequence, "build")
+ def test_build_children_parasequence(self, mock_parasequence_build):
+
+ xml_string = '''
+
+
+ Component Objective.
+
+
+ Component Application Notes.
+
+
+ Evaluation Sub-activity Objective.
+
+
+ Evaluation Sub-activity Appplication Notes.
+
+
+ Evaluation Sub-activtiy input.
+
+
+ '''
+
+ node = etree.fromstring(xml_string)
+ mocked_parasequence = []
+ for child in node:
+ self.builder._build_children(child)
+ mocked_parasequence.append(mock_parasequence_build(child))
+
+ self.assertEqual(mocked_parasequence, self.acomponent.container)
+
+ def test_build_children_hierarchical(self):
+ xml_string = '''
+
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ for child in node:
+ self.builder._build_children(child)
+
+ self.assertEqual(self.acomponent.hierarchical, ["Comp_Id.1"])
+
+ def test_build_children_dependencies(self):
+ xml_string = '''
+
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ for child in node:
+ self.builder._build_children(child)
+
+ self.assertEqual(self.acomponent.dependencies, ["Comp_Id.2"])
+
+ @patch.object(cct.AElementBuilder, "build")
+ def test_build_children_element(self, mock_element_build):
+ xml_string = '''
+
+
+ Developer Action Element.
+
+
+ Content and Presentation Element.
+
+
+ Evaluator Action Element.
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ mocked_elements = []
+ for child in node:
+ self.builder._build_children(child)
+ mocked_elements.append(mock_element_build(child))
+
+ self.assertEqual(mocked_elements, self.acomponent.children)
+
+
+class TestAFamily(unittest.TestCase):
+
+ def setUp(self):
+ self.afamily = cct.AFamily(_id="test_id", _name="test_name")
+ self.afamily.children = [MagicMock(cct.AComponent())]
+
+ def test_valid_child_type(self):
+ self.assertTrue(self.afamily.is_valid())
+
+ def test_invalid_child_type_raises_error(self):
+ self.afamily.children.append("InvalidChildType")
+ with self.assertRaises(C5decError):
+ self.afamily.is_valid()
+
+class TestAFamilyBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.afamily = cct.AFamily(_id='valid_id', _name='valid_name')
+ self.builder = cct.AFamilyBuilder(self.afamily)
+
+ def test_initialization(self):
+ self.assertIsInstance(self.builder.instance, cct.AFamily)
+
+ def test_initialization_wrong_instance_type(self):
+ with self.assertRaises(C5decError):
+ cct.AFamilyBuilder("INVALIDELEMENT")
+
+ @patch.object(cct.ParaSequence, "build")
+ def test_build_children_parasequence(self, mock_parasequence_build):
+
+ xml_string = '''
+
+
+ Family Objective.
+
+
+ Family Overview.
+
+
+ Family Levelling Criteria
+
+
+ Family Appplication Notes.
+
+
+ '''
+
+ node = etree.fromstring(xml_string)
+ mocked_parasequence = []
+ for child in node:
+ self.builder._build_children(child)
+ mocked_parasequence.append(mock_parasequence_build(child))
+
+ self.assertEqual(mocked_parasequence, self.afamily.container)
+
+ @patch.object(cct.AComponentBuilder, "build")
+ def test_build_children_component(self, mock_component_build):
+ xml_string = '''
+
+
+ Component text
+
+
+
+
+
+ Component text
+
+
+
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ mocked_elements = []
+ for child in node:
+ self.builder._build_children(child)
+ mocked_elements.append(mock_component_build(child))
+
+ self.assertEqual(mocked_elements, self.afamily.children)
+
+
+class TestAClass(unittest.TestCase):
+
+ def setUp(self):
+ self.aclass = cct.AClass(_id="test_id", _name="test_name")
+ self.aclass.children = [MagicMock(cct.AFamily())]
+ self.aclass.ac_introduction = MagicMock(cct.ParaSequence())
+ self.aclass.ac_introduction.original_tag = "ac-introduction"
+
+ def test_is_valid(self):
+ self.assertTrue(self.aclass.is_valid())
+
+ def test_invalid_child_type_raises_error(self):
+ self.aclass.children.append("InvalidChildType")
+ with self.assertRaises(C5decError):
+ self.aclass.is_valid()
+
+ def test_missing_introduction_raises_error(self):
+ self.aclass.ac_introduction = None
+ with self.assertRaises(C5decError):
+ self.aclass.is_valid()
+
+class TestAClassBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.aclass = cct.AClass(_id='valid_id', _name='valid_name')
+ self.builder = cct.AClassBuilder(self.aclass)
+
+ def test_initialization(self):
+ self.assertIsInstance(self.builder.instance, cct.AClass)
+
+ def test_initialization_wrong_instance_type(self):
+ with self.assertRaises(C5decError):
+ cct.AClassBuilder("INVALIDELEMENT")
+
+ @patch.object(cct.ParaSequence, "build")
+ def test_build_children_parasequence(self, mock_parasequence_build):
+
+ xml_string = '''
+
+
+ Class Introduction.
+
+
+ Class Overview.
+
+
+ Class Application Notes.
+
+
+ Evaluation Activtiy Introduction.
+
+
+ Evaluation Activity Objective.
+
+
+ Evaluation activity Appplication Notes.
+
+
+ '''
+
+ node = etree.fromstring(xml_string)
+ mocked_parasequence = []
+ for child in node:
+ self.builder._build_children(child)
+ mocked_parasequence.append(mock_parasequence_build(child))
+
+ self.assertEqual(mocked_parasequence, self.aclass.container)
+
+ @patch.object(cct.AFamilyBuilder, "build")
+ def test_build_children_family(self, mock_family_build):
+ xml_string = '''
+
+
+ Family.
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ mocked_elements = []
+ for child in node:
+ self.builder._build_children(child)
+ mocked_elements.append(mock_family_build(child))
+
+ self.assertEqual(mocked_elements, self.aclass.children)
+
+if __name__ == "__main__":
+ unittest.main()
\ No newline at end of file
diff --git a/tests/cct_basebuilder_test.py b/tests/cct_basebuilder_test.py
new file mode 100644
index 0000000..ef70e6b
--- /dev/null
+++ b/tests/cct_basebuilder_test.py
@@ -0,0 +1,144 @@
+import unittest
+from unittest.mock import MagicMock, patch, call
+import sys
+import os
+# Add the parent directory to the sys.path so modules can be imported
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+
+from lxml import etree
+from c5dec.core.cct import BaseClass, BaseBuilder, Index
+
+class MockBaseClass(BaseClass):
+ def is_valid(self):
+ pass # Implement the abstract method is_valid for testing
+
+class MockBaseBuilder(BaseBuilder):
+
+ def _build_children(self, child):
+ pass # Implement the abstract method _build_children for testing
+
+
+class TestBaseClass(unittest.TestCase):
+
+ def setUp(self):
+ self.base_instance = MockBaseClass()
+ self.base_builder = MockBaseBuilder(self.base_instance)
+
+ def test_build_attributes(self):
+ xml_string = ''
+ node = etree.fromstring(xml_string)
+ parent_obj = MockBaseClass(_id="parent_id", _name="parent_name")
+
+ self.base_builder._build_attributes(node, parent_obj)
+
+ self.assertEqual(self.base_instance._id, "123")
+ self.assertEqual(self.base_instance._name, "TestItem")
+ self.assertEqual(self.base_instance.parent, parent_obj)
+
+ def test_build(self):
+ xml_string = '''
+
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ parent_obj = MockBaseClass(_id="parent_id", _name="parent_name")
+
+ # Mocking methods to avoid actual calls and assert they were called correctly
+ self.base_builder._build_attributes = MagicMock()
+ self.base_builder._build_children = MagicMock()
+ self.base_instance.is_valid = MagicMock()
+
+ # assuming that _build_attributes correctly set the attributes
+ self.base_instance._id = "123"
+ self.base_instance._name = "TestItem"
+ result = self.base_builder.build(node, parent_obj)
+
+ # test that build methods were called
+ self.base_builder._build_attributes.assert_called_once_with(node, parent_obj)
+ self.base_builder._build_children.assert_called_once_with(node[0])
+
+ # test that build returns the build instance.
+ self.assertEqual(result, self.base_instance)
+
+ def test_build_children_called_correctly(self):
+ xml_string = '''
+
+
+
+
+ '''
+ node = etree.fromstring(xml_string)
+
+ # Mocking _build_children method
+ with patch.object(MockBaseBuilder, '_build_children', return_value=None) as mock_method:
+ self.base_builder.build(node)
+
+ self.assertEqual(mock_method.call_count, len(node))
+
+ def test_build_with_empty_xml(self):
+ xml_string = ''
+ with self.assertRaises(Exception):
+ node = etree.fromstring(xml_string)
+ self.base_builder.build(node)
+
+ def test_build_with_malformed_xml(self):
+ xml_string = ''
+ with self.assertRaises(etree.XMLSyntaxError): # lxml raises XMLSyntaxError for malformed XML
+ node = etree.fromstring(xml_string)
+ self.base_builder.build(node)
+
+ def test_build_attributes_with_unexpected_attributes(self):
+ xml_string = ''
+ node = etree.fromstring(xml_string)
+ parent_obj = MockBaseClass(_id="parent_id", _name="parent_name")
+
+ # Assume it ignores unexpected attributes without raising an exception
+ try:
+ self.base_builder._build_attributes(node, parent_obj)
+ except Exception as e:
+ self.fail(f"_build_attributes() raised {type(e)} unexpectedly!")
+
+ def test_build_with_no_children(self):
+ xml_string = ''
+ node = etree.fromstring(xml_string)
+
+ with patch.object(MockBaseBuilder, '_build_children', return_value=None) as mock_method:
+ self.base_builder.build(node)
+ mock_method.assert_not_called()
+
+ def test_build_with_deeply_nested_xml(self):
+ xml_string = '''
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ '''
+ node = etree.fromstring(xml_string)
+
+ with patch.object(MockBaseBuilder, '_build_children', return_value=None) as mock_method:
+ self.base_builder.build(node)
+ # Assert that _build_children is called 3 times (once for each child)
+ self.assertEqual(mock_method.call_count, 3)
+
+ def tearDown(self):
+ Index.clear()
+
+if __name__ == "__main__":
+ unittest.main()
diff --git a/tests/cct_baseclass_test.py b/tests/cct_baseclass_test.py
new file mode 100644
index 0000000..df8cefe
--- /dev/null
+++ b/tests/cct_baseclass_test.py
@@ -0,0 +1,270 @@
+from c5dec.core.cct import BaseClass
+from c5dec.common import C5decError
+from unittest.mock import patch, call
+import unittest
+import sys
+import os
+
+# Add the parent directory to the sys.path so that modules can be imported
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+
+
+class MockBaseClass(BaseClass):
+ def is_valid(self):
+ pass # Implement the abstract method is_valid for testing
+
+class AnotherClass:
+ pass
+
+class TestBaseClass(unittest.TestCase):
+
+ def setUp(self):
+ self.base_instance = MockBaseClass(_id="test_id", _name="test_name")
+ self.child_instance = MockBaseClass(_id="child_id", _name="child_name")
+ self.sibling_instance = MockBaseClass(_id="sibling_id", _name="sibling_name")
+
+ def test_init_and_attributes(self):
+ self.assertEqual(self.base_instance._id, "test_id")
+ self.assertEqual(self.base_instance._name, "test_name")
+ self.assertIn("_id", self.base_instance.attrib)
+ self.assertIn("_name", self.base_instance.attrib)
+
+ def test_repr(self):
+ self.assertEqual(repr(self.base_instance), "")
+
+ def test_clone(self):
+ cloned = self.base_instance.clone()
+ self.assertNotEqual(id(cloned), id(self.base_instance))
+ self.assertEqual(cloned._id, self.base_instance._id)
+
+ def test_clone_deep_copy(self):
+ # Clone the instance
+ cloned_instance = self.base_instance.clone()
+
+ # Make sure both instances are not the same object
+ self.assertNotEqual(id(self.base_instance), id(cloned_instance))
+
+ # Update attributes in the cloned instance
+ cloned_instance._id = "456"
+ cloned_instance._name = "UpdatedTestInstance"
+ cloned_instance.text = "Sample Text"
+ cloned_instance.children.append(MockBaseClass(_id="child", _name="ChildInstance"))
+
+ # Assert that changes in the cloned instance do not affect the original instance
+ self.assertNotEqual(cloned_instance._id, self.base_instance._id)
+ self.assertNotEqual(cloned_instance._name, self.base_instance._name)
+ self.assertNotEqual(cloned_instance.text, self.base_instance.text)
+ self.assertNotEqual(len(cloned_instance.children), len(self.base_instance.children))
+
+ # Modify the original and ensure it doesn't affect the clone
+ self.base_instance._name = "AnotherName"
+ self.assertNotEqual(cloned_instance._name, self.base_instance._name)
+
+ self.assertEqual(self.base_instance._name, "AnotherName")
+ self.assertEqual(cloned_instance._name, "UpdatedTestInstance")
+
+ def test_collector_attribute(self):
+ self.base_instance.children.append(self.child_instance)
+ collected = list(self.base_instance.collector(target="_name", mode="attribute"))
+ self.assertIn("test_name", collected)
+ self.assertIn("child_name", collected)
+
+ def test_collector_type(self):
+ collected = list(self.base_instance.collector(target=BaseClass, mode="type"))
+ self.assertIn(self.base_instance, collected)
+
+ def test_collector_invalid_mode(self):
+ collected = list(self.base_instance.collector("some_attr", mode="invalid_mode"))
+ self.assertEqual(len(collected), 0)
+
+ def test_collector_recursive_collection(self):
+ grandchild = MockBaseClass(_id="grandchild")
+ grandchild.some_attr = "deep_value"
+ child = MockBaseClass(_id="child")
+ child.children = [grandchild]
+ self.base_instance.children = [child]
+
+ collected = list(self.base_instance.collector("some_attr"))
+ self.assertEqual(len(collected), 1)
+ self.assertEqual(collected[0], "deep_value")
+
+ def test_basic_functionality(self):
+ instance = MockBaseClass(_id="test", _name="TestName")
+ result = instance.get_formatted_text()
+ expected = "\n# TEST TestName\n\n"
+ self.assertEqual(result, expected)
+
+ def test_hierarchy_handling(self):
+ child = MockBaseClass(_id="child", _name="ChildName")
+ instance = MockBaseClass(_id="test", _name="TestName")
+ instance.container = [child]
+ result = instance.get_formatted_text()
+ expected = "\n# TEST TestName\n\n\n## CHILD ChildName\n\n"
+ self.assertEqual(result, expected)
+
+ def test_missing_name(self):
+ instance = MockBaseClass(_id="test")
+ result = instance.get_formatted_text()
+ expected = "\n# TEST \n\n"
+ self.assertEqual(result, expected)
+
+ def test_custom_level(self):
+ instance = MockBaseClass(_id="test", _name="TestName")
+ result = instance.get_formatted_text(level=3)
+ expected = "\n### TEST TestName\n\n"
+ self.assertEqual(result, expected)
+
+ def test_empty_container(self):
+ instance = MockBaseClass(_id="test", _name="TestName")
+ instance.container = [] # Explicitly setting an empty container.
+ result = instance.get_formatted_text()
+ expected = "\n# TEST TestName\n\n"
+ self.assertEqual(result, expected)
+
+ def test_multiple_elements_container(self):
+ child1 = MockBaseClass(_id="child1", _name="ChildName1")
+ child2 = MockBaseClass(_id="child2", _name="ChildName2")
+
+ instance = MockBaseClass(_id="test", _name="TestName")
+ instance.container = [child1, child2]
+
+ result = instance.get_formatted_text()
+ expected = "\n# TEST TestName\n\n\n## CHILD1 ChildName1\n\n\n## CHILD2 ChildName2\n\n"
+ self.assertEqual(result, expected)
+
+ def test_object_without_get_formatted_text(self):
+ child = AnotherClass()
+ instance = MockBaseClass(_id="test", _name="TestName")
+ instance.container = [child]
+
+ with self.assertRaises(AttributeError):
+ instance.get_formatted_text()
+
+ def test_is_empty(self):
+ self.assertTrue(self.base_instance.is_empty())
+
+ def test_valid_id(self):
+ self.base_instance._id = "123"
+ self.assertTrue(self.base_instance.has_valid_id())
+
+ def test_missing_id(self):
+ self.base_instance._id = None
+ with self.assertRaises(C5decError):
+ self.base_instance.has_valid_id()
+
+ def test_invalid_id_data_type(self):
+ self.base_instance._id = 123 # integer
+ with self.assertRaises(C5decError):
+ self.base_instance.has_valid_id()
+
+ def test_valid_name(self):
+ self.base_instance._name = "John"
+ self.assertTrue(self.base_instance.has_valid_name())
+
+ def test_missing_name(self):
+ self.base_instance._name = None
+ with self.assertRaises(C5decError):
+ self.base_instance.has_valid_name()
+
+ def test_invalid_name_data_type(self):
+ self.base_instance._name = 123 # integer
+ with self.assertRaises(C5decError):
+ self.base_instance.has_valid_name()
+
+ def test_contains(self):
+ self.base_instance.children.append(self.child_instance)
+ self.assertTrue(self.base_instance.contains(self.child_instance))
+ self.assertFalse(self.base_instance.contains(self.sibling_instance))
+
+ def test_get_children(self):
+ self.base_instance.children.append(self.child_instance)
+ self.base_instance.children.append(self.sibling_instance)
+ self.assertListEqual(self.base_instance.get_children(), [self.child_instance,
+ self.sibling_instance])
+
+ def test_get_child_by_id(self):
+ self.base_instance.children.append(self.child_instance)
+ self.base_instance.children.append(self.sibling_instance)
+ self.assertEqual(self.base_instance.get_child_by_id("child_id"), self.child_instance)
+
+ def test_get_descendants(self):
+ grandchild = MockBaseClass(_id="grandchild", _name="Grand Child")
+ self.child_instance.children.append(grandchild)
+ self.base_instance.children.append(self.child_instance)
+ descendants = self.base_instance.get_descendants()
+ self.assertIn(self.child_instance, descendants)
+ self.assertIn(grandchild, descendants)
+
+ def test_circular_reference_in_descendants(self):
+ self.child_instance.children.append(self.base_instance)
+ self.base_instance.children.append(self.child_instance)
+ with self.assertRaises(C5decError) as context:
+ self.base_instance.get_descendants()
+ self.assertIn("Circular reference detected", str(context.exception))
+
+ def test_get_parent(self):
+ self.child_instance.parent = self.base_instance
+ self.assertEqual(self.child_instance.get_parent(), self.base_instance)
+
+ def test_get_ancestors(self):
+ parent2 = MockBaseClass(_id="parent2", _name="Parent 2")
+ self.base_instance.parent = parent2
+ self.child_instance.parent = self.base_instance
+ self.assertListEqual(self.child_instance.get_ancestors(), [self.base_instance, parent2])
+
+ def test_get_ancestors_circular_reference(self):
+ parent_instance = MockBaseClass(_id="parent_id", _name="parent_name")
+ child_instance = MockBaseClass(_id="child_id", _name="child_name")
+ grandchild_instance = MockBaseClass(_id="grandchild_id", _name="grandchild_name")
+
+ child_instance.parent = parent_instance
+ grandchild_instance.parent = child_instance
+ parent_instance.parent = grandchild_instance
+ with self.assertRaises(C5decError) as context:
+ grandchild_instance.get_ancestors()
+ self.assertIn("Circular reference detected", str(context.exception))
+
+ def test_get_siblings(self):
+ self.child_instance.parent = self.base_instance
+ self.sibling_instance.parent = self.base_instance
+ self.base_instance.children.extend([self.child_instance, self.sibling_instance])
+ self.assertListEqual(self.child_instance.get_siblings(), [self.sibling_instance])
+
+ def test_get_item_tree_basic(self):
+ expected_tree = {"id": "test_id", "name": "test_name"}
+ self.assertDictEqual(self.base_instance.get_item_tree(), expected_tree)
+
+ def test_get_item_tree_with_children(self):
+ # Adding children
+ self.base_instance.children = [MockBaseClass(_id="test_id_2", _name="child1"), MockBaseClass(_id="test_id_3", _name="child2")]
+ expected_tree = {"id": "test_id", "name": "test_name", "children": [{"id": "test_id_2", "name": "child1"},
+ {"id": "test_id_3", "name": "child2"}]}
+ self.assertDictEqual(self.base_instance.get_item_tree(), expected_tree)
+
+ def test_get_item_tree_return_type(self):
+ self.assertIsInstance(self.base_instance.get_item_tree(), dict)
+
+ def test_get_item_tree_deeply_nested_structure(self):
+ # Creating a deeply nested structure
+ child = MockBaseClass(_id="test_id_1", _name="child1")
+ child.children = [MockBaseClass(_id="test_id_1.1", _name="grandchild1")]
+ self.base_instance.children = [MockBaseClass(_id="test_id_2", _name="child2"), child]
+
+ expected_tree = {
+ "id": "test_id",
+ "name": "test_name",
+ "children": [{"id": "test_id_2", "name": "child2"},
+ {"id": "test_id_1", "name": "child1", "children": [
+ {"id": "test_id_1.1", "name": "grandchild1"}]}]}
+ self.assertDictEqual(self.base_instance.get_item_tree(), expected_tree)
+
+ def test_get_item_tree_edge_cases(self):
+ # Edge case: Empty _name
+ self.base_instance._name = ""
+ expected_tree = {"id": "test_id", "name": ""}
+ self.assertDictEqual(self.base_instance.get_item_tree(), expected_tree)
+
+
+if __name__ == "__main__":
+ unittest.main()
diff --git a/tests/cct_ccdocument_test.py b/tests/cct_ccdocument_test.py
new file mode 100644
index 0000000..5679df9
--- /dev/null
+++ b/tests/cct_ccdocument_test.py
@@ -0,0 +1,105 @@
+import unittest
+from unittest.mock import MagicMock, patch
+import sys
+import os
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+
+from lxml import etree
+from c5dec.core.cct import CCDocument, CCDocumentBuilder
+import c5dec.core.cct as cct
+from c5dec.common import C5decError, C5decWarning
+
+class TestCCDocument(unittest.TestCase):
+
+ def setUp(self):
+ self.doc = CCDocument()
+ self.doc.version = "3"
+ self.doc.revision = "5"
+ self.doc.clause = [MagicMock(cct.Clause())]
+ self.doc.f_class = [MagicMock(cct.FClass(_id="fclass_id", _name="fclass_name"))]
+ self.doc.a_class = [MagicMock(cct.AClass(_id="aclass_id", _name="aclass_name"))]
+ self.doc.eal = [MagicMock(cct.Package(_id="eal1"))]
+ self.doc.cap = [MagicMock(cct.Package(_id="cap1"))]
+
+ def test_is_valid(self):
+ self.assertTrue(self.doc.is_valid())
+
+ def test_missing_attributes_raises_warning(self):
+ self.doc.f_class = []
+ with self.assertRaises(C5decWarning):
+ self.doc.is_valid()
+
+ def test_missing_version_raises_attribute(self):
+ self.doc.version = ""
+ with self.assertRaises(C5decError):
+ self.doc.is_valid()
+
+ def test_missing_revision_raises_attribute(self):
+ self.doc.revision = ""
+ with self.assertRaises(C5decError):
+ self.doc.is_valid()
+
+class TestAClassBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.doc = MagicMock(CCDocument())
+ self.builder = CCDocumentBuilder(self.doc)
+
+ def test_initialization(self):
+ self.assertIsInstance(self.builder.instance, CCDocument)
+
+ def test_initialization_wrong_instance_type(self):
+ with self.assertRaises(C5decError):
+ CCDocumentBuilder("INVALIDELEMENT")
+
+ def test_build_attributes(self):
+ xml_string = '''
+
+ '''
+ node = etree.fromstring(xml_string)
+ self.builder._build_attributes(node)
+
+ self.assertEqual(self.doc._id, "CCv5R5")
+ self.assertEqual(self.doc.lang, "en")
+
+ @patch.object(cct.Clause, "build")
+ @patch.object(cct.FClassBuilder, "build")
+ @patch.object(cct.AClassBuilder, "build")
+ def test_build_children(self, MockABuilder, MockFBuilder, MockClause):
+ xml_string = '''
+
+
+
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ for child in node:
+ self.builder._build_children(child)
+
+ MockClause.assert_called_once()
+ MockFBuilder.assert_called_once()
+ MockABuilder.assert_called_once()
+
+ self.assertTrue(all([self.doc.clause, self.doc.f_class, self.doc.a_class]))
+
+ @patch.object(CCDocumentBuilder, "_build_attributes")
+ @patch.object(CCDocumentBuilder, "_build_children")
+ def test_build(self, MockBuildChildren, MockBuildAttrib):
+ xml_string = '''
+
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ result = self.builder.build(node)
+
+ MockBuildAttrib.assert_called_once_with(node)
+ MockBuildChildren.assert_called_once_with(list(node)[0])
+
+ self.assertEqual(result, self.doc)
+
+
+if __name__ == "__main__":
+ unittest.main()
\ No newline at end of file
diff --git a/tests/cct_functional_test.py b/tests/cct_functional_test.py
new file mode 100644
index 0000000..18c7340
--- /dev/null
+++ b/tests/cct_functional_test.py
@@ -0,0 +1,735 @@
+import unittest
+from unittest.mock import MagicMock, patch
+import sys
+import os
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+
+from lxml import etree
+import c5dec.core.cct as cct
+from c5dec.common import C5decError
+
+class TestFEItem(unittest.TestCase):
+
+ def setUp(self):
+ self.fe_item = cct.FEItem()
+
+ def test_is_valid_raises_value_error_when_empty(self):
+ with self.assertRaises(C5decError, msg="Object cannot be empty."):
+ self.fe_item.is_valid()
+
+ def test_is_valid_passes_when_non_empty(self):
+ # Adding dummy object to container to make FEItem non-empty
+ self.fe_item.container.append("Non-empty")
+ try:
+ self.fe_item.is_valid()
+ except C5decError:
+ self.fail("is_valid() raised C5decError unexpectedly!")
+
+ def test_initial_container_empty(self):
+ self.assertListEqual(self.fe_item.container, [], "Container should be initialized as empty.")
+
+ def test_initial_list_empty(self):
+ self.assertListEqual(self.fe_item.list, [], "List should be initialized as empty.")
+
+ def test_initial_operation_empty(self):
+ self.assertListEqual(self.fe_item.operation, [], "Operation should be initialized as empty.")
+
+class TestFEItemBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.fe_item_instance = cct.FEItem()
+ self.fe_item_builder = cct.FEItemBuilder(self.fe_item_instance)
+
+ def test_init_raises_value_error_for_invalid_instance(self):
+ with self.assertRaises(C5decError):
+ cct.FEItemBuilder("Not an FEItem")
+
+ def test_build_calls_is_valid(self):
+ xml_string = ""
+ node = etree.fromstring(xml_string)
+
+ self.fe_item_instance.is_valid = MagicMock()
+ self.fe_item_builder.build(node)
+
+ self.fe_item_instance.is_valid.assert_called_once()
+
+ @patch.object(cct.FEItemBuilder, "build")
+ @patch.object(cct.OperationBuilder, "build")
+ def test_build_children_for_non_fe_list(self, mock_op_builder_build, mock_fe_item_builder_build):
+ xml_string = ""
+ node = etree.fromstring(xml_string)
+
+ # Set up the mocked build methods to return dummy instances
+ mock_fe_item_builder_build.return_value = cct.FEItem()
+ mock_op_builder_build.return_value = cct.Operation()
+
+ self.fe_item_builder._build_children(node)
+
+ # Ensure the build method on OperationBuilder is called
+ mock_op_builder_build.assert_called_once()
+
+ @patch.object(cct.FEItemBuilder, "build")
+ @patch.object(cct.FEListBuilder, "build")
+ def test_build_children_for_fe_list(self, mock_fe_list_builder_build, mock_fe_item_builder_build):
+ xml_string = ""
+ node = etree.fromstring(xml_string)
+
+ # Set up the mocked build methods to return dummy instances
+ mock_fe_item_builder_build.return_value = cct.FEItem()
+ mock_fe_list_builder_build.return_value = cct.FEList()
+
+ self.fe_item_builder._build_children(node)
+
+ # Ensure the build method on FEListBuilder is called
+ mock_fe_list_builder_build.assert_called_once()
+
+ def test_build_children_handles_text_and_tail(self):
+ xml_string = '''
+
+ Text content
+
+ List Text
+ This is the item text
+
+ Tail content
+
+ '''
+ node = etree.fromstring(xml_string)
+ # Mock to avoid actual object build
+ with patch.object(cct.FEItemBuilder, "build"), \
+ patch.object(cct.FEListBuilder, "build"), \
+ patch.object(cct.OperationBuilder, "build"):
+
+ for child in node:
+ self.fe_item_builder._build_children(child)
+ # Check if text and tail content is appended to container
+ text_contents = [elem.text for elem in self.fe_item_instance.container if isinstance(elem, cct.Text)]
+
+ self.assertIn("List Text", ' '.join(text_contents))
+ self.assertIn("Tail content", ' '.join(text_contents))
+
+
+class TestFEList(unittest.TestCase):
+ def setUp(self):
+ self.fe_list = cct.FEList()
+
+ def test_is_valid(self):
+ # Test: FEList instance should not be valid when 'item' list is empty
+ with self.assertRaises(C5decError) as context:
+ self.fe_list.is_valid()
+ self.assertIn("must contain items", str(context.exception))
+
+ # Test: FEList instance should be valid when 'item' list is not empty
+ self.fe_list.item.append("dummy_item")
+ self.assertTrue(self.fe_list.is_valid()) # No exception should be raised
+
+ def test_initialization(self):
+ # Test: Check attributes after initialization
+ self.assertIsNone(self.fe_list._id)
+ self.assertIsNone(self.fe_list._name)
+ self.assertEqual(self.fe_list.item, [])
+
+class TestFEListBuilder(unittest.TestCase):
+ def setUp(self):
+ self.fe_list = cct.FEList()
+ self.builder = cct.FEListBuilder(self.fe_list)
+
+ def test_init_with_invalid_instance(self):
+ # Test: Check initialization with invalid instance type
+ with self.assertRaises(C5decError) as context:
+ cct.FEListBuilder("InvalidInstance")
+ self.assertIn("Object must be", str(context.exception))
+
+ def test_build_attributes(self):
+ # Mocked XML node
+ node = MagicMock(spec=etree._Element)
+ # Parent object mock
+ parent_obj = MagicMock()
+
+ # Test: Check if parent_obj is assigned to instance's parent attribute
+ self.builder._build_attributes(node, parent_obj)
+ self.assertEqual(self.fe_list.parent, parent_obj)
+
+ def test_build_children(self):
+ # XML string for creating a node
+ xml_string = ""
+ node = etree.fromstring(xml_string)
+ # Mock to avoid actual object build and method call
+ with patch.object(cct.FEItemBuilder, "build", return_value="MockItem"): # Replace path accordingly
+ self.builder._build_children(node)
+ # Check if mock item is appended to container and item of instance
+ self.assertIn("MockItem", self.fe_list.container)
+ self.assertIn("MockItem", self.fe_list.item)
+
+ def test_build(self):
+ # XML string for creating a node
+ xml_string = ""
+ node = etree.fromstring(xml_string)
+ # Mocks to avoid actual object build and method call
+ with patch.object(cct.FEListBuilder,"_build_attributes"), \
+ patch.object(cct.FEListBuilder,"_build_children"), \
+ patch.object(cct.FEList, "is_valid"):
+ built_instance = self.builder.build(node)
+ # Check if instance is returned
+ self.assertEqual(built_instance, self.fe_list)
+
+
+class TestFElement(unittest.TestCase):
+
+ def setUp(self):
+ self.fe_element = cct.FElement(_id="FE1", _name="Functional Element 1")
+ self.fe_element.container = [MagicMock(cct.Operation(op_type="selection")),
+ MagicMock(cct.Operation(op_type="assurance"))]
+
+ def test_is_valid_success(self):
+ # Test: Check is_valid returns True for proper FElement instance
+ self.assertTrue(self.fe_element.is_valid())
+
+ def test_is_valid_fail_on_empty(self):
+ # Test: Check is_valid raises C5decError when instance is empty
+ self.fe_element.container = [] # Assume it is empty now
+ with self.assertRaises(C5decError):
+ self.fe_element.is_valid()
+
+class TestFElementBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.fe_element = cct.FElement(_id="FE1", _name="Functional Element 1")
+ self.fe_element_builder = cct.FElementBuilder(instance=self.fe_element)
+
+ def test_init_validates_instance_type(self):
+ with self.assertRaises(C5decError):
+ # Trying to initialize with an invalid instance type should raise a C5decError.
+ cct.FElementBuilder(instance="invalid_instance")
+
+ def test_build_children(self):
+ xml_string = '''
+
+ Element Text 1
+
+ SelItemA
+ SelItemB
+
+ ItemA
+ ItemB
+
+
+ '''
+ node = etree.fromstring(xml_string)
+
+ for child in node:
+ self.fe_element_builder._build_children(child)
+
+ container_types = [type(obj) for obj in self.fe_element.container]
+ self.assertEqual(container_types, [cct.Text, cct.Operation, cct.FEList])
+
+ def test_build_requirement(self):
+ mock_text_1 = MagicMock(spec=cct.Text, text="This is ")
+ mock_text_2 = MagicMock(spec=cct.Text, text="just a ")
+ mock_text_3 = MagicMock(spec=cct.Text, text="simple test.")
+
+ # Assign the mocks to the container attribute
+ self.fe_element.container = [mock_text_1, mock_text_2, mock_text_3]
+
+ self.fe_element_builder._build_requirement()
+ self.assertEqual(self.fe_element.requirement, "This is just a simple test.")
+
+ def test_build_children_handles_fe_list(self):
+ # Creating a sample XML element that has 'fe-list' as a child node.
+ xml_string = "Some textTail content"
+ node = etree.fromstring(xml_string)
+
+ # Mocking the build method of FEListBuilder to avoid actual building.
+ with patch.object(cct.FEListBuilder, "build", return_value=cct.FEList()):
+ self.fe_element_builder.build(node)
+
+ # Check if fe_list is appended to container
+ self.assertIsInstance(self.fe_element.container[-1], cct.FEList)
+
+ def test_build_children_handles_text_and_tail(self):
+ xml_string = '''
+
+
+ Text content
+
+ List Text
+ This is the item text
+
+ Tail content
+
+ Tail content.
+
+ '''
+ node = etree.fromstring(xml_string)
+ # Mock to avoid actual object build
+ with patch.object(cct.FEItemBuilder, "build"), \
+ patch.object(cct.FEListBuilder, "build"), \
+ patch.object(cct.OperationBuilder, "build"):
+
+ for child in node:
+ self.fe_element_builder._build_children(child)
+ # Check if text and tail content is appended to container
+ text_contents = [elem.text for elem in self.fe_element.container if isinstance(elem, cct.Text)]
+ self.assertIn("Text content", ' '.join(text_contents))
+ self.assertIn("Tail content", ' '.join(text_contents))
+
+
+class TestFCoAudit(unittest.TestCase):
+
+ def setUp(self):
+ self.fco_audit = cct.FCoAudit(level="minimal")
+
+ def test_is_valid_with_valid_instance(self):
+ # Mocking is_empty method to return False.
+ self.fco_audit.is_empty = lambda: False
+ self.assertTrue(self.fco_audit.is_valid())
+
+ def test_is_valid_with_invalid_level(self):
+ # Assigning an invalid level
+ self.fco_audit.level = "invalid_level"
+ with self.assertRaises(C5decError):
+ self.fco_audit.is_valid()
+
+ def test_is_valid_with_empty_instance(self):
+ # Mocking is_empty method to return True.
+ self.fco_audit.is_empty = lambda: True
+ with self.assertRaises(C5decError):
+ self.fco_audit.is_valid()
+
+class TestFCoAuditBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.fco_audit = cct.FCoAudit(level="minimal")
+ self.builder = cct.FCoAuditBuilder(self.fco_audit)
+ # Assuming you have a function `clean_string` in your module. If it's in another module, adjust accordingly.
+ self.clean_string = cct.clean_string
+
+ def test_init_with_valid_instance(self):
+ self.assertIsInstance(self.builder, cct.FCoAuditBuilder)
+
+ def test_init_with_invalid_instance(self):
+ with self.assertRaises(C5decError):
+ cct.FCoAuditBuilder("Invalid instance")
+
+ def test_build_attributes(self):
+ xml_string = '''
+
+ Some Text.
+
+ '''
+ node = etree.fromstring(xml_string)
+ self.builder.build(node)
+
+ self.assertEqual(self.fco_audit.level, "basic")
+ self.assertEqual(self.fco_audit.isequal, "test_equal")
+
+ def test_build_children_noop(self):
+ # Since _build_children is a no-op, this is just to ensure it doesn't break existing functionality.
+ self.builder._build_children(None)
+
+ def test_build_with_isequal(self):
+ xml_string = '''
+
+ Some Text.
+
+ '''
+ node = etree.fromstring(xml_string)
+ built_instance = self.builder.build(node)
+
+ self.assertEqual(built_instance.text, "Equal to test_equal")
+ self.assertEqual(built_instance.level, "basic")
+ self.assertEqual(built_instance.isequal, "test_equal")
+
+ def test_build_without_isequal(self):
+ xml_string = '''
+
+ Some Text.
+
+ '''
+ node = etree.fromstring(xml_string)
+ built_instance = self.builder.build(node)
+
+ self.assertEqual(built_instance.text, "Some Text.")
+ self.assertEqual(built_instance.level, "basic")
+ self.assertIsNone(built_instance.isequal)
+
+ def test_build_invalid(self):
+ node = MagicMock()
+ node.text = "Some text"
+ node.attrib = {"level": "invalid_level"}
+ parent_obj = None
+
+ with self.assertRaises(C5decError):
+ self.builder.build(node, parent_obj)
+
+
+class TestFCoManagement():
+ """See TestFCoAudit"""
+
+class TestFCoManagementBuilder():
+ """See TestFCoAuditBuilder"""
+
+
+class TestFComponent(unittest.TestCase):
+
+ def setUp(self):
+ self.component = cct.FComponent(_id='test_id', _name='test_name')
+
+ def test_init(self):
+ self.assertEqual(self.component._id, 'test_id')
+ self.assertEqual(self.component._name, 'test_name')
+ self.assertIsNone(self.component.fco_levelling)
+ self.assertIsNone(self.component.audit)
+ self.assertEqual(self.component.hierarchical, [])
+ self.assertEqual(self.component.dependencies, [])
+
+ def test_valid_component(self):
+ self.component.fco_levelling = MagicMock()
+ self.component.fco_levelling.original_tag = "fco-levelling"
+ fake_element = MagicMock(cct.FElement)
+ self.component.children = [fake_element]
+
+ # Check if no exception is raised for a valid component
+ self.assertTrue(self.component.is_valid())
+
+ def test_missing_levelling(self):
+ fake_element = MagicMock(cct.FElement)
+ self.component.children = [fake_element]
+
+ with self.assertRaises(C5decError):
+ self.component.is_valid()
+
+ def test_invalid_levelling_tag(self):
+ self.component.fco_levelling = MagicMock()
+ self.component.fco_levelling.original_tag = "invalid_tag"
+ fake_element = MagicMock(cct.FElement)
+ self.component.children = [fake_element]
+
+ with self.assertRaises(C5decError):
+ self.component.is_valid()
+
+ def test_missing_children(self):
+ self.component.fco_levelling = MagicMock()
+ self.component.fco_levelling.original_tag = "fco-levelling"
+
+ with self.assertRaises(C5decError):
+ self.component.is_valid()
+
+ def test_invalid_children_type(self):
+ self.component.fco_levelling = MagicMock()
+ self.component.fco_levelling.original_tag = "fco-levelling"
+ self.component.children = [MagicMock()] # Not an FElement instance
+
+ with self.assertRaises(C5decError):
+ self.component.is_valid()
+
+class TestFComponentBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.component = cct.FComponent()
+ self.builder = cct.FComponentBuilder(self.component)
+
+ def test_init_valid_instance(self):
+ self.assertIsInstance(self.builder, cct.FComponentBuilder)
+
+ def test_init_invalid_instance(self):
+ with self.assertRaises(C5decError):
+ cct.FComponentBuilder("InvalidType")
+
+ @patch.object(cct.FCoManagementBuilder, "build")
+ def test_build_children_management(self, mock_mgmt_build):
+ xml_string = '''
+
+ Some Component Management Text.
+
+ '''
+ child = etree.fromstring(xml_string)
+ self.builder._build_children(child)
+ fco_mgmt = mock_mgmt_build(child)
+ self.assertEqual(self.component.management, fco_mgmt)
+
+ @patch.object(cct.FCoAuditBuilder, "build")
+ def test_build_children_audit(self, mock_audit_build):
+ xml_string = '''
+
+ Some Component Audit Text.
+
+ '''
+ child = etree.fromstring(xml_string)
+ self.builder._build_children(child)
+ fco_audit = mock_audit_build(child)
+ self.assertEqual(self.component.audit, fco_audit)
+
+ @patch.object(cct.FElementBuilder, "build")
+ def test_build_children_element(self, mock_felement_build):
+ xml_string = '''
+
+ Some Element Text.
+
+ '''
+ child = etree.fromstring(xml_string)
+ self.builder._build_children(child)
+ f_element = mock_felement_build(child)
+
+ self.assertEqual(self.component.children[0], f_element)
+
+ def test_build_children_parasequence_objects(self):
+ child = MagicMock()
+ child.tag = "fco-rationale"
+ self.builder._build_children(child)
+ self.assertIsInstance(self.component.fco_rationale, cct.ParaSequence)
+
+ def test_build_children_hierarchical(self):
+ child = MagicMock()
+ child.tag = "fco-hierarchical"
+ child.get.return_value = "TEST_COMPONENT"
+ self.builder._build_children(child)
+ self.assertEqual(["TEST_COMPONENT"], self.component.hierarchical)
+
+ def test_build_children_dependencies(self):
+ child = MagicMock()
+ child.tag = "fco-dependencies"
+ mock_component = MagicMock(etree._Element)
+ mock_component.get.return_value ="TEST_COMPONENT"
+ child.__iter__.return_value = [mock_component]
+ self.builder._build_children(child)
+ self.assertEqual(["TEST_COMPONENT"], self.component.dependencies)
+
+ def test_build_children_or_dependencies(self):
+ child = MagicMock()
+ child.tag = "fco-dependencies"
+ grandchild = MagicMock()
+ grandchild.tag = "fco-or"
+ mock_component = MagicMock(etree._Element)
+ mock_component.get.return_value ="TEST_COMPONENT"
+ grandchild.__iter__.return_value = [mock_component]
+ child.__iter__.return_value = [grandchild]
+ self.builder._build_children(child)
+ self.assertEqual([["TEST_COMPONENT"]], self.component.dependencies)
+
+ def test_build_children_without_dependencies(self):
+ child = MagicMock()
+ grandchild = MagicMock()
+ grandchild.get.retun_value = None
+ child.__iter__.return_value = [grandchild]
+ self.builder._build_children(child)
+ self.assertEqual([], self.component.dependencies)
+
+
+class TestFFamily(unittest.TestCase):
+
+ def setUp(self):
+ self.ffamily = cct.FFamily(_id="ID001", _name="TestFamily")
+
+ def test_initialization(self):
+ self.assertEqual(self.ffamily._id, "ID001")
+ self.assertEqual(self.ffamily._name, "TestFamily")
+ self.assertIsNone(self.ffamily.ff_behaviour)
+ self.assertIsNone(self.ffamily.ff_application_notes)
+ self.assertIsNone(self.ffamily.ff_user_notes)
+ self.assertIsNone(self.ffamily.ff_evaluator_notes)
+ self.assertEqual(self.ffamily.children, [])
+
+ def test_is_valid_valid_id_and_name(self):
+ self.ffamily.has_valid_id = MagicMock(return_value=True)
+ self.ffamily.has_valid_name = MagicMock(return_value=True)
+ self.ffamily.children = [MagicMock(cct.FComponent)]
+ self.ffamily.ff_behaviour = MagicMock()
+ self.ffamily.ff_behaviour.original_tag = "ff-behaviour"
+ self.assertTrue(self.ffamily.is_valid())
+
+ def test_is_valid_missing_behaviour(self):
+ self.ffamily.ff_behaviour = None
+ with self.assertRaises(C5decError) as context:
+ self.ffamily.is_valid()
+ self.assertIn("is missing family behaviour.", str(context.exception))
+
+ def test_is_valid_wrong_original_tag_behaviour(self):
+ self.ffamily.ff_behaviour = MagicMock()
+ self.ffamily.ff_behaviour.original_tag = "other-tag"
+ with self.assertRaises(C5decError) as context:
+ self.ffamily.is_valid()
+ self.assertIn("is missing family behaviour.", str(context.exception))
+
+ def test_is_valid_no_children(self):
+ self.ffamily.children = []
+ self.ffamily.ff_behaviour = MagicMock()
+ self.ffamily.ff_behaviour.original_tag = "ff-behaviour"
+ with self.assertRaises(C5decError) as context:
+ self.ffamily.is_valid()
+ self.assertIn("must contain child elements of type", str(context.exception))
+
+ def test_is_valid_wrong_child_type(self):
+ self.ffamily.children = [MagicMock()] # A mock that isn't an FComponent
+ self.ffamily.ff_behaviour = MagicMock()
+ self.ffamily.ff_behaviour.original_tag = "ff-behaviour"
+ with self.assertRaises(C5decError) as context:
+ self.ffamily.is_valid()
+ self.assertIn("must contain child elements of type", str(context.exception))
+
+class TestFFamilyBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.ffamily_instance = cct.FFamily(_id="ID001", _name="TestFamily")
+ self.builder = cct.FFamilyBuilder(self.ffamily_instance)
+
+ def test_initialization(self):
+ self.assertEqual(self.builder.instance, self.ffamily_instance)
+
+ def test_initialization_wrong_instance_type(self):
+ with self.assertRaises(C5decError):
+ cct.FFamilyBuilder("NotAnFFamilyInstance")
+
+ @patch.object(cct.ParaSequence, 'build')
+ @patch.object(cct.FFamily, '__setattr__')
+ def test_build_children_para_sequence_objects(self, mock_setattr, mock_build):
+ # Creating a dummy xml element
+ xml_string = 'Test Behaviour Text'
+ child = etree.fromstring(xml_string)
+
+ # Mocking the build method to return a dummy ParaSequence object
+ dummy_parasequence = cct.ParaSequence()
+ mock_build.return_value = dummy_parasequence
+
+ self.builder._build_children(child)
+
+ mock_build.assert_called_once_with(child, self.builder.instance)
+ mock_setattr.assert_called_once_with('ff_behaviour', dummy_parasequence)
+ self.assertIn(dummy_parasequence, self.builder.instance.container)
+
+ @patch.object(cct.FComponentBuilder, 'build')
+ def test_build_children_f_component(self, mock_build):
+ xml_string = ''
+ child = etree.fromstring(xml_string)
+
+ dummy_fcomponent = cct.FComponent()
+ mock_build.return_value = dummy_fcomponent
+
+ self.builder._build_children(child)
+
+ mock_build.assert_called_once_with(child, self.builder.instance)
+ self.assertIn(dummy_fcomponent, self.builder.instance.children)
+
+
+class TestFClass(unittest.TestCase):
+
+ def setUp(self):
+ self.fclass = cct.FClass(_id="ID001", _name="TestClass")
+
+ def test_initialization(self):
+ self.assertEqual(self.fclass._id, "ID001")
+ self.assertEqual(self.fclass._name, "TestClass")
+ self.assertIsNone(self.fclass.fc_introduction)
+ self.assertIsNone(self.fclass.fc_informative_notes)
+
+ def test_valid_case(self):
+ mock_intro = MagicMock(cct.ParaSequence())
+ mock_intro.original_tag = "fc-introduction"
+ self.fclass.fc_introduction = mock_intro
+ mock_note = MagicMock(cct.ParaSequence())
+ mock_note.original_tag = "fc-informative-notes"
+ self.fclass.fc_informative_notes = mock_note
+ self.fclass.children.append(MagicMock(cct.FFamily()))
+ self.assertTrue(self.fclass.is_valid())
+
+ def test_missing_fc_introduction(self):
+ self.fclass.fc_introduction = None
+
+ with self.assertRaises(C5decError):
+ self.fclass.is_valid()
+
+ def test_invalid_fc_introduction(self):
+ mock_intro = MagicMock(cct.ParaSequence())
+ mock_intro.original_tag = "invalid-tag"
+ self.fclass.fc_introduction = mock_intro
+
+ with self.assertRaises(C5decError):
+ self.fclass.is_valid()
+
+ def test_missing_fc_informative_notes(self):
+ self.fclass.fc_informative_notes = None
+
+ with self.assertRaises(C5decError):
+ self.fclass.is_valid()
+
+ def test_invalid_fc_informative_notes(self):
+ mock_note = MagicMock(cct.ParaSequence())
+ mock_note.original_tag = "invalid-tag"
+ self.fclass.fc_informative_notes = mock_note
+
+ with self.assertRaises(C5decError):
+ self.fclass.is_valid()
+
+ def test_missing_children(self):
+ mock_intro = MagicMock(cct.ParaSequence())
+ mock_intro.original_tag = "fc-introduction"
+ self.fclass.fc_introduction = mock_intro
+ mock_note = MagicMock(cct.ParaSequence())
+ mock_note.original_tag = "fc-informative-notes"
+ self.fclass.fc_informative_notes = mock_note
+ self.fclass.children = []
+
+ with self.assertRaises(C5decError):
+ self.fclass.is_valid()
+
+ def test_invalid_children_type(self):
+ mock_intro = MagicMock(cct.ParaSequence())
+ mock_intro.original_tag = "fc-introduction"
+ self.fclass.fc_introduction = mock_intro
+ mock_note = MagicMock(cct.ParaSequence())
+ mock_note.original_tag = "fc-informative-notes"
+ self.fclass.fc_informative_notes = mock_note
+ self.fclass.children = ["InvalidChildType"]
+
+ with self.assertRaises(C5decError):
+ self.fclass.is_valid()
+
+class TestFClassBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.fclass_instance = cct.FClass(_id="ID001", _name="TestClass")
+ self.builder = cct.FClassBuilder(self.fclass_instance)
+
+ def test_initialization(self):
+ self.assertEqual(self.builder.instance, self.fclass_instance)
+
+ def test_initialization_wrong_instance_type(self):
+ with self.assertRaises(C5decError):
+ cct.FClassBuilder("NotAnFClassInstance")
+
+ @patch.object(cct.ParaSequence, 'build')
+ @patch.object(cct.FClass, '__setattr__')
+ def test_build_children_para_sequence_objects(self, mock_setattr, mock_build):
+ # Creating a dummy xml element
+ xml_string = 'Some Class Introduction.'
+ child = etree.fromstring(xml_string)
+
+ # Mocking the build method to return a dummy ParaSequence object
+ dummy_parasequence = cct.ParaSequence()
+ mock_build.return_value = dummy_parasequence
+
+ self.builder._build_children(child)
+
+ mock_build.assert_called_once_with(child, self.builder.instance)
+ mock_setattr.assert_called_once_with('fc_introduction', dummy_parasequence)
+ self.assertIn(dummy_parasequence, self.builder.instance.container)
+
+ @patch.object(cct.FFamilyBuilder, 'build')
+ def test_build_children_f_family(self, mock_build):
+ xml_string = ''
+ child = etree.fromstring(xml_string)
+
+ dummy_ffamily = cct.FFamily()
+ mock_build.return_value = dummy_ffamily
+
+ self.builder._build_children(child)
+
+ mock_build.assert_called_once_with(child, self.builder.instance)
+ self.assertIn(dummy_ffamily, self.builder.instance.children)
+
+
+
+if __name__ == "__main__":
+ unittest.main()
+
diff --git a/tests/cct_index_test.py b/tests/cct_index_test.py
new file mode 100644
index 0000000..a49686f
--- /dev/null
+++ b/tests/cct_index_test.py
@@ -0,0 +1,141 @@
+from unittest.mock import MagicMock
+from c5dec.core.cct import Index, BaseClass
+from c5dec.common import C5decError
+import unittest
+import sys
+import os
+# Add the parent directory to the sys.path so modules can be imported
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+
+# Average cyclomatic complexity is A (3.0366). Calculated with Radon.
+
+
+class TestBaseClass(BaseClass):
+ def is_valid(self):
+ pass # Implement the abstract method is_valid for testing
+
+
+class TestIndex(unittest.TestCase):
+
+ def setUp(self):
+ # Create an instance of the Index class
+ self.index = Index()
+
+ def test_update_and_get(self):
+ # Create objects for testing
+ obj1 = TestBaseClass(_id="obj1")
+ obj2 = TestBaseClass(_id="obj2")
+
+ # Update the index with objects
+ self.index.update("obj1", obj1)
+ self.index.update("obj2", obj2)
+
+ # Retrieve objects from the index and check if they match the originals
+ retrieved_obj1 = self.index.get("obj1")
+ retrieved_obj2 = self.index.get("obj2")
+
+ self.assertEqual(retrieved_obj1, obj1)
+ self.assertEqual(retrieved_obj2, obj2)
+
+ def test_update_and_get_keys(self):
+ obj1 = TestBaseClass(_id="obj1")
+ obj2 = TestBaseClass(_id="obj2")
+
+ # Update the index with objects
+ self.index.update("obj1", obj1)
+ self.index.update("obj2", obj2)
+
+ keys = self.index.keys()
+ self.assertEqual(list(keys), [obj1._id, obj2._id])
+
+ def test_update_non_unique(self):
+ # Create objects with non-unique IDs
+ obj1 = TestBaseClass(_id="duplicate_id")
+ obj2 = TestBaseClass(_id="duplicate_id")
+
+ # Update the index with the first object (should not raise an error)
+ self.index.update("duplicate_id", obj1)
+ size = len(self.index._index)
+
+ # Attempt to update the index with the second object (should raise a ValueError)
+ with self.assertRaises(C5decError):
+ self.index.update("duplicate_id", obj2)
+
+ # Update the index with the same initial object. No changes expected
+ self.index.update("duplicate_id", obj1)
+ self.assertEqual(size, len(self.index._index))
+
+ def test_get_nonexistent_key(self):
+ # Try to retrieve an object with a key that does not exist in the index
+ with self.assertRaises(KeyError):
+ retrieved_obj = self.index.get("nonexistent_key")
+
+ def test_yield_objects(self):
+ # define BaseClass subclasses
+ class SubClass1(BaseClass):
+ def is_valid(self):
+ pass
+
+ class SubClass2(BaseClass):
+ def is_valid(self):
+ pass
+
+ # initialize subclasses
+ sub1 = SubClass1(_id="sub1", _name="subclass1")
+ sub2 = SubClass1(_id="sub2", _name="subclass2")
+ sub3 = SubClass2(_id="sub3", _name="subclass3")
+
+ # update index
+ self.index.update(sub1._id, sub1)
+ self.index.update(sub2._id, sub2)
+ self.index.update(sub3._id, sub3)
+
+ # yield objects of type SubClass1
+ type1 = list(self.index.yield_obj(SubClass1))
+
+ self.assertEqual(type1, [sub1, sub2])
+
+ def test_clear(self):
+ # Create a mock object for BaseClass
+ obj = MagicMock(spec=BaseClass)
+ obj._id = "obj_to_clear" # Set necessary attributes for the mock object
+
+ # Update the index with the mock object
+ self.index.update("obj_to_clear", obj)
+
+ # Clear the index and check if it's empty
+ self.index.clear()
+ self.assertFalse(self.index.keys())
+
+ def test_update_with_different_types(self):
+ # Create objects with different types
+ int_key = 123
+ str_value = "string_value"
+
+ # Attempt to update the index with non-BaseClass objects (should raise a ValueError)
+ with self.assertRaises(C5decError):
+ self.index.update(int_key, str_value)
+
+ def test_update_with_subclass_of_BaseClass(self):
+ # Create a subclass of BaseClass
+ class SubClass(BaseClass):
+ def is_valid(self):
+ pass
+
+ # Create an object of the subclass
+ obj = SubClass(_id="subclass_obj")
+
+ # Update the index with the subclass object (should not raise an error)
+ self.index.update("subclass_obj", obj)
+
+ # Retrieve the object from the index and check if it matches the original
+ retrieved_obj = self.index.get("subclass_obj")
+ self.assertEqual(retrieved_obj, obj)
+
+ def tearDown(self):
+ self.index.clear()
+
+if __name__ == '__main__':
+ unittest.main()
+
diff --git a/tests/cct_methods_tests.py b/tests/cct_methods_tests.py
new file mode 100644
index 0000000..c2e435b
--- /dev/null
+++ b/tests/cct_methods_tests.py
@@ -0,0 +1,199 @@
+import unittest
+from unittest.mock import MagicMock, patch, call
+import sys
+import os
+# Add the parent directory to the sys.path so modules can be imported
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+from lxml import etree
+import c5dec.core.cct as cct
+
+os.chdir(parent_dir + "/c5dec")
+
+class TestCheckHierarchical(unittest.TestCase):
+
+ def setUp(self):
+ componentA = MagicMock(cct.AComponent(_id="compA_id", _name="compA_name"))
+ # set a mock return value for the function get_hierarchical_tree
+ componentA.get_hierarchical_tree.return_value = ["compb_id"]
+ cct.Index.update("compA_id", componentA)
+ componentB = MagicMock(cct.AComponent(_id="compB_id", _name="compB_name"))
+ componentB.get_hierarchical_tree.return_value = []
+ cct.Index.update("compB_id", componentB)
+ componentC = MagicMock(cct.AComponent(_id="compC_id", _name="compC_name"))
+ componentC.get_hierarchical_tree.return_value = ["compa_id", "compb_id"]
+ cct.Index.update("compC_id", componentC)
+ componentD = MagicMock(cct.AComponent(_id="compD_id", _name="compD_name"))
+ componentD.get_hierarchical_tree.return_value = []
+ cct.Index.update("compD_id", componentD)
+
+ def test_check_hierarchical(self):
+ component_ids = set(['compa_id', 'compd_id'])
+ is_valid = cct.check_hierarchical('compa_id', component_ids)
+ self.assertFalse(is_valid)
+
+ def test_check_hierarchical_redundant(self):
+ component_ids = set(['compa_id', 'compb_id'])
+ is_valid = cct.check_hierarchical('compa_id', component_ids)
+ self.assertTrue(is_valid)
+
+ def test_check_hierarchical_redundant_inverted(self):
+ component_ids = set(['compa_id', 'compb_id'])
+ is_valid = cct.check_hierarchical('compb_id', component_ids, inverted=True)
+ self.assertTrue(is_valid)
+
+ def test_check_hierarchical_redundant_non_adjecent(self):
+ # tests if cases like CompC > CompA > CompB are correctly detected.
+ component_ids = set(['compc_id', 'compb_id'])
+ is_valid = cct.check_hierarchical('compc_id', component_ids)
+ self.assertTrue(is_valid)
+
+ def test_check_hierarchical_redundant_non_adjecent_inverted(self):
+ # tests if cases like CompC > CompA > CompB are correctly detected.
+ component_ids = set(['compc_id', 'compb_id'])
+ is_valid = cct.check_hierarchical('compb_id', component_ids, inverted=True)
+ self.assertTrue(is_valid)
+
+ def tearDown(self):
+ cct.Index.clear()
+
+class TestCheckDependencies(unittest.TestCase):
+
+ def setUp(self):
+ # set up components
+ componentA = MagicMock(cct.AComponent(_id="compA_id", _name="compA_name"))
+ componentA.get_dependency_pool.return_value = ["compb_id"]
+ cct.Index.update("compA_id", componentA)
+ componentB = MagicMock(cct.AComponent(_id="compB_id", _name="compB_name"))
+ componentB.get_dependency_pool.return_value = []
+ cct.Index.update("compB_id", componentB)
+ componentC = MagicMock(cct.AComponent(_id="compC_id", _name="compC_name"))
+ componentC.get_dependency_pool.return_value = [("compa_id", "compb_id")]
+ cct.Index.update("compC_id", componentC)
+ componentD = MagicMock(cct.AComponent(_id="compD_id", _name="compD_name"))
+ componentD.get_dependency_pool.return_value = []
+ cct.Index.update("compD_id", componentD)
+
+ def test_check_dependencies(self):
+ # valid set
+ component_ids = set(['compa_id', 'compb_id'])
+ is_valid = cct.check_dependencies('compa_id', component_ids)
+ self.assertFalse(is_valid)
+
+ def test_check_dependencies_invalid(self):
+ component_ids = set(['compa_id'])
+ is_valid = cct.check_dependencies('compa_id', component_ids)
+ self.assertTrue(is_valid)
+
+ def test_valid_or_dependencies(self):
+ component_ids_1 = set(['compc_id', 'compa_id', 'compb_id'])
+ component_ids_2 = set(['compc_id', 'compb_id'])
+
+ is_valid_1 = cct.check_dependencies('compc_id', component_ids_1)
+ is_valid_2 = cct.check_dependencies('compc_id', component_ids_2)
+
+ self.assertTrue(all([not is_valid_1, not is_valid_2]))
+
+ @patch.object(cct, 'check_hierarchical')
+ def test_check_hierarchical_dependencies(self, mock_check_h):
+ # CompD hierarchical to compB
+ mock_check_h.return_value = True
+ component_ids = set(["compa_id", "compd_id"])
+ is_valid = cct.check_dependencies('compa_id', component_ids)
+ self.assertFalse(is_valid)
+
+ def test_check_hierarchical_or_dependecies(self):
+ # same logic as before no need for additional unit test
+ pass
+
+ def tearDown(self):
+ cct.Index.clear()
+
+class TestValidateDependencies(unittest.TestCase):
+
+ def setUp(self):
+ componentA = MagicMock(cct.AComponent(_id="compA_id", _name="compA_name"))
+ componentA.get_dependency_pool.return_value = ["compb_id"]
+ componentA.get_hierarchical_tree.return_value = []
+ cct.Index.update("compA_id", componentA)
+ componentB = MagicMock(cct.AComponent(_id="compB_id", _name="compB_name"))
+ componentB.get_dependency_pool.return_value = []
+ componentB.get_hierarchical_tree.return_value = []
+ cct.Index.update("compB_id", componentB)
+ componentC = MagicMock(cct.AComponent(_id="compC_id", _name="compC_name"))
+ componentC.get_dependency_pool.return_value = [("compa_id", "compd_id")]
+ componentC.get_hierarchical_tree.return_value = []
+ cct.Index.update("compC_id", componentC)
+ componentD = MagicMock(cct.AComponent(_id="compD_id", _name="compD_name"))
+ componentD.get_dependency_pool.return_value = []
+ componentD.get_hierarchical_tree.return_value = ["compb_id"]
+ cct.Index.update("compD_id", componentD)
+
+ def test_validate_dependencies_valid_set(self):
+ component_ids = set(["compa_id", "compb_id"])
+ is_valid, valid_set = cct.validate_dependencies(component_ids)
+ self.assertTrue(is_valid)
+ self.assertEqual(valid_set, component_ids)
+
+ def test_validate_dependencies_invalid_set(self):
+ component_ids = set(["compa_id"])
+ is_valid, valid_set = cct.validate_dependencies(component_ids)
+ self.assertFalse(is_valid)
+ self.assertEqual(valid_set, set(["compa_id", "compb_id"]))
+
+ def test_validate_dependencies_redundante_set(self):
+ component_ids = set(["compd_id", "compb_id"])
+ is_valid, valid_set = cct.validate_dependencies(component_ids)
+ self.assertFalse(is_valid)
+ self.assertEqual(valid_set, set(["compd_id"]))
+
+ def test_validate_dependencies_hierarchical_dependency(self):
+ component_ids = set(["compa_id", "compd_id"])
+ is_valid, valid_set = cct.validate_dependencies(component_ids)
+ self.assertTrue(is_valid)
+ self.assertEqual(valid_set, component_ids)
+
+ def test_validate_dependencies_non_adjacent_hierarchy(self):
+ componentE = MagicMock(cct.AComponent(_id="compE_id", _name="compE_name"))
+ componentE.get_dependency_pool.return_value = []
+ componentE.get_hierarchical_tree.return_value = ["compd_id", "compb_id"]
+ cct.Index.update("compE_id", componentE)
+
+ component_ids = set(["compe_id", "compb_id"])
+ is_valid, valid_set = cct.validate_dependencies(component_ids)
+ self.assertFalse(is_valid)
+ self.assertEqual(valid_set, set(["compe_id"]))
+
+ def tearDown(self):
+ cct.Index.clear()
+
+class TestEvalIndexOperations(unittest.TestCase):
+
+ def setUp(self):
+
+
+ @mock.patch("builtins.open", new_callable=mock.mock_open)
+ def test_save_index(self, mock_open):
+ index = {'key': 'value'}
+ save_index(index, '/path/to')
+ mock_open.assert_called_once_with('/path/to/index.json', 'w')
+ mock_open().write.assert_called_once_with(json.dumps(index, indent=4))
+
+ @mock.patch("builtins.open", new_callable=mock.mock_open, read_data=json.dumps({'key': 'value'}))
+ def test_load_index(self, mock_open):
+ expected_index = {'key': 'value'}
+ index = load_index('/path/to')
+ mock_open.assert_called_once_with('/path/to/index.json', 'r')
+ self.assertEqual(index, expected_index)
+
+if __name__ == '__main__':
+ unittest.main()
+
+"""TODO
+- doorstop Index methods
+- create eval checklist methods
+- climethods
+"""
+
+if __name__ == '__main__':
+ unittest.main()
diff --git a/tests/cct_operation_test.py b/tests/cct_operation_test.py
new file mode 100644
index 0000000..bf1f535
--- /dev/null
+++ b/tests/cct_operation_test.py
@@ -0,0 +1,117 @@
+import unittest
+from unittest.mock import MagicMock, patch, call
+import sys
+import os
+# Add the parent directory to the sys.path so modules can be imported
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+
+from lxml import etree
+from c5dec.core.cct import Operation, OperationBuilder, FEItem, FEItemBuilder, FEList, FEListBuilder, \
+AElement, FElement, ParaSequence
+from c5dec.common import C5decError
+
+class TestOperation(unittest.TestCase):
+
+ def setUp(self):
+ self.functional_operation = Operation(_id='func1', op_type='selection', exclusive='NO')
+ self.functional_operation.parent = MagicMock(FElement(_id="func_el_id"))
+ self.assurance_operation = Operation(_id='ass1', op_type='selection')
+ self.assurance_operation.parent = MagicMock(AElement(_id="ass_el_id", el_type="developer"))
+
+ def test_init(self):
+ self.assertEqual(self.functional_operation._id, 'func1')
+ self.assertEqual(self.functional_operation.type, 'selection')
+ self.assertEqual(self.functional_operation.exclusive, 'NO')
+
+ def test_is_valid_with_valid_functional_operation(self):
+ # Valid functional operation containes FEItems
+ mock_item = MagicMock(FEItem())
+ self.functional_operation.item = [mock_item]
+ self.assertTrue(self.functional_operation.is_valid())
+
+ def test_is_valid_with_valid_assurance_operation(self):
+ # As per the provided method, this should return True without raising an exception.
+ self.assertTrue(self.assurance_operation.is_valid())
+
+ def test_is_valid_with_invalid_type(self):
+ self.functional_operation.type = 'invalid_type'
+ with self.assertRaises(C5decError) as context:
+ self.functional_operation.is_valid()
+ self.assertIn("invalid.", str(context.exception))
+
+ def test_is_valid_with_invalid_functional_operation(self):
+ with self.assertRaises(C5decError) as context:
+ self.functional_operation.is_valid()
+ self.assertIn("Operation must contain", str(context.exception))
+
+
+class TestOperationBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.operation = Operation()
+ self.builder = OperationBuilder(self.operation)
+
+ def test_invalid_instance_type_raises_value_error(self):
+ with self.assertRaises(C5decError):
+ OperationBuilder("invalid_instance")
+
+ def test_build_attributes(self):
+ xml_string = ''
+ node = etree.fromstring(xml_string)
+
+ self.builder._build_attributes(node)
+
+ self.assertEqual(self.operation._id, "123")
+ self.assertEqual(self.operation.exclusive, "NO")
+
+ def test_build_children_fe_assignmentitem(self):
+ xml_string = ''
+ node = etree.fromstring(xml_string)
+
+ with patch.object(FEItemBuilder, 'build', return_value=FEItem()) as mock_build:
+ self.builder._build_children(node[0])
+
+ mock_build.assert_called_once()
+ self.assertIsInstance(self.operation.item[0], FEItem)
+ self.assertIsInstance(self.operation.container[0], FEItem)
+
+ def test_build_children_fe_assignmentnotes(self):
+ xml_string = ''
+ node = etree.fromstring(xml_string)
+
+ with patch.object(ParaSequence, 'build', return_value=ParaSequence()) as mock_build:
+ self.builder._build_children(node[0])
+
+ mock_build.assert_called_once()
+ self.assertIsInstance(self.operation.note, ParaSequence)
+ self.assertIsInstance(self.operation.container[0], ParaSequence)
+
+ def test_build_children_fe_list(self):
+ xml_string = ''
+ node = etree.fromstring(xml_string)
+
+ with patch.object(FEListBuilder, 'build', return_value=FEList()) as mock_build:
+ self.builder._build_children(node[0])
+
+ mock_build.assert_called_once()
+ self.assertIsInstance(self.operation.container[0], FEList)
+
+ def test_build(self):
+ xml_string = ''
+ node = etree.fromstring(xml_string)
+
+ self.builder._build_attributes = MagicMock()
+ self.builder._build_children = MagicMock()
+ self.operation.is_valid = MagicMock()
+
+ result = self.builder.build(node)
+
+ self.builder._build_attributes.assert_called_once_with(node, None)
+ self.builder._build_children.assert_called_once_with(node[0])
+ self.operation.is_valid.assert_called_once()
+ self.assertEqual(result, self.operation)
+
+
+if __name__ == "__main__":
+ unittest.main()
diff --git a/tests/cct_pacakge_test.py b/tests/cct_pacakge_test.py
new file mode 100644
index 0000000..4e8dddb
--- /dev/null
+++ b/tests/cct_pacakge_test.py
@@ -0,0 +1,279 @@
+import unittest
+from unittest.mock import MagicMock, patch
+import sys
+import os
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+
+from lxml import etree
+from c5dec.core.cct import Package, PackageBuilder, AComponent, FComponent, ParaSequence, Index
+from c5dec.common import C5decError
+
+
+XML_STRING_EAL = '''
+
+
+
+ EAL2 requires the co-operation of the developer in terms of
+ the delivery of design information and test results, but
+ should not demand more effort on the part of the developer
+ than is consistent with good commercial practise. As such it
+ should not require a substantially increased investment of
+ cost or time.
+
+ EAL2 is therefore applicable in those circumstances where
+ developers or users require a low to moderate level of
+ independently assured security in the absence of ready
+ availability of the complete development record. Such a
+ situation may arise when securing legacy systems, or where
+ access to the developer may be limited.
+
+
+
+ EAL2 provides assurance by a full security target and an
+ analysis of the SFRs in that ST, using a functional and
+ interface specification, guidance documentation and a basic
+ description of the architecture of the TOE, to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the TSF,
+ evidence of developer testing based on the functional
+ specification, selective independent confirmation of the
+ developer test results, and a vulnerability analysis (based
+ upon the functional specification, TOE design, security architecture
+ description and guidance evidence provided) demonstrating
+ resistance to penetration attackers with a basic attack
+ potential.
+
+ EAL2 also provides assurance through use of a configuration
+ management system and evidence of secure delivery
+ procedures.
+
+ This EAL represents a meaningful increase in assurance from
+ EAL1 by requiring developer testing, a vulnerability analysis
+ (in addition to the search of the public domain), and
+ independent testing based upon more detailed TOE
+ specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+'''
+
+XML_STRING_CAP = '''
+
+
+
+ CAP-B permits a conscientious developer to gain maximum
+ assurance from understanding, at a subsystem level, the
+ affects of interactions between component TOEs integrated in
+ the composed TOE, whilst minimising the demand of involvement
+ of the base component developer.
+
+ CAP-B is applicable in those circumstances where developers or
+ users require a moderate level of independently assured
+ security, and require a thorough investigation of the composed
+ TOE and its development without substantial
+ re-engineering.
+
+
+
+ CAP-B provides assurance by analysis of a full security target
+ for the composed TOE. The SFRs in the composed TOE ST are
+ analysed using the outputs from the evaluations of the
+ component TOEs (e.g. ST, guidance documentation), a
+ specification for the interfaces between the component TOEs
+ and the TOE design (describing TSF subsystems) contained in
+ the composed development information to understand the
+ security behaviour.
+
+ The analysis is supported by independent testing of the
+ interfaces of the base component that are relied upon by the
+ dependent component, as described in the reliance information
+ (now also including TOE design), evidence of developer testing
+ based on the reliance information, development information and
+ composition rationale, and selective independent confirmation
+ of the developer test results. The analysis is also supported
+ by a vulnerability analysis of the composed TOE by the
+ evaluator demonstrating resistance to attackers with basic
+ attack potential.
+
+ This CAP represents a meaningful increase in assurance from
+ CAP-A by requiring more complete testing coverage of the
+ security functionality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+'''
+
+class TestPackage(unittest.TestCase):
+
+
+ def setUp(self):
+ self.package = Package(_id="Pkg1", _name="Pkg_name")
+ self.package.acronym = "Pkg"
+ self.package.objectives = MagicMock(ParaSequence())
+ self.package.assurance_components = MagicMock(ParaSequence())
+ pkg_comp = MagicMock(AComponent(_id="comp_id", _name="comp"))
+ Index.update(pkg_comp._id, pkg_comp)
+ self.package.children = [pkg_comp]
+
+
+ def test_is_valid_success(self):
+ self.assertTrue(self.package.is_valid())
+
+ def test_multiple_child_types_raises_error(self):
+ self.package.children.append("InvalidCompID")
+ with self.assertRaises(C5decError):
+ self.package.is_valid()
+
+ def test_non_uniform_components_raises_error(self):
+ fcomp = MagicMock(FComponent(_id="fcomp1", _name="fcomp"))
+ acomp = MagicMock(AComponent(_id="acomp1", _name="acomp"))
+ Index.update(fcomp._id, fcomp)
+ Index.update(acomp._id, acomp)
+ self.package.children = [fcomp, acomp]
+
+ with self.assertRaises(C5decError):
+ self.package.is_valid()
+
+ def test_non_component_type_raises_error(self):
+ # tests that children/components must be of type AComponent or FComponent
+ para = MagicMock(ParaSequence())
+ para._id = "para_id"
+ Index.update(para._id, para)
+ self.package.children = [para]
+
+ with self.assertRaises(C5decError):
+ self.package.is_valid()
+
+ def test_non_correspondant_id_raises_error(self):
+ # tests that string input must correspond to AComponent or FComponent obj.
+ para = MagicMock(ParaSequence())
+ para._id = "NotComponentID"
+ Index.update(para._id, para)
+ self.package.children = ["NotComponentID"]
+
+ with self.assertRaises(C5decError):
+ self.package.is_valid()
+
+ def test_not_updated_index_raises_error(self):
+ acomp = MagicMock(AComponent(_id="NotUpdatedId", _name="comp1"))
+ self.package.children = [acomp]
+
+ with self.assertRaises(C5decError):
+ self.package.is_valid()
+
+ def test_missing_objectives_raises_error(self):
+ self.package.objectives = None
+ with self.assertRaises(C5decError):
+ self.package.is_valid()
+
+ def test_missing_assurance_components_raises_error(self):
+ self.package.assurance_components = None
+ with self.assertRaises(C5decError):
+ self.package.is_valid()
+
+ def tearDown(self):
+ Index.clear()
+
+
+class TestPackageBuilder(unittest.TestCase):
+
+ def setUp(self):
+ self.package = Package(_id="Pkg1", _name="Pkg_name")
+ self.package.acronym = "Pkg"
+ self.builder = PackageBuilder(self.package)
+
+ def test_initialization(self):
+ self.assertIsInstance(self.builder.instance, Package)
+
+ def test_initialization_wrong_instance_type(self):
+ with self.assertRaises(C5decError):
+ PackageBuilder("INVALIDELEMENT")
+
+ def test_build_attributes(self):
+ xml_string = '''
+
+ Package Content.
+
+ '''
+ parent_obj = MagicMock()
+ node = etree.fromstring(xml_string)
+
+ self.builder._build_attributes(node, parent_obj=parent_obj)
+
+ self.assertEqual(self.package._id, "pkg2")
+ self.assertEqual(self.package._name, "pkg_name")
+ self.assertEqual(self.package.acronym, "pkg")
+ self.assertEqual(self.package.parent, parent_obj)
+
+ @patch.object(ParaSequence, "build")
+ def test_build_children_parasequence(self, mock_parasequence_build):
+ xml_string = '''
+
+
+ Objectives.
+
+
+ Assurance Components.
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ mocked_parasequence = []
+ for child in node:
+ self.builder._build_children(child)
+ mocked_parasequence.append(mock_parasequence_build(child))
+
+ self.assertEqual(mocked_parasequence, self.package.container)
+
+ def test_build_children_component(self):
+ xml_string = '''
+
+
+
+
+ '''
+ node = etree.fromstring(xml_string)
+ for child in node:
+ self.builder._build_children(child)
+
+ self.assertEqual(self.package.children, ["Comp_Id", "Comp_Id1"])
+
+
+
+if __name__ == "__main__":
+ unittest.main()
\ No newline at end of file
diff --git a/tests/cct_uidmanager_test.py b/tests/cct_uidmanager_test.py
new file mode 100644
index 0000000..970a77b
--- /dev/null
+++ b/tests/cct_uidmanager_test.py
@@ -0,0 +1,111 @@
+import unittest
+from unittest.mock import MagicMock
+import sys
+import os
+# Add the parent directory to the sys.path so modules can be imported
+parent_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
+sys.path.append(parent_dir)
+
+from c5dec.core.cct import UniqueIDManager # Replace 'your_module' with the actual module name
+from c5dec.common import C5decError
+
+class TestUniqueIDManager(unittest.TestCase):
+
+ def setUp(self):
+ """Set up test environment with a custom separator and count width."""
+ self.uid_manager = UniqueIDManager(separator='-', count_width=3)
+
+ def test_get_next_id(self):
+ """Test generating unique IDs with the specified separator and count width."""
+ id1 = self.uid_manager.next("prefix")
+ id2 = self.uid_manager.next("prefix")
+ id3 = self.uid_manager.next("another_prefix")
+
+ self.assertEqual(id1, "prefix-001")
+ self.assertEqual(id2, "prefix-002")
+ self.assertEqual(id3, "another_prefix-001")
+
+ def test_singleton_property(self):
+ """Ensure only one UniqueIDManager instance exists at a time."""
+ uid_manager1 = UniqueIDManager()
+ uid_manager2 = UniqueIDManager()
+ self.assertIs(uid_manager1, uid_manager2)
+
+ def test_custom_config_update(self):
+ """Verify that configuration can be updated on subsequent instantiations."""
+ uid_manager = UniqueIDManager(separator="p", count_width=4)
+ uid = uid_manager.next("test")
+ self.assertEqual(uid, "testp0001")
+
+ # Update the configuration.
+ uid_manager = UniqueIDManager(separator="-", count_width=2)
+ uid = uid_manager.next("test")
+ self.assertEqual(uid, "test-02")
+
+ def test_configurabilty(self):
+ """Check that separator and count_width can be configured."""
+ UniqueIDManager.reset()
+ uid_manager = UniqueIDManager(separator="@", count_width=4)
+ uid = uid_manager.next("PreFix")
+ self.assertEqual(uid, "PreFix@0001")
+
+ def test_counter_reset(self):
+ """Ensure counters reset after the UniqueIDManager instance is reset."""
+ self.uid_manager.next("prefix")
+ UniqueIDManager.reset()
+ new_uid_manager = UniqueIDManager()
+ uid = new_uid_manager.next("prefix")
+ self.assertEqual(uid, "prefix-1")
+
+ def test_prefix_isolation(self):
+ """Ensure counters for different prefixes do not overlap."""
+ self.uid_manager.next("prefixA")
+ uid = self.uid_manager.next("prefixB")
+ self.assertEqual(uid, "prefixB-001")
+
+ def test_reset(self):
+ """Verify instances before and after reset are different."""
+ uid_manager = UniqueIDManager()
+ UniqueIDManager.reset()
+ new_uid_manager = UniqueIDManager()
+ self.assertIsNot(uid_manager, new_uid_manager)
+
+ def test_boundary(self):
+ """Test boundary condition for unique ID generation."""
+ for _ in range(999):
+ self.uid_manager.next("prefix")
+ uid = self.uid_manager.next("prefix")
+ self.assertEqual(uid, "prefix-1000")
+
+ def test_invalid_separator(self):
+ with self.assertRaises(C5decError):
+ UniqueIDManager(separator='invalid') # Ex: a separator longer than one character
+
+ def test_negative_count_width(self):
+ with self.assertRaises(C5decError):
+ UniqueIDManager(count_width=-1)
+
+ def test_non_integer_count_width(self):
+ with self.assertRaises(C5decError):
+ UniqueIDManager(count_width="a")
+
+ def test_maximum_count_width(self):
+ # This isn't a true edge case since there isn't a defined max width.
+ # However, it tests a large count width for demonstrative purposes.
+ uid_manager = UniqueIDManager(count_width=10)
+ uid = uid_manager.next("prefix")
+ self.assertEqual(uid, "prefix-0000000001")
+
+ def test_minimum_count_width(self):
+ uid_manager = UniqueIDManager(count_width=1)
+ uid = uid_manager.next("prefix")
+ self.assertEqual(uid, "prefix-1")
+
+ def tearDown(self):
+ """Clean up after each test by resetting the UniqueIDManager instance."""
+ UniqueIDManager.reset()
+
+if __name__ == '__main__':
+ unittest.main()
+
+
diff --git a/tests/content/acronyms/persons.json b/tests/content/acronyms/persons.json
new file mode 100644
index 0000000..fe08508
--- /dev/null
+++ b/tests/content/acronyms/persons.json
@@ -0,0 +1,7 @@
+{
+ "Alan Turing": "ATU",
+ "John von Neumann": "JVN",
+ "Pierre de Fermat": "PDF",
+ "Andrew Wiles": "AWI",
+ "Mathematicians": "MAT"
+}
\ No newline at end of file
diff --git a/tests/content/c5dec-isms-test/DocumentList.xlsx b/tests/content/c5dec-isms-test/DocumentList.xlsx
new file mode 100644
index 0000000..ff2195a
Binary files /dev/null and b/tests/content/c5dec-isms-test/DocumentList.xlsx differ
diff --git a/tests/content/c5dec-isms-test/Subfolder/subsubfolder/test-file_v1.1-dqw.txt b/tests/content/c5dec-isms-test/Subfolder/subsubfolder/test-file_v1.1-dqw.txt
new file mode 100644
index 0000000..e69de29
diff --git a/tests/content/c5dec-isms-test/Subfolder/test-file_v2.0-ega.txt b/tests/content/c5dec-isms-test/Subfolder/test-file_v2.0-ega.txt
new file mode 100644
index 0000000..e69de29
diff --git a/tests/content/c5dec-isms-test/tag-processing-test-file.docx b/tests/content/c5dec-isms-test/tag-processing-test-file.docx
new file mode 100644
index 0000000..987a046
Binary files /dev/null and b/tests/content/c5dec-isms-test/tag-processing-test-file.docx differ
diff --git a/tests/content/c5dec-isms-test/tag-to-link-mapping.csv b/tests/content/c5dec-isms-test/tag-to-link-mapping.csv
new file mode 100644
index 0000000..f874651
--- /dev/null
+++ b/tests/content/c5dec-isms-test/tag-to-link-mapping.csv
@@ -0,0 +1,4 @@
+#S-1-4-S,https://www.google.com/
+#S-32-12-B,https://www.msn.com/
+#S-5-9-C,https://atlassian.iee.lu/confluence/pages/viewpage.action?pageId=59999192
+#S-63-94-H,https://wikipedia.org
diff --git a/tests/content/c5dec-isms-test/test-file_v0.6-pfe.txt b/tests/content/c5dec-isms-test/test-file_v0.6-pfe.txt
new file mode 100644
index 0000000..e69de29
diff --git a/tests/content/c5dec-isms-test/test-file_v1.1-cfg.txt b/tests/content/c5dec-isms-test/test-file_v1.1-cfg.txt
new file mode 100644
index 0000000..e69de29
diff --git a/tests/content/c5dec-isms-test/test-file_v7.1-mbe.txt b/tests/content/c5dec-isms-test/test-file_v7.1-mbe.txt
new file mode 100644
index 0000000..e69de29
diff --git a/tests/content/openproject_params.csv b/tests/content/openproject_params.csv
new file mode 100644
index 0000000..6127ab6
--- /dev/null
+++ b/tests/content/openproject_params.csv
@@ -0,0 +1,2 @@
+WP,Domain,Type
+C5-DEC,CyFORT,RD
\ No newline at end of file
diff --git a/tests/content/translations/translations.de.json b/tests/content/translations/translations.de.json
new file mode 100644
index 0000000..3d9b22e
--- /dev/null
+++ b/tests/content/translations/translations.de.json
@@ -0,0 +1,97 @@
+{
+ "_comment1": "template",
+ "Back": "Zurück",
+ "Quit": "Verlassen",
+ "Template": "Vorlage",
+
+ "_comment2": "Builder",
+ "filepath": "Dateipfad",
+ "copy to clipboard": "in Zwischenablage kopieren",
+ "Result": "Ergebnis",
+ "no entries found": "keine Einträge gefunden",
+ "Status bar": "Statusleiste",
+
+ "_comment3": "Generate hash",
+ "Hash Generator": "Hash Generator",
+ "Algorithms": "Algorithmen",
+ "Shake length": "Shake Länge",
+ "Save to file?": "In Datei speichern?",
+ "Calculate": "Berechnen",
+ "The path to F_0 is invalid": "Der Dateipfad zu F_0 ist ungültig",
+ "The path to F_1 is invalid": "Der Dateipfad zu F_0 ist ungültig",
+ "An algorithm has to be chosen": "Ein Algorithmus muss ausgewählt werden",
+ "invalid shake length": "Ungültige Shake Länge",
+ "Hash successfully saved": "Hash erfolgreich gespeichert",
+
+ "_comment4": "Compare hash",
+ "Compare": "Vergleichen",
+ "The hash values are matching": "Die Hashwerte stimmen überein",
+ "The hash values are different": "Die Hashwerte sind unterschiedlich",
+ "The path to H_0 is invalid": "Der Dateipfad zu H_0 ist ungültig",
+ "The path to H_1 is invalid": "Der Dateipfad zu H_1 ist ungültig",
+ "file": "Datei",
+ "hash value": "Hashwert",
+
+
+ "_comment5": "Digital signatures",
+ "Digital signatures": "Digitale Signaturen",
+ "sign": "signieren",
+ "verify": "verifizieren",
+ "Secret key": "Privater Schlüssel",
+ "Public key": "Öffen. Schlüssel",
+ "generate keys": "Schlüssel generieren",
+ "The computation started, please wait": "Die Berechnung ist gestartet, bitten warten",
+ "Signed": "Signiert",
+ "The key is invalid": "Der Schlüssel ist ungültig",
+ "The file could not be found": "Die Datei konnte nicht gefunden werden",
+ "Signature is correct": "Die Signatur ist korrekt",
+ "Signature was forged or corrupt": "Die Signatur wurde bearbeitet oder beschädigt",
+
+ "_comment6": "Filename validator",
+ "folder/ file": "Ordner/ Datei",
+ "Validate": "Validieren",
+ "Number of files:": "Anzahl der Dateien",
+ "Number of invalid names:": "Anzahl ungültiger Namen",
+
+ "_comment7": "Filename generator",
+ "other document": "anderes Dokument",
+ "Add a date?": "Ein Datum hinzufügen?",
+ "Add an author?": "Einen Autor hinzufügen?",
+ "year": "Jahr",
+ "month": "Monat",
+ "day": "Tag",
+ "Documenttype": "Dokumententyp",
+ "Document title Acronym": "Dokumentnamenacronym",
+ "Invalid entries: ": "Ungültige Eingaben: ",
+ "Subdomaincode (number)": "Subdomaincode (Zahl)",
+ "Addition": "Addition (Buchstabe)",
+ "Entity acronym (capitalized)": "Entity Acronym (kapitalisiert)",
+ "Title acronym (capitalized)": "Title acronym (kapitalisiert)",
+ "Date": "Datum",
+
+ "_comment8": "activity report",
+ "The path to the folder is invalid": "Der Ordnerpfad ist ungültig",
+ "User": "Benutzer",
+ "File": "Datei",
+ "Event": "Aktivität",
+ "Save as csv?": "Als CSV speichern?",
+ "months": "Monate",
+ "days": "Tage",
+ "hours": "Stunden",
+ "Author": "Autor",
+ "Save to": "Speichern in",
+ "Folder": "Ordner",
+ "List": "Auflisten",
+ "all": "alle",
+ "The path to the CSV file is invalid": "Der Pfad zur CSV Datei ist ungültig",
+ "file successfully saved": "Datei erfolgreich gespeichert",
+
+ "_comment9": "main",
+ "Cryptography": "Kryptographie",
+ "Compare hashes": "Hashes vergleichen",
+ "Generate hash": "Hash generieren",
+ "Document Management": "Dokumentverwaltung",
+ "Filename Validation": "Dateinamenvalidierung",
+ "Filename Generator": "Dateinamen generieren",
+ "Activity Report": "Aktivitätenbericht"
+}
\ No newline at end of file
diff --git a/tests/content/translations/translations.en.json b/tests/content/translations/translations.en.json
new file mode 100644
index 0000000..0e0dcd2
--- /dev/null
+++ b/tests/content/translations/translations.en.json
@@ -0,0 +1,3 @@
+{
+
+}
\ No newline at end of file
diff --git a/tests/content/translations/translations.fr.json b/tests/content/translations/translations.fr.json
new file mode 100644
index 0000000..cf7b342
--- /dev/null
+++ b/tests/content/translations/translations.fr.json
@@ -0,0 +1,54 @@
+{
+ "_comment1": "template",
+ "Back": "Retour",
+ "Quit": "Fermer",
+ "Template": "",
+
+ "_comment2": "Builder",
+ "filepath": "Chemin du fichier",
+ "copy to clipboard": "Copier dans le presse-papiers",
+ "Result": "résultat",
+ "no entries found": "Aucune entrée trouvée",
+ "Status bar": "Barre d'état",
+
+ "_comment3": "Generate hash",
+ "Hash Generator": "",
+ "Algorithms": "algorithmes",
+ "Shake length": "longueur du shake",
+ "Save to file?": "Enregistrer dans un fichier?",
+ "Calculate": "Calculer",
+ "The path to F_0 is invalid": "Le chemin vers F_0 n'est pas valide",
+ "The path to F_1 is invalid": "Le chemin vers F_1 n'est pas valide",
+ "An algorithm has to be chosen": "Un algorithme doit être choisi",
+ "invalid shake length": "longueur de shake non valide",
+ "Hash successfully saved": "Hachage enregistré avec succès",
+
+ "_comment4": "Compare hash",
+ "Compare": "Comparer",
+ "The hash values are matching": "Les valeurs de hachage correspondent",
+ "The hash values are different": "Les valeurs de hachage sont différentes",
+ "The path to H_0 is invalid": "Le chemin vers H_0 n'est pas valide",
+ "The path to H_1 is invalid": "Le chemin vers H_1 n'est pas valide",
+ "file": "fichier",
+ "hash value": "valeur de hash",
+
+
+ "_comment5": "Digital signatures",
+ "Digital signatures": "Signatures numériques",
+ "sign": "signer",
+ "verify": "vérifier",
+ "Secret key": "clé secrète",
+ "Public key": "clé publique",
+ "generate keys": "générer des clés",
+ "The computation started, please wait": "Le calcul est lancé, veuillez patienter",
+ "Signed": "Signé",
+ "The key is invalid": "la clé n'est pas valide",
+ "The file could not be found": "Le fichier n'a pas pu être trouvé",
+ "Signature is correct": "La signature est correcte",
+ "Signature was forged or corrupt": "signature a été falsifiée ou corrompue",
+
+ "_comment6": "main",
+ "Cryptography": "Cryptographie",
+ "Compare hashes": "Comparer les hachages",
+ "Generate hash": "Générer un hachage"
+}
\ No newline at end of file
diff --git a/tests/menu_tests.py b/tests/menu_tests.py
new file mode 100644
index 0000000..1325b52
--- /dev/null
+++ b/tests/menu_tests.py
@@ -0,0 +1,56 @@
+from c5dec.frontend.tui.foundation.menu import Menu
+import unittest
+
+
+class MenuTest(unittest.TestCase):
+ def test_add_function(self):
+ a.add_function("f1", test_function)
+ self.assertTrue("f1" in a.functions.keys())
+ self.assertTrue(test_function in a.functions.values())
+
+ def test_add_menu(self):
+ a.add_menu("A")
+ self.assertTrue("A" in a.submenus.keys())
+ self.assertTrue(isinstance(a.submenus["A"], Menu))
+ self.assertEqual(a.submenus["A"].name, "A")
+
+ def test_get_submenu(self):
+ self.assertEqual(
+ a.get_submenu("A"),
+ list(a.submenus.values())[0]
+ )
+ self.assertTrue(isinstance(a.get_submenu("A"), Menu))
+
+ def test_get_nested_submenu(self):
+ a.add_menu("B")
+ a.get_submenu("B").add_menu("S1")
+ self.assertEqual(
+ a.get_nested_submenu(["B", "S1"]).name,
+ list(a.get_submenu("B").submenus.values())[-1].name
+ )
+
+ def test_get_path(self):
+ a.add_menu("P1")
+ a.get_submenu("P1").add_menu("P2")
+ a.get_nested_submenu(["P1","P2"]).add_menu("P3")
+ self.assertEqual(
+ a.get_nested_submenu(["P1", "P2", "P3"]).get_path(),
+ ["main","P1", "P2"]
+ )
+
+ def test_get_all_submenus(self):
+ a.add_menu("B")
+ a.get_submenu("B").add_menu("C")
+ self.assertEqual(
+ [i.name for i in a.get_all_submenus()],
+ ["A", "B", "C"]
+ )
+
+
+def test_function():
+ pass
+
+a = Menu("main")
+
+if __name__ == "__main__":
+ unittest.main()
\ No newline at end of file
diff --git a/tests/op_test_files/export-29-06-2023-T-11-55-49.xls b/tests/op_test_files/export-29-06-2023-T-11-55-49.xls
new file mode 100644
index 0000000..33668ff
Binary files /dev/null and b/tests/op_test_files/export-29-06-2023-T-11-55-49.xls differ
diff --git a/tests/op_test_files/source-TSH/Example-timesheet-01.xlsx b/tests/op_test_files/source-TSH/Example-timesheet-01.xlsx
new file mode 100644
index 0000000..93994cc
Binary files /dev/null and b/tests/op_test_files/source-TSH/Example-timesheet-01.xlsx differ
diff --git a/tests/op_test_files/source-TSH/Example-timesheet-02.xlsx b/tests/op_test_files/source-TSH/Example-timesheet-02.xlsx
new file mode 100644
index 0000000..e487e6b
Binary files /dev/null and b/tests/op_test_files/source-TSH/Example-timesheet-02.xlsx differ
+
+## Overview
+
+C5-DEC is aimed at assisting both system/software designers/developers as well as system security analysts with creating and evaluating secure software systems. C5-DEC CAD can be used by evaluation laboratories for the execution of impartial assessments of the security of computer systems and software according to the Common Criteria (CC), a set of internationally recognized standards (ISO/IEC 15408), and the complementary ISO/IEC 18045, dealing with a common methodology for computer security evaluation (CEM). CC certification gives users the assurance that a product satisfies the security guarantees and properties it claims to possess. Among other things, C5-DEC is also aimed at providing tools for supporting a secure software development life cycle (SSDLC).
+
+C5-DEC consists of two key elements: a software component (C5-DEC CAD) and a knowledge base including guides and a wiki of key CC concepts. These elements complement each other to form a coherent set of tools aimed at supporting activities related to CC certification, SSDLC and security assessment of cyber-physical systems, based on the C5-DEC method for Cyber-Physical System Security Assessment (CPSSA).
+
+## Features
+
+- Free/libre and open source
+- Cross platform: works on GNU/Linux, MacOS and Windows
+- Easily and highly extensible due to a modular design and architecture
+- Advanced and extensible textual user interface (TUI), powered by the open-source [asciimatics](https://github.com/peterbrittain/asciimatics) framework
+- A command-line interface (CLI) for more efficient user interactions and scripting
+- Comprehensive [Common Criteria](https://www.commoncriteriaportal.org/index.cfm) Toolbox (CCT), with a focus on efficient browsing of the CC database, creating and processing evaluation checlists
+ - includes all baseline CC Security Functional Requirements (SFR) and Security Assurance Requirements (SAR)
+ - built-in capabilities for assisting the process of generating technical evaluationr reports (ETR)
+ - comes with a CC wiki capturing the key concepts of Common Criteria
+- Tools for enhancing secure software development life cycle (SSDLC), powered by the open-source [Doorstop](https://github.com/doorstop-dev/doorstop) tool
+- Complete integration of the CCT data store with the Doorstop data model and formats
+- Based on and designed around open data formats such as Markdown, (La)TeX, YAML, XML, JSON, CSV, HTML, txt, etc.
+- Straightforward integration into well-known Dev(Sec)Ops platforms such as GitHub and GitLab
+- Project (resource) management functionality
+- Import/export from and to open data formats
+- Cryptography-related functionality aimed at improving SSDLC (currently not implemented, but on the roadmap and planned for [future releases](./docs/manual/cryptography.md))
+- A method for Cyber-Physical System Security Assessment (CPSSA) and related functionality (see [CPSSA](./docs/manual/cpssa.md))
+
+## User manual
+
+Check the [CAD user manual](./docs/manual/overview.md) to learn more about the specific modules of C5-DEC CAD and its usage. The table of contents is also shown below:
+
+- [Installation](./docs/manual/installation.md)
+- [Setup](./docs/manual/setup.md)
+- [Quick start](./docs/manual/start.md)
+- [CCT: Common Criteria Toolbox](./docs/manual/cct.md)
+- [SSDLC: secure software development life cycle](./docs/manual/ssdlc.md)
+- [Cryptography](./docs/manual/cryptography.md)
+- [CPSSA: Cyber-Physical System Security Assessment](./docs/manual/cpssa.md)
+- [Transformer: import, export, publish](./docs/manual/transformer.md)
+- [ISMS: document management](./docs/manual/isms.md)
+- [PM: project (resource) management](./docs/manual/pm.md)
+- [C5-DEC Common Criteria wiki](./c5dec/assets/database/KnowledgeBase/0_MapofContent.md)
+
+## Getting Started
+
+C5-DEC CAD can be deployed using any of the following methods:
+
+- Installation via [pipx](https://pypa.github.io/pipx/) using the official [distribution file]() (recommended for end-users)
+- Installation in a containerized environment (recommended for developers)
+- Install via the official PyPI repository (**currently not available, coming soon**)
+
+### Installing C5-DEC CAD via pipx
+
+#### Requirements
+
+- [Python 3](https://www.python.org/)
+- [git](https://git-scm.com/), the distributed version control system
+
+##### Optional
+
+- [Doorstop](https://github.com/doorstop-dev/doorstop) (recommended to install via `pipx`)
+
+Strictly speaking, a Doorstop installation is not required; nevertheless, we strongly recommend installing Doorstop such that it can be used in combination with C5-DEC CAD. This is mainly due to the fact that the SSDLC module in the current implementation of C5-DEC CAD does not provide a full coverage of the Doorstop API, which is why users may find it easier to carry out certain complementary operations using Doorstop.
+
+To install Doorstop, we recommend the following method using [pipx](https://pypa.github.io/pipx/) as it is rather straightforward. On a GNU/Linux distribution or MacOS, open a terminal (e.g., bash, Zsh) and execute the following commands:
+
+1. Install pipx if not already installed
+```sh
+python3 -m pip install --user pipx
+python3 -m pipx ensurepath
+```
+
+2. Once `pipx` is installed, run the following command:
+```sh
+$ pipx install doorstop==3.0b10
+```
+
+#### Installation
+
+Run the following command, assuming that the Wheel distribution file (.whl) is placed in the current directory and pipx is installed (see instructions above):
+
+```sh
+pipx install ./c5dec-0.1-py3-none-any.whl
+```
+
+#### Launching C5-DEC CAD
+
+You can start C5-DEC CAD by simply entering “c5dec” in an open terminal, with the current directory being an unpacked copy of the C5-DEC CAD [project folder](). For the sake of this example, we assume that the zip archive is unpacked at the following path `/home/user/c5dec-cad-alpha`; it then suffices to change to this directory and run `c5dec`:
+
+```sh
+$ cd /home/user/c5dec-cad-alpha
+$ c5dec
+```
+This would then launch the TUI by default, as shown below.
+
+
+
+For more details and installing on Windows, see the [Installation](./docs/manual/installation.md) page of the user manual.
+
+### Installation in a containerized environment
+
+The easiest and recommended way to get a local copy of the development environment up and running is described next.
+
+#### Requirements
+
+The following pieces of software are necessary for setting up the C5-DEC CAD containerized environment.
+
+* A local installation of [Docker Desktop](https://www.docker.com/products/docker-desktop/)
+* [Visual Studio Code](https://code.visualstudio.com/) (VS Code)
+* The [Dev Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension for VS Code by Microsoft
+
+#### Installation
+
+1. Clone this repository
+```sh
+git clone http://gitlab.abstractionslab.com/cyfort/c5-dec/cad.git
+```
+2. Verify that your Docker Desktop instance is running (if not, start it).
+3. In VS Code, open the folder "cad", located at the root of the cloned project. This can be done directly in VS code or from the terminal, if the CLI of VS Code is installed:
+```sh
+code cad
+```
+4. In the notification that pops up in VS Code, select the option "Reopen in Container". This will create and run the project inside a Docker container; alternatively, the same command can be selected and invoked from the VS Code command palette.
+4. Open a terminal in VS Code and run the following command in the GNU/Linux container for which the local file system is automatically mapped by VS Code to that of the Ubuntu container:
+```sh
+poetry install
+```
+This verifies the correct installation of all the dependencies.
+
+_**Hint:**_ to solve warnings in the code related to missing imports, select the Python interpreter installed by poetry. This can be done quickly by clicking on the light bulb that appears next to the warnings.
+
+## Usage
+
+The C5-DEC CAD tool has two modes of operation: a textual user interface (TUI) and a command line interface (CLI).
+
+### Textual User Interface
+
+Once installed, the C5-DEC CAD tool can be launched from the VS Code terminal as follows:
+
+```sh
+$ cd c5dec
+$ poetry run c5dec
+```
+
+Alternatively, the tool can be executed from Docker Desktop:
+
+1. In the left-side menu, go to the tab "Containers".
+2. Open the container associated to C5-DEC CAD (the image name starts with "vsc-cad").
+3. Go to the "Exec" tab.
+4. Run the same commands as above.
+
+### Command Line Interface
+In a VS Code (or Docker Desktop) terminal run:
+
+```sh
+$ cd c5dec
+$ poetry run c5dec